Awn

AwnThemedIcon API improvements

Registered by onox on 2009-06-06

- It seems icons are only retrieved from a system dir (/usr/share/icons/), I want to be able to retrieve themes from <applet dir>/themes/ or <applet dir>/icons/ (for example)
- I want to be able to retrieve a list of names of themes that can (likely) provide most of a set of icons (Because I want to display a combobox with the theme names in the preferences window of several applets)
- I want to retrieve the name of the current theme; whether the theme is in the set of useable themes (see above) doesn't matter
- I want that the API by default uses the system theme (if it provides the necessary icons, if default theme cannot provide the icons (is not in the list of useable themes -- see above) I want to be able tell the API which theme to use)
- I want to be able to switch themes: for example when API is using "Tango", I want to say: use "gnome" theme now
- I want to be able to switch icons: for example current can be "audio-volume-low", I want to be able to switch to "audio-volume-muted". The API should keep using the current theme. I think the applet dev should first tell the API which theme to start using, before telling which icon to use. So if the API doesn't know yet which theme to use, then display nothing (in other words: don't try to use default gtk theme or something)
- Performance: some themes (moonbeam themes in volume-control) have a much larger set of icons; preloading may be necessary. For example when I use a moonbeam theme and chang the volume in the slider, the applet quickly displays an icon that represents the new state. Currently it preloads the icons so that changing the volume doesn't become sluggish. However, currently in volume control, when changing the theme you feel a lag (because it preloads everything). I think when changing the theme it should first just load the current icon (if one has been set), and then in a different thread load the rest of the icons.

Blueprint information

Status:
Started
Approver:
None
Priority:
Low
Drafter:
None
Direction:
Approved
Assignee:
moonbeam
Definition:
Review
Series goal:
Accepted for 0.4
Implementation:
Good progress
Milestone target:
milestone icon 0.4.0
Started by
Michal Hruby on 2009-07-23

Related branches

Sprints

Whiteboard

Tested:
* switch icons. This is one of the main features of AwnThemedIcon. Every icon is associated with a state name. to change the icon you just switch to the corresponding state.
* use non-default theme.
* <applet dir>/themes/ and <applet dir>/icons/ (Briefly tested... seems to be working)

Implemented but Untested:
* default uses the system theme otherwise specify fallback. (needs a bit of discussion). I believe this should just be a matter of putting the desired fallbacks into the proper place in <applet dir>/themes/ . This _may_ need some additional code.

Not Implemented:
* list of names of likely themes
* retrieve the name of the current theme (this might not be as obvious as it seems).
* Performance. Caching can be done easily enough in AwnThemedIcon if it turns out to be necessary.

(moonbeam Edited 20090620)

Regarding: Determining if the current theme has full coverage of the icon names. I am willing to provide a convenience function to check if _all_ icons are present in the theme if this would be useful. Otherwise one can roll one's own with gtk_icon_theme_has_icon().

I will hold off on caching until we actually see an need for it. If it does become necessary to implement, the default would be loaded as needed and cache from that point, along with a preload that could be called at an arbitrary time. Shouldn't be overly painful to implement but I'm not inclined to do so unless there is a verified need.

(moonbeam 20090620)

At this time I'm leaning against the list of likely themes request. I can see it's appeal but I'm not convinced it's a good idea. It's also rather non-trivial to implement if fallback icons have been installed under a hicolor/ dir as they should be.... In other words all themes should show full coverage because icons should be in hicolor/ (at least in a perfect world). I guess the point is... even if it was implemented by traversing all the directories where themes could be installed the best I think we would get (without a lot of work) is something along the lines either no the icon is not there or yes the icon is present in the checked icon theme or hicolor.

(moonbeam 20090620)

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.