Hi, On Mon, Sep 23, 2019 at 8:21 PM Simon Lees <sfl...@suse.de> 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
