Making your app appear in the Indicators - Instructors: tedg

   1 [19:00] <ClassBot> Logs for this session will be available at following the conclusion of the session.
   2 [19:01] <tedg> Howdy folks.
   3 [19:02] <tedg> My name is Ted and I work at the Canonical Desktop Experience team.
   4 [19:02] <tedg> Specifically I work with the various indicators, I like to joke that "I control the upper right corner of your screen" ;-)
   5 [19:02] <tedg> But, that's really not the case.
   6 [19:03] <tedg> Really what we do is expose the functionality that is in the system to the user.
   7 [19:03] <tedg> *and* probably more importantly, the information that comes from applications.
   8 [19:03] <tedg> This session is about getting that information out of the applications and handing it up to the indicators.
   9 [19:04] <tedg> We're going to cover quickly a few different ways, and then I'll take questions as long as you guys have 'em to go more in depth.
  10 [19:04] <tedg> Specifically, I'm going to cover messaging menu, application indicator and the sound menu.
  11 [19:04] <tedg> So, let's get started.
  12 [19:05] <tedg> I'm going to start with the messaging menu because it's the oldest (and I couldn't figure out any other ordering that made sense)
  13 [19:05] <tedg> The spec for the messaging menu is here:
  14 [19:05] <tedg> I think what makes the most sense to look there is at the rationale.
  15 [19:05] <tedg> It's a menu that is designed to handle human-to-human communication in an aggregated way.
  16 [19:06] <tedg> It's like you communicate with people in a variety of ways, but not all of those need icons on your panel.
  17 [19:06] <tedg> So if you're looking at an application that does that, how do you integrate?
  18 [19:06] <tedg> You use libindicate, which allows your application to indicate on dbus that you have messages.
  19 [19:07] <tedg> libindicate hides all the dbus stuff, so you don't need to worry about that, it's more about representing the info you have.
  20 [19:07] <tedg> So where is it?  The source for the library itself is at
  21 [19:07] <tedg> It has both the client and the server, but chances are you'll only need one of those.
  22 [19:07] <tedg> And that's the server.
  23 [19:08] <tedg> The client is used by the menu itself, and put into a single library so they always remain consistent
  24 [19:08] <tedg> Let's look at an example in Python:
  25 [19:08] <tedg> This is a simple "IM Client"
  26 [19:09] <tedg> thought it really only makes a single entry in the messaging menu.
  27 [19:09] <tedg> And it tells the messaging menu that it's really Empathy.
  28 [19:09] <tedg> I don't recommend lying in your code :-)
  29 [19:10] <tedg> As we look at that example you can see that the code grabs the default server and sets some properties on it.
  30 [19:10] <tedg> The most significant here is the desktop file as we use that to get a bunch of information like the icon and name of the application out of there.
  31 [19:10] <tedg> Your application probably already has a desktop file, just throw the path to it in there.
  32 [19:11] <tedg> Then it creates an indicator.  These are the items under your application in the messaging menu.
  33 [19:11] <tedg> This one is a time based one as you see the time gets set there.
  34 [19:11] <tedg> But there can also be count based for applications like e-mail programs that have mailboxes.
  35 [19:12] <tedg> There are design guide lines for how various applications should integrate.
  36 [19:12] <tedg>
  37 [19:12] <tedg> Obviously that doesn't cover all applications, but it should be enough to get you started.
  38 [19:13] <tedg> You can also set properties like whether the envelope changes color or not as well.
  39 [19:13] <tedg> And sort the various items.
  40 [19:14] <tedg> There is also the ability to put custom menu items on the menu, but I'm not going to go into that today unless there are some questions.
  41 [19:14] <tedg> Second up is application indicators.
  42 [19:14] <tedg> You can find out some about the design of those guys here:
  43 [19:15] <tedg> And a bit about their rationale.
  44 [19:15] <tedg> One of the things that they're targeting is allowing applications that are long running and need to put status of some type on the panel, to do so in a consistent way.
  45 [19:15] <tedg> The way that we've chose is an icon (possibly with a label) and a menu.
  46 [19:16] <tedg> This allows the entire top of the screen to behave like a menu bar.
  47 [19:16] <tedg> Application indicators are based on the KDE Status Notifier Item spec, but to create one you can just use libappindicator.
  48 [19:17] <tedg>
  49 [19:17] <tedg> This is a small library that implements the KSNI spec over dbus and provides an easy way to support it in your application.
  50 [19:17] <tedg> It also provides an internal fallback to using the status area on desktops that don't support KSNI.
  51 [19:17] <tedg> So you don't have to do that fallback in your application manually.
  52 [19:18] <tedg> For those who are already familiar with libappindicator, we've got some new features this cycle.
  53 === tyler is now known as Guest71989
  54 [19:18] <tedg> First off, it's now it's own library.  Which will hopefully ease its adoption by other distros.
  55 [19:19] <tedg> There's no need to pull in the entire indicator stack just for providing libappindicator.
  56 [19:19] <tedg> We're also supporting actions on middle click.
  57 [19:19] <tedg> This is a tricky one, as we don't want to create undiscoverable functionality.
  58 [19:19] <tedg> So what we've done is allow for a menu item that's already in the menu to be specified to receive middle click events.
  59 [19:20] <tedg> This way that functionality is always available, and visible, to the user.
  60 [19:20] <tedg> But power users can get some quick access to it if they choose.
  61 [19:20] <tedg> We have some design guidlines for the app indicators.
  62 [19:20] <tedg>
  63 [19:21] <tedg> The important thing to remember, is that app indicators aren't the end all be all of what you want.
  64 [19:21] <tedg> There's been a long tradition in computing of doing stuff like this for every application, but that doesn't mean it's right :-)
  65 [19:21] <tedg> We'd love it if people would integrate with the other category indicators (messaging, sound, etc.) before building their own.
  66 [19:21] <tedg> Also, for many applications, launcher integration makes more sense.
  67 [19:22] <tedg> (I believe Jason just talked about that, no?)
  68 [19:22] <tedg> So remember all of those options before you choose an applicaiton indicator
  69 [19:22] <tedg> Now, if you do, it's easy to do :-)
  70 [19:23] <tedg> Here's a simple client, that does everything possible (except middle click)
  71 [19:23] <tedg> Now it's a bit more complex than you need really.
  72 [19:23] <tedg> As it has dynamic items and changes status, but it does show you the full spectrum of possibilities.
  73 [19:24] <tedg> There's a C version as well
  74 [19:24] <tedg>
  75 [19:24] <tedg> The most important part is here:
  76 [19:24] <tedg>
  77 [19:24] <tedg> Where it creates the new object.
  78 [19:24] <tedg> It has a name and an icon.
  79 [19:25] <tedg> And a category.
  80 [19:25] <tedg> Then you build up a standard GTK menu, and you set it here:
  81 [19:25] <tedg> Your menu doesn't need to be as long.
  82 [19:25] <tedg> But it's neat to see the things you can do there.
  83 [19:25] <tedg> As far as signals go, you can just attach to the standard GTK ones on the menu items.
  84 [19:26] <tedg> libappindicator will synthesize them for you.
  85 [19:26] <tedg> So there's nothing to learn other than standard GTK menus.
  86 [19:27] <tedg> So while the example is longer, there's only those two critical spots.
  87 [19:27] <tedg> Okay, just checking my notes... think I got everything :-)
  88 [19:28] <tedg> Last up is the newest in our bunch, the sound menu.
  89 [19:29] <tedg> The sound menu takes care of all your sound related stuff.
  90 [19:29] <tedg> Again it uses a standard protocol, MPRIS, but we've provided a smaller library that implements the critical functionality.
  91 [19:29] <tedg> In this case, it is a couple of interfaces in libunity.
  92 [19:29] <tedg>
  93 [19:30] <tedg> There's no need for you to learn DBus or MPRIS, you can ust use the MusicPlayer interface there.
  94 [19:30] <tedg>
  95 [19:30] <tedg> It provides your basic setting of playlists and getting signals for play/pause/next/prev type controls.
  96 [19:31] <tedg> So as soon as you set up one of those objects, your application will get a full music player control in the sound menu.
  97 [19:31] <tedg> Just like Rhythmbox or Banshee.
  98 [19:31] <tedg> It doesn't matter if you're getting the sound off the web, or local files, or how you get the music.
  99 [19:31] <tedg> That's up to you :-)
 100 [19:32] <tedg> Let's look at an example
 101 [19:32] <tedg> here's a "TypicalPlayer" object
 102 [19:32] <tedg>
 103 [19:32] <tedg> You can see how it sets the metadata for the song
 104 [19:33] <tedg> And even the album art
 105 [19:33] <tedg> And create a playlist as well.
 106 [19:33] <tedg> The typical player then sets up signals for the various buttons.
 107 [19:33] <tedg> This is part of the test suite, so it doesn't implement all of the backend for this.
 108 [19:34] <tedg> But it provides a good show of how you can connect into the object.
 109 [19:34] <tedg> You'll also see on line 56:
 110 [19:34] <tedg> That it builds a small menu for custom items like setting your preference for the song.
 111 [19:34] <tedg> This can help with something like a Pandora client, where we want more information quickly available to the user.
 112 [19:35] <tedg> These are standard menu items so you can make them check boxes, radio buttons, or what ever you wish.
 113 [19:35] <tedg> There's not a whole lot of magic there, but that's largely because libunity takes care of all of that for you :-)
 114 [19:36] <tedg> Lastly, I wanted to talk about the TODO list a little if this interested you but you didn't have an application specifically that you wanted to work on.
 115 [19:36] <tedg> One of the big things that we did in this cycle was ensure that we had GObject Introspection bindings for all the indicator libs.
 116 [19:37] <tedg> We'd like to drop all the hand coded ones.
 117 [19:37] <tedg> But to do that we need all the applications currently using them in non-C languages to port over.
 118 [19:37] <tedg> So if you're interested in helping out, we'd love some help there.
 119 [19:37] <tedg> Also, we need to port the various examples over to using the GI bindings.
 120 [19:38] <tedg> To make it easier for new people coming in to using them.
 121 [19:38] <tedg> So, that's the end of my notes on the various ways for applications to integrate with the indicators.
 122 [19:39] <tedg> I hope that gives everyone a good introduction to the possibilities
 123 [19:39] <tedg> Does anyone have questions or want me to dive deeper into any of the topics?
 124 [19:41] <tedg> Great!  Thanks everyone.
 125 [19:42] <tedg> Come grab me in #ayatana if you think of anything later

MeetingLogs/appdevweek1109/AppIndicators (last edited 2011-09-09 18:27:50 by dpm)