Posted on December 17, 2009 - by jono
Application Indicators In Python
I am really excited to see Ted’s post regarding some of the improvements coming to the desktop notification area. This part of our desktop has become something of a wild west – icons look ugly, are spaced too close together, have left/right click inconstancy, often provide obscure and inaccessible widgets and cannot be easily controlled across notification icons with a single keyboard shortcut. This approach will fix many of these issues.
This approach has two distinctive components – the user interface improvements and the technology to implement. The user interface changes I think are really interesting and bring some distinctive benefits:
- Application indicators are more consistent – no more left and right-click inconsistency. Always left click to see the items.
- Scrubbing – you can click once on an app indicator and scrub left and right through other indicators with your mouse.
- More accessible – importantly, scrubbing also applies to the keyboard: this means you could bind a key to the indicator applet, hit that key and then use the arrow keys to navigate through all the indicators.
- Themable panel icons – you can set a specific icon to be a panel icon for an indicator: this should make it easier for creating single colour panel icons for light and dark themes.
- KDE/GNOME compatability – one thing that really excites me is that by using this spec, KDE applications running in GNOME will have their application notification menus rendered with GTK widgets and vice-versa.
I am really excited about the opportunities this brings to the desktop, and I am also really excited about us working with our friends in KDE on this spec.
I wanted to give this a roll in my more native Python tongue so I added the Karmic PPA and started playing with the module. I contributed my code as an example on the wiki. Here it is to show how it works:
import gobject
import gtk
import appindicator
if __name__ == "__main__":
ind = appindicator.Indicator ("example-simple-client", "indicator-messages", appindicator.CATEGORY_APPLICATION_STATUS)
ind.set_status (appindicator.STATUS_ACTIVE)
ind.set_attention_icon ("indicator-messages-new")
# create a menu
menu = gtk.Menu()
# create some labels
for i in range(3):
buf = "Test-undermenu - %d" % i
menu_items = gtk.MenuItem(buf)
menu.append(menu_items)
# this is where you would connect your menu item up with a function:
# menu_items.connect("activate", self.menuitem_response, buf)
# show the items
menu_items.show()
ind.set_menu(menu)
gtk.main()
I basically created an indicator object and threw a GTK menu into it and as if by magic my app appeared in the notification panel, properly spaced out and enjoying the benefits I mentioned above. Pretty simple. 
19 Comments
We'd love to hear yours!
Leave a Reply
Here's your chance to speak.
-
Flickr Photos
Visit My Website
December 17, 2009
Permalink
Jono,
What’s the string “indicator-messages-new”? Is it the name of an icon in the current theme or something?
Cheers, Rick
Visit My Website
December 17, 2009
Permalink
Yep, I believe so.
Visit My Website
December 17, 2009
Permalink
Rick,
Yeah, there is two icon names. One for when your status is ACTIVE and one for when your status is ATTENTION. The API allows for setting them at build time so then later when you want to swap, it’s just a simpler call.
Ted
Visit My Website
December 17, 2009
Permalink
Are there any plans to have separate areas for notifications and icons? Currently, many applications (NetworkManager, Transmission, VLC, Rhythmbox, Gwibber, etc) place an icon in the notification area. After a while, it becomes difficult to see the notifications between all the extra garbage.
“Oh boy OH BOY, NetworkManager is still running!”
It would be even better if there was a gconf key or similar configuration mechanism to hide icons entirely, or collapse them to a single Indicator Applet-style menu.
Visit My Website
December 17, 2009
Permalink
Yep, they should be more distinguishable in the future.
Visit My Website
December 17, 2009
Permalink
Dude, I don’t believe you. No screenshot, no proof :p I don’t want to install GNOME just to check this out homeskillet. Show me the pretties!
Visit My Website
December 17, 2009
Permalink
The best way to improve the notification area is to get rid of it. It’s an outdated idea that really has no place in a modern desktop, with a bit of lateral thinking. “Improving” it is simply holding us back in the Windows 95 era.
Visit My Website
December 18, 2009
Permalink
That’s a tad silly to say, since even Windows 7 uses its legacy system tray style notification area quite extensively
The roadmap, if memory serves me right, does include the old system tray being completely removed on a fairly aggressive schedule (Lucid+1, I think). The system allows different types of indicators to be categorized, so the system and hardware ones are each separated from the others, for example. It is very, very different from the existing design.
For the rest, I think there needs to be a safe landing place for applications that no longer fit on the panel with this spec. (Notification area abusers, eg: Basket Notes).
One possibility that springs to mind is to improve the launchers and the window list. Maybe the window list could just show important and minimized windows to reduce clutter, for example.
Visit My Website
December 17, 2009
Permalink
While I applaud this effort (such standardization has been needed for a long time), I’m concerned about implementation. The requirement of using menus is precisely what makes NetworkManager-applet so ugly, and many applications just simply can’t use it; for instance: volume control and zapplet (DISCLAIMER: I am the author of zapplet) use pop-up windows aligned to the icon. Pop-out buddy lists for communications are also hampered by this.
I’m also concerned about cross-platform support.
Do you know where the best place for feedback is?
Visit My Website
December 17, 2009
Permalink
I tried to leave a comment on Ted’s page, but it requires OpenID, which I don’t use.
Visit My Website
December 17, 2009
Permalink
Thanks for the input, Nathan. The plan is that for most applications, menus are suitable, but for some apps that require custom widgets that can’t be satisfied by menus, those apps will use other indicators or we will extend the spec. Ted can offer more input on this, I will ask him to weigh in here.
Visit My Website
December 17, 2009
Permalink
<
p>I agree, sometimes the menu restriction can lead to a weaker interface. It’s a trade off, right? With doing popup windows means you don’t get the benefits of it being a menu. Long term, I think that we’d like to start making menus a little bit richer. Of course they’ll never be popup dialogs, but I think that we can get a larger subset of the use-cases with a few improvements. We’re experimenting with that in the Lucid cycle with the Me Menu: https://wiki.ubuntu.com/MeMenu Lastly, we tend discuss the design of all parts of the Ayatana project on the Ayatana mailing list. You (or anyone else reading) can subscribe here: https://launchpad.net/~ayatana
Visit My Website
December 17, 2009
Permalink
What about cross-platform compatibility? As much as StatusIcon sucks, I can use it on Linux/Mac/Windows and it pretty much works.
Also, in Zapplet we embed a TreeView into the pop-up window so that we can handle (sometimes) 10s of thousands of rows. Menu will never work for us (unless you have some really cool menu improvements; perhaps you do).
And look at the latest NetworkManager-applet menu. I would argue that, even with its massive recent improvements, its still just too cumbersome.
I think it is precisely this rich format which needs some standardizing, otherwise we’ll end up with yet another wild-west scenario or worse, lots of applications cramming stuff into menus that should never be there. In conclusion, I promise this is not stop-energy. I really want to see something workable.
Say hi to Mark for me. I meant to stop by the office when I was in London a few weeks back, but never found time.
Visit My Website
December 17, 2009
Permalink
Also, I think it would be a mistake to ghettoize this discussion to the ayatana mailing list. Something this broad deserves much broader exposure. There are lots of programs that use StatusIcon that should be using this. They should all have an avenue for input into the design (though not design-by-committee of course).
Visit My Website
December 17, 2009
Permalink
“ghettoize”? I hardly think that discussing the usability direction of an upstream project on it’s mailing list is ghettoizing it.
Visit My Website
December 17, 2009
Permalink
My understanding was that it was a project for Ubuntu. I was just concerned that perhaps XDG be involved, GTK/QT devs, perhaps usability lists from other distros, etc. Perhaps I misunderstand Ayatana though… Not being an Ubuntu dev anymore, I’m probably just hiding under a rock.
Visit My Website
February 20, 2010
Permalink
is this all about adding menus and attaching it to a custom function?
Many paths lead to Rome (qt, kde scripting, ..)
What so special about this one? or I did not understand the source code. then sorry
Visit My Website
June 25, 2010
Permalink
That example is a bit buggy. But it doesn’t really matter.
One thing with python-appindicator I find troubling. Once you call ind.set_menu you can no longer add items to that menu. You can do all sorts of stuff to menu items (hide, show, change label), but you can’t add :/ new items. My guess is that when set_menu is called AppIndicator iterates through menu and picks all the items.
This awkward behavior makes AppIndicator in my case unusable. I need the ability to update items on the run.
Visit My Website
September 1, 2010
Permalink
It seems like a bad idea to replace panel applets with the buggy and poorly documented libindicator at this point.
It appears that when the developed application is run, the menu that is set is not directly used. It is packaged up and sent over dbus to the indicator-applet. This process is the source of countless weird bugs where menus don’t behave like normal due to problems in the translation. It seems like most of the function calls in the base classes have not been implemented in the translator.
I wouldn’t mind all the bugs if things were at least documented so that time wasn’t wasted trying to figure out why some function doesn’t work.
Make application indicators stable before you start talking about making it the only option.