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.

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

This patch looks good to me (without dependent patches D9304, D9305)

It seems that developer should use efl_new for spotlight manager by this patch.
When efl_add is used for spotlight manager, then it becomes broken with this patch.

In D9300#171566, @bu5hm4n wrote:

Okay, please, take a step back and reevaluate this. If you chain the unref with the unrefing of the previous ref (which this here is doing), then those two references are basically *one* reference. There is no way that the reference that was taken by C# can overlife the other reference taken by anyone else. Which effectively means, you can just remove the initial reference that C# took on this object. So this patch here makes the reftaking of C# completly useless, in the case that this here is resulting in correct behaviour for you in C#, then please remove the efl_ref that is in C#.

In D9300#171564, @bu5hm4n wrote:

Can you tell me if i am understanding you currently:

• When a eo object is created from C# or C and it is used in C#, the wrapper will get a reference on it?

yes, not to free eo before C# instance is destructed.

I think I misunderstood the purpose and the meaning of the name.
Now I see the name would be ok :)
Thank you @segfaultxavi @bu5hm4n

Actually I don't mind the name Efl.Input.Event. It's ok but the reason why I suggested is to change the name "Efl.Input.Interface".

What do you think about changing the name of this interface as follows?

@bu5hm4n
Can we leave this under beta for now? (if value and value_has in Efl.Input.Pointer remains under beta for now(T7963))

@bu5hm4n
I totally agree with you about value and value_has..

It seems that @property is_pointer_type supports get() only.
Then how about changing it to a method? is_pointer_type?

What is the difference between efl_input_processed_set/get and efl_input_hold_set/get?
Are they duplicated?

Ok. Now I just know about those 2 functions. I will ask developers if there are more requirements related to scroll features for ManagerScroll.

There are some demands to use scroll functions (e.g. scroll_hold, scroll_freeze) for Efl.Ui.Active_View.View_Manager_Scroll.
To do that, it seems that Efl.Ui.Active_View.View_Manager_Scroll uses or inherits/implements Efl.Ui.Scroller or Elm.Interface_Scrollable.

Thank you :)

In T8019#137815, @zmike wrote:

I'm not sure I see how setting the event to be processed in the 'move' callback would affect the 'up' callback? Can you explain your thinking here?

@zmike

In the event where e.g., someone calls edje_object_message_signal_process from within the event callback, however, this method would not work.

Could you review this patch?

@lauromoura
Thank you very much!! :)

Do you mean something like this? (Instead of ownership, I used efl_input_processed)
https://git.enlightenment.org/core/efl.git/commit/?h=devs/jaehyun/efl_clickable_test3&id=699a1c2e705d1dccd8b8cfee1834a9280de929c5

Yes, since Efl.Ui.Alert_Popup simply adds its buttons and button clicked event to Efl.Ui.Popup, extending Efl.Ui.Popup is enough for developer who needs a more flexible popup.

Thank you for the suggestion.
I want to fully understand your idea so I have some questions about the ownership steps.

This patch is required to support enum type to event info. (related to comments on T7948)

Thank you for the opinion.
I agree with you about event info. Regardless of the original intention (why event info is structure), it seems that no new information is required for alert popup's button clicked event.

I discussed this topic with @woohyun and @Hermet

Thank you for suggesting an idea.
I think that your idea can resolve this issue but a solution which does not add new feature would be better.

This issue is related to widget which uses Efl.Ui.Clickable_Util.

Yes, the button should be pressed and unpressed but clicked event should not happen.

The reproduction case is as follows in the description.

@bu5hm4n
Could you tell me where I need to add efl_input_processed_set for efl_ui_active_view_view_manager_scroll.c?

@eagleeye
Thank you for checking this issue!

In D8920#167501, @bu5hm4n wrote:

I am totally in favor of discussing that, and get feedback, but you are right now suggesting that i am going back to solution 1, which was considered *confusing*. Additionally, i feel like you do not have any example or usage for *not* having push or pop, this means every single time you want to know when the animation is finished you have to subscribe to the event, and unsubscribe from the event when it got called, which is an enormous code overhead, so if you showcase the solution of *do it yourself*, people will find it confusing as you do have to do two calls instead of pop, and a lot more in case of push.

I am strongly in favor of adding this *now* as beta API, if sample applications do like how this is API is done, then they will use it, and we can unbeta it. If not, we can still remove it again. And not include it at all. Does that sound like a plan ?

In D8920#167475, @bu5hm4n wrote:

Okay, we have had now 3 different approaches, and every single approach implemented 2 times.I seriously do not buy that this is confusing, where or why is it confusing? it is a dead simple push and pop that inserts things just like in a normal addressable stack data struct. What exactly is the reason ? where it is confusing ?

We are turning here in circles again and again and again. And each time the current implementation is confusing. Maybe we should reach a point where we say "get used to it" and continue with this ? I honestly have to say, every single time such a argument as "this is confusing" is done i am more and more loosing trust in the feedback i am getting here... Why should i now for example implement pack() like pack_end(), it may be considered confusing tomorrow ... and the progress is 0.

One more thing here ;)

I am sorry for saying this now.

@segfaultxavi @bu5hm4n
Thank you for the opinion :) It helped me to understand new developers better~ :)

In D8920#167362, @bu5hm4n wrote:

@Jaehyun_Cho Can you answer if you are happy with pop / push ?

@bu5hm4n
There are 2 things I want to comment related to the Radio_Group and Radio_Box.

After thinking about this patch and Radio widget for a while, I thought that
"how about providing Efl.Ui.Radio_Group class?" (not interface)

@felipealmeida @vitor.sousa
I think this patch is correct and should be submitted.
What do you think? Do you agree with this patch?

@bu5hm4n
I see~ You are right we have time to change before release (although it might not be that long! :( ) Thank you :)
Just a rebase is needed to push this~

@bu5hm4n
Basically, I agree with you. I think that the returned future is good.
However, I am concerning if it is available to use EINA_VALUE_TYPE_OBJECT in EFL C# before we release EFL C# bindings publicly.
If the future is returned by active_view_unpack(), then developers want to know what is the eina_value in their eina_future_then callback. (now the Eina_Value argument cannot be used as an object in C#)

sorry, I missed the comments.. :(

In T8012#137174, @bu5hm4n wrote:

From eolian side, there is already this syntax:

@property allow_parent_unref @beta {
         [[... ]]
         values {
            allow: bool(false); [[...]]
         }
      }

Which is copied from efl_object.eo

Thank you for the implementation! :)
I haven't used future on C# bindings so I think I need to check it on C# as well.

Could you tell me your opinion on this task?

I have thought about APIs for push/pop and I think that the following 3 methods are sufficient for our push/pop usecase.

In D8920#166470, @bu5hm4n wrote:

What is active_view_pack / active_view_unpack doing ?

This is resolved by D9033

To support push/pop, I write specification for push and pop.
(The names, push and pop, can be changed)

I tested it and I found a problem.
As you know, unpack does not delete the content so the content should be deleted by developer manually.
Therefore, it becomes the same as developer registers callback for transition finish and delete the content manually ;(

I thought more about your suggestion about fix.

As you mentioned, we have animation issues on pop with only using gravity. Because the unpacked view cannot be in the pop animation.

In D8784#166080, @bu5hm4n wrote:

Good Catch,

With this done, i have submitted https://travis-ci.org/Enlightenment/efl/branches. When this build succeeded, i will land the 3 accepted revisions, okay ?

Thank you :)

I see~ Thank you :)

I've found out that the different scroll transition happens because efl_ui_active_view_active_index_set is called twice.
This causes efl_ui_active_view_active_index_set called with the same index value again.
e.g. if now active view: 0, new active view: 2, active view becomes from 0 to 2 and from 2 to 2.

Thank you! :)

Thank you! :)

I applied the latest D8784 and I tested again.

It seems that the scroll transition issue happens because the same active index is set again.

I tested the tab pager example but I found some weird scroll transition when I drag the views.
(selecting tab is ok but if I drag view with scroll transition, then the scroll transition look weird)

Please delete callbacks in invalidate.
(This can be tested on D8906)