Page MenuHomePhabricator

theme api
Closed, ResolvedPublic

Description

The following widgets are slated for stabilization and need theme analyzing to ensure that we're doing sane things:

  • bg
  • button
  • check
  • collection (alias of scroller)
  • datepicker
  • grid
  • group_item
  • image/zoomable
  • list
  • popup
  • radio
  • scroller
  • slider
  • spin
  • spin_button
  • tab_bar
  • tab_page
  • tab_pager
  • timepicker

Details

Commits
D10197 / rEFLbc855ec8b62e: theme: add spec documentation for all stabilized theme groups in 1.23
D10167 / rEFL59709bc90776: theme: migrate all efl,anim,activate (and similar) signals to efl,state…
D10166 / rEFLaab934176637: theme: efl,state,anim,stop -> efl,state,animating,stopped
D10165 / rEFL3ec56e0dc43d: api: efl,state,busy,(start|stop) -> efl,state,busy,(started|stopped)
D10163 / rEFLecd3d2723b79: theme: remove unused scroller group
D10162 / rEFL6d6bfeecfa85: theme: use more explicit signal names for C <- theme scrollbar signals
D10159 / rEFL41f37c328ee9: theme: use 'visible' style signals for spin_button button/entry visibility
D10161 / rEFLedab064de9af: theme: efl,action,clicked -> efl,action,click
D10160 / rEFLab8306135c58: theme: use more explicit signal names for C -> theme scrollbar signals
D10158 / rEFL9b18e5a29160: theme: efl,state,(content|text),(set|unset) -> efl,(content|text),(set|unset)
D10157 / rEFL75c8fd1cc297: api: move eo-based radio and check widgets to use selectable signal names
D10164 / rEFLf24ce654c0c2: efl_ui/layout: add mechanism for deferring versioned theme signals
D10156 / rEFLd2adb0d30860: theme: /efl,orient,(horizontal|vertical)/efl,state,(horizontal|vertical)/
D10153 / rEFL9206960dfac9: efl_ui/layout: add explicit error case when theme version > efl version
D10098 / rEFL25fddaa748c2: efl_ui/scroller: remove unused "looping" signals
D10100 / rEFLc99f7d06cb60: efl_ui/spin_button: fix signal namespacing
D10099 / rEFLcc88a1f875bd: efl_ui/timepicker: rename and namespace visibility signals
D10097 / rEFL9f7417dddea5: efl_ui/focus: rename focus visibility signals
D10096 / rEFL84f7998caec0: efl_ui/scroller: rename bar visibility signals
D10095 / rEFL3d9b2f666657: efl_ui/alert_popup: rename show/hide signals to visible,on/off
D10094 / rEFL63358e42862b: theme: add 'required' to efl/border parts
D10081 / rEFL1511430c29b7: efl_ui/layout: validate theme api version in theme_apply
D10080 / rEFLc85e6e147d21: theme: manually specify version info for all eo-based widget themes
D10087 / rEFL5de77bd005cf: theme: add 'required' to efl/tab_pager group parts
D10086 / rEFLb90bcbd3b59e: theme: add 'required' to efl/button:anchor group parts
D10084 / rEFL84dd06aa667e: theme: add 'required' to efl/spin_button group parts
D10083 / rEFL27ec3c7c671e: theme: add 'required' to efl/timepicker parts
D10056 / rEFL40b22d644d48: theme: add 'required' to efl/bg group parts
D10058 / rEFLc4f87b46a67a: theme: add 'required' to efl/scroller group parts
D10057 / rEFLdb71c0764668: theme: add 'required' to efl/popup (and related group) parts
D10059 / rEFLacad0bd16386: theme: add 'required' to efl/datepicker parts
D10052 / rEFL659e0fc00c8f: theme: efl/photocam -> efl/image_zoomable
D10054 / rEFL527ca2e6c08d: theme: remove dead popup theme groups
There are a very large number of changes, so older changes are hidden. Show Older Changes

@zmike

I think that HQ can give a help on this work.
If you make some work items for this work, then we will handle them together.

(work items for not doing duplicate work)

Or, do you have better idea on this ?

raster added a subscriber: raster.Sat, Sep 21, 12:57 AM

This really needs to be carefully reviewed before release. I won't have time over the next week or so (conference event all next week + travel).

zmike added a comment.Sat, Sep 21, 6:13 AM

@zmike

I think that HQ can give a help on this work.
If you make some work items for this work, then we will handle them together.

(work items for not doing duplicate work)

Or, do you have better idea on this ?

It's important that we mark all efl. namespaced parts with required; in the edc so that we are not using any non-required parts from the C code. I've put up a bunch of patches to start doing this already, and the above list shows which parts are still missing it. As for other work items that can be easily handled:

  • look at part/signal names and see if they seem "intuitive" for people who would be making themes.
    • The cases I've cited 3 comments above this are good examples of ones which could maybe use renaming to be more informative
  • check to make sure that all widgets in the list are implementing (in EDC) all the signals they send from the C code, and that all the EDC signals are being sent/handled in the C code
    • This can probably be handled somewhat programmatically by grep? There is also my branch of theme analyzer which you can use like edje-theme-spec /path/to/default.edj and it will print out all the parts and signals for the classes we're looking at; needs D10055
zmike added a comment.Sat, Sep 21, 6:24 AM

This really needs to be carefully reviewed before release. I won't have time over the next week or so (conference event all next week + travel).

I agree. I have been meaning to do this for several weeks, but I continually get sidetracked with urgent issues.

If you have anything in particular you know you want to examine, you can send a list of criteria that I can add to my list. Thus far the themes I've looked at have been exceedingly simple and/or just based on the legacy equivalent. We're pushing the release back to Wednesday I think, and my goal is to spend the interim time on this item provided that more urgent issues don't arise.

The only serious issue I've come across thus far is the use of internal widgets which implicitly pull in other widgets which are legacy; specifically, the widgets pulled in are elm_label and elm_entry, the latter of which I may be able to replace with an efl_ui_text in its specific case to at least avoid using a legacy theme group. The elm_label cannot be replaced as there is currently no widget which displays text and has a similar sizing policy, so widgets which utilize this would no longer function without it. None of the cases with this issue expose the legacy widget at an API level, so the sole issue here is the theme group which is used.

zmike added a comment.Mon, Sep 23, 7:38 AM

I'm going to mitigate future issues here by forcing themes for all eo-based widgets to provide versioning info. At least then we can provide a mechanism for easily updating theme API if necessary.

zmike added a comment.EditedMon, Sep 23, 1:19 PM
  • all show and hide signals should be renamed to visible,on and visible,off, using the format efl,$name,visible,on|off
zmike added a comment.EditedMon, Sep 23, 1:26 PM
  • ,end signals need to be renamed to ,done
zmike added a comment.EditedMon, Sep 23, 2:14 PM

I've done a lot of work on this today and have updated the above block comments with latest states of theme (all patches currently available), some work remaining:

  • anim is used in various places; should this be expanded to animation to be clearer? If this were C API then we definitely would...
  • the above examples of:

efl.content_b
efl.content_r
efl.content_rb
efl.dec_button
efl.inc_button

are not yet solved.

  • Also group names should be reviewed.
  • Also we have a lot of things in the efl,state namespace for signals. Are these all really "states"?
  • Lastly the big issue of text widget themes that we're importing from legacy (and efl/text) which we probably don't want to. The best option here may be to just leave those classes as beta for now and plan to stabilize post-release once text widgets are ready.
zmike moved this task from Backlog to Evaluating on the efl: api board.Mon, Sep 23, 8:02 PM

We also maybe want to redo the theme of the grid item. Frankly said, it looks quite shitty.

zmike added a comment.Tue, Sep 24, 6:11 AM

We also maybe want to redo the theme of the grid item. Frankly said, it looks quite shitty.

We aren't super concerned with the current appearance here, just in how the parts/signals are. And it seems about how I'd expect for an item in that regard.

Some thoughts now, more later:

  • I would definitely rename all anim to animation
  • I would definitely rename efl.content_[rb]* to whatever it really means. I guess it is right and bottom? I would use something more suggestive of the purpose of that part (is it a lane end, stopper, buffer?)
  • (inc|dec)_button do not look that bad. We can use (plus|minus)_button if we want to talk about the looks of it instead of its purpose.

Having a look at some of the edc's for efl/* things:

General

  1. we have efl.background. we should really have efl.foreground too (on top of all content but otherwise just like background).
  1. version data key per group... this is the same version as for the file as a whole... isn't this just duplication? I don't see anything even checking version other than efl_ui_win on specific objects (only on edje files as a whole).

Specifics

  1. bg - efl.rectangle. this smells wrong to me. not sure quite how. name-wise this is really a swallow for the purposes of just specifying a solid color (and doing that by creating a rect object and swallowing it). so name-wise shouldn't this be more like efl.color? that's the purpose and it makes more sense that way. probably better is to use colorclasses and set a colorclass name SPECIFICALLY on this object (you can set a cc on a specific edje obj). this actually then should just modifhy the base part color then. to do this though requires we standardize colorclass names which we haven't done to date. we'd need to at least standardize the base/background one.
  1. win - efl.rect.background - this is namespaced... should it be? the colorclass name sure - like the above bg object... the colorclass here is elm/* instead of efl/* ... but again - thought needs to go into this. we shouldn't namespace this unless we want to set it in stone.
  1. win - efl.background - i think this needs either another swallow for a "full background or some signal to switch it between just being the background behind the client area or the background that extends through titlebar AND the resize bar at the bottom until the window boundary/edges. we need to decide if this should be done with multiple swallows or by signals to switch how a background might fill a widget.
  1. win - efl.menu - this assumes the menu bar is just a simple bar at the top. what if we want a menu button in the titlebar? how would we do this? it's not obvious. multiple swallows and api decides what to swallow where? we can add these in future but decide how to do that now...
  1. win - efl.client - shouldn't this be efl.content ?
  1. win - efl,state,* - shouldn't we make this simpler like efl,state,focus,on/off or efl,state.urgent,on/off instead of trying to find 2 different words like focus, unfocus or urgent, not_urgent ... it'll clean up code to make it a common emit thing that just turns a boolean to on or off strings and appends this to a base string...
  1. win - elf,state,background,solid* and efl.state,background,standard* - this seems to not exist in the bg widget at all and the button widget has different signals or this... this is a big of an inconsistent nightmare so far. this stuff all need a big fat rethink and turned into consistent things across all widget groups.
  1. win - efl,action.show_/hide_indicator ... shouldn't this be a state?
  1. efl,action.indicator,show_/hide_effect ... this just smells bad ... ok - we need to differentiate between an unanimated state setup so it's instantly like that vs a runtime change you may want to animate...
  1. efl,action.indicator,bg_transparent/_opaque - state again not action.... ?
  1. efl,action,show_/hide_menu - state again.... ?
  1. the efl,action,*,show/hide/start/stop should probably be simplified to just start/stop? starting a resize shows whatever info is needed for that resize implicitly...
  1. shouldn't we have a swallow on the left size next to the icon for extended widgets like the volume indicator/control and on the top-right between titlebar and close/max/minimize for extended buttons there too?

... i haven't even gotten past bg and button yet :) i think this release is going ot have to pend for a bit.

zmike added a comment.Tue, Sep 24, 1:05 PM

Thanks for starting to check things out!

Having a look at some of the edc's for efl/* things:

=== General ===

  1. we have efl.background. we should really have efl.foreground too (on top of all content but otherwise just like background).

This can be added in a future release. There's no demand for it currently.

  1. version data key per group... this is the same version as for the file as a whole... isn't this just duplication? I don't see anything even checking version other than efl_ui_win on specific objects (only on edje files as a whole).

This is pending in D10081 and related patches.


=== Specifics ===

  1. bg - efl.rectangle. this smells wrong to me. not sure quite how. name-wise this is really a swallow for the purposes of just specifying a solid color (and doing that by creating a rect object and swallowing it). so name-wise shouldn't this be more like efl.color? that's the purpose and it makes more sense that way. probably better is to use colorclasses and set a colorclass name SPECIFICALLY on this object (you can set a cc on a specific edje obj). this actually then should just modifhy the base part color then. to do this though requires we standardize colorclass names which we haven't done to date. we'd need to at least standardize the base/background one.

I'd rather not get into trying to stabilize color classes and such things given that we're supposed to be within 1-3 days of a release. Renaming the part would be fine; if we start doing more with color classes in the future then we could change this with theme versioning and still retain compatibility without much trouble. Given that you seem interested in changing how this works in the future, I think leaving it as efl.rectangle is optimal for now since it's more descriptive about what the part is used for, and it can easily be contrasted with a future efl.color part which might work using color classes as you've described.

  1. win - efl.rect.background - this is namespaced... should it be? the colorclass name sure - like the above bg object... the colorclass here is elm/* instead of efl/* ... but again - thought needs to go into this. we shouldn't namespace this unless we want to set it in stone.
  2. win - efl.background - i think this needs either another swallow for a "full background or some signal to switch it between just being the background behind the client area or the background that extends through titlebar AND the resize bar at the bottom until the window boundary/edges. we need to decide if this should be done with multiple swallows or by signals to switch how a background might fill a widget.
  3. win - efl.menu - this assumes the menu bar is just a simple bar at the top. what if we want a menu button in the titlebar? how would we do this? it's not obvious. multiple swallows and api decides what to swallow where? we can add these in future but decide how to do that now...
  4. win - efl.client - shouldn't this be efl.content ?
  5. win - efl,state,* - shouldn't we make this simpler like efl,state,focus,on/off or efl,state.urgent,on/off instead of trying to find 2 different words like focus, unfocus or urgent, not_urgent ... it'll clean up code to make it a common emit thing that just turns a boolean to on or off strings and appends this to a base string...
  6. win - elf,state,background,solid* and efl.state,background,standard* - this seems to not exist in the bg widget at all and the button widget has different signals or this... this is a big of an inconsistent nightmare so far. this stuff all need a big fat rethink and turned into consistent things across all widget groups.
  7. win - efl,action.show_/hide_indicator ... shouldn't this be a state?
  8. efl,action.indicator,show_/hide_effect ... this just smells bad ... ok - we need to differentiate between an unanimated state setup so it's instantly like that vs a runtime change you may want to animate...
  9. efl,action.indicator,bg_transparent/_opaque - state again not action.... ?
  10. efl,action,show_/hide_menu - state again.... ?
  11. the efl,action,*,show/hide/start/stop should probably be simplified to just start/stop? starting a resize shows whatever info is needed for that resize implicitly...
  12. shouldn't we have a swallow on the left size next to the icon for extended widgets like the volume indicator/control and on the top-right between titlebar and close/max/minimize for extended buttons there too?

It's great that you've spent time looking at the win theme. Unfortunately, this is something that nobody looked at for 1.22, and this theme is now stable. Any changes here can still be done with versioning, but this is not on the radar for the current release planning, and I don't think it's especially useful to put time into it considering how close we are to the 1.23 release.

... i haven't even gotten past bg and button yet :) i think this release is going ot have to pend for a bit.

I think you're focusing too much on trying to get everything perfect at this point in time. The reality is that we're already pushing the 1.23 release back, and we have hard limits (not just in terms of business use, but in terms of people availability with vacations and trips and such). This Friday is roughly the last possible day that we can delay to. The goal with all API design has been to give it a "best effort" and accept that we're not going to get things right every time. It's just not possible given the available time. So we do what we can and try to provide a quality API, and if we mess up (which has happened in some cases) then we can go back and add some things here and there to improve it in a future release (e.g., using theme versioning). If it's bad to the extent of being unusable, it may just have to wait for EFL 2.0, when we can continue applying all the lessons we've learned along the way.

The goal of this ticket is to fix the most urgent things which would impede our ability to:

  • provide a usable API
  • update the API in the future

This involves reworking things if they're broken to the point of not being usable or if they would prevent us from making changes in the future, such as by forcing the widget-side code to work in such a way that it can never be changed. I've gotten through about half the classes so far, and none of them has been so poorly designed that it would impede future development or be impossible to use by application developers. I've done considerable work already to smooth out some of the rough edges and fix some smaller bugs here and there, but on the whole it could be much worse.

I'm planning to continue reviewing this right up until the release now that I've finally gotten through the last of the last-minute items which keeps sidetracking me.

can we then keep the theme api unstable? yes - there is versioning but it means:

  1. code has to handle both old and new.
  2. new themes can work on older efl's

so probably should try avoid version breaks if we can...

zmike added a comment.Tue, Sep 24, 7:42 PM

I don't really see how, conceptually, we can consider the theme API completely unstable if we're releasing widgets? The premise I'm working off is that any theme built off the current API will continue to work until 2.0. Thus:

  1. Yes, this is the whole point of the versioning
  2. No, this is not how efl versioning works: if you have a newer config file than efl's current config version, elm_config will erase that file and overwrite it with the defaults. This is how we've always done versioning. Similarly, we would fall back to the default theme if the provided theme is too new, or we would just critically error.

This does raise the point that the provided implementation for handling versioning doesn't handle versions newer than the installed efl version, so I'll add a case for it in the morning.

I categorized the signal names into 4 groups as follows.
I want to discuss how we can categorize signal types. If we are able to categorize signal types, then it would be helpful to choose the right name for it.

  1. To pass input action (e.g. mouse down) - efl,action,<action type>,<adjective/adverb>
    • efl,action,multi,down
    • efl,action,multi,up
    • efl,action,pressed
    • efl,action,scroll
    • efl,action,unpressed
  1. To change an object's state - efl,state,<state type>,<adjective/adverb>
    • efl,state,horizontal (efl,orient,horizontal)
    • efl,state,vertical (efl,orient,vertical)
    • efl,state,busy,on (efl,state,busy,start)
    • efl,state,busy,off (efl,state,busy,stop)
    • efl,state,even
    • efl,state,odd
    • efl,state,inverted,off
    • efl,state,inverted,on
    • efl,state,check,off ?
    • efl,state,check,on ?
    • efl,state,disabled
    • efl,state,enabled
    • efl,state,pressed
    • efl,state,unpressed
    • efl,state,radio,off ?
    • efl,state,radio,on ?
    • efl,state,selected
    • efl,state,unselected
  1. To set/unset an object's property(part) - efl,<property(part) name>,set/unset
    • efl,background,set (efl,state,background,set)
    • efl,background,unset (efl,state,background,unset)
    • efl,content,set (efl,state,content,set)
    • efl,content,unset (efl,state,content,unset)
    • efl,text,set (efl,state,text,set)
    • efl,text,unset (efl,state,text,unset)
  1. To change an object's property(part) state - efl,<property(part) name>,<state type>,<adjective/adverb>
    • efl,ampm,visible,off
    • efl,ampm,visible,on
    • efl,buttons,visible,on
    • efl,colon_field0,visible,off
    • efl,colon_field0,visible,on
    • efl,colon_field1,visible,off
    • efl,colon_field1,visible,on
    • efl,focus,visible,off
    • efl,focus,visible,on
    • efl,horizontal_bar,visible,off (efl,hbar,visible,off)
    • efl,horizontal_bar,visible,on (efl,hbar,visible,on)
    • efl,vertical_bar,visible,off (efl,vbar,visible,off)
    • efl,vertical_bar,visible,on (efl,vbar,visible,on)
    • efl,highlight,visible,off (efl,highlight,off)
    • efl,highlight,visible,on (efl,highlight,on)
    • efl,button,visible,off (efl,state,button,inactive)
    • efl,button,visible,on (efl,state,button,active)
    • efl,entry,visible,off (efl,state,entry,inactive)
    • efl,entry,visible,on (efl,state,entry,active)
    • efl,title,visible,off
    • efl,title,visible,on

0. Need to be categorized with modification

  • efl,anim,activate -> 2.efl,state,animation,active,on or 2.efl,state,animation,started or 4.efl,animation,active,on or 4.efl,animation,started
  • efl,state,access,active -> 2.efl,state,access,active,on or 2.efl,state,access,enabled or 4.efl,access,active,on or 4.efl,access,enabled
  • efl,state,access,inactive -> 2.efl,state,access,active,off or 2.efl,state,access,disabled or 4.efl,access,active,off or 4.efl,access,disabled
  • efl,state,anim,stop -> 2.efl,state,animated,stopped or 4.efl,animation,stopped
  • efl,state,icon_new,set ?
  • efl,state,icon,reset ?
  • efl,state,icon,set ?
  • efl,state,icon,unset ?
  • efl,state,label,reset (not used)
  • efl,state,label_set (not used)
  • efl,state,label_set,backward (not used)
  • efl,state,label_set,forward (not used)
  • efl,state,moving (not used)

Could you give your opinion on the above or your own opinion on how to categorize signal types?

BTW, I have some trouble to choose the name for "active", "inactive", "start", and "stop".
In the above list, I converted "active" to "visible,on" if it is about the visibility. However, if it is not related to visibility, then I think we need to keep the word "active".

About the above words, which one is better?

  • "active" and "inactive" OR "active,on" and "active,off"
  • "start" and "stop" OR "started" and "stopped"

Please give me your thoughts.

zmike added a comment.EditedWed, Sep 25, 5:49 AM

Wow, this is some nice work!

I categorized the signal names into 4 groups as follows.
I want to discuss how we can categorize signal types. If we are able to categorize signal types, then it would be helpful to choose the right name for it.

  1. To pass input action (e.g. mouse down) - efl,action,<action type>,<adjective/adverb>
    • efl,action,multi,down
    • efl,action,multi,up
    • efl,action,pressed
    • efl,action,scroll
    • efl,action,unpressed
  2. To change an object's state - efl,state,<state type>,<adjective/adverb>
    • efl,state,horizontal (efl,orient,horizontal)
    • efl,state,vertical (efl,orient,vertical)

These are from the base layout class, which was stabilized in 1.22 and cannot be changed without versioning. We can do this, I just want to make a note of it.
EDIT: I was wrong about this, the signals were never actually stabilized.
EDIT2: nope, wrong grep, they're stable. I'll version this.
EDIT3: no, this is even more confusing. these signals are not stable and ignore anything else I say on the topic.

  • efl,state,busy,on (efl,state,busy,start)
  • efl,state,busy,off (efl,state,busy,stop)

Maybe even efl,state,busy and efl,state,idle ?

  • efl,state,even
  • efl,state,odd
  • efl,state,inverted,off
  • efl,state,inverted,on
  • efl,state,check,off ?
  • efl,state,check,on ?

I was considering these as well, since it seems like this is a case where the same "type" of signal is duplicated for many widgets. This could be changed to something like efl,state,selected and efl,state,unselected maybe?

  • efl,state,disabled
  • efl,state,enabled
  • efl,state,pressed
  • efl,state,unpressed
  • efl,state,radio,off ?
  • efl,state,radio,on ?

Same as check.

    • efl,state,selected
    • efl,state,unselected
  1. To set/unset an object's property(part) - efl,<property(part) name>,set/unset
    • efl,background,set (efl,state,background,set)
    • efl,background,unset (efl,state,background,unset)
    • efl,content,set (efl,state,content,set)
    • efl,content,unset (efl,state,content,unset)
    • efl,text,set (efl,state,text,set)
    • efl,text,unset (efl,state,text,unset)

The content and text signals were also stable for 1.22, though we can version them. I don't have a strong opinion.

  1. To change an object's property(part) state - efl,<property(part) name>,<state type>,<adjective/adverb>
    • efl,ampm,visible,off
    • efl,ampm,visible,on
    • efl,buttons,visible,on
    • efl,colon_field0,visible,off
    • efl,colon_field0,visible,on
    • efl,colon_field1,visible,off
    • efl,colon_field1,visible,on
    • efl,focus,visible,off
    • efl,focus,visible,on
    • efl,horizontal_bar,visible,off (efl,hbar,visible,off)
    • efl,horizontal_bar,visible,on (efl,hbar,visible,on)
    • efl,vertical_bar,visible,off (efl,vbar,visible,off)
    • efl,vertical_bar,visible,on (efl,vbar,visible,on)
    • efl,highlight,visible,off (efl,highlight,off)
    • efl,highlight,visible,on (efl,highlight,on)
    • efl,button,visible,off (efl,state,button,inactive)
    • efl,button,visible,on (efl,state,button,active)
    • efl,entry,visible,off (efl,state,entry,inactive)
    • efl,entry,visible,on (efl,state,entry,active)
    • efl,title,visible,off
    • efl,title,visible,on

These changes all seem good.

0. Need to be categorized with modification

  • efl,anim,activate -> 2.efl,state,animation,active,on or 2.efl,state,animation,started or 4.efl,animation,active,on or 4.efl,animation,started

I think this should be paired with efl,state,anim,stop? If we use the state namespace then it should be a state, so I think we can maybe use efl,state,animation,started.

  • efl,state,access,active -> 2.efl,state,access,active,on or 2.efl,state,access,enabled or 4.efl,access,active,on or 4.efl,access,enabled
  • efl,state,access,inactive -> 2.efl,state,access,active,off or 2.efl,state,access,disabled or 4.efl,access,active,off or 4.efl,access,disabled

Access is not stable, so we can ignore these for now I think?

  • efl,state,anim,stop -> 2.efl,state,animated,stopped or 4.efl,animation,stopped

This should probably be efl,state,animation,stopped to pair with the above signal...

  • efl,state,icon_new,set ?
  • efl,state,icon,reset ?
  • efl,state,icon,set ?
  • efl,state,icon,unset ?
  • efl,state,label,reset (not used)
  • efl,state,label_set (not used)
  • efl,state,label_set,backward (not used)
  • efl,state,label_set,forward (not used)
  • efl,state,moving (not used)

These are all tab_bar signals, so we can ignore them for now...

Could you give your opinion on the above or your own opinion on how to categorize signal types?

BTW, I have some trouble to choose the name for "active", "inactive", "start", and "stop".
In the above list, I converted "active" to "visible,on" if it is about the visibility. However, if it is not related to visibility, then I think we need to keep the word "active".

I agree with all your suggestions above, they seem like good improvements.

About the above words, which one is better?

  • "active" and "inactive" OR "active,on" and "active,off"
  • "start" and "stop" OR "started" and "stopped"

I think it depends on context? For example, animation,active and animation,inactive seem weird, because what is an "inactive" animation? But "started" and "stopped" seem fine (start and stop are actions, so they cannot be states)

Please give me your thoughts.

A few more thoughts:

  • efl,state,busy: I don't like start and stop, since this is really about showing or hiding the "busy" indicator. I think "idle" is confusing because it is not straightforward that the widget is waiting for user input. How about efl,busy_indicator,visible,on|off ?
  • efl,state,selected | unselected seem the most generic and easy to understand to me.
  • All proposals in point 4 look OK to me.
  • efl,state,animation,started | stopped sounds inconsistent with the other signals. Are we asking the theme to start the animation or are we telling the theme that the animation has started?
  • In general, I'd like to have more descriptive names, so I prefer on|off over active|inactive to avoid having strings too long.
zmike added a comment.EditedWed, Sep 25, 7:06 AM

A few more thoughts:

  • efl,state,busy: I don't like start and stop, since this is really about showing or hiding the "busy" indicator. I think "idle" is confusing because it is not straightforward that the widget is waiting for user input. How about efl,busy_indicator,visible,on|off ?

That's not really what the signal means though; it's not a requirement that there is such an indicator, and there's nothing in the widget which expects such a thing. It's just informing the theme that the widget is busy doing something.

  • efl,state,selected | unselected seem the most generic and easy to understand to me.
  • All proposals in point 4 look OK to me.
  • efl,state,animation,started | stopped sounds inconsistent with the other signals. Are we asking the theme to start the animation or are we telling the theme that the animation has started?

The former.

  • In general, I'd like to have more descriptive names, so I prefer on|off over active|inactive to avoid having strings too long.
In T8231#143545, @zmike wrote:

That's not really what the signal means though; it's not a requirement that there is such an indicator, and there's nothing in the widget which expects such a thing. It's just informing the theme that the widget is busy doing something.

OK then I think I prefer efl,busy,on|off or efl,state,busy,on|off

  • efl,state,animation,started | stopped sounds inconsistent with the other signals. Are we asking the theme to start the animation or are we telling the theme that the animation has started?

The former.

Shouldn't it then end with a verb? efl,animation,start|stop?

I am not sure if having the word state is that important.

zmike added a comment.Wed, Sep 25, 7:40 AM
In T8231#143545, @zmike wrote:

That's not really what the signal means though; it's not a requirement that there is such an indicator, and there's nothing in the widget which expects such a thing. It's just informing the theme that the widget is busy doing something.

OK then I think I prefer efl,busy,on|off or efl,state,busy,on|off

It's a state, so it would need to be efl,state,busy,on|off.

  • efl,state,animation,started | stopped sounds inconsistent with the other signals. Are we asking the theme to start the animation or are we telling the theme that the animation has started?

The former.

Shouldn't it then end with a verb? efl,animation,start|stop?

I am not sure if having the word state is that important.

I think what we're trying for here is to use the namespace (the first bit after efl,) when properties related to parts are modified, such as efl,content,set and efl,text,set. animation is a more general thing, so it would need to be in the state namespace.

zmike added a comment.Wed, Sep 25, 9:34 AM

Alright, once all the outstanding patches are merged that should take care of the discussed issues. The themes should be reasonable from a naming/consistency perspective.

I've done a sample case of signal versioning for layout signals. This implementation can likely be improved in the future, but for now it's pretty painless to add new ones. Unless something drastically wrong is found with the widget themes (which seems unlikely since they do, at a minimum, function), I think we're probably good to go for this release.

I don't really see how, conceptually, we can consider the theme API completely unstable if we're releasing widgets? The premise I'm working off is that any theme built off the current API will continue to work until 2.0.

Well we can say the library API is stable so code will keep working but you need to live with "default theme only" until theme api is stable. that may come in another release or 2?

zmike added a comment.Wed, Sep 25, 3:04 PM

Ah, I think we're talking about slightly different things.

I'm referring to "theme API" as "theme API for stable widgets", and you are referring to it as the entire theme. The sensible plan for going forward, imo, is to treat the theme API as a library containing components. This means that as widgets become stable, the theme gains more API. So "stable" applies only to theme groups which apply to (features of) stabilized widgets. A theme created for any version of EFL 1.X should always work for versions of EFL which are >= the version for which it was created.

I'm planning to add some documentation to the edc for currently-stable groups tomorrow which will make it easy to see at a glance exactly which groups are stable and what's required in order to create a theme for that group.

What do you think about using edc part type as a namespace?
i.e. "efl.text.title", "efl.rect.background", "efl.text.status", "efl.swallow.event", "efl.content.hotspot", "efl.spacer.opaque", "efl.spacer.content"

Now, we have the above cases which support edc part type as a namespace based on .c file.

I think we need to decide either using the namespace or not.

I think using namespaces here is not really usefull, with the output of edje-spec in the top of each .edc file, the type of each part is standardized (bc855ec8b62e989d778e47262c7b15e02e70b352). Additionally, from the c api, you see the type per API

@bu5hm4n
Thank you for your opinion. I agree with you.
Then the following cases should be modified to keep consistency with other part names.
"efl.text.title", "efl.rect.background", "efl.text.status", "efl.swallow.event", "efl.content.hotspot", "efl.spacer.opaque", "efl.spacer.content"

BTW, is it right if we do the part standardization work for border.edc as well?

I think @zmike should comment on that, i am not too deep into this topic to comment on that ...

zmike closed this task as Resolved.Fri, Sep 27, 6:41 AM
zmike claimed this task.

Generally speaking, there was some decision made for the new theme naming style to remove the old-style "include part types in the part names" namespacing. I think this is fine, since we can provide explicit documentation which makes it clear what types each part should be.

@bu5hm4n
Thank you for your opinion. I agree with you.
Then the following cases should be modified to keep consistency with other part names.
"efl.text.title", "efl.rect.background", "efl.text.status", "efl.swallow.event", "efl.content.hotspot", "efl.spacer.opaque", "efl.spacer.content"

BTW, is it right if we do the part standardization work for border.edc as well?

No, border.edc's theme was unfortunately stabilized in 1.22 without review. We can version this in a future release, but I don't think this is useful to focus on right now since we're so close to a release.

Plus, this is for actual client-side window frames, which are not likely to be used on products in the near future, yes? This would only impact Wayland desktop users, and there are basically none of those at the moment.

I think this issue can be considered resolved for now. We can come back to it for referencing with future theme stabilizations.

Thank you, I think you are right.

Just as an idea for later discussion after release, I think it would be good if we use namespace "text" and "content" only if app users use the part names directly to set content/text.

  • "efl.content" is the default swallow part
  • "efl.text" is the default text part
  • "efl.content.xxx" is a swallow part which allows app users to use the part name directly to set content. i.e. efl_content_set(efl_part(obj, "efl.content.xxx"), content);
  • "efl.text.xxx" is a text part which allows app users to use the part name directly to set text. i.e. efl_text_set(efl_part(obj, "efl.text.xxx"), text);