Hi,
On 9/24/19 12:43 PM, Simon Lees wrote:
On 9/24/19 9:50 AM, Simon Lees wrote:
On 9/21/19 11:06 PM, Mike Blumenkrantz wrote:
Hi,
As we prepare for the release (which is now postponed to Wednesday, I
think?), we must review the theme API for the widgets that are being
stabilized. A ticket for this can be found here:
https://phab.enlightenment.org/T8231
The only significant issue that I've discovered so far is that several
classes make use of legacy widgets internally, which would implicitly
pull
in legacy theme groups. The specific legacy widgets used are
elm_entry and
elm_label, but in neither case is any API exposed to the user.
It's possible that the elm_entry could be replaced with an
efl_ui_text, and
I'm planning to investigate this on Monday if nobody else has done so at
that time. This may or may not be a solution that we want, however,
as that
would pull in the efl_ui_text theme, which is not slated for
stabilization.
For the case of the elm_label usage, there is no such eo-based widget
(Yes,
I've tried) due to the fact that label sizes entirely based on its
internal
edje object.
The question here is this: given that legacy widgets are stable, as
is the
corresponding theme API, is it acceptable for widgets to pull these in
internally if there is no eo-based equivalent?
To me, it seems like the only issue here is that this is an implicit
dependency, so this could be solved with documentation. Then in the
future,
when we do have stable eo-based widgets which provide the needed
functionality and want to move to using them, it would be simple
enough to
verify that a user has a stable version of the new widget's theme group
(using some future data.item for those groups in edc) and fall back to
existing legacy widgets if none is found.
Please share your thoughts so that we can consider this carefully before
the release.
Mike
I found some issues in the theme itself, I was going to attempt to
script the port, but for now I don't have time but before I gave up I
noticed the following. I'll also try and find time to look through the
rest in a bit of detail but i'm not sure ill have time
1. elm.event.* has been renamed to event.* with the exception of
elm.event.resize.*
2. name: "elm/button/base/default" has been replaced with name:
"efl/button" when in all other cases the "name:" has simply been dropped
3. button.edc adds an #undef ICON but doesn't undef anything else,
from where the undef is called I suspect its hiding something else
that should have undef'd that somewhere else.
4. name: "elm/check/base/toggle" is replaced with "efl/check:toggle"
should this be "efl/check/toggle" instead? Although
"elm/focus_highlight/top/blank" has become
"efl/focus_highlight/top:blank" so maybe this is intentional,
efl/panes/vertical:right-fold, efl/pointer, efl/progressbar/*:wheel
efl/scroller:noclip efl/slider/horizontal:disabled,
efl/focus_highlight/top:blank, efl:tooltip:transparent are others.
efl/scroller:popup/no_inset_shadow is an extra special case.
I guess its just not really obvious as to when one should use : over /
The idea here is that you have the group name which is assembled out of
the klass name, a component name and the style at the end.
Klass and compontent are decided by the widget, properties might have an
impact on the resulting name. The style is completly left to the user to
decide, and is also applied in that manner, no widget internally sets a
style for itself, ever.
The user style is also seperated with a ":" from the rest, in order to
make clear what is a style, and what is an essential group.
As an example, group efl/spin_button/horizonal/dec_button:foobar
- the prefix efl/ is std
- spin_button/horizontal is the klass (This is probebly not perfect that
we used / here.)
- dec_button is the element
- foobar would be the style, which does not exist, i just needed an example.
5. panel.edc, still has a efl.swallow.event part
(Not meant to be stable in this release)
Thats everything I see anyway.
I hope this helps,
bu5hm4n
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel