Canonical Voices

What Ted Gould talks about

Searching Menus

One of the neatest parts about starting to get more application data into the open is that we can start to use it in interesting ways. I'm happy to talk about a new way that we're using the menu data: the HUD. The idea behind the HUD is that you can quickly find functionality in an application without having to know the menu structure. But how does it do it? How can you make it better?

Getting the data

We're using the same Dbusmenu data that is currently exported to the global menu, just remixing it for search. We are searching through the labels in the menu items which gives us already localized data straight from the application. This means that it should work for the language that the application is in. In the future we hope to use information like accessibility data as well as any tooltips that might be attached to a menuitem (though we don't show tooltips in the global menu).

Any application that works with the window menus today should also work with HUD out of the box.

Matching the label

To match the label we're basically using an implementation of the Levenshtein distance with a few additions. What this allows us to do is rank possible solutions in a relevancy order, and present some solutions that might occur via "fat finger" or other similar type errors. But, this also means that there is some fuzzy algorithms involved in the matching which will have to be tuned.

We expect to tune them over the next few releases, and to do that we have a set of test cases that we're using for the tuning. The problem with those test cases? They're only in the languages I speak. You probably speak in more/different/better languages than I do, please feel free to propose merges that extend this test suite so that as we continue to tune the search algorithms we don't leave any language behind.

Remembering Favorites

One of the additions that we add to the distance calculation is an offset based on which entries you've used most recently. Your favorite functionality in the application. Quite simply we're storing a list of items you've used over the last thirty days and a timestamp of when you used them. This database is simple but it can be fun to look into for the curious and I wanted to talk a bit about a couple of the tools that you can use to see the data.

$ hud-list-applications

This will list all the applications that have data on them in your HUD usage database. They are identified by the path to their desktop file as determined by BAMF. You can then look at the menu items used in a specific application:

$ hud-dump-application /usr/share/applications/inkscape.desktop 

This shows the individual items that you've used, and the number of times that you've used them. If you want to inspect the exact file tracking the data it is available at:

~/.cache/indicator-appmenu/hud-usage-log.sqlite

While talking about various tools to work with HUD I thought I'd also mention that you can also, just for fun, work with HUD from the command line using the command line tool:

$ hud-cli

Application initial bias

Application designers have always had a problem figuring out how to promote specific functionality that is commonly used to the forefront, while still making the rest of the functionality easily available. The most recent ways that they've done this is with toolbars and ribbon style. You can't adjust the positioning even when you know that the particular toolbar isn't best for the user because it will mess up the user's spacial memory. HUD sidesteps this issue by providing all the options, just promoting certain ones based on usage. They're all in the same place (the HUD) but with always improving ordering.

What happens on first usage of the application? At that point we don't have any way to know what the user wants to do, we we've provide a way for the application designer to provide the most likely items for general users. Effectively, this is the HUD's version of the default toolbar setup in an application; though it automatically decays and adjusts to the user's usage pattern.

The files that control this initial bias are very simple and there is an example in the test suite. Basically they have the various menu items along with a value that describes how to preload the usage database. A '5' there would mean that 5 entries are added to the usage database for that item on the first time that application is used; one for today and each of the four days previous. In this way, as values drop off by being too old, there isn't a step function in how the item is ranked, it just slowly drops down in priority. Application designers should start to think about how they would rank the menu items in their application, and start getting these integrated into either the releases or the packages of those applications so that users have a good first experience with their application.

Development notes

The code for the HUD lives in the indicator-appmenu repository. Currently it exists on a branch that needs to be reviewed before merging, but that shouldn't be for long. I expect it to get merged to trunk in the next couple of weeks.

After that the biggest change will be integration with indicator-appmenu. It was originally implemented as it's own service to make development more agile, but it clearly shares a large amount of data with the global menu and there's no reason to have two repositories in memory of the same data. It also needs to synchronize heavily with the application menu and BAMF, which is also already in indicator-appmenu. Thanks to the magic of DBus no one should notice the change in processes as the names and objects will migrate over to the new process.

As this is more of a first prototype there are also some missing features that need to be added. The first of those is to simply improve the matching. We also need to get better descriptions from application indicators, today we're using their accessibility description (you set those, right?) but that typically has too much information. Lastly, we need to integrate better with applications that expect the about-to-show signal for their menus. This includes XUL applications and some Qt ones, so it's an important feature for making the HUD usable for everyone.

Merges and bugs should be directed towards the indicator-appmenu project and also make sure you've signed the Canonical Contributor Agreement for any code contributed.

Comments: Identi.ca | Twitter

Read more

I'm excited about two new team members that we have, Thomas Voß and Allan LeSage, who are working to increase our quality infrastructure. One of the first things they've been working on is getting per-commit code coverage measurements of our unit tests in to Jenkins. I think that this is great because, while we have tests, we have no real way to know if we have enough tests. Code coverage isn't a magic bullet there, but it does give us some idea of where we stand.

If you had asked me (as soon as yesterday) about dbus-test-runner's test suite I would have described it as good. It's a small amount of code, and it has quite a few tests. So it must be good. Allan submitted a merge request to add code coverage measurements. Here's what came out on the summary:

Line Coverage Functions Branches
79.4 % 239 / 301 88.0 % 22 / 25 62.0 % 67 / 108

Ouch! I don't think we could really describe that as good. Not awful, but it should be better, especially for a test tool!

This story does have a happy ending. I took a little bit of time to make a new branch that adds tests, but also makes the utility more testable so that the code can be hit in a reasonable test. Overall, a big win for dbus-test-runner. Here's the results after that branch:

Line Coverage Functions Branches
95.2 % 317 / 333 96.2 % 25 / 26 84.4 % 103 / 122

Comments: Identi.ca | Twitter

Read more

Calendar to Phone

I've got an Android phone and I really wanted to get the calendars syncing with my desktop (Ubuntu). I tried the Android recommended Google Calendar, and it didn't really work for a variety of reasons. Off to try a new solution.

What I ended up doing is using Ubuntu One (U1) to sync the iCal files that Evolution Data Server (EDS) uses as its backend to the cloud. And then I published those files using U1's publish feature. Then I brought those back into my phone using ICSSync. Let's go through that step by step so you can get it set up too.

To get your EDS calendars are in your home directory under ~/.local/share/evolution/calendar so to get U1 to start syncing them to the cloud you need to execute this command u1sdtool --create-folder=/.local/share/evolution/calendar. U1 should start sync'ing that folder, and it should show up on the U1 website here.

You should there have a variety of folders that are your individual calendars. If you can then publish the calendar.ics file that is in each of these folders by clicking on the "More" button the right. You can enter the URL of the published file into ICSSync's "Add feed" dialog.

There are some downsides to this approach, specifically the answer to the U1 question "Are published files private?" But it is working well for me. Hope it works for you too!

Comments: Identi.ca | Twitter

Read more

Richard Fontana has written an article talking about the Harmony agreements using the idea that "input = output" for Open Source projects. I think this is a misunderstanding of Open Source that lies at the foundation of his argument. Motivations of many contributors to Open Source projects are because their contribution enables them to use a large corpus of functionality for relatively small amount of work. Perhaps a better equation would be:

einput = output

Let's look to the example of someone getting a new laptop that would perhaps not have a keyboard driver in Linux. That person would have the choice of writing or paying someone to write that driver for their laptop. What would they get in return? They'd get a fully functioning kernel with world-class functionality across a variety of subsystems. I don't think that we could say that the size of the contribution was equivalent to the amount of benefit.

This is a very good thing. This is what makes Open Source interesting to me. It's a group of people coming together with differing interests and goals with the desire to make something greater than what they could on their own. And there's trade-offs, not everyone can get all of what they want, but they all realize working together makes all of their contributions more noteworthy. The essence of their collaboration, the project itself, is what makes the Open Source great more than any individual commit or contribution.

If our goals are to make Open Source projects better, stronger and more competitive in difficult software world we should focus on how to create better projects instead of prioritizing the desires of small contributors.

Now, because I work for a company that's considered to be pushing CLA's I think it's important to reiterate that the opinions on this blog have always been my own. They always will be. Trust me, I'll get something at canonical.com for official stuff if I ever need it.

Comments: Twitter | Identi.ca

Read more

There was a lot of discussion when we did a netbook interface with the application menus in the top panel. Now that we're talking about taking the same interface to the desktop, there is new concern. Personally, I have always put myself in the camp of people who prefer their menus inside the application window. But why? Is it just something that I'm used to?

So in an attempt to figure out how I really use menus I wanted to watch myself using a program as a user, and using a program that was a "typical GUI" type program (not a development tool). The one that I settled on is GnuCash. I've used GnuCash for years, but not done any development or other work on it, so I figured that even though it was somewhat specialized software I could consider myself a user of it. I then used IOGraph (sadly not open source, and Java) to record my mouse for an hour of doing my finances in GnuCash. Here's what it created:

Mouse tracings of my GnuCash session

What seems the most interesting to me is that I hardly use the menus at all. I do use the toolbar a bunch, and I interact with the register. So it makes me wonder, in a well designed application, it would seem that all the functionality I need quickly would be a toolbar; and the menus only exist to expose the full breadth of functionality that the application provides. If it's the case that I only use the menus when exploring, it seems to matter very little how far they are away from the canvas I'm working on.

Obviously this is not scientific in any way, shape or form but in the end; I wonder if we spend more time debating where the menus should go than we do actually using them.

Read more

No GUADEC this time

A small announcement to mention that I won't be at GUADEC this year. So if you're expecting to see me there to chat about something, harass or just hang out we'll need to figure out a virtual method for all those. This isn't because I'm avoiding anyone, I've fallen in love with Qt and C++ or that there's a warrant for my arrest in The Hague for being too sexy (trying to cover all the rumors). In fact, my wife and I are expecting a new addition to our family around the same time. I hope to see everyone at the Boston GNOME Summit in the Fall!

Read more

Just a quick note to mention that my Ubuntu Developer Week session on Application Indicators got moved to today. It's at 1900 UTC. It'll be an overview of what we're doing, why, and some of what application developers need to think about when implementing AppIndicators in their code. I hope to leave a lot of time to questions as well. Stop on by #ubuntu-classroom on Freenode and bring questions!

Read more

Having a tidy systray

For too long on the Free Software desktop there has been a systray that is simply out of control. It provides for an arbitrary window with arbitrary behavior that developers have used arbitrarily. This provides a difficult interface for users as they don't know what to expect. It provides a difficult situation for applications as there is no way that they can give the user a good experience as there are no standards to follow. And it makes the whole support system for software more difficult through documentation and long explanations of how to use the computer.

Enough bitching. We're going to fix it.

We're starting with the KDE Status Notifier spec. It has been proposed to XDG and is currently used inside of KDE. It provides a DBus based interface for applications to advertise systray style information over DBus thus eliminating the need for XEmbed. The way that the Notifier Item spec is written it's designed to make the application expose information independent of the visualization, and we'll be one visualization of this data. A restricted visualization specifically focused on panels. We're going to have each application represented by a menu.

So with every application being a menu, and the panel knowing this and being able to assume it, then the whole systray can be a menu bar. This makes it easy to browse application's menus, find what you want, and work with it. It also improves keyboard navigation and increases the accessibility. Menus are a nice mix between simplicity and expandability as they're easy to use and yet provide a way for applications to provide a rich set of functionality.

I'm sorry, your browser doesn't seem to support embedded video. The video is available to download.

To do all of this, and make it easy for application developers to implement, we've built a small convenience library. That library is libappindicator. Basically it takes an icon and a menu and magically sends it over DBus and puts it in the panel for you. No fuss. It will also handle the cases where you're on KDE and want to use the older KDE Status Notifier API. Or, even the old XEmbed way of doing things. We've tried to make it pretty easy for application developers:

/* Indicator */
indicator = app_indicator_new ("example-simple-client", /* ID   */
                               "simple-client-icon",    /* Icon */
                               APP_INDICATOR_CATEGORY_APPLICATION_STATUS);

indicator_menu = gtk_ui_manager_get_widget (uim, "/ui/IndicatorPopup");

app_indicator_set_status (indicator, APP_INDICATOR_STATUS_ACTIVE);
app_indicator_set_attention_icon (indicator, "simple-client-att-icon");
app_indicator_set_menu (indicator, GTK_MENU (indicator_menu));

Some of this stuff is, unsurprisingly, not yet complete. The menu support basically only works with labels today, and the fallbacks aren't yet in place for the legacy protocols. I promise I'm working on it. We'll be getting better menu support here probably this week and then I'll start working on the legacy support. I believe that there's enough here to get started, and to start understanding what we're thinking.

This post is getting long, let me just finish up with some links:

  • Indicator Application Launchpad page -- this is where all the code and bugs are. Feel free to branch and do what ever you want with it.
  • Documentation Wiki -- To understand what we're doing and how to port applications we've tried to put up some documentation. We'll continue to add as we get language bindings up and running here shortly.
  • PPA for Karmic -- We've backported the modules required so you can develop and play with what we're doing today. There's also a preliminary patch to Rhythmbox that you can look at, which will, of course, be submitted upstream when it's cleaned up.
  • Ubuntu Developer Week -- I'll be talking about this there, if you want to come and ask questions or just lurk.

Read more

Kinda like Fedora

I admit it, I'm a little jealous of the Fedora feature of being able to install signed packages without a password prompt. I set out to get close on Ubuntu. The way that you edit the PolicyKit practices towards package install is to edit the file /usr/share/polkit-1/actions/. If you look at the action for "Install packages" you can change <allow_active>auth_admin_keep</allow_active> to <allow_active>yes</allow_active>. Then software center works as expected.

Read more

I gave a talk at my first ever Desktop Summit, which went well, though a little short. Brought out some of the technical underpinnings of the messaging menu and indicator system, and had some frank discussion about the mistakes that we've made (and are fixing). I've put up the slides for those not there, I'm told there will be video shortly.

Desktop Summit '09 Talk

Also, I forgot to blog about the talk that I was giving to my local Rotary chapter about Free Software. It was a fun talk and one that was more of an emotional talk than the technical talks that I normally give. Which allowed me to be a little more Tufte-ian.

Rotary Talk

Lastly, I made a project on Launchpad for people to put thier presentations in so that they're easy to find. It's creatively called "presentations" you can upload your presentation with: bzr push lp:~<lp username>/presentations/<talk name>

Read more

What's GNU?

I saw this at Target today. It made me laugh; enjoy.

A children's game called 'What's GNU?'

Read more

Back when I wrote the Bazaar Power Management plugin (still the only VCS with desktop power integration) I also wrote a small little command line utility. The utility came out of a discussion at UDS that no one wanted computers sleep by default if there was no easy way for command line apps to ensure that the computer won't go to sleep while they're running. I really want all Linux desktops to sleep by default. So I wrote this small utility.

And a few people asked me questions, which resulted in me sending it to them, and then I thought that I'd just make things simple and put it into the gnome-power-manager package for everyone. And I did. And that shipped with Intrepid. But nobody uses it because I never promoted it. Now I am.

If you go and you call the utility gnome-power-manager-inhibit it won't do much. That's because it works similarly to nice and time in that it works while the rest of the command line is running. So if you do:

$ gnome-power-manager-inhibit ls
Then you can rest assured that your computer won't go to sleep while listing that directory. What is more common for me is that I'll kick off a build before going to bed:
$ gnome-power-manager-inhibit make install
Where I know that if the build takes over a half hour (my configured sleep time) the computer won't go to sleep. But, my computer will be asleep when I wake up in the morning.

I hope that helps people to start configuring their laptops (and desktops) to sleep automatically. It really is important.

Read more

Pinkitude for life!  A pink reminder that self breast exams are 'for life' by QuichLouraine

When people try to talk about how working on Open Source is some sort of social work I'm usually dismissive; saying something like "well, we're not curing cancer." Wouldn't you know it? People are trying to prove me wrong!

Recently Deviant Art held a contest with the Susan G. Koman foundation to make art informing people (okay, mostly women) about breast cancer. Lorain A. Baird won for her work titled Pinkitude for life (right) which was done in Inkscape. For those who don't know Deviant Art it's a website where artists from all over using all different mediums gather to share and comment on each other's work. This means that that the contest included entries spanning the possibilities of tools and techniques, and an Inkscape entry won. Of course, the true credit there goes to Lorain for her great work, but I'm proud for Inkscape too.

Louise Brooks the silent film star by Quiche Louraine

Looking through Lorain's Gallery there is a ton to love, but I started reading through the comments on her portrait of Louise Brooks and noticed a comment that was really nice. From montroytana:

ive never seen a piece of art (before yours) and said GOD ive got to have the program that made that! your stuff is really wonderful
That's the feeling that I want everyone to have when thinking about choosing Open Source software. I want them to be so impressed with what they can do that they feel empowered to go get it done.

I'm hugely proud of the Inkscape team in what we've accomplished and I think that I can speak for all of us and say that we're impressed with all the great work that Inkscape artists do to make us look good.

Read more

One thing that kept bothering me in the GNOME UI Hackfest was how little data applications export out to the desktop. As I was in the shell group we were discussing various things that we wanted to do and John Mccann kept having to remind me not to worry about the implementation as I would get frustrated that we simply didn't have the data. I want to fix this. I want to have the data in a structured way.

What I've come to realize is that we need to let applications be applications, let panels be panels and let applets be applets. With the notification area specification we created a way for applications to break through this barrier and put a little segment of the application into the panel. While this sounds great, and it has created a quick way to prototype some interesting ideas, it's also created a complete mess in our panels. There is no consistency of action nor in look for that section of the panel. I like to call the notification area the "bag of crap." While it's created a way for applications to innovate, it's drastically stalled innovation for panels and shells.

What I'd like to put forward is the idea of little flags that applications can hold up to say what they're thinking or doing, which I'm going to call indicators. The application can then represent in a structured way that it's got something of interest to the desktop as a whole, and then the desktop can represent that to the user. How ever it likes. It's not the application's responsibility to figure out how to do this, or if it needs to be done in a single place or multiple, or anything other than raising the flag. While I think that this might frustrate application developers at first in that they don't have control over the display of this information, I think that long term it will empower them in that they don't have to fiddle with this type of interaction any more.

First off I want to build something simple (start small, think big), the messaging indicator, which will mostly consist of a GNOME panel applet. It will do simple things like represent IMs and e-mail and not a lot more, but the real goal is starting to get applications like Evolution and Pidgin to export this information. Once we're there, then we can start to look at new ways to use it. I love the idea of having the Evolution icon having the number of unread messages a la Apple or Gwibber also putting messages in the messaging indicator. Those are all next steps, but I think important ones in starting to explore how we can get data out of the applications and to the users in usable and attractive ways.

Read more

Where music is going

I'm going to make a bold prediction here, hold on to your hats! I'm going to predict that the next music player I buy will have more storage than the one I have now. I'd bet even the one after that will have more than that one!

While that prediction isn't groundbreaking, thinking about it lead me down an interesting path. I, like probably a lot of people, got onto the bandwagon of ripping my CDs to MP3s pretty early. It was exciting to have my whole collection of music on my hard drive (portable players were pretty rare back then) and compared to my computer speakers the quality was amazing! After doing that, I was then at the point of realizing that I needed to do it again. Things like reliable tagging made it so most of the files weren't useless, but I would get better results by just starting from scratch. So I did.

I then realized that I never want to do this again so I needed to rip all my music into a lossless format, but no player could hold all that data, at least not yet. In turn that forced me to realize that over time storage will probably grow faster than the amount of music I'm interested in, but the variable I can adjust is quality. So I can build a bunch of 96 kbps MP3s for my phone and keep 256 kbps OGGs for my laptop. And, eventually, everyone will just have those flac files I originally ripped. Whew, now getting from A to B.

I decided that I needed to make a Makefile for a few different reasons:

  • Make handles the idea of transformations pretty easily, so the idea of a transformation between flac and another format would be simple to express.
  • Make already tracks which jobs are complete by looking at the file times and which files are created. This would make it easy to rip new CDs as only the new files would be re-encoded.
  • Make can parallelize the whole thing for me to work on my dual-core processor. nice make -j 2
  • If I quit half way make will delete the half built files and allow me to pick up where I left off.
The one problem that I had using Make is that it doesn't easily handle file names with spaces in them. This was easy enough to change:
$ find . -name "*.flac" -exec rename "y/ /_/" {} \;
Which is a small one line operation to find all the files ending in .flac and replace all the spaces in their name with underscores.

Here is the Makefile and the small shell script that I'm using to do the conversion (mostly stolen from a forum thread I can't find now). Everything is grossly hardc oded, but it works great for my situation. My situation includes putting both of these in the Flac folder and wanting to put all the MP3s into the ../mp3 folder. Currently it only builds MP3s at 96 kbps. Good luck, hopefully my collection will be encoded in a couple of days.

Read more

Where are my messages?

One of the improvements that we worked on for the Intrepid release is building a combined applet with the fast user switching, session management and maintaining instant message status. I'm happy with how this turned out. I'm planning on continuing the messaging story in Jaunty.

An interesting aspect of messaging on the desktop is that while you can get messages, and get a notification of their appearance, you still may want to respond to them. Currently every messaging app you run provides this through it's own icon into the notification area. Many people I know have both Pidgin and XChat icons in their notification area routinely. Besides the fact that both of these work significantly differently, they also are very different visually providing the appearance of clutter in the panel.

How do we fix this? I think that a reasonable approach is to consolidate them into what I'm coining as a "messaging indicator." The goal of the messaging indicator is provide a simple and clean way for messaging apps to provide the notification to the user that other people are trying to talk them while not having to put something in the notification area. The notification area is evil. Here's a simple use case done as an SVG mockup:

I'm sorry, it seems that your browser does not support SVG. Here is the diagram, please upgrade your browser to a newer version.
Or, you're reading this through a planet, which apparently doesn't like SVG. Sadly.

The diagram is simple, and that's a really good thing. Here we're seeing a IM message coming in. The notification disappears into the messaging icon and the message can be found underneath that icon. Nothing complex, but it allows the user to know that all of their messages are a single tidy place and there is only one graphic required on the panel for all messaging.

What is a message? It's really easy to over reach with the idea of what a message is. One could say: "Apparmor is messaging me that I can't edit that file." While that sentence is correct, it's important to note that users don't agree. So my goal is limit this indicator to messages sent from other humans to the human using the computer. Now I need to go and fight some feature creep.

Read more

I'm here at UDS and joined a session between the kernel and desktop teams talking about power. Like all of such sessions the kernel team thinks that the desktop should fix all the problems and vice versa. At their suggestion, I took an action item.

One of the features of GTK+ is that it provides two timeout functions: gtk_timeout_add and gtk_timeout_add_seconds. The difference is much more important than not having to add a "* 1000" in one and not the other. The important thing that the second function does is that it tried to group wake-ups to ensure that the program wakes up as little as possible. This is never perfect, but it's a small thing that can help to save some power and reduce the number of wake-ups.

So I looked through the Ubuntu main archive to figure out how many applications use the more precise function, but just pass in several seconds as the parameter. I figured this would be a few apps, and I'd submit a couple patches, then I could go back to blaming the kernel team for all our problems. There are more than a couple packages. There are a lot of packages. The results of the grep and a cleaned up list of packages that are likely to have easy fixes.

I realize now that I can't do this by myself, the only hope is to document how to fix it.

So if you'd like to help save a little power on your machine, follow these instructions.

  1. Take one of the packages in the list above and find it in the package repository (instructions).
  2. Branch it:
    $ bzr branch http://package-import.ubuntu.com/x/xproject/jaunty localfix
  3. Find the instances that might be causing the problem.
    $ rgrep timeout_add *
  4. Commit and build a package:
    $ bzr commit -m "Saving the world"
    $ dch -i
    $ debuild
  5. Test it on your system, make sure things still work reasonably.
  6. Generate a patch:
    $ bzr diff -r ancestor:
  7. Submit it upstream!

Read more