Parent is regular but should be abstract

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

In T7553#128415, @woohyun wrote:

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... :(

In T7553#131574, @woohyun wrote:

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 :)

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)

Totally agreed.

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

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 (?)

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.

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.