This is the class hierarchy required for Efl.Ui.Layout. In other words, all these classes need to be stable for Efl.Ui.Layout to have any chance of being stable:

$ elua print_hierarchy.lua efl_ui_layout.eo
class Efl.Ui.Layout
| abstract Efl.Ui.Widget
| | class Efl.Canvas.Group
| | | abstract Efl.Canvas.Object
| | | | class Efl.Loop_Consumer
| | | | | abstract Efl.Object
| | | | interface Efl.Gfx.Entity
| | | | mixin Efl.Gfx.Color
| | | | interface Efl.Gfx.Stack
| | | | interface Efl.Animator
| | | | interface Efl.Input.Interface
| | | | interface Efl.Gfx.Size_Hint
| | | | mixin Efl.Gfx.Map
| | | | | interface Efl.Interface
| | | | | abstract Efl.Object
| | | | interface Efl.Ui.Base
| | | | interface Efl.Canvas.Pointer
| | mixin Efl.Access.Object
| | | interface Efl.Interface
| | | abstract Efl.Object
| | mixin Efl.Access.Component
| | | interface Efl.Gfx.Entity
| | | interface Efl.Gfx.Stack
| | interface Efl.Part
| | mixin Efl.Ui.Focus.Object
| | interface Efl.Ui.Cursor
| | interface Efl.Ui.Translatable
| | mixin Efl.Selection
| | mixin Efl.Ui.Dnd
| interface Efl.Container
| mixin Efl.File
| interface Efl.Ui.View
| interface Efl.Ui.Model.Connect
| interface Efl.Ui.Factory
| | interface Efl.Ui.Model.Connect
| interface Efl.Layout.Calc
| interface Efl.Layout.Signal
| interface Efl.Layout.Group

Note many classes are repeated, and many classes are actually acting as interfaces (due to the infamous mixin conundrum).

After a first pass, this are the problem I can see (Please do your own review as I may have missed things):

• Efl.Layout.Signal -> expose Edje callback function that can't be managed by binding. Need to think on how to handle this. Maybe just do that class manually.
• Efl.Selection -> Efl.Ui.Selection : I think the name should be in the Ui namespace.
• Efl.Ui.Base: I think we should rename this one as it is mostly internationalization parameters actually.

@segfaultxavi

Could you share print_hierarchy.lua? :)

https://pastebin.com/AsfEdLxa :)

You need to execute it with elua, and you need to have the luajit bindings installed.

Let's make it official: P251 :)
The original author is @q66, btw.

Uploaded a few patch, I also went by and renamed Efl.Ui.Translatable to Efl.Ui.L10n if we are to use Efl.Ui.I18n for the internationalization. Not to sure of all of those naming.

I've sorted and deduplicated the list:

		Efl.Access.Component
		Efl.Access.Object
		Efl.Animator
		Efl.Canvas.Group
		Efl.Canvas.Object
		Efl.Canvas.Pointer
		Efl.Container
		Efl.File
		Efl.Gfx.Color
		Efl.Gfx.Entity
		Efl.Gfx.Map
		Efl.Gfx.Size_Hint
		Efl.Gfx.Stack
		Efl.Input.Interface
		Efl.Interface
		Efl.Layout.Calc
		Efl.Layout.Group
		Efl.Layout.Signal
		Efl.Loop_Consumer
		Efl.Object
		Efl.Part
		Efl.Selection
		Efl.Ui.Base
		Efl.Ui.Cursor
		Efl.Ui.Dnd
		Efl.Ui.Factory
		Efl.Ui.Focus.Object
		Efl.Ui.Layout
		Efl.Ui.Model.Connect
		Efl.Ui.Translatable
		Efl.Ui.View
		Efl.Ui.Widget

Let's continue discussing these items here and ignore them in T7511. I'll post a complementary list in that ticket.

Some of above classes include lots of definitions it them.
For instance, "Efl.Ui.Widget" and "Efl.Canvas.Object".

What would be the best way to check how stable they are ?

What I can think for now is that -

1. marking beta to unstable methods (or properties)
2. modifying improper names (of classes, methods, or properties)
3. making as many test cases as we can -> I don't think this is not something we can perfectly in a short term
4. ???

I'm checking "Efl.Access.Component", "Efl.Access.Object", and "Efl.Ui.Widget" now - but I want to get the idea how this work should be processed

@bu5hm4n @segfaultxavi

Thank you for sharing the lua code :)

In T7512#127753, @woohyun wrote:

What I can think for now is that -

To be honest, I would say a bit of all of that, depends of the context, but I would be fine if you decide to mark some API beta, some get their naming changed and some get a test case to validate them.

1. marking beta to unstable methods (or properties)
2. modifying improper names (of classes, methods, or properties)
3. making as many test cases as we can -> I don't think this is not something we can perfectly in a short term
4. ???

4. Improve documentation if it makes no sense. Maybe an angle that @segfaultxavi can help with.

Sure, I'll take care of all documentation needs.
Also, I think this task needs somebody to lead it, or I am afraid it will be forgotten.

I've done further modifications to the script (P258) to provide all necessary info for these tickets.

P257 for full output.

I've created subtasks for the entire hierarchy. The only things which should be discussed in this ticket are things directly related to layout:

class Efl.Ui.Layout
├ (P) theme
├ (E) theme,changed

Its questionable to me why the theme property has a attribute called style, since we have style on the widget, why not just use this one ?

theme property

Considering it a bit more, theme is pretty contrived here: this is only for legacy objects and adds (imo) unnecessary complexity. The theme groups for interfaces-based widgets are all named like efl/$widgetname (and occasionally efl/$widgetname/$subobject). There is no need for base, as this is no longer a common case in interfaces-based widgets: for the occasion when it is used, it's trivial enough to just pass the full $widgetname/$subobject string. style exists as a separate property, as @bu5hm4n points out, so this can also be removed. So what we would be left with should be something like theme_group as a property.

Newly added (to layout_base):

@property automatic_theme_rotation {
  [[This flag tells if this object will automatically mirror the rotation changes of the window to this object.
  ]]
  values {
     automatic : bool; [[$true to mirror orientation changes to the theme $false otherwise]]
  }
}
theme_rotation_apply {
  [[Apply a new rotation value to this object.]]
  params {
    orientation : Efl.Orient; [[The new rotation value.]]
  }
}

I'm not super sold on this API: I think we may want to leave it as beta for now when the rest of the class is released.

@woohyun any thoughts on this?

@zmike

It seems that all the properties and methods are required to be marked @beta for now :)
(P) theme may be required to change its values (style) based on @bu5hm4n and your opinion.
(P) automatic_theme_rotation and (M) theme_rotation_apply are submitted recently. So it seems that it requires some time to check them.

Thinking further, theme should contain style because if they are separate then this will trigger unnecessary recalcs and/or errors when the group and style are applied separately. But I am still not sure of the requirement to keep $widgetname and $subobject separated.

In T7512#131886, @zmike wrote:

Thinking further, theme should contain style because if they are separate then this will trigger unnecessary recalcs and/or errors when the group and style are applied separately. But I am still not sure of the requirement to keep $widgetname and $subobject separated.

@zmike
First, about "theme_rotation" things, I think we are not urgent with supporting them.
So, I agree with making them as @beta for now.

And, about (P)theme.
I thought you indicated the important point. If "style" would be separated, then there can be several expected problems (which you already commented above)
So, with current codes, I don't feel like separating "style" is good idea.

About $widgetname and $subobject, honestly I agree with any way if reference description for this property is enough good.

Okay, thanks for this feedback!

This can be marked stable once D8059 and D8060 land.