Ubuntu Wiki

Dev Week -- Making your application shine with application indicators -- TedGould -- Wed, Jul 14th, 2010

(03:01:11 PM) tedg: I'm not sure if I'm comfortable being an "Instructor" (sounds so official), but hello everyone!
(03:01:30 PM) tedg: So this session is about Application Indicators.
(03:02:07 PM) tedg: For those who aren't familiar with them they're basically the small custom menus that are put in the panel by applications.
(03:02:34 PM) tedg: These provide extra functionality that is persistent.  Things like your music player, where you'll keep it running, but not want the full window all the time.
(03:03:03 PM) tedg: While we'd all love to have 40" screens, that's rarely practical, so we allow an easy way to do minimized status.
(03:03:27 PM) tedg: That doesn't mean that every application under the sun should have an application indicator.
(03:03:38 PM) tedg: For most it really doesn't make any sense what so ever.
(03:03:57 PM) tedg: It's rare that you'd want continuous status on your word processor for instance.
(03:04:34 PM) tedg: mpt has written up some practical guidelines on what should and shouldn't be an application indicator.
(03:04:42 PM) tedg: https://wiki.ubuntu.com/CustomStatusMenuDesignGuidelines
(03:05:03 PM) tedg: That page goes into a lot more, but it starts off talking about how to think about the application indicators.
(03:05:25 PM) tedg: Our long term goal with Application Indicators is to replace the Notification Area.
(03:06:14 PM) tedg: Which, has become a usability ghetto.  Everything behaves differently, which makes them difficult to use overall.  Sure you can learn them, but really you shouldn't have to.
(03:06:33 PM) tedg: For a discussion on the notification area and application indicators there a good post on the Canonical Design Blog.
(03:06:41 PM) tedg: http://design.canonical.com/2010/04/notification-area/
(03:07:09 PM) tedg: So to get to more predictability on how the icons behave, we took an opinionated tact to say that all of them are menus.
(03:07:37 PM) tedg: This provides some limitations, but it also can be a very flexible interfaces for providing rich functionality to users.
(03:09:00 PM) tedg: I just realized I wasn't in the chat room.
(03:09:03 PM) tedg: Sorry about that.
(03:09:16 PM) tedg: If people have posted questions please repost them.
(03:09:40 PM) tedg: Okay, back on track :)
(03:10:09 PM) tedg: So, how does all of this work?
(03:10:21 PM) tedg: The basis is the KDE Status Notifier Item specification.
(03:10:29 PM) tedg: http://www.notmart.org/misc/statusnotifieritem/index.html
(03:10:55 PM) tedg: KSNI provides an interface for status notifier items that is independent of how they can be displayed.
(03:11:21 PM) tedg: While we have a particular ideas on how that display should work, KNSI doesn't provide anything on that.
(03:11:47 PM) tedg: So it is possible to link KSNI supporting applications in a variety of displays, but we're not currently using any of those.
(03:11:55 PM) tedg: There are some available on KDE for Plasma.
(03:12:07 PM) tedg: On top of that we added the ability to export a menu across dbus.
(03:12:18 PM) tedg: That is implemented using the Dbusmenu protocol and librarly.
(03:12:33 PM) tedg: If you're interested in dbusmenu you can start on Launchpad at http://launchpad.net/dbusmenu
(03:13:03 PM) tedg: For the most part, application developers don't need to know anything about either of these protocols because they're hidden behind libappindicator which provides a pretty simple interface to both.
(03:13:57 PM) tedg: That interface is the AppIndicator object who's C Language documentation is available here: http://people.canonical.com/~ted/libappindicator/current/AppIndicator.html
(03:14:52 PM) tedg: Muscovy, Working windicators are on the todo list, but with the shorted development time in the Maverick cycle they probably won't make the Feature Freeze cutoff.
(03:16:02 PM) tedg: So if you're wanting to implement Application indicators there are a few guides available.
(03:16:15 PM) tedg: There is the reference documentation above, but you probably want one of the guides.
(03:16:24 PM) tedg: https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Porting%20Guide%20for%20Applications
(03:16:37 PM) tedg: The Wiki goes through examples in a variety of languages.
(03:17:00 PM) tedg: There are Mono, Python and Vala bindings in Maverick.  Including GObject Introspection support.
(03:17:12 PM) tedg: So I haven't heard of anyone doing it, but Javascript should work too :)
(03:17:53 PM) tedg: matttbe, I believe that we are using the same address as KSNI names, so KDE applications do work with the application indicators.
(03:18:26 PM) tedg: matttbe, We do register with dbus for two names, one for dbus activations purposes and the other to connect with the KSNI protocol.
(03:18:52 PM) tedg: On the topic of application work, I want to again mention the design guidelines.
(03:19:02 PM) tedg: https://wiki.ubuntu.com/CustomStatusMenuDesignGuidelines
(03:19:15 PM) tedg: The reason being is that many times an Application Indicator isn't what you need.
(03:19:37 PM) tedg: We don't want to end up in a situation where people need a 40" screen just to show all the app indicators!
(03:20:18 PM) tedg: It's also important to not that the category indicators like the Messaging Menu and/or the Sound Menu might be a better solution for your particular application.
(03:21:38 PM) tedg: matttbe, I'm not sure about Cairo Dock in particular, but if the address has changed we'd change too.  We're not intentionally using a different name.  I haven't switched to Maverick yet *blush* :)
(03:22:38 PM) tedg: So I wanted to talk a little about an issue that comes up a lot and that's falling back to the notification area.
(03:22:58 PM) tedg: Of course the default Ubuntu/UNE desktop isn't what everyone on the planet uses (we're working on it, not there yet :) )
(03:23:12 PM) tedg: So it's important that we can fallback to using something compatible in the end.
(03:23:34 PM) tedg: So libappindicator by default provides a fallback to a GtkStatusIcon that behaves very similar to the Application Indicators.
(03:24:15 PM) tedg: Some people don't necessarily want to make the same opinionated choices on the design when they're falling back.
(03:24:28 PM) tedg: Which is fine, but we don't take in enough information to do anything else.
(03:24:46 PM) tedg: So what we instead provide is a way to change how the fallback is handled via subclassing.
(03:25:04 PM) tedg: There is two virtual functions fallback and unfallback that can be used to handle the fallback differently.
(03:25:19 PM) tedg: This could include anything you possibly want, it's just a function call.
(03:25:39 PM) tedg: If you'd like to see an example of that there is a fallback test included in the test suite of libappindicator.
(03:25:47 PM) tedg: http://bazaar.launchpad.net/~indicator-applet-developers/indicator-application/trunk/annotate/head:/tests/test-libappindicator-fallback-item.c
(03:26:02 PM) tedg: For those who aren't C/GObject programmers there is a lot there that you dont' need to understand.
(03:26:16 PM) tedg: You're probably just most interested in the two functions.
(03:26:36 PM) tedg: In this case it marks the test as passed/failed based on the calls to the fallback/unfallback functions.
(03:26:58 PM) tedg: So, if you're using those functions, you know that they're tested as the test suite uses this feature as well :)
(03:27:18 PM) tedg: There is also a signal when a fallback occurs.
(03:27:36 PM) tedg: I don't think that this is as useful for implementing a fallback, but it could be used in other parts of your code.
(03:27:50 PM) tedg: That signal is "connection-changed" which will give you a boolean on the status.
(03:28:48 PM) tedg: Again, I don't really recommend that route for fallback, but you *could* do it if you wanted :)
(03:30:14 PM) tedg: When jcastro was asking me about doing this session he said "talk about what's new".  I want to stress, there is nothing new -- we're polishing at this point.
(03:30:31 PM) tedg: But that does introduce some change, but there shouldn't be any API breakage, just extensions.
(03:30:57 PM) tedg: One of the things that we're planning on supporting is KNSI's support for mouse scroll wheels.
(03:31:17 PM) tedg: We'll be adding signals to the object for the scroll event.
(03:31:36 PM) tedg: And then when the mouse is over your icon users can have a "power user" function with the scroll wheel.
(03:31:55 PM) tedg: The important thing to realize is that this isn't something most folks will find on their own, so don't make that a critical feature of the app.
(03:32:09 PM) tedg: Try to keep it something that your advanced users can use as they become more comfortable with it.
(03:32:50 PM) tedg: We're also working on adding label into the interface.
(03:33:05 PM) tedg: The reason for this is that some applications need custom icons with some text on this.
(03:33:06 PM) tedg: them
(03:33:16 PM) tedg: Things like the temperature or the batter percentage.
(03:33:18 PM) tedg: battery
(03:33:25 PM) tedg: (typing too much)
(03:33:46 PM) tedg: There is no reasonable way for them to really make these icons as they don't know the theme that the panel is rendering with.
(03:34:03 PM) tedg: So if they make an icon that has black text, they could end up on a dark panel and be unreadable.
(03:34:29 PM) tedg: You can see this today with the keyboard selector in gnome-settings-daemon.
(03:34:46 PM) tedg: We hope to fix that by rendering the test panel side.
...