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:
(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:
(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:
(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
(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:
(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:
(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:
(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:
(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.
(03:35:43 PM) tedg: jacob, That is basically the icon policy that GNOME and Ubuntu would like to get to.  Unfortunately we're not close to that overall.
(03:36:01 PM) tedg: jacob, So hopefully all applications, even with icons on, will end up with something similar.
(03:36:58 PM) tedg: matttbe, We try to release version every week for Maverick on Thursdays.
(03:37:29 PM) tedg: matttbe, Those in general are pretty stable as we use a Continuous Integration server to make sure they all pass the test suite on every commit.
(03:37:38 PM) tedg: matttbe, But, I'm sure there's bugs -- it's software :)
(03:38:29 PM) tedg: Back to talking about new things we want to provide a way for applications to control some of their ordering, and also allowing users to override this.
(03:39:07 PM) tedg: The idea being that if you have two applications, say Getting Things GNOME! and Hamster, you probably want those two next to each other.
(03:39:14 PM) tedg: It makes a lot of sense.
(03:39:44 PM) tedg: For the first pass we'll probably just provide the mechanisms without any UI or real configurability, but we want to grow that in the future.
(03:40:11 PM) tedg: As currently the order is dependent on the users system, so even from Ubuntu machine to Ubuntu machine they could be different.
(03:40:37 PM) tedg: This increases "support costs" as if someone calls you on the phone you get to describe the icon instead of saying the "third one"
(03:41:44 PM) tedg: Last up we want to provide a way to associate the AppIndicator item with the desktop file.
(03:42:09 PM) tedg: So we're working with the KDE folks to come up with a key in the desktop file to hold the AppIndicator IDs.
(03:42:31 PM) tedg: This will give us a static way to determine which applications we can expect application indicators from.
(03:42:43 PM) tedg: We hope to use this to provide better user experiences in the future.
(03:43:07 PM) tedg: I think the Unity guys might try to get things into Maverick, but I doubt we'll use it for anything in Desktop for Maverick.
(03:43:40 PM) tedg: Okay, so that's all the material that I wanted to go through.
(03:43:46 PM) tedg: Is there any other questions?
(03:44:45 PM) tedg: sao, I believe that the Weather Indicator is being written in Vala.  jcastro do you have a link?
(03:46:12 PM) tedg: jacob, There is currently an applet that you can install called "indicator-applet-complete" that brings all the indicators into a single menu bar.  I doubt that we'll use that by default in Maverick, but that's the call of the Ubuntu Desktop Team.  The main issue being that the clock indicator doesn't provide all the functionality of the GNOME Applet yet.
(03:46:29 PM) tedg: jacob, Though, personally, I've switched as I think the tradeoff is worth it.
(03:47:42 PM) tedg: Okay, thanks everyone for attending.
(03:47:54 PM) tedg: I'm usually in #ayatana or #ubuntu-desktop if you have further questions.
(03:48:09 PM) tedg: Or you can join the Ayatana mailing list at
(03:48:36 PM) tedg: Sorry, that should have been
(03:48:54 PM) tedg: One is the projects, the "~" is the mailing list.

MeetingLogs/devweek1007/AppIndicators (last edited 2010-07-14 20:02:36 by ausimage)