More than a few, actually. As part of our ongoing focus on App Developers, and helping them get their apps into the Ubuntu Software Center, we need to keep the Application Review Board (ARB) staffed and vibrant. Now that the App Showdown contest is over, we need people to step up and fill the positions of those members who’s terms are ending. We also want to grow the community of app reviewers that work with the ARB to process all of the submissions that are coming in to the MyApps portal.

ARB Membership

Two of the existing members, Bhavani Shankar and Andrew Mitchell, will be continuing to serve on the board, and Alessio Treglia will be joining them. But we still need four more members in order to fill the full 7 seats on the board. ARB applicants must be Ubuntu Members, Ubuntu Developers, and should create a wiki page for their application.

ARB members help application developers get their apps into Software Center by reviewing their package, providing support and feedback where needed, and finally voting to approve the app’s publication. You should be able to dedicate a few hours each week to reviewing apps in the queue, and discussing them on IRC and the ARB’s mailing list.

If you would like to apply, you can contact the current ARB members on #ubuntu-arb on Freenode IRC, or the team mailing list (app-review-board at lists.ubuntu.com). The current term will expire at the end of the month, so be sure to get your applications in as soon as you can.

ARB Helpers

In addition to the 7 members of the ARB itself, we are building a community of volunteers to help review submitted packages, and work with the author to make the necessary changes. There are no limits or restrictions on members of this community, though a rough knowledge of packaging will surely help. This group doesn’t vote on applications, but they are essential to helping get those applications ready for a vote.

The ARB helpers community was launched in response to the overwhelming number of submissions that came in during the App Showdown competition. Daniel Holbach put together a guide for new contributors to help them get started reviewing apps, and you can still follow those same steps if you would like to help out.

For the past several week, David Planella, Jono Bacon and I have been drafting a spec that proposes a radically different approach to getting desktop applications into the Ubuntu Software Center. Now, there’s nothing that annoys me more than somebody proposing radical changes for no reason, and without giving much thought as to how it would actually be done. So I wanted to write down, here, both the justification for this proposal, and the process that we went through in drafting it.

The current process splits submissions between closed-source and commercial apps, which get reviewed by a paid team of Canonical employees, and non-commercial open source apps which are reviewed by the Application Review Board (ARB). The ARB consists of 7 volunteers from the Ubuntu community, who will review the source code and packaging of each submission. Members of the ARB are very smart, very dedicated members of the community, but they also have paying jobs, or are pursuing higher education (or both), so their time is a limited resource. The ARB process was meant to provide an easier route for app developers than the more rigorous process that distro packages must follow to get into the Universe repository or Debian’s archives, and in that respect it has been a success. But even with eased requirements, there was a limit to how many apps they could manually review.

The recent App Developer Showdown competition, which resulted in more than 140 new apps being submitted through our MyApps portal, showed us the limits of our current process. We even drafted a number of new volunteers to help review the incoming apps, and Daniel Holbach provided both instructions and programs to help speed things up. It took us weeks to give an initial review to all of the apps. Almost two months later and we still haven’t been able to publish more than a quarter of them. Android has seen over 9,000 new apps in a month, and I can only assume that iOS has seen similar numbers. If we can’t even scale to handle 140, something has to change.

The spec didn’t get written down all at once from some grand design. It grew organically, from a short list of general goals to the massive text it is today. In fact, the spec we ended up with is quite a bit different than the one we initially set out to write. We took our list of goals and started asking the obvious questions: what work is involved, who will it impact, and what could (will) go wrong? We could have just throw these questions out to other people, but those people are busy and have their own things they are trying to do. Before we could ask anybody else to spend time on this, we had to put in some effort ourselves.

So we answered as many of these as we could between the three of us, and those answers changed our spec accordingly. That raised more questions, and we repeated the process, updating the spec and finding more questions that needed to be answered. In the process we gained both a clearer idea of what we wanted, and a better understanding of how to get there. By the time we had answered as many as we could on our own, our list of goals had transformed into a longer list of implementation items and who would most likely be doing them.

At that point, we had a more specific direction and a pretty good idea of how much work it would take. Having done as much of the leg-work as we could, we took the implementation items, and any unanswered questions we still had, and started talking to the people who would have to implement it. Unsurprisingly, these conversations had an even bigger impact on the spec, and it underwent some pretty drastic changes as we tried to nail down the details of the implementation. Just like the previous stage, we iterated over this one multiple times until we had as many details as we could collect, and answered all of the questions that we could. At the end, we had the massive spec we announced today.

But this is just the next stage, the spec isn’t final. The three of us have answered as much as we could, the teams who will implement it have answered as much as they could, now we’re introducing it the community to gather even more details and answer even more questions. The feedback we get in this stage will go back into the spec, and very likely generate new questions and feedback, and we’ll iterate through this stage too.

The final spec, whatever it ends up being, isn’t going to be perfect, and it’s not going to make everybody happy. But we can be confident that is will be a very well thought out spec, it will be a very detailed spec, and it will allow us to accomplish the goals we set out to accomplish at the beginning of it all. It will help make Ubuntu a much more attractive platform for application developers, it will make Software Center more useful to developers and users alike, and it will make Ubuntu a better OS for all of our users.

If you have any questions or comments on the spec itself, please send them to the ubuntu-devel mailing list, not the comments section here.

As you’ve probably heard already, Ubuntu is running an App Developer Showdown competition where contestants have three weeks to build an Ubuntu app from scratch. The rules are simple: It has to be new code, it has to run on Ubuntu, and it has to be submitted to the Software Center. The more you use Ubuntu’s tools, the better your chances of winning will be. This week we ran a series of workshops introducing these tools and how they can be used. It all seemed like so much fun, that I’ve decided to participate with my own submission!

Now 2 our of the 6 judges for this competition are my immediate co-workers, so let me just start off by saying that I will not be eligible for any of the prizes. But it’s still a fun and interesting challenge, so I’m going to participate anyway. But what is my entry going to be? Well in my typical fashion of building tools for tools, I’ve decided to write a GUI wrapper on to of Quickly, using Quickly.

Before I started on any code, I first wanted to brainstorm some ideas about the interface itself. For that I went back to my favorite mockup tool: Pencil. I knew I wanted to cover all of Quickly’s functions, both for creating projects and working on them afterwards. I also wanted something that would keep track of my projects, so I wouldn’t have to find where they are on my disk whenever I wanted to hack on them.

Now, I’ve never been a fan of GUI builders. Even back when I was writing Java/Swing apps, and GUI builders were all the rage, I never used them. I didn’t use one for Hello Unity, and I wasn’t planning on using Glade for this project either. But after Jono’s fantastic workshop session about Glade, I decided to give it another chance. I found that I was able to get a basic UI built and running in very little time. I’m still struggling with some, and there’s a point where you need to switch from Glade to code, but all in all it has saved me a significant amount of time.

Quickly also saved me a large amount of time, both in creating the project and adding things too it. Being able to add an Application Indicator to your app by just running “quickly add indicator” is amazing. From there is was a simple matter to build a menu based on available Quickly commands and tie them in with callback functions.

But the part I like the best about this app so far, is that it’s useful even when you’re not using it. Most of the time you spend developing a Quickly app is going to be in some other application, such as your code editor of choice, Glade or something. Thanks to Unity’s HUD, and the fact that it’s smart enough to check Indicator menus in addition to the focused application’s menus, you can call your Quickly commands any time, simply by tapping ‘Alt’ and the command you want to run. It’s like having Quickly integrated into all of your other tools.

And thanks to the developer tools available in Ubuntu, I was able to accomplish all of this in only a few hours of work.

Now it’s very, very far from being complete. For instance, the “active” project is hard-coded to my quickly-gtk working directory, it can’t start a project yet, or support commands that take optional arguments or user input. But in a short amount of time I was able to go from a mockup to a working layout and even some functional code. It even packages successfully, something I found out quite by accident when I selected “Share” from the indicator menu and ended up with a package in my PPA.

Building an app in 4 hours then accidentally building a proper package and uploading it to a PPA, who’d have thought we’d ever make it that easy? I hope you all are having as much fun and success in your showdown applications as I am.

Last week we introduced a new ‘Download for Ubuntu’ campaign for upstreams to use on their websites, letting their users know that the app is available in Ubuntu already. We event generated a list of targeted upstreams we wanted to reach out to in order to spur the adoption of these buttons. What we didn’t go into much detail about why upstreams should use them. I hope to remedy that here.

It’s easy

Let’s just get that out of the way, this won’t take a significant amount of work on the part of an upstream. It’s just a one time change to a website. You don’t even need to change it every cycle, since the buttons point to the App Directory entry for the application itself, not any specific version of it.

It makes installing your app more appealing

The button isn’t just another way of getting your app, it also tells the user that it will install correctly, all of it’s dependencies are available and will be installed, everything is configured to work with their system, and they will get be getting updates and security fixes to it through a mechanism they already use and trust. In short, it’s a promise of a good user experience (which I’ll admit we don’t always live up to, more on that below). Telling 20 million users (and growing) that your app is safe and easy to install is surely worth a few pixels on your website.

It’s good social exposure for your app

By sending users to the App Directory, instead of just immediately installing, new users get to see what others are saying about your app through the ratings and reviews (which will be mostly positive, because your app is awesome right?) of other Ubuntu users. Not only does this tell your users that other people like your app, but it’s also telling them that they can add their own ratings and reviews, which will in turn boost your app’s standing. More reviews leads to more users, which leads to more reviews, it’s a great positive feedback loop.

Users will be looking for it

Not right now, obviously, since we just started this campaign. But as more upstreams adopt the new button, it’s going to be one of the first things Ubuntu users will be looking for on your website (for all the reasons mentioned above). With a majority of website visitors leaving in less than a minute (according to a lazy Google search), the promise of a quick and easy install might just be the difference between a new user and a lost opportunity.

This campaign benefits everybody: end users, upstream developers and, yes, Ubuntu too. So let’s improve these ties, together. If you’re an upstream, you can copy/paste the following HTML snippet directly into your website (replacing {{pkgname}} with the name of your application’s package in Ubuntu). If you want to reach out to an upstream developer, please add them to our list so we know who’s contacting them, and what the status is.

Now I know we can’t always give the best user experience possible (see, I told you I’d get to that). Sometimes our packagin isn’t quite right, or the default configuration of your app is sub-optimal. Our six month release cadence and package freezes mean that rapidly developing applications will often be out of date in our main repositories. We’ve taken on a lot of work by distributing apps the way we do, and even though we’re a very large community, it’s still hard to get every package right. Luckily, you’re not powerless here, if you spot problems with the way we distribute your app, or you need to get a newer version out to Ubuntu users, you can do something about that.

Package fixes

Even though our process locks applications to the version in the archives for that particular release of Ubuntu, we will still allow changes to the packaging itself. So if we’ve done something wrong on our end that is giving your app a hard time, we’ll fix it and make that available to all of your Ubuntu users as a Stable Release Update.

Backport newer versions

A six-month release cycle means that every Ubuntu release has relatively up to date versions of applications, at least compared to distros that have a longer cadence. But for rapidly developed applications, where new versions come out more frequently than that, this means their packages can become outdated quickly. And with the five year lifetime of our LTS releases, most packages will get to be stale by the end. That’s why we have a special repository just for backporting new versions of packages to stable releases of Ubuntu. And starting with 11.10, this repository is enabled by default.

In order to have your application backported to a stable release, it first has to be accepted into the current development release. If your new version was in Debian’s unstable repository at the beginning of the development cycle, chances are it’s already there. If it’s not in Debian you’ll need to submit your package to be included in the development release. Once it’s there, you can request that it be backported to one more more stable Ubuntu releases. You can use the requestbackport command line tool (from ubuntu-dev-tools package) to automate much of the process, or if you’re not running Ubuntu simply file a bug to start the request.

It’s no secret anymore, we want apps in Ubuntu. Big app, small apps, shiny apps, cute apps, apps that play a catchy tune while avian avengers explode porcine poachers. You name it, we want it in Ubuntu. And we need your help getting them.

It doesn’t matter if you’re not a programmer, there are plenty of programmers in the world, and they’re making all kinds of really cool apps that you want, that I want, that we all want. But they’re not putting them in Ubuntu, and that’s why I need your help.

You see I’m just one person, and with David Planella we’ve got, well, two people. Now, two people can find an awful lot of apps on the internet, that’s true. Especially when that’s part of your job. But even still that would hardly amount to a drop in the bucket of apps that have been made. And we’re not happy with just a drop in the bucket, are you?

No, of course you’re not. So right about now you’re probably thinking of a bunch of cool apps you’ve used or seen or read about recently (and if you weren’t before, you certainly are now, aren’t you). And you may be wondering how you can help us get them into the Ubuntu Software Center. Well wonder no more my friend, because we have a Trello board.

Not terribly impressive, I’ll admit, but it is terribly useful. You see, David and I will be contacting each and every one of these app developers about submitting their apps to the Software Center, and moving the card from column to column as that conversation progresses. And while we have a nice long “To Contact” list right now, it’s not going to stay that way without your help.

We’re opening up this board to anybody who wants to add new upstream apps for us to contact. All you need to do is follow David’s instructions on this wiki page to get started. It’s quick, mostly painless, and best of all you get to start telling us what to do (at least a little bit).

But wait! There’s more! Didn’t I say we were just two people? There’s no way we could contact all these upstreams on our own. And hey, you’ve just signed up to join the Trello board (you did do that, right?), which means you can start contacting them too, and moving their cards, and make Ubuntu even better. We’ve even created a reusable email template that you can use for that initial contact.

If you contact one of the app developers, make sure you move their card to the “Conversation Started” column, assign it to yourself, and add comments about who you contacted and any other relevant information. This of course requires that you joined the board, which you definitely should do if you are going to be working on this. And please note that is says “Started”, not “Finished”. Once you contact the developer, keep that line of communication open and help them through the process of submitting their app. If you get to a point where you can’t help them, let David or I know and we’ll be happy to pick it up.

Expanding on my previous post calling for pkgme backend contributors, here’s a list of the backends we would like to see added, and who in the community you can contact for help in making them. If you can act as a mentor for one of these backends, please say so in the comments and I will add your name to the list. For any questions about pkgme itself, and what options are available to backends, your best bet is to ask James Westby (james_w) in the #pkgme channel on freenode.

Qt/qmake

QMake is a Makefile-generator. It uses information that the application author puts into a project file to build the Makefile for a project. A qmake backend would need to either use qmake to extract the information requested by pkgme, or parse the same project file that qmake uses in order to provide that information.

Flash

Flash applications can be packaged for Ubuntu by wrapping them in a GTK window that contains a Webkit browser widget, and an index.html file for it to load that embeds the given flash file.

The Quickly Flash template currently does much the same thing. To do the same in pkgme, you will need to pass the necessary wrapper files to the extra_files request. extra_files should return a JSON object where the key is the file path relative to the root of the target application, and the value is the contents of that file.

HTML5

A backend for an HTML5 application would also require wrapping the target application in a GTK window with embedded Webkit widget. Only instead of creating an index.html, you would just point the Webkit widget to the target application’s HTML files.

pkgme is a small utility created by James Westby, its purpose is to create a Debian package for any unpackaged applications. It’s currently used when applications are submitted through the Ubuntu Developer Portal as tarballs, inspecting the contents of the application to determine how to build a package from it. In order to support many different types and configurations of application, James built pkgme to support any number of different backends.

Currently there is support for apps using Python and Distutils, apps compiled by cmake, and apps written in Vala. But there are still many, many applications out there that aren’t covered by these backends, including Qt apps, HTML5 apps, Flash apps and more. That’s where you, dear contributor, come in.

But I don’t know how to create packages!

That’s okay, you don’t need to know how to make packages to create a pkgme backend. It already knows how to make packages, what it doesn’t know is where to find the information it needs to do that. This is what backends are, just one or more small scripts that extract enough information about a project to let pkgme do its thing.

Ok, I’m interested, how do I start?

First of all, get a copy of the latest pkgme code from its bazaar branch in Launchpad:

bzr branch lp:pkgme ./pkgme

Then, create a VirtualEnv environment to install it into:

virtualenv ./env

Then, install it into the Virtualenv:

source ./env/bin/activate
cd ./pkgme
python setup.py develop

Now you’ve got a working pkgme installed and running in your virtualenv. You can leave your virtualenv by running ‘deactivate’. Time to get started on your backend!

Where do I put my new backend code?

Since we’re going to submit your new backend to the pkgme branch, we can just create it there:

cd ..
mkdir ./pkgme/pkgme/backends/<your backend name>

Great, now I have an empty Backend, what do I put here?

The first thing your backend needs is a ‘want’ file. You see, in order for pkgme to know which backend it should use on any particular application, it needs to ask every backend how much they want it. It does this by executing a script named ‘want’ in each backend.

Your want file is executed from the target application’s directory, so in your script ./ will be the root of the target application’s directory. This lets you script easily browse through the files in the application to determine how well it can provide packaging information for it.

In order to tell pkgme how much your backend wants to handle the target application, your ‘want’ file simply needs to print a number to STDOUT. The backend with the highest number is the one pkgme will use. These are the suggested ranges for your ‘want’ value:

0 – no information can be provided about the project (e.g. a Ruby backend with a Python project).

10 – some information can be provided, but the backend is generic (e.g. Ruby backend).

20 – some information can be provided, and the backend is more generic than just language (e.g. Ruby on Rails backend).

30 – some information can be provided, and the backend is highly specialized.

Now I have what I want, what do I do with it?

Once pkgme has chosen your backend to use against an application, it will call one or more scripts from your backend to get information about the application. As the backend author, you can choose to provide separate scripts for each piece of information, or you can provide just a single script called ‘all_info’ that will provide everything.

Lots of scripts

For separate scripts, you will need to provide an executable in your backend directory for each of the pieces of information that pkgme might request. Each script should print that information to STDOUT, or exit with an error if it can not provide it.

Just one script

However, if looking up bits of information one at a time is a time-consuming task for your backend, you can do it all in one shot. If you want to do that, then the only script you need is one called ‘all_info’. When this script is called, it is also given a JSON list on STDIN. This list contains the keys for all the pieces of information that pkgme needs from your backend. As output, this scripts needs to print a JSON dictionary to STDOUT. This dictionary should contain a key for each of the fields sent as input, along with its corresponding value. If your backend can’t provide a value for one of those fields, it should be left out of the dictionary.

You can test your new backend by switching to the directory of a project your backend is made to support, and running:

pkgme

Make sure your virtualenv is still activated, or pkgme won’t be found. If everything works, you should have a ./debian/ directory in the application’s root folder.

Hurray, my backend works. Do you want it?

Of course we want it! What a silly question. And it’s already in your local branch of pkgme too! Well, it’s in the directory anyway, you still need to add it to the workingset:

Then head on over to https://code.launchpad.net/pkgme, click on your new branch name, and then click the “propose for merging” link. Fill out the description of what your backend adds, and submit it. From there it will get reviewed by one of pkgme’s maintainers, and either get merged into the main branch, or sent back to you for fixes.

My big focus during the week of UDS will be on improving our Application Developer story, tools and services. Ubuntu 12.04 is already an excellent platform for app developers, now we need to work on spreading awareness of what we offer and polishing any rough edges we find. Below are the list of sessions I’ll be leading or participating in that focus on these tasks.

Ubuntu 12.04, the Precise Pangolin, is scheduled to be released in a little over a week. This is a very exciting release for us, not only is it an LTS release with 5 years of support, but it also brings some major improvements to Unity and other areas of the desktop. It’s also going to see a very big focus on independent application developers.

Developers, Developers, Developers!

During the last six months we’ve spent a lot of time building tools and documentation for app developers. In September of 2011 we launched the Ubuntu Developer Portal, a site dedicated to helping application developers target the Ubuntu platform, and for getting their applications distributed through Ubuntu.

The developer portal provides all the information an app developer needs to write apps for Ubuntu. It will get you started with tools like Quickly, tell you what languages, toolkits and IDEs are available, and introduce you to the tools and workflows that make developing for Ubuntu a joy.

Once your app is ready, the Developer Portal will walk you through packaging it and submitting it to be published in the Ubuntu Software Center. The MyApps section lets you upload and manage all your applications, provide branding and screenshots, and set your purchase price.

Going Native

In the past couple of months we’ve added extensive documentation on Unity integration, which allows your application to become part of the desktop experience. The Unity APIs give your application a presence in multiple areas of the desktop, letting you to add extra information to the Launcher, indicators in the panel, search results in the Dash and more.

All about the Apps

Everybody knows that “Apps” are the big thing now. No longer relegated to tablets and smartphones, “App Stores” are coming to both major proprietary desktop operating systems as well. The Ubuntu Software Center already supports independent free and paid app downloads, and with 12.04 we want to grow that segment exponentially.

Not only do we provide a rich platform for app developers to target, we also have the means of delivering those apps directly to over 12 million users worldwide. With Unity, your app isn’t just visible in the Ubuntu Software Center, but we put it right in the Dash! Your app will show up whenever the user searches their system for something similar, giving it a level of visibility that no other platform offers.

Join the conversation

Developing applications for Ubuntu doesn’t have to be something you do in isolation. Having a strong community is an important aspect in today’s software market, and Ubuntu provides you with the tools for collaborating with the existing Ubuntu user community and for growing a strong user community around your own application. These users can help grow your app by add translations, identify bugs, and even submitting patches.

We’re also building a vibrant community of app developers, and we want you to be a part of that. Learn tips and tricks from other app developers, share your own expertise and build professional connections. Here you will also find a number of Ubuntu and Canonical developers who will take your suggestions and feedback for making app development on Ubuntu even better.

When the topic of contributions to FOSS come up, it usually happens that people focus entirely on the aspect of creation, specifically code creation, to the exclusion of all others. In the context of software, this makes a certain amount of sense, since the primary product is the code itself, either in source or binary form. Even the more broadly-focused, who make a point to expand their definition to include things like documentation and artwork, will still focus exclusively on the creation of those works. And yet perhaps the single biggest factor towards increased creation of code is in the distribution of what is being created.

There are a number of reasons for people to write new code. We often talk about a developer “scratching their own itch”, but other times it can be a matter of personal improvement, monetary gain, or even just plain fun. While there are many reasons to write code, there are not so many reasons for releasing it under a Free or Open Source license. By choosing such a license, the author explicitly wants his or her creation to be used by others, as many others as possible in fact. The use of their creation is what motivates them, and it stands to reason that the more it is used, the more motivating it becomes to create. The underlying reason why this is motivating can vary, but the fact is that creators of FOSS are motivated by the use of FOSS, and the more users there are, the more motivation there will be for creating it.

The number and variety of potential consumers of FOSS is larger than any single developer can hope to reach. Even a group of developers, even a large group of them, will find it impossible to make their creations available to the widest possible audiences. And the more effort they put into making their creation available, the less time and resources they have to put back into creating new things. Likewise the smaller the pool of potential consumers, the less reason developers have to improve on or create something in the first place. But by choosing an open source license, developers separate the work of distribution from that of creation. The desire for their creation, then, will naturally lead to a much larger number of individuals and groups bringing these creations to the people who want them. More importantly, by focusing exclusively on the task of distributing, these new groups are able to afford not just one project, but a multitude of projects, with an increase in the consumption of their creation. And with an increase in consumption, it is reasonable to expect an increase in contributions.

The default application selection for each Ubuntu release is often the subject of much discussion and advocacy. People called for the inclusion of Banshee long before Ubuntu made the switch. It’s unimaginable that people who like a project and appreciate it’s developers would actively seek to have it used by an organization that contributed nothing back. Likewise when it was announced that Ubuntu would switch back to Rhythmbox, those same advocates genuinely believed that they had lost something, again something unimaginable if they weren’t gaining something valuable from the distribution. When PiTiVi was selected as a default application, advocates for Openshot made a very strong case for why their preferred application should be included, again because they knew that the project would gain something of value from the increased distribution. The same happened with F-Spot and Shotwell, with the removal of the Gimp, the various boot splash systems, and more. I can only assume that the same happens in other distributions. The only reason why this would happen is if, whether consciously or not, people see a real value, as real as the value of code contributions, in being distributed as widely as possible.

By relieving the developers of the need to put resources into distribution, distributors allow them to create more using the same commitment of time and resources. Likewise, by increasing the number of people who will be using it, the distributors multiply the motivating value, whatever it may be, that the developer gets in return. And as the motivation for creating increases, the number of people who participate in creating also increases. In this way, every distributor of Free and Open Source software contributes towards increasing the total number of creators and creations (including lines of code written), and they do so in direct proportion to the expansiveness of their distribution.

I spent some more time over the weekend working on Hello Unity. If you haven’t already, be sure to read my first post about it. In short, Hello Unity is a showcase application that demonstrates all the different ways an application developer can integrate their app with the Unity desktop.

The current version of Hello Unity sports a new syntax-highlighted code display, which makes it much easier to read and understand what the code is doing. I also spent a significant amount of time going through and heavily commenting the code to explain what everything was doing.

In the Launcher section I added support for setting the “urgent” status of the application. In Unity, this will cause the application’s icon in the Launcher to shake and, if the Launcher is set to auto-hide, will also cause the icon to slide out into view while it shakes. This is a very useful way of telling a user that your application needs their attention.

A new section was added for integrating with the Message Menu. It automatically adds a Hello Unity section to the menu, and allows you to add count indicators to it. Clicking on an item in the menu will execute the code for removing it. All of this is explicitly commented on in the source code.

Another new section is for Notifications. While it uses the generic libnotify API, it does highlight how to use it with Ubuntu’s Notify-OSD display system, including how to updated and append text to the currently displayed notification.

Once again, if you are interested in contributing to this project, you can get the code from the Launchpad project page. Also available there are source tarballs and installable .DEB files.

Everybody knows that programmers can contribute to Unity, and I’ve shown in my previousposts that non-developers can still contribute features and fixes that make applications integrate better. But what if your skills lay more on the creative side of the spectrum?

Well it just so happens that you have something to contribute to Unity too. In fact, we’re currently in need of some graphic design talent to put some extra polish on some areas of application integration. Specifically, we need people to help create vector art for application icons that only have raster images, PNG, XPM, etc.

This wiki page contains a list of applications that have been identified as needing an SVG icon.

Now graphic creation isn’t my specialty, so I’m not going to write a step by step guide to creating these images, that’s up to you artists. What I am going to do, however, is walk you through the process of coordinating with the upstream application developers and submitting your finished image to Ubuntu.

1) Contact the upstream

This is an important step, because even if an application doesn’t have an SVG icon in Ubuntu, there’s still a chance that one already exists. Read over the first half of my post on upstreaming Quicklists for ways to get in contact with with them. Ask them if they have an SVG source for their application’s icon. If they do, that’s great! You can take that and skip down to step #3. If they don’t, then you will need to work with the upstream project to create one that is right for them.

2) Work with the current image

It’s important that we don’t try and re-brand an application unless the authors want it re-branded. What we want is a more flexible/scalable version of the image icon we already have. If you are creating a new SVG file, try to keep as close to the raster image as possible, and be sure to talk to the upstream developers about any deviations or changes you need to make. And finally, keep with the spirit of open source and make your new image available to both Ubuntu and the upstream project under a copy-left license like the CC-BY-SA or another permissive license of the upstream’s preference.

3) Preparing your image

Since we are getting close to the release of 12.04, the requirements for any further changes are getting stricter. In order to get your image into the Precise packages, you will need to meet the following two criteria:

It must be approved by the upstream project. Since your image will be representing their application in Ubuntu, we absolutely need their acceptance of it before it can be used. This is why step #1 is so vitally important, make sure you are working and communicating closely with upstream from the very beginning.

It must be a plain SVG file. This is because it will be added as a patch file against the package, and patch files don’t work well with binary data. Since a plain SVG file is text, not binary, it makes it much easier to convert into a patch.

4) Submit your new image

The wiki page containing the list of applications has a link to the corresponding bug report filed in Launchpad. When your image is ready, attach it to the bug report.

You will also need to add the upstream project to the bug report. Click the “Also affects project” link on the bug page, and choose the Launchpad Project that matches your upstream.

That’s it! Well, almost. Once we have your image, the application’s package in Ubuntu will need to be updated to use it, but that will require some changes to packaging scripts and patch files, which will be the subject of a more technical post. But getting the necessary image is itself a big step.

Bazaar is a great tool for distributed development, but distros are built on packages, and so packages are what distro developer care about. That’s why many of you who have followed my previous blogs have probably been asked for patches to the package itself, not to the bzr branch.

Why the difference? Well for package maintainers, it’s easier and faster to import upstream changes if they keep their source code clean. To do that, any changes made by the distro are applied on top of the unmodified upstream code in the form of patches. There are many tools designed specifically to make this easy for the package maintainers.

Below I’m going to show you how to turn your code change into a package patch that is easy for Ubuntu developers to add to the distro’s packages. Only do this if your submitted branch is to a package in main and it hasn’t already been merged.

0) Check your source package format

The following instructions will only work on source packages using quilt 3.0 for managing patches. Before you do anything else, check that the file debian/source/format contains the following:

3.0 (quilt)

1) Find your revisions

Starting from your existing code branch, we first need to identify which revisions in your branch we need to turn into a patch. To do that, we simply check for revisions in your branch that don’t exist in the main one. Here is what I used for geany:

bzr missing --mine-only ubuntu:geany

You just need to replace ‘geany’ with your application’s branch name (the same you bzr branched in my earlier articles). The –mine-only will limit the result to only revisions in your branch just to keep things simple. You’ll want to make note of the first and last revisions in this output. If, like me, you only had one revision missing, that makes it even easier.

2) Generate the patch

Fortunately the package “bzr-builddeb” provides a command that makes this step easy.

Again, just replace ‘geany’ with your application’s branch name, and dep3-patch will find the differences in your branch and convert them into a patch file.

Now that you have a patch file, we need to add it to the list of patches for this package. To do that, all you need is to add it’s name to the end of the debian/patches/series file like this:

echo add_keywords.patch >> debian/patches/series

3) Convert your source changes

Now that your changes are in a patch file, we need remove those changes from the source code itself. This is where those revision numbers from step 1 come in, you will need the highest revision number and one less than the lowest. Since I only had one revision, rev 32, my numbers are 32 and 31.

bzr diff -r 32..31 | bzr patch

This causes bzr to generate a reverse-diff of your changes (by going from the higher to the lower revision), and then apply that reverse-diff to your current code, effectively undoing your changes.

Now you need to apply your new patch file using quilt, so that quilt knows about it:

quilt push -a

Which should give you the following output if everything applies cleanly (if not, then your package is going to need some extra work, and you should ask for help from someone in #ubuntu-devel on freenode IRC).

4) Log your changes

You will, of course, want to replace my name and email with your own (Hint: you can put those 2 export lines into ~/.bashrc for future packaging work). This will create a new entry in the chanelog for you, with one higher version number. All you need to do it add in the comments:

* Add search keywords to .desktop file (LP: #942154)

Be sure to use the proper bug number for your changes. Also, if you are not running on Precise, you will need to change the release target at the top of the file to ‘precise’. Here’s what my new record looks like:

There has been a fantastic amount of feedback and contributions being made by folks who have been following my recentposts, and we’ve already had some of those contributions landing in Ubuntu 12.04. But we’re not done yet!

Ubuntu means “I am who I am, because of who we all are”. In a very literal sense, Ubuntu is what it is, because of what other distros are. We all bring together the best open source software from upstream developers, and we should all be giving our improvements back to those developers. Unity may be the default desktop on Ubuntu, but it’s also been ported to ArchLinux and SuSe, and is making it way to Fedora too. That means that your Quicklist contribution can help more than just Ubuntu, all you need to do is submit it upstream.

Step 1: Find your Upstream

While all of Ubuntu’s package sources use Launchpad, and are therefore all in the same place, your upstream developers will all of their own separate spaces. Some are rather easy to find, for example Firefox is developed over on mozilla.org. Others may use GitHub, SourceForge, or their own sites. So you first task if to find out where the code is developed.

Step 2: Talk to your Upstream

Once you’ve found their development home, look for ways of contacting the developers. Usually there will me an email/mailing list available, an IRC channel or a forum. Whatever method they prefer, us it to ask the developers how they want you to submit your patch. Most developers love being contacted by somebody who already has a patch written.

Step 3: Submit your changes

Depending on your upstream’s development process, they may want a patch file with your changes, or they might ask you to use their version control system of choice (svn, git, etc) to submit your change in a way that is easy for them to merge. Some, especially Debian, may request a patch for the package itself. This is why Step 2 is so important, you need to know how to submit it in order for it to be accepted. Don’t worry if you don’t know how do what they want, ask them to help you learn it. Again, developers like people who come to them with patches.

For Geany, I first found their website, geany.org, and from there a link to their Feature Tracker on SourceForge. I also found their IRC channel, #geany on freenode, and was in contact with their developers there. In the end, I was asked to create a fork of their code on GitHub, and submit my change as a Pull Request.

Step 4: Updated your Merge Proposal

Once you’ve submitted you changes upstream, leave a comment to that effect in your merge proposal. Ubuntu developers don’t like to keep custom changes in Ubuntu, and your merge proposal is much more likely to be accepted if they know the change will eventually be made in the upstream project as well.

Step 5: Stay involved with your Upstream

If you were working on a program you like, don’t let this be the end of your contribution! You now have experience making and submitting changes (to both Ubuntu and Upstream), and you are forming a relationship with the upstream developers. Keep up with both of those, as they will be invaluable assets to you.