discussions regarding stabilization of efl.ui.layout class and dependencies
Description
Details
- Differential Revisions
- D7507: elementary: rename Efl.Ui.Translatable -> Efl.Ui.L10n
D7506: efl: rename Efl.Ui.Base -> Efl.Ui.I18n as that is really what it does.
D7505: elementary: rename Efl.Selection -> Efl.Ui.Selection as it is only usable with User Interface related element. - Commits
- D8273 / rEFL954cdb36561c: efl: apply the stabilzed column of the efl api board
D8060 / rEFL2f007f7a08b6: efl.ui.layout: mark methods as beta
D8059 / rEFLda1671197446: efl.ui.layout: fix theme.get implementation (+unit test)
Status | Assigned | Task | ||
---|---|---|---|---|
Resolved | zmike | T7512 efl.ui.layout | ||
Resolved | zmike | T7553 efl.ui.widget | ||
Resolved | zmike | T7554 efl.canvas.group | ||
Resolved | zmike | T7555 efl.canvas.object | ||
Resolved | None | T7556 efl.loop_consumer | ||
Resolved | cedric | T7557 efl.object | ||
Resolved | zmike | T7558 efl.gfx.entity | ||
Resolved | zmike | T7560 efl.gfx.stack | ||
Resolved | zmike | T7561 efl.animator | ||
Resolved | zmike | T7563 efl.gfx.size_hint | ||
Resolved | zmike | T7564 efl.gfx.map | ||
Resolved | None | T7565 efl.interface | ||
Resolved | zmike | T7567 efl.canvas.pointer | ||
Resolved | zmike | T7559 efl.gfx.color | ||
Resolved | zmike | T7570 efl.part | ||
Resolved | zmike | T7571 efl.ui.focus.object | ||
Resolved | zmike | T7572 efl.ui.cursor | ||
Resolved | zmike | T7576 efl.container | ||
Resolved | zmike | T7577 efl.file | ||
Resolved | zmike | T7672 efl.file_save | ||
Resolved | zmike | T7581 efl.layout.calc | ||
Resolved | zmike | T7582 efl.layout.signal | ||
Resolved | cedric | T7671 change efl layout signal callbacks | ||
Resolved | zmike | T7583 efl.layout.group |
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.
https://pastebin.com/AsfEdLxa :)
You need to execute it with elua, and you need to have the luajit bindings installed.
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 -
- marking beta to unstable methods (or properties)
- modifying improper names (of classes, methods, or properties)
- making as many test cases as we can -> I don't think this is not something we can perfectly in a short term
- ???
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
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.
- marking beta to unstable methods (or properties)
- modifying improper names (of classes, methods, or properties)
- making as many test cases as we can -> I don't think this is not something we can perfectly in a short term
- ???
- 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 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?
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.
@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.