Re: [E-devel] EFL Theme Usage
Hi, On Mon, Sep 23, 2019 at 8:21 PM 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.* > I assume you mean for the win groups. This kind of slipped through the cracks with everything that was going on last release. We'll probably do a compatibility layer with the current theme and have some fixes with an improved API in a future version to make it a bit better. > > 2. name: "elm/button/base/default" has been replaced with name: > "efl/button" when in all other cases the "name:" has simply been dropped > You mean in terms of the syntax used? That has no bearing on anything. > > 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. > It's at the top of the file to avoid a redefinition cpp warning. This is fine. > > -- > > Simon Lees (Simotek)http://simotek.net > > Emergency Update Team keybase.io/simotek > SUSE Linux Adelaide Australia, UTC+10:30 > GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B > > > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL Theme Usage
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
Re: [E-devel] EFL Theme Usage
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 / 5. panel.edc, still has a efl.swallow.event part Thats everything I see anyway. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL Theme Usage
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. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] EFL Theme Usage
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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
