Canonical Voices

Posts tagged with 'work'

Michael Hall

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.

Read more
Michael Hall

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.

Read more
Michael Hall

David Planella and I have spent the past couple of weeks gathering, cleaning and verifying Unity integration documentation that has existed on the Ubuntu wiki, individual blogs and inside the source code itself.   After publishing those docs, a couple of people asked for some kind of simple “hello world” type of application to show off how all that integration works.

So, I made one.

You can get the code from Launchpad:

bzr branch lp:hello-unity

It’s not complete yet, but it’s a start.  Let me know if you’re interesting in contributing to it.

Read more
Michael Hall

Everybody knows that programmers can contribute to Unity, and I’ve shown in my previous posts 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.

Read more
Michael Hall

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.

mkdir -p debian/patches
bzr dep3-patch -d ubuntu:geany . > debian/patches/add_keywords.patch

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).

Applying patch add_keywords.patch
patching file geany.desktop.in

Now at patch add_keywords.patch

 

4) Log your changes

Since you are making changes to the package itself now, you need to add that information to the debian/changelog:

export DEBFULLNAME="Michael Hall"
export DEBEMAIL="mhall119@ubuntu.com"
dch -i

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:

geany (0.21.dfsg-1ubuntu4) precise; urgency=low

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

-- Michael Hall <mhall119@ubuntu.com> Wed, 07 Mar 2012 14:40:32 -0500

 

5) Commit and push

Now it’s time to put everything back into your bzr branch.  First you need to add your patch file:

bzr add debian/patches/add_keywords.patch
bzr add debian/patches/series
bzr add .pc/

If your package branch didn’t already have a ‘series’ file, my instructions in step 2 will have created one, so I’m adding it here just in case.  If it already existed, bzr add won’t do anything.

Next, commit and push your changes back to your submitted branch:

bzr commit -m "Convert source changes into a package patch file"
bzr push lp:~mhall119/ubuntu/precise/geany/add_keywords

 

Read more
Michael Hall

It’s sometimes easy to talk about “Ubuntu developers” as if they are some faceless “others” who are separate from “Ubuntu users”.  But the reality is that the line between user and developer isn’t quite as clear as many people imagine.

In the response to my recent posts, this mixing of user and developer has become even more clear to me, and I wanted to share it with everybody.  These are the faces of some of the many non-developer users who make Ubuntu better for you.

Nekhelesh Ramananthan

Nekhelesh was one of the first contributors to respond to my postings, and he never slowed down.  He has contributed multiple additions of Quicklists and Keywords, improving the Unity integration for many popular applications.

Trenton Fox

Trenton was another early contributor, creating Quicklists for several of the applications I had targeted for better Unity integration.

David Baucum

David is a long-time member of of my own LoCo Team, so I was thrilled to see him submitting patches to Ubuntu apps.  He was also one of the first to have his contributions land in Ubuntu 12.04.

If you should happen to run into any of these guys online or in real life, be sure to thank them for making Ubuntu better for you.

Read more
Michael Hall

After all the terrific feedback and contributions we received from community contributors as a result of my Quicklists article, I’ve been asked to talk about how to contribute to improving another feature of Unity, the Applications Lens.

Search is the heart of the Unity Dash, and making search better is great way to contribute to the overall quality and usability of Ubuntu.  And just like Quicklists, there are ways you can do this without being a developer.  In this article, I will show you how to add Keywords to an application that will be used by the Dash’s search function.

Just like in my previous tutorial on Quicklists, I will once again be using Geany as my example application since it is one of my most-used programs.  Geany will be found in a search for “IDE” or “Development”, thanks to those words being in the Comment and GenericName fields of it’s .desktop file.  However, I think it should also be found in a search for “Code” and “Programming”, which it currently does not.

Step 0: File bug reports

This wasn’t part of the Quicklist tutorial, because I had already  filed bugs for the apps we were targetting.  But this time there is no list, so it’s up to you to make sure there is a bug report.  For ubuntu, you can file it against:

https://bugs.launchpad.net/ubuntu/+source/<source_name>/

It’s equally important to file a bug in the upstream’s Bug Tracker.  Refer to the stems up my post about upstreaming your quicklists for how to find your upstream.

Once you  have your bugs filed, post a link to them in the comments so that others know you are working on them.

Step 1: Getting the package code

Everything in Ubuntu exists in bzr, which makes getting the source for the package easy.  just “bzr branch ubuntu:<project>”.  For geany, this is what I ran:

bzr branch ubuntu:geany

If you followed the Quicklist tutorial, you’ll have already done this.  However, if your merge proposal hasn’t been accepted yet, it’ll be easier to do these changes on a clean branch.  You can give the name of a new directory for this checkout by running:

bzr branch ubuntu:geany ./geany-keywords

Step 2: Adding keywords

Again, just like with Quicklists, you first need to locate the .desktop file for your application.  For me, it was located in the root of the branch in a file called “geany.desktop.in”.  If you don’t see it in the root of your project’s branch, try running this command:

find ./ -name "*.desktop*"

This may not look exactly like the file in your /usr/share/applications/, since some processing is done to add translated strings for the application name and comments.  But as long as you are just adding the Keywords item to the bottom of the file you shouldn’t have to worry about that.

Next you  should look for deprecated keyword fields.  ”Keywords” is a new part of the XDG specification, but your application may have already been using the desktop-specific field “X-GNOME-Keywords”.  If it does, go ahead and rename it to “Keywords”.  Also check for the existence of fields starting with an underscore, like “_Name”.  If your .desktop file has those, that means it’s probably setup for translations already, and you should use “_Keywords” instead, so that they can be translated as well.

For geany, there was no existing Keywords field of any kind, but it was setup for translations, so I used the following:

mhall@mhall-laptop:~/projects/Ubuntu/unity/quicklists/geany$ bzr diff
=== modified file 'geany.desktop.in'
--- geany.desktop.in	2012-02-24 19:30:41 +0000
+++ geany.desktop.in	2012-02-27 18:31:39 +0000
@@ -10,3 +10,4 @@
 Categories=GTK;Development;IDE;
 MimeType=text/plain;text/x-chdr;text/x-csrc;text/x-c++hdr;text/x-c++src;text/x-java;text/x-dsrc;text/x-pascal;text/x-perl;text/x-python;application/x-php;application/x-httpd-php3;application/x-httpd-php4;application/x-httpd-php5;application/xml;text/html;text/css;text/x-sql;text/x-diff;
 StartupNotify=true
+_Keywords=Code;Editor;Programming;

Step 3: Submitting to Ubuntu

Now you need to send your changes to Ubuntu.  This is very similar to what we did for Quicklists, but I’ve added one extra piece to the commit command.

bzr commit -m "Add Keywords to .desktop file" --fixes lp:942154
bzr push lp:~mhall119/ubuntu/precise/geany/add_keywords

By passing the –fixes flag, along with your Launchpad bug #, to the bzr commit command, you will automatically link your new branch with the bug report you created in step 0.

The next step is to once again propose that your changes be merged into the Ubuntu package. To do that, run the following command to open the Launchpad page for your new branch:

bzr lp-open

On that page you’ll see a link labeled “Propose for merging”, click that and fill out the form on the next page to create your merge proposal.

Step 4: Submitting to Upstream

The final step is to send your changes upstream as well.  This is good practice whenever you are making changes, plus it makes it easier for Ubuntu’s package maintainers.  Since every upstream is different in how they want to get submissions, I recommend following my previous upstreaming tutorial for this step.

Read more
Michael Hall

The Ubuntu Florida LoCo Team is my home team, and this cycle I will once again be meeting up with Chris Johnston to participate in the Ubuntu Global Jam.  Since Chris is the one organizing this event again, I asked him a few questions about it.

Tell me about yourself and how you are involved in Ubuntu

My name is Chris Johnston. I got involved in Ubuntu about 3 years ago. I started by attending a Florida LoCo Team event at Michael Hall’s house. I got involved with the Ubuntu Beginners Team, the Classroom Team, and the BugSquad. I was one of the original planners of Ubuntu User Days and I got involved in developing for what is now the LoCo Team Portal. After attending my first UDS I saw a need and started coding on the Summit Scheduler. Now days I spend most of my time developing on Summit or the LoCo Team Portal.

Have you organized a Global Jam event before, and if so what was your experience? How did you choose a venue and select activities?

I organized a Global Jam event last cycle. We ended up with only 3 people participating, but we had a productive day hacking on summit.ubuntu.com and even got a new developer involved.

What kinds of activities do you plan of doing as part of your upcoming jam?

During this Global Jam, we will again be working on some of the community supported websites, including Summit and the LoCo Team Portal.

How do you spread the word about your event to get more people to participate?

Through the LoCo Team Portal and talking to people about it.

 

Now it’s time for you all to share your stories about past and future Global Jam events!

Read more
Michael Hall

As part of an ongoing series of blogs about LoCo Team Jams, I spoke with Benjamin Kerensa (bkerensa), the team contact for Ubuntu Oregon about their Global Jam activities.

 

Tell me about yourself and how you are involved in Ubuntu

My name is Benjamin Kerensa and I’m Team Lead for Ubuntu Oregon and also actively contribute to  the Ubuntu Weekly News, Ubuntu Developer News, Ubuntu Documentation, Ubuntu BugSquad and I write for OMG! Ubuntu!. I have been involved mostly behind the scenes for a number of years providing community support.

 

Have you organized a Global Jam event before, and if so what was your experience? How did you choose a venue and select activities?

I have organized a Global Jam before in fact I organized our event last year and I feel it turned out really nice however I did not fully take into account the amount of time needed to get people contributing at an event so our Jam last year was mostly social in nature but this year we are planning for a whole day from morning till late night. Last year I chose PuppetLabs to be our venue because I knew that the folks there shared a very common love for Free Open Source Software and also had facilities that were very accommodating for a crowd of our size. I selected documentation and bugs last cycle however due to the limited time we really didnt get to work on any tasks but we did however get to do a general overview of how to contribute in those areas.

 

What kinds of activities do you plan of doing as part of your upcoming jam?

This cycle we hope to focus on Bug Triaging and Bitesize Fixes with the help of Ubuntu BugMaster Brian Murray and potentially have a talk on packaging by
Steve Langasek. It is my hope that these focuses will not only benefit the LTS but also gear our community towards accelerated contributions in the area of    development and continue to lay a foundation for future contributors in Oregon to be involved in more technical focused contributions.

Our LoCo is lucky to have the opportunity to work with Western Oregon University this year in a Mentorship Project for their students in which they have chosen to learn how to contribute to Ubuntu as such we anticipate a number of those students to be in attendance.

 

How do you spread the word about your event to get more people to participate?

I announce via our mailing list and the loco directory and then cross post those announcements to other LUG and Tech focused mailing lists in our region and then I use a mix of social media and IRC to encourage our existing Ubuntu LoCo folks and others to come and check out what we have going on.

Thanks Ben and the entire Ubuntu Oregon team!

Read more
Michael Hall

There has been a fantastic amount of feedback and contributions being made by folks who have been following my recent posts, 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.

 

Read more
Michael Hall

Since almost all of recommended packages in my original post have been tackled already thanks to Nekhelesh Ramananthan and David Baucum, here’s a new list for those of you who are still itching to knock a few out.

This list contains some of the most popular downloads from the Ubuntu Software Center that don’t have a Quicklist in Precise.  Not all of them will have useful command line options to make shortcuts for, so if you run across one of those just mention it in the comments and I’ll take it off the list.

Available

Done

Not Available

  • firefox doesn’t properly handle command line options
  • vlc doesn’t support command line options
  • skype does not support command line options
  • gparted only supports 1 commandline option which is useless
  • gtk-recordmydesktop does not support command line options
  • openshot only supports 1 commandline option which is useless
  • eclipse does not support command line options
  • ubuntuone-control-panel needs dynamic quicklist (required coding)

Jorge Castro has also linked to an AskUbuntu page that lists many pre-made Quicklists for various apps that just need to be made in a bzr branch and turned into a merge proposal, which is another great and simple way to contribute to Ubuntu.

Read more
Michael Hall

Last night I posted about how non-developers can directly contribute to the Unity desktop experience, and this morning I was greated by not one, but two contributions already made by Nekhelesh Ramananthan.

First he added player controls to Totem, then he added shortcuts for Update Manager and PPA management to the Software Center launcher. That is some awesome work.

Thanks Nekhelesh!

Read more
Michael Hall

So you want to contribute to Ubuntu’s Unity desktop, but you’re not a software developer?  No problem, there are still plenty of things you can do.  And not just in terms of documentation and translations either, there are ways to contribute directly to the desktop without having to know any programming languages.  One of these is adding Quicklists to application launcher.

Quicklists can be added dynamically from within the program code, but they can also be defined statically outside of it, in a simple text file.  It’s these static Quicklists that anybody can contribute.

For this post, I’m going to walk through the process of adding a Quicklist to Geany, my personal programming editor of choice.  You can add one for your favorite app, of choose from one of the following popular applications that are in need of a Quicklist:

IMPORTANT! Leave a comment before you start on one of these, we has 2 people working on a Brasero Quicklist because of a lack of communication.
If you chose one of these, be sure to update the linked bug report with your work.  If you choose something different, it would be a good idea to file a bug for adding a Quicklist.  Either way, I’d like to know what you’re doing, so please leave a comment on this post.

Step 1: Getting the package code

Everything in Ubuntu exists in bzr, which makes getting the source for the package easy.  just “bzr branch ubuntu:<project>”.  For geany, this is what I ran:

bzr branch ubuntu:geany

 Step 2: Add your Quicklist items

The first think you need to do is locate the .desktop file for your application.  For me, it was located in the root of the branch in a file called “geany.desktop.in”.  If you don’t see it in the root of your project’s branch, try running this command:

find ./ -name "*.desktop*"

This may not look exactly like the file in your /usr/share/applications/, since some processing is done to add translated strings for the application name and comments.  But as long as you are just adding the Quicklist items to the bottom of the file you shouldn’t have to worry about that.

The next step is to add your Quicklist shortcuts following this specification:

mhall@mhall-laptop:~/projects/Ubuntu/unity/quicklists/geany$ bzr diff
=== modified file 'geany.desktop.in'
--- geany.desktop.in 2011-05-28 19:49:19 +0000
+++ geany.desktop.in 2012-02-22 01:18:55 +0000
@@ -10,3 +10,9 @@
Categories=GTK;Development;IDE;
MimeType=text/plain;text/x-chdr;text/x-csrc;text/x-c++hdr;text/x-c++src;text/x-java;text/x-dsrc;text/x-pascal;text/x-perl;text/x-python;application/x-php;application/x-httpd-php3;application/x-httpd-php4;application/x-httpd-php5;application/xml;text/html;text/css;text/x-sql;text/x-diff;
StartupNotify=true
+Actions=New
+
+[Desktop Action New]
+Name=Open a New Instance
+Exec=geany --new-instance
+

(UPDATE 2012-02-28: A new XDG spec has been approved to make Quicklists desktop agnostic.  The Unity documentation has the new examples, and I have update the snippet above to match.)

As you can see in the example above, there isn’t much you need to do to add a Quicklist shortcut.  Calling the application’s binary with a different argument (as I did here with –new-instance) is a common and easy shortcut.  You can usually find all the available arguments to your application by calling with with –help.

 Step 3: Submitting your changes

Now that you’ve made your changes, we need to get them back into the main package.  Chances are you don’t have permission to apply them directly (otherwise you wouldn’t need this tutorial), so instead you’re going to put it somewhere else.

bzr commit -m "Add a Unity Quicklist"
bzr push lp:~mhall119/ubuntu/precise/geany/add_quicklist

This will put your changes on Launchpad in a place that the people who actually can apply it to the main packages can see your work.  But just because they can see it doesn’t mean they will see it, at least not without a little prompting from you.

To open the page on Launchpad that you just created (with your bzr push), run the following:

bzr lp-open

On that page you’ll see a link labeled “Propose for merging”, click that and fill out the form on the next page to create your merge proposal.

Step 4: Recompiling your kernel

Just kidding, there is no step 4.  You’re done!  You’ve contributed to making Ubuntu and Unity a better experience for millions of users.  Congratulations, and thank you!

 

Read more
Michael Hall

There have been some recent accusation that the Ubuntu community isn’t taking criticism well.  However, those making the accusations seem to have a misunderstanding about what exactly criticism is.  In an effort to improve the quality of that feedback, I’ve put together a short, simple list of things you can check to make sure your criticism is in fact criticism.

1) “It sucks” is not criticism

It’s an insult.  It means “I have no respect for you, your time, or your talents”.  Don’t be surprised when the recipient of this message is not inclined to help you, or even listen to you, afterwards.

2) “I don’t like it” is not criticism

It’s complaining.  In order to elevate complaining to criticism, you need to explain why it is bad in a way that gives enough information for it to be improved.  If you are not capable of explaining why it is bad, then you don’t fully understand why you don’t like it.  And if you don’t understand why you don’t like it, what hope do we have of knowing how to fix it?

3) “It’s not perfect” is not criticism

We know it’s not perfect.  It’s not perfect because we are not perfect.  Another consequence of our being mortal is the fact that we don’t necessarily know where it’s not perfect, so please go back and read #2 again.

4) “Make it more like X” is not criticism

If what you  really want is X, then use X.  If you  think X is doing something better, then explain what it is and why it is better in a way that is more than just “It is better because X has it, and X is better”.  Again go back and re-read #2.

5) “Turn it into something different” is not criticism

Just because something isn’t what you want, doesn’t mean it’s not what it is supposed to be.  Don’t ask for changes to the fundamental nature of something. If something is fundamentally different from what you want, look for something else.

If your feedback doesn’t fall into one of these five areas, then there’s a very good chance that it will be welcomed and worked on by the Ubuntu community.  If it does, then I would seriously recommend going back and re-thinking your position.

Read more
Michael Hall

One of the most requesting things since I first introduced Singlet was to have a Quickly template for creating Unity Lenses with it.  After weeks of waiting, and after upgrading Singlet to work in Precise, and getting it into the Universe repository for 12.04, I finally set to work on learning enough Quickly internals to write a template.

It’s not finished yet, and I won’t guarantee that all of Quickly’s functions work, but after a few hours of hacking I at least have a pretty good start.  It’s not packaged yet, so to try it out you will need todo the following:

  1. bzr branch lp:~mhall119/singlet/quickly-lens-template
  2. sudo ln -s ./quickly-lens-template /usr/share/quickly/templates/singlet-lens
  3. quickly create singlet-lens <your-lens-project-name>
  4. cd <your-lens-project-name>
  5. quickly package

Read more
Michael Hall

We’re coming up on the next Ubuntu Global Jam, the point in every cycle where the community gets together for a weekend of contributing to the next release of Ubuntu.  And this time we’re shaking things up a little bit.

Every cycle we help people organize their jams, and suggest the same generic topics: Bug triaging, packaging, translations, documentation, testing, etc.  This time, in addition to these topics, we will be reaching out to the various teams both in Canonical and the Community, and picking some very specific activities that will directly help them make the Precise Pangolin the best release of Ubuntu ever.

Another change this cycle is a focus on bringing all of the global jam activities together so that we can all see, in real time, the work being done by contributors around the world.  To that end, we’ve added a Global Jam Dashboard to the LoCo Teams Portal, which features an integrated webchat, updating twitter/identi.ca stream, and photo feed.  So while you are jamming locally, be sure to tweet about it using the #ubuntu hashtag, and upload photos to Flickr, Picasa or pix.ie, again using the #ubuntu hashtag.

Read more
Michael Hall

Starting today at 1500 UTC, we’ll be conducting a series of online classes for Ubuntu Developer Week.  Whether you are interest in developing new applications for Ubuntu, or want to make an existing app take advantage of all of Ubuntu’s features, this is definitely something you should attend.

This cycle Daniel Holbach will kick things off with a overview of Ubuntu development, using Bazaar and Launchpad to collaborate both online and off with teams of developers all over the world.

After that I will be giving an overview of the unique collection of technologies and services that Ubuntu offers application developers, including Unity integration, Ubuntu One cloud storage, and the Software Center.  Then I will be joined by Micha? Sawicz to talk about Ubuntu TV, and how you can get a development environment setup and start hacking on it yourself

Later, David Callé and Michal Hruby will be showing you how to integrate with the Unity Dash by writing custom lenses and scopes for your content.  And if you are interested in that, be sure to come back Thursday for my session on writing simple lenses and scopes in Python using the Singlet library.

Mark Mims and Dustin Kirland will both by presenting on different ways Ubuntu lets you take advantage of the latest cloud technology to improve the development, testing and deployment of your application and stack.  And Stuart Langridge will be talking about the latest developments in the Ubuntu One Database (U1DB), and then showing how you can integrate our file and data syncing infrastructure into your own application.

You will also learn how to work upstream with Debian (both pulling changes in and sending them back), how to properly and easily package your application for distribution, and of course how to work on contributing changes back to Ubuntu itself.

Read more
Michael Hall

If you have written or know how to write a Quickly template, I’d like to get some help making one for Singlet Lenses and Scopes.

Read more
Michael Hall

I’ve finally had a little extra time to get back to working on Singlet.  There’s been a lot of progress since the first iteration.  To start with, Singlet had to be upgraded to work with the new Lens API introduced when Unity 5.0 landed in the Precise repos.  Luckily the Singlet API didn’t need to change, so any Singlet lenses written for Oneiric and Unity 4 will only need the latest Singlet to work in Precise[1].

The more exciting development, though, is that Singlet 0.2 introduces an API for Scopes.  This means you can write Lenses that support external scopes from other authors, as well as external Scopes for existing lenses.  They don’t both need to be based on Singlet either, you can write a Singlet scope for the Music Lens if you wanted to, and non-Singlet scopes can be written for your Singlet lens.  They don’t even have to be in Python.

In order to make the Scope API, I chose to convert my previous LoCo Teams Portal lens into a generic Community lens and separate LoCo Teams scope.  The Lens itself ends up being about as simple as can be:

from singlet.lens import Lens, IconViewCategory, ListViewCategory 

class CommunityLens(Lens): 

    class Meta:
        name = 'community'
        description = 'Ubuntu Community Lens'
        search_hint = 'Search the Ubuntu Community'
        icon = 'community.svg'
        category_order = ['teams', 'news', 'events', 'meetings']

    teams = IconViewCategory("Teams", 'ubuntu-logo')

    news = ListViewCategory("News", 'news-feed')

    events = ListViewCategory("Events", 'calendar')

    meetings = ListViewCategory("Meetings", 'applications-chat')


As you can see, it’s really nothing more that some meta-data and the categories.  All the real work happens in the scope:

class LocoTeamsScope(Scope):

    class Meta:
        name = 'locoteams'
        search_hint = 'Search LoCo Teams'
        search_on_blank = True
        lens = 'community'
        categories = ['teams', 'news', 'events', 'meetings']

    def __init__(self, *args, **kargs):
        super(LocoTeamsScope, self).__init__(*args, **kargs)
        self._ltp = locodir.LocoDirectory()
        self.lpusername = None

        if os.path.exists(os.path.expanduser('~/.bazaar/bazaar.conf')):
            try:
                import configparser
            except ImportError:
                import ConfigParser as configparser

            bzrconf = configparser.ConfigParser()
            bzrconf.read(os.path.expanduser('~/.bazaar/bazaar.conf'))

            try:
                self.lpusername = bzrconf.get('DEFAULT', 'launchpad_username')
            except configparser.NoOptionError:
                pass

    def search(self, search, model, cancellable):


I left out the actual search code, because it’s rather long and most of it isn’t important when talking about Singlet itself.  Just like the Lens API, a Singlet Scope uses an inner Meta class for meta-data.  The most important fields here are the ‘lens’ and ‘categories’ variables.  The ‘lens’ tells Singlet the name of the lens your scope is for.  Singlet uses this to build DBus names and paths, and also to know where to install your scope.  The ‘categories’ list will let you define a result item’s category using a descriptive name, rather than an integer.


 model.append('http://loco.ubuntu.com/events/%s/%s/detail/' % (team['lp_name'], tevent['id']), team['mugshot_url'], self.lens.events, "text/html", tevent['name'], '%s\n%s' % (tevent['date_begin'], tevent['description']), '')

It’s important that the order of the categories in the Scope’s Meta matches the order of categories defined in the Lens you are targeting, since in the end it’s still just the position number that’s being passed back to the Dash.

After all this, I still had a little bit of time left in the day.  And what good is supporting external scopes if you only have one anyway?  So I spent 30 minutes creating another scope, one that will read from the Ubuntu Planet news feed:

The next step is to add some proper packaging to get these into the Ubuntu Software Center, but you impatient users can get them either from their respective bzr branches, or try the preliminary packages from the One Hundred Scopes PPA.

[1] Note that while lenses written for Singlet 0.1 will work in Singlet 0.2 on Precise, the reverse is not necessarily true.  Singlet 0.2, as well as lenses and scopes written for it, will not work on Oneiric.

Read more
Michael Hall

In an effort to increase the exposure of the work being done to improve the Unity desktop, we are moving discussions from the code-named #ayatana channel on freenode to the more discoverable #ubuntu-unity channel (still on freenode).  If you want to talk to Unity developers, find out what’s happening, or join the growing ranks of community contributors, this is a good place to start.

Read more