- User Since
- Jul 24 2013, 3:26 AM (311 w, 5 d)
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)
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.
Fri, Jul 12
yes, not to free eo before C# instance is destructed.
Thu, Jul 11
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?
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?
Wed, Jul 10
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.
Tue, Jul 9
Fri, Jun 28
Thank you :)
Thu, Jun 27
Wed, Jun 26
In the event where e.g., someone calls edje_object_message_signal_process from within the event callback, however, this method would not work.
Tue, Jun 25
Could you review this patch?
Thank you very much!! :)
Mon, Jun 24
Do you mean something like this? (Instead of ownership, I used efl_input_processed)
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.
Thu, Jun 20
Wed, Jun 19
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.
Could you tell me where I need to add efl_input_processed_set for efl_ui_active_view_view_manager_scroll.c?
Thank you for checking this issue!
Tue, Jun 18
One more thing here ;)
I am sorry for saying this now.
Mon, Jun 17
Sun, Jun 16
Jun 13 2019
There are 2 things I want to comment related to the Radio_Group and Radio_Box.
Jun 12 2019
After thinking about this patch and Radio widget for a while, I thought that
"how about providing Efl.Ui.Radio_Group class?" (not interface)
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~
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#)
Jun 11 2019
Jun 10 2019
sorry, I missed the comments.. :(
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?
Jun 7 2019
I have thought about APIs for push/pop and I think that the following 3 methods are sufficient for our push/pop usecase.
Jun 6 2019
Jun 5 2019
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 ;(
Jun 4 2019
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.
May 30 2019
I see~ Thank you :)
May 29 2019
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)