Canonical Voices

What Ted Gould talks about

In order to reduce the bus factor a bit, I'm documenting how I do releases for the indicators. This is not a complex process, but not obvious either. This post will involve lots of Bazaar, Launchpad and Ubuntu. If that's not what you want, skip to the next post in your reader.

Understanding Ubuntu Distributed Development

I think the first think to understand is what our goals are in making a set of releases. It's a set of artifacts to mark a point in the continual development of the software. But, that point is marked differently by different groups of people. Largely this is mirrored by the "trunks" of Ubuntu Distributed Development. It's important to realize that Bazaar doesn't really have the concept of "trunk" in it. We name a branch in Launchpad that to make it easier to communicate, but Bazaar doesn't treat that branch any differently than any other. So for the different audiences, they each have their own trunk, and releases there mean different things. The trunks we're using are:

  • Upstream Trunk. Traditionally this is what software developers think of as trunk. The place where the artificats that are edited by the developers exist
  • Upstream Import Trunk. This is a branch that is maintained by the UDD tools and represents the tarball releases. The tarballs are slightly different than upstream in that they contain additional files generated by the build.
  • Upstream packaging. A packaging branch that is mostly a pure representation of upstream software, perhaps more up-to-date that distro. This allows us to do test builds and maintain updates for things like our Jenkins builds independent of having to ship the change to every Ubuntu user.
  • Ubuntu packaging. A branch maintained by the Ubuntu Desktop team that represents what is sent to Ubuntu users.

As we move through the release process we'll go through these branches. Some will end up slightly obscured, but I'll try to point them out along the way.

Releasing Upstream

Building and shipping the upstream tarballs is mostly straight forward, but I want to take the time to be explicit and note a couple of tricks that are useful along the way. For our examples here I'm going to release indicator-messages version 1.2.3. First grab the trunk:

$ bzr branch lp:indicator-messages trunk

Then you can edit to update the version and commit that. It's important to commit before distcheck since our ChangeLog is built dynamically at dist and you want the top of it to be the version number that is released.

$ vi
$ bzr commit -m 1.2.3

Note, we're not tagging, and that's for good reason! Tags are a pain to move, and as releases go there's a reasonable chance that distcheck will fail, but let's check first:

$ ./
$ make
$ make distcheck

Distcheck will build the tarball, uncompress it and ensure it builds and can run the test suite. Most of the time this works so you can just:

$ bzr tag 1.2.3
$ bzr push :parent

But, sometimes it doesn't. And you'll need to fix it. I'm going to leave fixing it as an exercise for the reader, but what I want to talk about is how that should look on the branch. You don't want your fix to occur after you set the version in the history. So you can step back by doing:

$ bzr uncommit
$ bzr shelve

This saves your changes. So then when you want to come back to releasing again

$ bzr unshelve
$ bzr commit -m 1.2.3

And you're back to where we left off. We need to put the tarball into Launchpad, and fortunately there's a handy script for that:

$ lp-project-upload indicator-messages 1.2.3 indicator-messages-1.2.3.tar.gz 1.2.4

An interesting thing here is the "1.2.4", where does that come from? It's creating the next milestone in Launchpad for you so that we can start assigning bugs that are Fix Committed to it and they're already there come release time. Also you'll need to take the bugs that are Fix Committed on the 1.2.3 release. You can do that with this script if there's a bunch, but if there's not too many just do it by hand.

Building a test package

We've built and released a tarball, and it passes all the tests, and all the code's been reviewed, but until you install it on your machine you're not putting any skin in the game. Let's really believe in that release. First we need to get the upstream branch. Go ahead and put that in a directory next to your trunk branch. In this example we're assuming the Ubuntu release is precise because that's the current right now.

$ bzr branch lp:~indicator-applet-developers/ubuntu/precise/indicator-messages/upstream upstream

You should at this point make sure that this branch is in sync with the Ubuntu Desktop branch. Frequently they'll make updates to the packaging or cherry pick revisions they're interested in from the developers. This isn't a necessary step to make everything work, but it makes the merge for them easier, so you should do it.

$ bzr merge lp:~ubuntu-desktop/indicator-messages/ubuntu
$ bzr commit -m "Sync from Ubuntu Desktop" 

We're now going to use the UDD toolchain to pull in the tarball and merge it into the packaging. I'm purposely providing two parameters here that are optional. The first is the tag that should be used to pull from. Chances are that if you just edited trunk the revision there would be exactly the same, but let's not take that chance. The second is the version where I'm just being more explicit about what we're doing.

$ bzr merge-upstream indicator-messages-1.2.3.tar.gz lp:indicator-messages -r tag:1.2.3 --version 1.2.3

At this point the tarball has been imported and merged into the current branch. One innocuous warning that you'll see in this step is about criss-cross merges. This usually happens when the desktop team cherry picks a branch. I have argued that this shouldn't be a warning and largely I regard this as Bazaar saying "if there are conflicts they're your fault," rarely are there ever conflicts from this.

We're now at the point where we start switching from the Bazaar-based tools to the Debian ones. We need to talk about what's changed in the Debian ChangeLog by using

$ dch -a

There will already be a section made for you buy the import, but you should continue to describe the upstream release with what has changed, specifically which bugs have been fixed. Also, I always change the version number from "1.2.3-0ubuntu1" to "1.2.3-0ubuntu1~ppa1". This is so that when I install the packages locally they'll get overridden by the ones that are built in the Ubuntu builders. Also it creates a unique namespace if I mess up that I can increment. You can then commit with the message you put into the changelog with

$ debcommit

A couple of quick things that you can check at this point. Debian packages have a way to include patches, we should have merged those upstream and if you leave them there they won't apply when building. So you can just remove them and comment as such

$ rm -rf debian/patches
$ dch -a
$ debcommit

Also you can check to ensure that you're shipping actually the tarball that you build, plus only the Debian packaging. All of the Debian packaging should be in the the debian/ directory so we can look to see if anything is not in that directory

$ bzr diff -r tag:upstream-1.2.3 | lsdiff

The astute reader will notice that I just used a tag that I didn't build. Hmm. This is where the Upstream Import branch comes into play. When we did the merge-upstream above we actually edited two branches. The first is the import branch where the clean tarball was placed. Then it was pulled into our packaging branch from that revision. I find it handy to look at the revision history at this point

$ bzr visualize

Now let's build ourselves a package. The first thing you want to do is set up your environment if you haven't done any packages before. Usually if it builds I also tag it as a version in the revision history so that I can keep track of what I've installed. So to ensure I don't mess that up I chain the commands

$ bzr builddeb && dch -r && debcommit -r

You should now have packages in the directory above the current directory that you can install.

$ sudo dpkg -i *1.2.3-0ubuntu1~ppa1*deb

Now you can test on your machine if things are generally working.

Pushing downstream

If everything looks good you should push that branch back up and then propose a merge into the Ubuntu Desktop branch. This tells the Ubuntu Desktop team that we've got a package that we think works and they should consider for usage in Ubuntu. They'll run their own set of acceptance tests, and I'm sure they'll find you if they fail.

Read more

It has become popular (at least in the US) to start to put bandwidth caps on customers. Technologists are upset, they've seen Star Trek and they know that everyone is going to start video conferencing constantly any time now. These uses would easily go over the paltry limits that network providers have setup. Real consumers won't care, what will actually happen is the economics of connecting to the Internet will change.

We can start to see this with AT&T;'s recent foray into allowing phone apps to pay for the bandwidth that their app consumes. This would mean that a user could grab the new app from their favorite sports team and not worry that the video highlights will knock them over their cap, the bandwidth is "free." The reality is that the way it's paid for has changed. Instead of being amalgamated over all the users, averaged and sold at a fixed rate for all you can use, it's being paid for out of the money you're paying the application provider. If it's $10/mo to Netflix, they're giving AT&T; a kickback of 10% of that to ensure you don't worry about using it.

Consumers will love this! Why? Because what will in turn happen is that the cost of the bandwidth to them will go down. Do you want a gigabit of bandwidth to your house? Sure you do, especially if it's only $20/mo. What other restrictions would you take to get that much bandwidth so cheap? I'm guessing if most people didn't feel the pain of the restrictions, they'd all take that trade. And this is where the "gain" to consumers lies. Most of them aren't doing bit torrents, they're using Hulu and Google and Youtube, all people who can give the DSL provider money to subsidize that bandwidth whether it be from subscriptions or advertising.

Network neutrality in this scenario sadly becomes a moot point. The provider isn't providing any preference to the routing, or deciding which packets to put on which line, they're just adjusting how they bill the customer. You can rest assured that no one (at least in the US) would regulate how they the ISP bills the customer. But, the restrictions would be such that consumers would choose (no mater how manipulated that choice is) one site over another based on their cost, which is effectively a negotiated price by their ISP. Again, the ISP is manipulating and choosing which sites the user is most likely to see and use.

It seems doubtful to me that all bandwidth will go to this model, only consumer level home and mobile bandwidth. Companies and Universities are unlikely to see significant change in how they purchase their own bandwidth as there isn't as much direct billing there. But, I think it might effect how people could work from home. I imagine this will result in the ability to purchase unlimited bandwidth to a single domain for VPN usage.

There is, of course, a lot more to say about this. It's an interesting pivot in how we see the Internet structured today, but was probably inevitable. We continued to squeeze the companies that owned the last miles to our houses, asking for more bandwidth for cheaper. And then we had the gall to actually use it! They're trying to figure out how to recoup those costs, and consumers aren't willing to pay more, so they have to hide it.

Comments: | Twitter

Read more

One of the prongs of our strategy to increase the quality of software throughout our developments in Product Strategy was to introduce static analysis to our code where possible. After evaluating several tools we decided that Coverity was the best tool for this, and we started figuring out how to make this work on our code bases. After a fair amount of work in pulling things together I'm happy to say we're scanning projects and processing the bugs in production now. You can see the open bugs and you can find out about what data is there.

While there were various technical issues I think one of the more interesting and difficult ones was social. How can we introduce a tool that we're restricted on distribution to a community without restrictions? It would have been very easy to create two classes of developers, those in Canonical with access to the tool and those outside that wouldn't have "all the info" about what was going on. We didn't want to do that, it's not how we work.

What we did was build a tool that would take the bugs out of the Coverity Integration Manager (CIM) and put them into Launchpad. So every time a commit happens on trunk a Coverity Scan is performed, the issues are put into CIM, and then Launchpad is updated. This includes both creating new defects in Launchpad as well as closing ones that were fixed. We also take the annotations of what branches Coverity took throughout the code and create an annotated source file and attach it to the bug.

Our sync tool is Open Source, and while it's hard to test as you'd need a license for Coverity to do so, we're happy to take patches. We want to see all the needed information to work on the bug in the Lauchpad bug. If there's something you think we need to add, come talk to us, it's a conversation we're interested in.

In the end we hope that we've created an environment that allows for Coverity to be used by everyone in our development community, on largely equal footing. Currently we're only licensed to scan Unity and the other projects it uses directly. I'm excited to see how we can use this new tool to improve the quality of PS projects as we continue to expand it to scan more projects we're licensed for, along with hopefully expanding its coverage as it shows value.

Comments: | Twitter

Read more

Procmail vs. Launchpad

Launchpad users know that it can send quite a bit of e-mail. Okay, a LOT of e-mail. There has been effort on the Launchpad side of things to add controls to set the amount of Launchpad e-mail you get. But for some of us, even getting the mail that you need results in a fair amount of Launchpad mail. In playing with my procmail config for Launchpad mail I stumbled on this little feature that I love, and thought I'd share, as it's cleaned up my mail a lot. The secret rule is:

* ^X-launchpad-bug:.*product=\/[a-z0-9-]+

Quite simply that rule takes the project specifier on a bug mail, and uses it for the folder name that it puts the mail into. This means each project gets it's own mail box, no matter what. So even as you add groups or subscribe to new bugs, you just get new mail boxes. Works for me. Hope it helps other folks too.

Comments: | Twitter

Read more

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:


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: | 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: | 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: | 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 for official stuff if I ever need it.

Comments: Twitter |

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 */

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