Posted on January 14, 2010 - by jono
Application Indicators Rocking The House
Something we have been spending some time working on in this cycle has been fixing the mess that is the system tray. This is based upon an awesome specification submitted to Freedesktop by KDE. The spec has been implemented by KDE, we have written an implementation for the GNOME panel and it will ship in Ubuntu 10.04 Lucid Lynx Alpha 2. We have also started adding application indicator support to many of the applications we ship in Ubuntu, and of course these patches are going upstream as they are written. I would to encourage GNOMErs to join the discussion on the XDG list regarding the spec.
I think the Application Indicator framework rocks. It solves a problem that has niggled me for years: with it system tray applets now have a consistent UI in terms of spacing, a unified left click to access the menu (no more confusing different left/right menus in different apps), you can scrub between icons, KDE applications render their application indicator menus in GNOME as GTK menus and vice versa and the whole shebang is a lot more accessible.
The Application Indicator team have produced C, Mono and Python bindings and documented it all on this wiki page. I wanted to have a play with it with Python so I knocked together a simple little script that demos how it works:
#!/usr/bin/env python
#
# [SNIPPET_NAME: Create an Application Indicator]
# [SNIPPET_CATEGORIES: Application Indicator]
# [SNIPPET_DESCRIPTION: How to create an application indicator and add items to it]
# [SNIPPET_AUTHOR: Jono Bacon <jono@ubuntu.com>]
# [SNIPPET_LICENSE: GPL]
import pygtk
pygtk.require('2.0')
import gtk
import appindicator
class AppIndicatorExample:
def __init__(self):
self.ind = appindicator.Indicator ("example-simple-client", "indicator-messages", appindicator.CATEGORY_APPLICATION_STATUS)
self.ind.set_status (appindicator.STATUS_ACTIVE)
self.ind.set_attention_icon ("indicator-messages-new")
self.ind.set_icon("distributor-logo")
# create a menu
self.menu = gtk.Menu()
# create items for the menu - labels, checkboxes, radio buttons and images are supported:
item = gtk.MenuItem("Regular Menu Item")
self.menu.append(item)
check = gtk.CheckMenuItem("Check Menu Item")
self.menu.append(check)
radio = gtk.RadioMenuItem(None, "Radio Menu Item")
self.menu.append(radio)
image = gtk.ImageMenuItem(gtk.STOCK_QUIT)
image.connect("activate", self.quit)
self.menu.append(image)
self.menu.show()
self.ind.set_menu(self.menu)
def quit(self, widget, data=None):
gtk.main_quit()
def main():
gtk.main()
return 0
if __name__ == "__main__":
indicator = AppIndicatorExample()
main()
To make this as helpful as possible for people I have added it to python-snippets which you can of course enjoy using my little Acire tool that I blogged about recently. If you want to give it a go, I recommend you use it with another app that uses Application Indicators, and then you can play with scrubbing between icons and using the arrows on your keyboard to move around. It is pretty awesome.
To continue playing with it I thought I would have a go at writing an application indicator plugin for the always awesome Getting Things GNOME. I only had time spend an hour or so on it last night, but my work in progress is available in this branch. Most of it is complete, but what I am missing from the framework is a signal when a user clicks on the indicator icon: I need this to re-generate the dynamic list of tasks in that menu. I spoke to Ted Gould about it and he said this is likely to be added in the future. When it is ready I will propose it to upstream GTG for inclusion. 
16 Comments
We'd love to hear yours!
Leave a Reply
Here's your chance to speak.
-
Flickr Photos
Visit My Website
January 14, 2010
Permalink
Sorry for complaining…. but here goes
The problem isn’t applicaton indicator styling or inconsistency among closely related objects. The inconsistency stems from objects that aren’t supposed to be there. Basicly applications like empathy,rhythmbox
We already have application representation (taskbar). Improve that, so no applications needs to use notification area.
So the worst part is the naming, calling it ‘application indicator’ is exactly what’s not suppused to be there, why not let the application representation (taskbar) be tasked for notification? Yes the current highlight animation sucks and is extremely limited – fix that instead?
Visit My Website
January 14, 2010
Permalink
Also, I think part of the benefit of the new specification is that it is declarative, abstract from its presentation. So if someone wrote a system for incorporating the menus into your taskbar/dock, they could do it without the cooperation of the individual application developers. I think your idea is a great one! And this seems to be a step towards making it possible.
Visit My Website
January 14, 2010
Permalink
that would be great too.
if docky would remove the tray-icon from the tray for all apps I have on it, and use the tray menu itself.
good idea!!
Visit My Website
January 15, 2010
Permalink
I think that’s the way Docky does, with its “helpers”. You can activate plugins for some applications, like Banshee, Transmission or Pidgin. Those plugins can for exemple give you the current track covert art instead of your player icon and multimedia control with right-click (for Banshee), you can also have your last opened documents (with the integration of Zeitgeist), etc… I think it’s really the right way to go, because coders have not to modify their software, but someone has just to create a dedicated plugin for the application he wants.
I really would like to see something similar in Gnome 3.x…
– Non-native english speaker
Visit My Website
January 14, 2010
Permalink
Oops, looks like my first comment got eaten.
I was basically asking this: Have you tried the standalone version of docky? It has plugins to do this for various applications. One of the problems, however, is that in the current system, some of those applications don’t allow you to disable the tray icon. Tomboy in particular comes to mind.
Try it, and let us know what you think.
Visit My Website
January 15, 2010
Permalink
I like to think that application indicators are to describe background tasks. The API is shaped in a way that feels a lot less suited to one-off notifications, as in the current notification area (which is generally used for system status icons by default).
It would be nice to have these menus attached to application launchers, I agree (and those launchers attached to an application’s windows in turn). As mentioned, the declarative design renders this fairly doable
As an extra bonus, the way these are categorized means that system indicators like volume and battery could be placed on the top right as usual.
On the other hand, we have a conveniently empty space for active operations and things wanting attention. THAT would be the window list. I think that’s where minimized windows, urgent windows and notifications like new messages should appear.
I think these need to be strongly detached, with notifications (both the bubble and the lasting button somewhere) need to be in the same API. GNOME Shell’s Messaging Tray seems to be doing that, nicely enough.
Unfortunately, I do feel that Ubuntu’s OTHER movement, with the message indicator, is going to pollute the scope of this technology and drop us right where we left off by encouraging developers to use the app indicator specification for one-off messages.
Visit My Website
January 15, 2010
Permalink
I agree. I’ve yet to read the new spec but I’m a bit worried about reinventing the infamous MS systray : http://ploum.frimouvy.org/?219-the-aristocratic-desktop-part-3-there-s-no-tray-icon-in-gnome
Visit My Website
January 14, 2010
Permalink
The menu-like behavior is great, because sometimes I click the wrong icon.
and this is the main problem, the icons are so small, they should be the main interaction between me and the program (like tomboy for example).
so what I prefer is writing better app-specific support into gnome-do.
then you just have to type the tasks, and not click that tiny icon first and select the stuff.
this works very well for me so far, but it only supports a handful of apps.
excited to see how GNOME 3.0 will use the tray.
main annoyance in gnome 2.x is that you have multiple indicator (tray and app-bar/doc/whatever).
Visit My Website
January 14, 2010
Permalink
@Frej Soya: I do not use a taskbar in my Plasma desktop. And not all applications that may notify/indicate have windows. But still I like that idea, a taskbar-notification-indicator hybrid.
Visit My Website
January 15, 2010
Permalink
Yes when using a dock there is no need for a taskbar, by removing it you create space on the desktop
Visit My Website
January 15, 2010
Permalink
Nice! That will (hopefully) make things a bit more clean and consistent. Although I’d love to see a desktop policy about the cases in which to use the application inicator framework to go along with the api specification.
Visit My Website
January 15, 2010
Permalink
The main problem is that apps shouldn’t be putting this sort of stuff on the panel at all… it was a vaguely useful notion back in 1995, when Windows first popularised it, but we should be thinking way outside that particular box by now.
Visit My Website
January 17, 2010
Permalink
This is a great step forward. Thanks also for the straightforward Python API — it looks very similar to gtk StatusItem code, should be easy to convert (or allow either conditionally).
Anyway, it’s hurting us every day that the linux desktop has no application object, and this is another sign of that. We have application launchers (.desktop), windows, processes and status icons and libunique, but nothing to tie this together. I don’t give much for all the ad-hoc solutions out there, but kudos to those who try.
Visit My Website
January 18, 2010
Permalink
I have a question. Why is it that KDE always has to implement everything GNOME does. Why doesn’t GNOME start implementing stuff done by KDE.
Visit My Website
February 10, 2010
Permalink
Hi Jono, I completed the work on your branch, and commited it to trunk. Now Getting things GNOME embraces appindicate.