@lauromoura
As I mentioned in D10001, some words are used as verb in some method names and they are used as noun in other method names.
To resolve this problem, we may need to introduce a new eo syntax.

add ref T8225

Fixed not to keep array and rebased

fixing memory leak in efl_ui_widget_factory.c is included

rename the error name

update indentation

@lauromoura
I cannot find a proper way to install Efl.Csharp.1.23.0.nupkg on Visual Studio Code on Ubuntu.
But that .nupkg can be installed Visual Studio on Windows.

Thank you. This patch wisely removes the redundant event callbacks. I think it's nice :)

@lauromoura
After applying this patch, it seems that efl_sharp.dll is not installed.
efl_sharp.dll is created in efl/core/efl/build/src/bindings/mono/efl_sharp.dll but it is not installed in /usr/local/...

The declarations of evas_object_callback_init() and evas_object_callback_shutdown() in evas_private.h are required to be removed.

Thank you~

One minor thing.

I've left some comments based on the test result of "Navigation stack" in elementary test.

@lauromoura
It is confirmed that SA1402 is not mandatory but it is recommended.

@lauromoura
I will ask the reporter who raised this issue in detail and I will let you know.

Honestly, I dont have enough knowledge about canvas object's event so I cannot judge your idea.. :(
As you said we should ask canvas people about it.

Hello~
@YOhoho and I found an issue related to this patch.

This may be hard with meson. See my first comment on its limitations.

I totally understand. If it is hard on upstream with meson, then I consider that I run some script manually to generate directories and change the cs names only for Tizen.

@segfaultxavi
The main issues of this task are as follows.

Thank you for this patch! :)

Sorry I missed D9692, I've reverted ac99e2ac9410d5b2ef6225fa1aaaf9ffcd6578fb

For now, I've removed the underscore of Evt_Args by ac99e2ac9410d5b2ef6225fa1aaaf9ffcd6578fb

As we discussed, this patch is basically additional manual binding specific for being able to associate native object to an eo object.

I don't know well about the original purpose of T7383 but the related tasks are mainly about how to support config set easily in EFL#.

Sorry about replying late.. ;)

Can we change this task name?

@lauromoura
Could you please consider this task?

I have the same opinions with @SanghyeonLee for 1, 2, 3.

It seems that this task is related to T8057.

No, there is no information about the initial time interval.
So I think there is no problem of applying 0.25 second here :)

@YOhoho Thank you very much for your comment! :) I did not know that. I also updated the commit message as well. When I modified time interval from 0.5 to 0.25, I think that repeated counter is calculated fine for double click and triple click.

@segfaultxavi Thank you very much! :) Your clear explanation helped me to fully understand this feature. I made D9485 to increase the time interval. I adopted your explanation~ :)

In T7976#139313, @segfaultxavi wrote:

Is there a use case that developers use the value "repeated"?

There are some apps which use triple-clicking (like selecting a word with double-click, and a whole paragraph with triple-click).

Is there a use case that developers use the value "repeated"?

thank you :)

@bu5hm4n I haven't started yet. It's ok if you go with this :) Are you thinking of implementing all (Selectable for item + Selectable for container) ?

@bu5hm4n I agree with this patch~ If you also agree with this patch, then I will submit this patch~ :)

I restored the code that initially creates and packs pages in stack example.
I also fixed the code of future_then_cb to check eina_value correctly in stack example.

@bu5hm4n Thank you very much for the comment! It corrects this patch clearly and easily :)
BTW, I return efl_loop_future_resolved although the content is deleted. It seems that other content deleted case returns future with NULL Eina_Value.

There is one thing related to this patch.

yes right~

@bu5hm4n Thank you for the comment :) I added the condition to check if mouse move is active.

Added commit message related task T8040

I totally agree with you creating a ticket to discuss general things and concepts.

Like D9304, this patch is to keep @owned mark for Eo handle.
I think we need to discuss if it is appropriate that we allow @owned for Eo handle to pass ownership from caller to callee.

• Eo handle cannot be exclusively possessed

I don't know how important of using integer values instead of continuous indices for Radio_Buttons.

I think that the use case you mentioned is so special and specific case.
IMO, most of the cases, it appears that user feels no difficulties when they use continuous numbers for Radio_Buttons.

I understand the convenience of state_value.

About state_value of Efl.Ui.Radio_Button, I would like to let's think if we really need this property.

If you say we need interface because SingleSelectable interface does not have (P) selected_object, then we can add it to Single_Selectable interface, right?

Since register() and unregister() is not required to be called by user with radio group container and all the selected methods are provided in SingleSelectable interface, it would be the same.
User calls select(), unselect(), and other selected methods which may not be written by me in the proposal.

If Radio_Group becomes a class based on the proposal, your design to turn any container into radio group container works.

I created https://phab.enlightenment.org/T8057 for refactoring interface Efl.Ui.Selectable.

In T8025#138414, @segfaultxavi wrote:

However, I wanted to say that avoiding name collisions between `Efl.Ui.Button` and `Efl.Ui.Radio.Button` is not a good argument. We already have multiple collisions with the `Object` name. In C#, when you start `using` multiple namespaces you know you will have collisions, and it will be your fault!

In T8025#138411, @zmike wrote:

In T8025#138408, @Jaehyun_Cho wrote:

Because both Check and Radio_Button change their state to "selected" if "clicked" event happens.
But unlike Check, Radio keeps its state as "selected" if "clicked" event happens on its "selected" state. (Check changes its state to "unselected" in the same case)

I'm not sure I understand this point?

Conceptually, when a button is "clicked", it enters the "pressed" state and then immediately returns to the "unpressed" state. At no point does a button remain "pressed" or, as you call it, "selected".

When a check or a radio is "clicked", it enters the "selected" state. It does not leave this state unless another click occurs. While it's true that clicking the same check again has a different effect than re-selecting a radio, typically you would consider the entire radio group as a single widget; one radio by itself is not very useful.

I left a comment on efl_ownable in D9304.

In D9304#172204, @bu5hm4n wrote:

I agree that there should be a error preventing you from doing something that is not good. I will add a helper to eo, which makes it easy to use, (or maybe can be added completly by eolian). However, such a helper will only contain a error, and never change the state or reference things of a object. Its IMO bad if we have code that just alters the references and parents to *prepare* something for you, there is one case where it might be right, others where it might be wrong. But overall the API user should have the overview (and a error if he does wrong things).

I agree with you that we should avoid manipulation of user's object as far as possible

After thinking about ownership a while, somehow I understand your opinion about ownership.
(If I understand you correctly, you think that user should understand ownership and user should do the right thing for ownership)

Related to the Radio_Button, what do you think about Efl.Ui.Check inherits from Efl.Ui.Button?

@segfaultxavi
Thank you for suggestion! :)

The following is my initial comment in T7867 of this comment threads.. ;)

In T7867#138325, @segfaultxavi wrote:

In T7867#138317, @Jaehyun_Cho wrote:

Related to radio, we need to support setting radio into other containers. (e.g. Efl.Ui.List)

This is exactly the reason why @bu5hm4n separated Efl.Ui.Radio_Group into an interface and an implementation class. This separation allows attaching the Efl.Ui.Radio_Group_Impl implementation to any widget, turning the widget into a radio group manager.
This is currently in use in the Efl.Ui.Radio_Box widget, making it very easy to implement and to use.
I think you should do the same thing to include radio buttons inside a list: Create an Efl.Ui.Radio_List widget, that behaves like Efl.Ui.Radio_Box.

Honestly, I think that developers don't know why they should not use efl_add for spotlight manager.
Although they read description of the manager_set() and @owned, they still don't know why efl_add is not allowed.