Having a tidy systray
For too long on the Free Software desktop there has been a systray that is simply out of control. It provides for an arbitrary window with arbitrary behavior that developers have used arbitrarily. This provides a difficult interface for users as they don't know what to expect. It provides a difficult situation for applications as there is no way that they can give the user a good experience as there are no standards to follow. And it makes the whole support system for software more difficult through documentation and long explanations of how to use the computer.
Enough bitching. We're going to fix it.
We're starting with the KDE Status Notifier spec. It has been proposed to XDG and is currently used inside of KDE. It provides a DBus based interface for applications to advertise systray style information over DBus thus eliminating the need for XEmbed. The way that the Notifier Item spec is written it's designed to make the application expose information independent of the visualization, and we'll be one visualization of this data. A restricted visualization specifically focused on panels. We're going to have each application represented by a menu.
So with every application being a menu, and the panel knowing this and being able to assume it, then the whole systray can be a menu bar. This makes it easy to browse application's menus, find what you want, and work with it. It also improves keyboard navigation and increases the accessibility. Menus are a nice mix between simplicity and expandability as they're easy to use and yet provide a way for applications to provide a rich set of functionality.
To do all of this, and make it easy for application developers to implement, we've built a small convenience library. That library is libappindicator. Basically it takes an icon and a menu and magically sends it over DBus and puts it in the panel for you. No fuss. It will also handle the cases where you're on KDE and want to use the older KDE Status Notifier API. Or, even the old XEmbed way of doing things. We've tried to make it pretty easy for application developers:
/* Indicator */
indicator = app_indicator_new ("example-simple-client", /* ID */
"simple-client-icon", /* Icon */
APP_INDICATOR_CATEGORY_APPLICATION_STATUS);
indicator_menu = gtk_ui_manager_get_widget (uim, "/ui/IndicatorPopup");
app_indicator_set_status (indicator, APP_INDICATOR_STATUS_ACTIVE);
app_indicator_set_attention_icon (indicator, "simple-client-att-icon");
app_indicator_set_menu (indicator, GTK_MENU (indicator_menu));
Some of this stuff is, unsurprisingly, not yet complete. The menu support basically only works with labels today, and the fallbacks aren't yet in place for the legacy protocols. I promise I'm working on it. We'll be getting better menu support here probably this week and then I'll start working on the legacy support. I believe that there's enough here to get started, and to start understanding what we're thinking.
This post is getting long, let me just finish up with some links:
- Indicator Application Launchpad page -- this is where all the code and bugs are. Feel free to branch and do what ever you want with it.
- Documentation Wiki -- To understand what we're doing and how to port applications we've tried to put up some documentation. We'll continue to add as we get language bindings up and running here shortly.
- PPA for Karmic -- We've backported the modules required so you can develop and play with what we're doing today. There's also a preliminary patch to Rhythmbox that you can look at, which will, of course, be submitted upstream when it's cleaned up.
- Ubuntu Developer Week -- I'll be talking about this there, if you want to come and ask questions or just lurk.
posted on Wed, 16 Dec 2009 at 11:30 | permanent link | 8 Comments
I don't like the spec. that this implements. There's no way to do the message answering and dismissal that we talked about at Summit. Nor a way to do a good music player interface. I like the idea and spirit of the work but am looking forward to a better DBus API than the one proposed by KDE.
For messaging we have already created a different API that makes a little more sense. It's what we're using in the messaging menu and is at http://launchpad.net/libindicate
Looks nice!
Any thoughts about integration with Gnome 3? The Gnome Shell panel seems to be quite different (no applets).
Would be nice if this allowed things like arranging the systray(-like?) items in a certain order, maybe depending on the type or perhaps even per-application (e.g.: put mail and rss items before all other items, or put network before mail and mail before rss, etc.).
Agree with Jason -- the DBus specification is frankly a bit mental.
Looks nice, and the fact that it is going to be a spec backed by XDG makes it all more relevant. Congrats.
@Ben, it does using the ID. We also plan on using the category for sorting. That way things that are related end up close together.
@Ross, I think that the spec is a bit complex, but that's why we're only using a subset of it and adding a very simple menu property. Considering the amount of work that's gone into development on the KDE side already I think that drastically changing it isn't useful. Most fields are optional.
Oops, sorry. I forgot to repsond to Fabio :)
I'd love it if GNOME Shell would consider picking this up. I think it would be better than the systray support hat they have now. It is roughly the same WRT to applets in the panel. These aren't applets in the traditional sense, but do provide some of the same customizable functionality for application developers.