GNOME Bugzilla – Bug 583272
have a way to provide monochrome icons for system status area icons
Last modified: 2011-02-01 02:32:26 UTC
Many products use monochrome (or low color) style icons in the system status area. For example: OS X, iPhone, android, moblin, etc. It would be nice if we have a way to do this while retaining the ability to use high color icons for the rest of the icon theme. One of the problems today is that some of the status icons use standard icon names from the naming spec (the volume indicator for example).
This is not a gnome icon theme bug, as you said the icons used in the notification area are just normal icons so we can do nothing about it. We'd need special icon names for notification area icons, and every application (ab)using the notification area should use these names.
One work-around could be to set the GtkStatusIcon widgets to use one of the HighContrast icon themes. Not sure it's possible to set a separate icon theme for a widget though.
Ok, new plan. We should add a new tray manager hint for the icon theme to: http://standards.freedesktop.org/systemtray-spec/systemtray-spec-latest.html#id2509999 _NET_SYSTEM_TRAY_ICON_THEME and we'll modify clients to use this and respond to changes. We'll likely need to make some changes to GtkStatusIcon to enable this.
didn't this already get implemented via another bug? (either way, it no longer blocks the shell, which isn't going to be using trayicons there)
Then what _are_ you going to use ?! I must have asked this question a million times already, for ages. Without ever getting a clear answer...
Yeah, we never had a clear answer until last week. The UI parts of it will be entirely in javascript, in the shell. For icons that need access to complicated data (eg, network), they'll get the raw information from another process (eg, nm-applet) via D-Bus, and then create an appropriate visualization of that information in JS. (This is based on the assumption that there are going to be several major redesigns of the status area after the initial implementation, and so we want the UI aspects of it to be completely determined by code in the shell, so we can implement those redesigns ourselves without needing to coordinate with multiple other modules.)
It's really a dup of bug 614711. *** This bug has been marked as a duplicate of bug 614711 ***