Dev Week -- Getting your application in the panel -- ted -- Wed, Jan 27
1 [19:01] <didrocks> soren will now discuss about Automated server testing :) 2 [19:01] <didrocks> oups 3 [19:01] <didrocks> sorry, tedg's turn 4 [19:02] <didrocks> from the awesome dx team and indicator applet's hacker 5 [19:02] <tedg> Cool, thanks cjohnston! 6 [19:02] <cjohnston> yup 7 [19:02] <tedg> I was yelling, but it was no good :) 8 [19:02] <tedg> Howdy everyone. 9 [19:03] <tedg> This is the session on AppIndicators 10 [19:03] <tedg> Or I guess "Application Indicators" but I'll use AppIndicators for short. 11 [19:04] <tedg> Basically what AppIndicators are is a way for applications to add extra things to the panel for functionality that is continuously used throughout a users session. 12 [19:04] <tedg> For the most part, there aren't a lot of applications that users need all the time, so it's important to think about whether an application needs an AppIndicator before starting. 13 [19:05] <tedg> Some of the design considerations that you should take into account are available here: 14 [19:05] <tedg> https://wiki.ubuntu.com/CustomStatusMenuDesignGuidelines 15 [19:06] <tedg> One of the key values of AppIndicator that makes it a little different that the legacy notification area in the Freedesktop world (and systray in win32) is that it restricts every application to having a menu. 16 [19:06] <tedg> This is a tradeoff. 17 [19:06] <tedg> We want something that let's applications do really cool stuff and provide rich functionality to users, but at the same time we want the user to know what to expect when the click on an icon. 18 === zen is now known as Guest20508 19 [19:07] <tedg> With the old notification area, users didn't know what to do. They learned it, but they didn't know, and often made mistakes. 20 [19:07] <tedg> This predictability will hopefully make users feel more comfortable using Ubuntu. 21 [19:07] <tedg> Some of the usability rationale is here: 22 [19:07] <tedg> https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators 23 [19:08] <tedg> Of course, as you go down that page you'll start to realize that we do have migration issues. 24 [19:08] <tedg> If we removed the notification area in a signal release, that would suck for both users and app developers as there'd be no way to port all those applications in one cycle. 25 [19:08] <tedg> So, for Lucid, there will still be a notification area, but we want to get rid of it ASAP. 26 [19:09] <tedg> I hope we can for Lucid + 1, but we're planning to make the final decision there at UDS. 27 [19:09] <tedg> You can see our planes in abstract fashion here: 28 [19:09] <tedg> https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Proposed%20changes 29 [19:10] <tedg> So, then, that leads to: How do you do it? 30 [19:10] <tedg> :) 31 [19:10] <tedg> What we did is provide a small convenience library called libappindicator which provides the basic interface for adding an application to the panel. 32 [19:11] <tedg> At a high level you give it an icon, and a standard GTK menu, and it does the rest. 33 [19:11] <tedg> Though, it's likely that many applications will want to move slightly beyond that. 34 [19:12] <tedg> Let's first look at a sample little program in Python. 35 [19:12] <tedg> because well, python make jonobacon25 happy :) 36 [19:12] <tedg> https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Python%20version 37 [19:12] <tedg> If you look at that python snippet one of the most important things is the object creation. 38 [19:13] <tedg> appindicator.Indicator ("example-simple-client", "indicator-messages", appindicator.CATEGORY_APPLICATION_STATUS) 39 [19:13] <tedg> Basically there are three parameters. 40 [19:13] <tedg> The first is a unique ID for your application. 41 [19:14] <tedg> In most cases this will be the program name, package name, or something that is unique to your app 42 [19:14] <tedg> The second is your default icon. In this example the indicator-message icon is being stolen. Any icon in an icon theme can be used. 43 [19:14] <tedg> Lastly is the category that your app indciator is in. 44 [19:14] <tedg> This category is used for general grouping of the app indicators. 45 [19:15] <tedg> This creates the basic object that is the app indicator. But, you also need a menu. 46 [19:15] <tedg> Basically that is done with: ind.set_menu(menu) 47 [19:16] <tedg> The rest of the code is standard PyGTK code for creating the menu. 48 [19:16] <tedg> Let me grab some questions here. 49 [19:16] <tedg> jwendell: QUESTION: why to do this if panel is about to dead anyway? 50 [19:16] <tedg> jwendell: I don't think panels in general are dead. GNOME Panel is, but that's only a small part of this. 51 [19:17] <tedg> jwendell: The overall user experience change is what we're pushing right now, the gnome-panel applet is a small part of that. 52 [19:17] <tedg> ripps818: QUESTION: Are there going to be vala bindings? 53 [19:17] <tedg> ripps818: Yes, there's actually a patch for that now. I just need to get it merged in. 54 [19:18] <tedg> ripps818: I'll find the bug number for you afterwards, ping me. 55 [19:18] <tedg> qense: QUESTION: GNOME Shell is developing things that replace the functionality of AppIndicator, Notify OSD, MeIndicator, etc almost exactly. Is Ayatana working there as well, or is this duplicating of effort? 56 [19:19] <tedg> qense: I hope that they won't duplicate all of this effort. 57 [19:19] <tedg> qense: They're working on various things, but mostly I believe they've used some existing specs like the notification area so far. 58 [19:19] <tedg> qense: I hope that they'll use some of this work when they go beyond this. 59 [19:20] <tedg> qense: But, of course, I can't force them to take our code. 60 [19:20] <tedg> qense: :) 61 [19:20] <tedg> Okay, I think I caught up on some of the questions. I'll continue on for a bit to collect some more :) 62 [19:21] <tedg> So we went through some of the basic code to create an AppIndicator. 63 [19:21] <tedg> This is the core boiler plate, but I want to talk about a few other bits that are in the examples. 64 [19:21] <tedg> One of the things that the appindicator library provides is an easy way to switch between an attention icon and a standard icon. 65 [19:22] <tedg> First you'll need to set the AttentionIcon using a call like this: ind.set_attention_icon ("indicator-messages-new") 66 [19:22] <tedg> That basically just puts the icon in queue for when the status gets changed. 67 [19:23] <tedg> And then you can call "set_status" like this: 68 [19:23] <tedg> ind.set_status (appindicator.STATUS_ACTIVE) 69 [19:23] <tedg> There are three statuses (statusi ?) 70 [19:23] <tedg> Passive, which means the icon isn't shown. Active, which shows the default icon. And Attention, which uses the attention icon. 71 [19:24] <tedg> Many apps do something like this where you'd have a basic icon in a standard state, then when something like you have a task to complete, it switching to an icon that draws the users attention. 72 [19:25] <tedg> Those are probably the most interesting parts of the libappindicator API for app developers. 73 [19:25] <tedg> The full API (in C) is available here: http://people.canonical.com/~ted/libappindicator/current/AppIndicator.html 74 [19:26] <tedg> It has all the functions you could possibly love :) 75 [19:26] <tedg> npmccallum: tedg: QUESTION: One of the biggest advantages of the standard GtkStatusIcon (and I know Qt has something similar) is cross-platform support. What is the cross-platform support plan for AppIndicators? 76 [19:26] <tedg> npmccallum: Thanks, I forgot to mention that :) 77 [19:27] <tedg> npmccallum: We've based all of this work on a spec developed and released by the KDE developers. 78 [19:27] <tedg> npmccallum: It's call StatusNotifierItem and it's currently being discussed on the XDG list for official Freedesktop.org status. 79 [19:28] <tedg> npmccallum: So we hope for Lucid to provide an experience where KDE apps will run under GNOME with native menus and look beautiful. 80 [19:28] <tedg> npmccallum: And integrated with the desktop as a whole. More than with the notification area previously. 81 [19:28] <tedg> AnAnt: QUESTION: is there a screenshot (or video) showing AppIndicators in action ? I saw some video few days ago, but I figured nothing from it 82 [19:29] <tedg> AnAnt: The only video I have is an early demo that I put on my blog. 83 [19:29] <tedg> AnAnt: http://gould.cx/ted/blog/Having_a_tidy_systray 84 [19:29] <tedg> AnAnt: It just has a few of the same, but kinda shows them working. 85 [19:30] <tedg> npmccallum: BTW, here's the spec: http://www.notmart.org/misc/statusnotifieritem/ 86 [19:30] <tedg> qense: QUESTION: Does it do flickering and yelling and fireworks? Or just another icon? 87 [19:31] <tedg> qense: Just another icon. The goal here is to use icon names for the different visualizations so they can be better matched to the panel theme in general. 88 [19:31] <tedg> qense: Also, in general, I dislike the <blink> tag :) 89 [19:31] <tedg> npmccallum: tedg: QUESTION2 - How about rendering icons on the fly? I have an app that currently draws the icon on the fly with cairo and renders into a pixbuf, then displays with GtkStatusIcon. Can I do this with AppIndicators? 90 [19:32] <tedg> npmccallum: No, for the same reason as above. 91 [19:32] <tedg> npmccallum: tedg: QUESTION1 revisited - I meant cross-platform as in win32 and mac 92 [19:33] <tedg> npmccallum: The libappindicator will fallback and create a GtkStatusIcon if there is no Application Indicator service availabe. 93 [19:33] <tedg> npmccallum: So I would image that it would work on win/mac like the current status icon. 94 [19:33] <tedg> npmccallum: Though I haven't tested it or tried. 95 [19:34] <tedg> I wanted to talk a little more about the fallback. 96 [19:35] <tedg> The way that the fallback is implemented is that it's a set of two functions that are on the class of the AppIndicator. 97 [19:35] <tedg> Some applications may wish to provide a different fallback than what is set up by default. 98 [19:35] <tedg> To provide a different fallback what an app developer will need to do is to subclass the AppIndicator class and replace those two functions. 99 [19:36] <tedg> Actually, a good place to look for that example is in the app-indicator.c file. 100 [19:36] <tedg> As the two functions that are put there were designed to only use public API functions. 101 [19:36] <tedg> So you should be able to copy-and-paste them into your own code, and then modify what you'd like to change. 102 [19:37] <tedg> I wanted to talk a little about menus, and a good lead off is: 103 [19:37] <tedg> lantash58: QUESTION: Is there a reason why menu entries with icons are indented? See http://dl.dropbox.com/u/232786/indicator.png Will the still icons be dropped as seen in regular menus? 104 [19:37] <tedg> Yes the icons are indented. 105 [19:38] <tedg> This is an issue with being cross desktop. 106 [19:38] <tedg> The reason that they're not indented on GTK is that you can't have a check box and an image in the same item. 107 [19:38] <tedg> So they can both override that space with their own graphic. 108 [19:38] <tedg> But most toolkits don't have that restriction. 109 [19:39] <tedg> So we need to be able to do both in a consistent fashion, and thus the icons need to be indented as shown there. 110 [19:39] <tedg> In general, for Lucid we're supporting the basic menu types that are found in stock GTK. 111 [19:39] <tedg> Those are image item, label item, radio and checkbox. 112 [19:40] <tedg> While we certainly realize that people do more with menus than just those, the realities of a timed release schedule is that we don't get all we want :) 113 [19:40] <tedg> (and I need to sleep sometime) :) 114 [19:40] <tedg> So we expect to, for Lucid + 1 and beyond to start taking into account more complex menu needs. 115 [19:41] <tedg> For instance in Tomboy there are pins in the right gutter. 116 [19:41] <tedg> Or in KNetworkManager there are widgets to show signal strength. 117 [19:42] <tedg> These menus pose quite a challenge, but it's one I'm personally excited to take on. 118 [19:43] <tedg> Okay, that's all I have in my outline. 119 [19:43] <tedg> Are there more questions for me? 120 [19:44] <tedg> AnAnt: QUESTION: so how will clutter be reduced ? 121 [19:45] <tedg> AnAnt: We expect clutter to be reduced in a few ways. 122 [19:45] <tedg> AnAnt: The first is that a lot of clutter is disorganization, when things to feel like they connect together right. 123 [19:45] <tedg> AnAnt: By having a single interface (menu) we hope that the whole thing will feel more unified. 124 [19:45] <tedg> AnAnt: Secondly, but using icon names theme designers can do a specific "panel" theme that'll work across applications. 125 [19:46] <tedg> AnAnt: Where before that was nearly impossible as changing an icon would change it everywhere. 126 [19:46] <tedg> AnAnt: So if you changed the panel, in many cases you'd change the About screen too. 127 [19:46] <tedg> AnAnt: So we expect less visual clutter on the panel itself. 128 [19:46] <tedg> npmccallum: tedg: QUESTION: Would you consider adding a set_icon_with_number() API which would take a background icon and render a number on top of it? 129 [19:47] <tedg> npmccallum: Definitely consider it. I think I'd need to see some use cases for how it should work and all that jazz. 130 [19:47] <tedg> npmccallum: Jump onto the Ayatana mailing list and let's talk about it further. 131 [19:47] <tedg> npmccallum: Though, just incase my manager is listening, not for Lucid. Lucid + 1 ;) 132 [19:48] <tedg> qense: QUESTION: Is there a library for receiving the AppIndicator signals? 133 [19:48] <tedg> qense: For the most part there aren't that many AppIndicator signals, just a couple coming off the object itself. 134 [19:48] <tedg> qense: For most of the user actions they're routed into the various GTK menu items. 135 [19:48] <tedg> qense: So you can use the standard GTK signaling that is already in the rest of your application. 136 [19:49] <tedg> oskude: joined little late, so maybe i missed a question like this QUESTION - is there a tutorial to do an "applet" with a window that opens directly under the applet icon ? (like time/date/calendar/tasks/locations applet) 137 [19:50] <tedg> oskude: No, we'd really like people to think of this as "applications" and "menus" instead of doing pseudo menus like the calendar applet. 138 [19:50] <tedg> oskude: If you have specific features you'd like in a menu for an idea you have. 139 [19:50] <tedg> oskude: I'd like to talk about that, so we can make sure menus handle as many use cases as possible. 140 [19:51] <tedg> (obviously we don't want a mail client in a menu) :) 141 [19:52] <tedg> oskude: Yes, I'd agree. I think that a internet radio tracklisting is a usecase that we can put into a menu. 142 [19:53] <tedg> oskude: Draw it up, by hand, whatever. Throw it on the Ayatana list, and lets try to get that spec'd out for Lucid + 1. 143 [19:54] <tedg> I've said it a couple of times, but here's the link for the Ayatana mailing list. 144 [19:54] <tedg> https://launchpad.net/~ayatana 145 [19:54] <tedg> It's in Launchpad so you just have to join that team and you'll start getting mail :) 146 [19:56] <tedg> Cool, I think that pretty much wraps things up. 147 [19:57] <tedg> Thanks everyone for coming. 148 [19:57] <tedg> I'm usually in #ayatana on Freenode if something comes up. 149 [19:57] <tedg> Ping me there, or join the Ayatana mailing list above. 150 [19:57] <tedg> Thanks again!