Page MenuHomePhabricator

efl.ui.widget
Closed, ResolvedPublic

Description

abstract Efl.Ui.Widget
├ (P) cursor @beta
├ (P) cursor_style @beta
├ (P) cursor_theme_search_enabled @beta
├ (P) resize_object :: set@protected
├ (P) disabled
├ (P) style :: set@protected
├ (P) focus_allow
├ (P) widget_parent :: set@protected
├ (P) access_info @beta
├ (P) interest_region
├ (P) focus_highlight_geometry
├ (P) focus_move_policy @beta
├ (P) focus_move_policy_automatic @beta
├ (M) widget_input_event_handler :: @protected
├ (M) on_access_activate :: @protected @beta
├ (M) on_access_update :: @protected @beta
├ (M) widget_sub_object_add :: @protected
├ (M) widget_sub_object_del :: @protected
├ (M) theme_apply :: @protected
├ (M) scroll_hold_push @beta
├ (M) scroll_hold_pop @beta
├ (M) scroll_freeze_push @beta
├ (M) scroll_freeze_pop @beta
├ (M) focus_state_apply :: @protected
├ (E) language,changed
├ (E) access,changed @beta

non-beta:

abstract Efl.Ui.Widget
├ (P) resize_object :: set@protected
├ (P) disabled
├ (P) style :: set@protected
├ (P) focus_allow
├ (P) widget_parent :: set@protected
├ (P) interest_region
├ (P) focus_highlight_geometry
├ (M) widget_input_event_handler :: @protected
├ (M) widget_sub_object_add :: @protected
├ (M) widget_sub_object_del :: @protected
├ (M) theme_apply :: @protected
├ (M) focus_state_apply :: @protected
├ (E) language,changed
zmike created this task.Jan 8 2019, 11:27 AM
zmike triaged this task as TODO priority.

Parent is regular but should be abstract

woohyun updated the task description. (Show Details)Jan 8 2019, 10:06 PM
woohyun updated the task description. (Show Details)Jan 8 2019, 10:09 PM
woohyun updated the task description. (Show Details)Jan 8 2019, 10:11 PM

I've added @protected and @beta in the description for better understanding.

zmike added a comment.Jan 9 2019, 6:01 AM

I've added @protected and @beta in the description for better understanding.

Thanks for this, I've updated the script (P258) to output these tags.

Why does this have a moved event?

Most likely legacy, I would say. If it is a legacy event, you have to keep generating it, but not necessarily as an eo event.

I cannot find any trace about "moved" event. Somebody knows about this ?

./src/bin/elementary/test_gengrid.c:    evas_object_smart_callback_add(grid, "moved", grid_moved, NULL);

I guess this is the place where such things are used... :(

YOhoho added a subscriber: YOhoho.EditedFeb 22 2019, 2:01 AM

I cannot find any trace about "moved" event. Somebody knows about this ?

I guess this is mistake on 7c4411630c063746285161072ecee8bd0db46665.
see, elm_gengrid.c:1067 and elm_widget.eo:840.
moved should have been defined in elm_gengrid.eo.

@bu5hm4n @YOhoho
Thank you,
and I made D8005 because both of your comments looked correct :)

bu5hm4n added a comment.EditedFeb 23 2019, 12:41 PM

Comments regarding this class:

  • X orientation: it appears that the only entity that is actaully setting is the window implementation. There is no user of the on_* method. To me it looks like the efl_ui_win.c implementation could just go and walk the widget tree, and emit events on the layouts that dont orientation_mode_set set to DISABLE.
  • focus_highlight_{animate, style, enabled}: They should be moved to the Efl.Ui.Win, as the comments in the .eo file state
  • X focused_item: this should go, there are no items in the new API.
  • show_region: interest_region: This should be merged into one concept, and in the API this should only be the getter of one single rectable IMO (pos relative to the widget)
  • X on_disabled: Should be disabled,changed event.
  • scroll_*: Not sure what it does here ...
  • theme_apply: what it tells to do makes sense. However, it syncs up mirrored states o_O.

In general:
I think the children API of this class is a little bit clumsy and feels weird, we should IMO find a different solution here. However, i think we will need more time for this, which means this should be beta and stay beta

(things with a "X" are in revision)

@zmike

Could you please mark @beta for scroll methods?
As @bu5hm4n said, it may be not the right place for these methods..
I think that @eagleeye will check if it is possible to move these methods out of Efl.Ui.Widget. (T7714)

├ (M) scroll_hold_push
├ (M) scroll_hold_pop
├ (M) scroll_freeze_push
├ (M) scroll_freeze_pop

Totally agreed.

bu5hm4n updated the task description. (Show Details)Feb 28 2019, 4:24 AM
zmike updated the task description. (Show Details)Feb 28 2019, 5:53 AM
zmike updated the task description. (Show Details)Feb 28 2019, 6:42 AM
zmike moved this task from Backlog to Evaluating on the efl: api board.Feb 28 2019, 9:32 AM
zmike updated the task description. (Show Details)Feb 28 2019, 9:34 AM
bu5hm4n added a comment.EditedFeb 28 2019, 9:47 AM

widget_top is questionable to me, could also be just efl_provider_find(asdf, EFL_UI_WIN);

The rest looks just fine to me tbh :)

widget_top gone

zmike added a comment.EditedMar 1 2019, 7:52 AM

I think we should mark all the cursor apis as beta for now; these seem very X11-specific (e.g., Wayland has no cursor "name" property, you just send render buffers to the compositor) and we may want to change it later.

access_info (and the related event) seems suspicious considering we aren't stabilizing access at all, so this should be beta.

widget_event should probably be renamed to widget_input_event ? Otherwise this seems pretty vague.

focus_state_apply should possibly be renamed to focus_state_register (?)

woohyun added a subscriber: stanluk.Mar 4 2019, 3:30 AM
In T7553#131982, @zmike wrote:

I think we should mark all the cursor apis as beta for now; these seem very X11-specific (e.g., Wayland has no cursor "name" property, you just send render buffers to the compositor) and we may want to change it later.

I also agree with this opinion. We can find a better way to get along with wayland.

access_info (and the related event) seems suspicious considering we aren't stabilizing access at all, so this should be beta.

I think @Jaehyun_Cho and @stanluk can give an answer on this.

widget_event should probably be renamed to widget_input_event ? Otherwise this seems pretty vague.

I agree on this. It's currently used for supporting widget's "input event" and I think it will be the same in the future.

focus_state_apply should possibly be renamed to focus_state_register (?)

@bu5hm4n can give a clear answer on this :)

access_info (and the related event) seems suspicious considering we aren't stabilizing access at all, so this should be beta.

I think @Jaehyun_Cho and @stanluk can give an answer on this.

this property and event are not planned to be a part of final access interface, so it could be removed.

zmike updated the task description. (Show Details)Mar 5 2019, 3:57 AM

I am reworking the documentation of focus_state_apply, so it does not tell register anymore. It should IMO not change its name.

After working with @bu5hm4n on the focus_state_apply docs, I think the name is fitting. I would not change it.

zmike moved this task from Evaluating to Stabilized on the efl: api board.Mar 8 2019, 7:32 AM
zmike closed subtask T7570: efl.part as Resolved.Mar 11 2019, 10:47 AM
zmike closed subtask T7554: efl.canvas.group as Resolved.
zmike closed this task as Resolved.Mar 11 2019, 10:49 AM
zmike claimed this task.