Right now the style property is protected, we might want to have that available for external users (see the spinner example for that)
I don't know yet how styles work, so here's my less than two-cents worth:
- It seems obvious that the user should be able to change a widget's style. No? Or is that meant to be changed through other APIs, like set_layout_direction()?
- style_set is meant to be called inside the constructor. How's the spinner cxx example supposed to work?
- All C# widgets can change style at construction time through a constructor parameter. Does something similar exist for cxx?
- As I recall, styles are free-form strings, defined by themes, widgets, extensions and whatnot. How are we gonna document that? Do we need a runtime tool that lists available styles?
My feeling is that cxx bindings have been neglected for a long time and it might take a while to get them up to speed... time we don't have right now.
- Yes, but there is something like the "toggle" style for check, which has nothing to do with spinner.
- style is protected, you cannot call it in the constructor, because you are not allowed to call it.
- That is a little bit concerning, the style parameter is protected, how is it getting into the constructor list ? style is not a constructor property
- I have no idea
Sure, but this shows that IMO style should not be protected.
If my memory is correct -
when we began these interface works, upstream developers discussed together about STYLE.
And, we got the conclusion that -
- efl_ui_xxx classes never use STYLE
- if specific class needs to change it's appearance, it should be covered by property of the class
- if the change can not be covered by properties, then class should be extended newly
These ideas came from the discussion that -
- legacy widgets' style is doing too many things, and changing style gives almost new widget functionality
- theme's role should be limited to "layouting for the widget's appearance"
I'm still scratching my head to recall the more information about this STYLE.
If I get more, then will share that here.
I don't see a particular reason why it should be @protected other than preventing people from potentially footgunning themselves by overriding it improperly.
To clarify @woohyun's comment, I think the idea was that we should not be using style for widget features; style should still be used by widgets to change their appearance.