Canonical Voices

Posts tagged with 'work'

Michael Hall

It’s official, UDS 13.05 is coming up next month, marking our second online Ubuntu Developer Summit, and coming only two months after the last one. While going virtual was part of our transition to make Ubuntu’s development more open and inclusive, the other side of that coin was to start holding them more often. The first we put into affect in March, and the second is coming in May. Read below for information about this UDS, and changes that have been made in response to feedback from the last one.

Scheduling

The dates for UDS 13.05 are May 14, 15 and 16, from 1400 UTC to 2000 UTC.  We will once again have 5 tracks: App Development, Community, Client, Server & Cloud and Foundations.  The track leads for these will be:

  • App Development: Alan Pope, David Planella & Michael Hall
  • Community: Daniel Holbach, Nick Skaggs & Jono Bacon
  • Client: Jason Warner & Sebastien Bacher
  • Server & Cloud: Dave Walker & Antonio Rosales
  • Foundations: Steve Langasek

Track leads will be in charge of approving Blueprints and getting them on the schedule.  If you are going to be responsible for running a session, please get with the track lead to make sure they have marked you as being required for that session. If you would like to get a session added for this UDS, you can do so either through registering a Blueprint or proposing a meeting through Summit itself.  Both approaches will require the approval of a Track Lead, so make sure you discuss it with them ahead of time.

Changes to…

Using feedback from attendees of the March UDS, we will be implementing a number of changes for UDS 13.05 to improve the experience.

Hangouts

Google+ Hangouts have a limit of 15 active participants (if started with a Canonical user account, it’s 10 if you don’t have a Google Apps domain), but in practice we rarely had that many people join in the last UDS.  This time around we’re going to encourage more people to join the video, especially community participants, so please check your webcams and microphones ahead of time to be ready.  If you want to join, just ask one of the session leaders on IRC for the hangout URL. We are also investigating ways to embed the IRC conversations in the Hangout window, to make it easier for those on the video to keep track of the conversation happening there.

The Plenaries

Most people agreed that the mid-day plenaries didn’t work as well online as they do in person.  There was also a desire to have a mid-day break to allow people to eat, stretch, or hold a sidebar conversation with somebody.  So we are replacing the mid-day plenaries with a “lunch” slot, giving you an hour break to do whatever you need to do. We will be keeping the introductory plenary on the morning of the first day, because that helps set the tone, goals and information needed for the rest of the week.  In addition to that, we have added back a closing plenary at the end of the last day, where track leads will be able to give a summary of the discussions and decisions made.

The Schedule

In addition to the above plenary changes, we have added an extra day to this UDS, making it 3 days instead of two.  The last day will allow for overflow of sessions that couldn’t fit into 2 days, or the scheduling of follow-up session when it is determined they are necessary following a discussion earlier in the week.

Registration

Registration to attend will now be done in Summit itself, rather than through a Launchpad Sprint.  So if you’re not a track lead, and you’re not registering Blueprints, there’s nothing you need to do on Launchpad itself.  This will help those who do not have a Launchpad profile, though you will still need an Ubuntu SSO account to log in.

To register for UDS 13.04, go to the summit page, and just above the schedule you will see an orange “Register in Summit” button.  If you don’t see that, you either need to log in to  summit or you’ve already registered.

Summit Scheduler

Chris Johnston and Adnane Belmadiaf have been working hard to improve the Summit Scheduler website, taking feedback from attendees to improve the interface and workflow of the site.  We will include as many enhancements as possible before the start of UDS 13.05.  If you are interested in helping improve it, and you have some web development skills, please find them on #ubuntu-website on Freenode to find out how you can get involved.

Read more
Michael Hall

I’m happy to announce that today I filed for a Feature Freeze Exception to get the latest Unity stack into Ubuntu Raring.  It’s a lot of new code, but it should all be available in a PPA in the next day or so, and it’ll be available there for about two weeks for people to test and provide feedback before it lands.  I won’t go into all of the fixes, performance work and other technical changes, but if you’re interested in what this means for you as a user, keep reading.

Smart Scopes

Discussed during a UDS-style Ubuntu On-Air hangout back in January, Smart Scopes use an intelligent server-side service to decide when they should be used to search.  This allows a single process (the Dash Home) to run a query through only a sub-set of your installed scopes.  It also allows the scopes processes to be terminated when you close the dash, and only re-start those that are likely to produce a relevant result.  As defined by the spec, this service will learn as more people use it, providing more relevant results, so you don’t get unwanted Amazon product results when it should be obvious you’re looking for an application.  It also means fewer running processes on your local machine, and therefore less memory usage overall.

100 Scopes

While there won’t be quite 100 in this release, there will be more scopes installed on the client than in previous releases, and even more that we will be able to implement on the server-side.  Thanks to the Smart Scope Service, these additional local scopes won’t be using up a lot of your system resources, because they’ll only be run when needed, then immediately terminated.  You will be able to install 3rd party scopes, just as before, even ones that the Smart Scope Service doesn’t know about yet.  Plus we will be able to add more server-side scopes during the lifetime of a stable release.  So while we’re not at 100 yet, there is still a large and growing number of scopes available.

Privacy

Now I know I couldn’t get away with talking about changes to the Dash, especially ones that put more of it’s functionality online, without talking about privacy concerns.  With these changes we’ve tried to strike a balance between control and convenience, privacy and productivity.  So while we’re providing more fine-grained controls over what scopes to enable, and whether or not to use the Smart Scope service, the default will still be to enable the services that we believe provides the best user experience on Ubuntu.  In addition, 13.04 has already added more notice to users that their the Dash will search online sources as well as local.

Read more
Michael Hall

UPDATE: A command porting walk-through has beed added to the documentation.

Back around UDS time, I began work on a reboot of Quickly, Ubuntu’s application development tool.  After two months and just short of 4000 lines of code written, I’m pleased to announce that the inner-workings of the new code is very nearly complete!  Now I’ve reached the point where I need your help.

The Recap

First, let me go back to what I said needed to be done last time.  Port from Python 2 to Python 3: Done. Add built-in argument handling: Done. Add meta-data output: Well, not quite.  I’m working on that though, and now I can add it without requiring anything from template authors.

But here are some other things I did get done. Add Bash shell completion: Done.  Added Help command (that works with all other commands): Done.  Created command class decorators: Done.  Support templates installed in any XDG_DATA_DIRS: Done.  Allow template overriding on the command-line: Done.  Started documentation for template authors: Done.

Now it’s your turn

With the core of the Quickly reboot nearly done, focus can now turn to the templates.  At this point I’m reasonably confident that the API used by the templates and commands won’t change (at least not much).  The ‘create’ and ‘run’ commands from the ubuntu-application template have already been ported, I used those to help develop the API.  But that leaves all the rest of the commands that need to be updated (see list at the bottom of this post).  If you want to help make application development in Ubuntu better, this is a great way to contribute.

For now, I want to focus on finishing the port of the ubuntu-application template.  This will reveal any changes that might still need to be made to the new API and code, without disrupting multiple templates.

How to port a Command

The first thing you need to do is understand how the new Quickly handles templates and commands.  I’ve started on some documentation for template developers, with a Getting Started guide that covers the basics.  You can also find me in #quickly in Freenode IRC for help.

Next you’ll need to find the code for the command you want to port.  If you already have the current Quickly installed, you can find them in /usr/share/quickly/templates/ubuntu-application/, or you can bzr branch lp:quickly to get the source.

The commands are already in Python, but they are stand-alone scripts.  You will need to convert them into Python classes, with the code to be executed being called in the run() method.  You can add your class to the ./data/templates/ubuntu-application/commands.py file in the new Quickly branch (lp:quickly/reboot).  Then submit it as a merge proposal against lp:quickly/reboot.

Grab one and go!

So here’s the full list of ubuntu-application template commands.  I’ll update this list with progress as it happens.  If you want to help, grab one of the TODO commands, and start porting.  Email me or ping me on IRC if you need help.

add: TODO
configure: TODO
create: DONE!
debug: TODO
design: TODO
edit: DONE!
license: TODO
package: DONE!
release: TODO
run: DONE!
save: DONE!
share: TODO
submitubuntu: TODO
test: TODO
tutorial: TODO
upgrade: TODO

Read more
Michael Hall

During this latest round of arguing over the inclusion of Amazon search results in the Unity Dash, Alan Bell pointed out the fact that while the default scopes shipped in Ubuntu were made to check the new privacy settings, we didn’t do a very good job of telling third-party developers how to do it.

(Update: I was told a better way of doing this, be sure to read the bottom of the post before implementing it in your own code)

Since I am also a third-party lens developer, I decided to add it to my come of my own code and share how to do it with other lens/scope developers.  It turns out, it’s remarkably easy to do.

Since the privacy setting is stored in DConf, which we can access via the Gio library, we need to include that in our GObject Introspection imports:

from gi.repository import GLib, Unity, Gio

Then, before performing a search, we need to fetch the Unity Lens settings:

lens_settings = Gio.Settings(‘com.canonical.Unity.Lenses’)

The key we are interested in is ’remote-content-search’, and it can have one of two value, ‘all’ or ‘none’.  Since my locoteams-scope performs only remote searches, by calling the API on http://loco.ubuntu.com, if the user has asked that no remote searches be made, this scope will return without doing anything.

And that’s it!  That’s all you need to do in order to make your lens or scope follow the user’s privacy settings.

Now, before we get to the comments, I’d like to kindly point out that this post is about how to check the privacy setting in your lens or scope.  It is not about whether or not we should be doing remote searches in the dash, or how you would rather the feature be implemented.  If you want to pile on to those argument some more, there are dozens of open threads all over the internet where you can do that.  Please don’t do it here.
&nbps;

Update

I wasn’t aware, but there is a PreferencesManager class in Unity 6 (Ubuntu 12.10) that lets you access the same settings:

You should use this API instead of going directly to GSettings/DConf.

Read more
Michael Hall

The Ubuntu Skunkworks program is now officially underway, we have some projects already staffed and running, and others where I am gathering final details about the work that needs to be done.  Today I decided to look at who has applied, and what they listed as their areas of interest, programming language experience and toolkit knowledge.  I can’t share details about the program, but I can give a general look at the people who have applied so far.

Most applicants listed more than one area of interest, including ones not listed in Mark’s original post about Skunkworks.  I’m not surprised that UI/UX and Web were two of the most popular areas.  I was expecting more people interested in the artistic/design side of things though.

Not as many people listed multiple languages as multiple areas of interest.  As a programmer myself, I’d encourage other programmers to expand their knowledge to other languages.  Python and web languages being the most popular isn’t at all surprising.  I would like to see more C/C++ applicants, given the number of important projects that are written in them.  Strangely absent was any mention of Vala or Go, surely we have some community members who have some experience with those.

The technology section had the most unexpected results.  Gtk has the largest single slice, sure, but it’s still much, much smaller than I would have expected.  Qt/QML even more so, where are all you KDE folks?  The Django slice makes sense, given the number of Python and Web applicants.

So in total, we’ve had a pretty wide variety of skills and interests from Skunkworks applicants, but we can still use more, especially in areas that are under-represented compared to the wider Ubuntu community.  If you are interested, the application process is simple: just create a wiki page using the ParticipationTemplate, and email me the link (mhall119@ubuntu.com).

Read more
Michael Hall

Now that Google+ has added a Communities feature, and seeing as how Jorge Castro has already created one for the wider Ubuntu community, I went ahead and created one specifically for our application developers.  If you are an existing app developer, or someone who is interested in getting started with app development, or thinking about porting an existing app to Ubuntu, be sure to join.

Google+ communities are brand new, so we’ll be figuring out how best to use them in the coming days and weeks, but it seems like a great addition.

Read more
Michael Hall

Shortly after the Ubuntu App Showdown earlier this year, Didier Roche and Michael Terry kicked off a series of discussions about a ground-up re-write of Quickly.  Not only would this fix many of the complications app developers experienced during the Showdown competition, but it would also make it easier to write tools around Quickly itself.

Unfortunately, neither Didier nor Michael were going to have much time this cycle to work on the reboot.  We had a UDS session to discuss the initiative, but we were going to need community contributions in order to get it done.

JFDI

I was very excited about the prospects of a Quickly reboot, but knowing that the current maintainers weren’t going to have time to work on it was a bit of a concern.  So much so, that during my 9+ hour flight from Orlando to Copenhagen, I decided to have a go at it myself. Between the flight, a layover in Frankfurt without wifi, and a few late nights in the Bella Sky hotel, I had the start of something promising enough to present during the UDS session.  I was pleased that both Didier and Michael liked my approach, and gave me some very good feedback on where to take it next.  Add another 9+ hour flight home, and I had a foundation on which a reboot can begin.

Where is stands now

My code branch is now a part of the Quickly project on Launchpad, you can grab a copy of it by running bzr branch lp:quickly/reboot.  The code currently provides some basic command-line functionality (including shell completion), as well as base classes for Templates, Projects and Commands.  I’ve begun porting the ubuntu-application template, reusing the current project_root files, but built on the new foundation.  Currently only the ‘create’ and ‘run’ commands have been converted to the new object-oriented command class.

I also have examples showing how this new approach will allow template authors to easily sub-class Templates and Commands, by starting both a port of the ubuntu-cli template, and also creating an ubuntu-git-application template that uses git instead of bzr.

What comes next

This is only the very beginning of the reboot process, and there is still a massive amount of work to be done.  For starters, the whole thing needs to be converted from Python 2 to Python 3, which should be relatively easy except for one area that does some import trickery (to keep Templates as python modules, without having to install them to PYTHON_PATH).  The Command class also needs to gain argument parameters, so they can be easily introspected to see what arguments they can take on the command line.  And the whole thing needs to gain a structured meta-data output mechanism so that non-Python application can still query it for information about available templates, a project’s commands and their arguments.

Where you come in

As I said at the beginning of the post, this reboot can only succeed if it has community contributions.  The groundwork has been laid, but there’s a lot more work to be done than I can do myself.  Our 13.04 goal is to have all of the existing functionality and templates (with the exception of the Flash template) ported to the reboot.  I can use help with the inner-working of Quickly core, but I absolutely need help porting the existing templates.

The new Template and Command classes make this much easier (in my opinion, anyway), so it will mostly be a matter of copy/paste/tweak from the old commands to the new ones. In many cases, it will make sense to sub-class and re-use parts of one Template or Command in another, further reducing the amount of work.

Getting started

If you are interested in helping with this effort, or if you simply want to take the current work for a spin, the first thing you should do is grab the code (bzr branch lp:quickly/reboot).  You can call the quickly binary by running ./bin/quickly from within the project’s root.

Some things you can try are:

./bin/quickly create ubuntu-application /tmp/foo

This will create a new python-gtk project called ‘foo’ in /tmp/foo.  You can then call:

./bin/quickly -p /tmp/foo run

This will run the applicaiton.  Note that you can use -p /path/to/project to make the command run against a specific project, without having to actually be in that directory.  If you are in that directory, you won’t need to use -p (but you will need to give the full path to the new quickly binary).

If you are interested in the templates, they are in ./data/templates/, each folder name corresponds to a template name.  The code will look for a class called Template in the base python namespace for the template (in ubuntu-application/__init__.py for example), which must be a subclass of the BaseTemplate class.  You don’t have to define the class there, but you do need to import it there.  Commands are added to the Template class definition, they can take arguments at the time you define them (see code for examples), and their .run() method will be called when invoked from the command line.  Unlike Templates, Commands can be defined anywhere, with any name, as long as they subclass BaseCommand and are attached to a template.

Read more
Michael Hall

A few weeks ago, Canonical founder Mark Shuttleworth announced a new project initiative dubbed “skunk works”, that would bring talented and trusted members of the Ubuntu community into what were previously Canonical-only development teams working on some of the most interesting and exciting new features in Ubuntu.

Since Mark’s announcement, I’ve been collecting the names and skill sets from people who were interested, as well as working with project managers within Canonical to identify which projects should be made part of the Skunk Works program.  If you want to be added to the list, please create a wiki page using the SkunkWorks/ParticipationTemplate template and send me the link in an email (mhall119@ubuntu.com).  If you’re not sure, continue reading to learn more about what this program is all about.

 What is Skunk Works?

Traditionally, skunk works programs have involved innovative or experimental projects lead by a small group of highly talented engineers.  The name originates from the Lockheed Martin division that produced such marvels as the U-2, SR-71 and F-117.  For us, it is going to focused on launching new projects or high-profile features for existing projects.  We will follow the same pattern of building small, informal, highly skilled teams that can work seamlessly together to produce the kinds of amazing results that provide those “tada” moments.

Why is it secret?

Canonical is, despite what some may say, an open source company.  Skunk Works projects will be no exception to this, the final results of the work will be released under an appropriate open license.  So why keep it secret?  One of the principle features of a traditional skunk works team is autonomy, they don’t need to seek approval for or justify their decisions, until they’ve had a chance to prove them.  Otherwise they wouldn’t be able to produce radically new designs or ideas, everything would either be watered down for consensus, or bogged down by argument.  By keeping initial development private, our skunk works teams will be able to experiment and innovate freely, without having their work questioned and criticized before it is ready.

Who can join?

Our Skunk Works is open to anybody who wants to apply, but not everybody who applies will get in on a project.  Because skunk works teams need to be very efficient and independent, all members need to be operating on the same page and at the same level in order to accomplish their goals.  Mark mentioned that we are looking for “trusted” members of our community.  There are two aspects to this trust.  First, we need to trust that you will respect the private nature of the work, which as I mentioned above is crucial to fostering the kind of independent thinking that skunk works are famous for.  Secondly, we need to trust in your ability to produce the desired results, and to work cooperatively with a small team towards a common goal.

What kind of work is involved?

We are still gathering candidate projects for the initial round of Skunk Works, but we already have a very wide variety.  Most of the work is going to involve some pretty intense development work, both on the front-end UI and back-end data analysis.  But there are also  projects that will require a significant amount of new design and artistic work.  It’s safe to say that the vast majority of the work will involve creation of some kind, since skunk works projects are by their nature more on the “proof” stage of development rather than “polish”.  Once you have had a chance to prove your work, it will leave the confines of Skunk Works and be made available for public consumption, contribution, and yes, criticism.

How to join

Still interested?  Great!  In order to match people up with projects they can contribute to, we’re asking everybody to fill out a short Wiki page detailing their skill sets and relevant experience.  You can use the SkunkWorks/ParticipationTemplate, just fill it in with your information.  Then send the link to the new page to my (mhall119@ubuntu.com) and I will add you to my growing list of candidates.  Then, when we have an internal project join the Skunk Works, I will give the project lead a list of people who’s skills and experience match the project’s need, and we will pick which ones to invite to join the team.  Not everybody will get assigned to a project, but you won’t be taken off the list.  If you revise your wiki page because you’ve acquired new skills or experience, just send me another email letting me know.

Read more
Michael Hall

When the Unity developers introduced Dash Previews in Unity 6, I knew it was something I wanted to add to Singlet.  I didn’t have time to get the feature added in time to get it into Quantal’s Universe archive, but thanks to Didier Roche and Iain Lane, I was able to get it into Quantal’s Backports archive before the actual release date, so it will be available to all Ubuntu users right away.

Previews for all!

One of the main goals of Singlet, second only to making it easy to write Unity lenses and scopes, was to automatically add new features to any lenses and scopes written with it.  Previews are my first opportunity to put this into practice.  Singlet 0.3 will add Preview information for any Scope or SingleScopeLens written for Singlet 0.2!  To do this, Singlet 0.3 will use the same image, title and description used in the search results to populate the preview.  This is a big improvement over having no preview at all, and there is absolutely nothing the developer needs to do. Even better, if you have a custom handle_uri method, it will also add an “Open” button to your preview which will call it.

Better, faster, simpler Previews

Getting previews for free is nice, but it does limit the preview to only the information you are giving to the result item.  But the Previews API allows you to do so much more, and Singlet lenses and scopes can take full advantage of them.

The simplest way to add more data to your preview is to add a method to your Scope or SingleScopeLens class called add_preview_data.  This method will be called whenever Unity needs to show a preview for one of your result items, and will be given the specific result item being previewed, as well as a reference to the Unity.Preview object itself.

def add_preview_data(self, result_item, preview):
    if result_item['category'] == self.lens.events:
        url_parts = result_item['uri'].split('/')
        event = self._ltp.getTeamEvent(url_parts[5])
        venue = self._ltp.getVenue(event['venue'])
        if 'latitude' in venue and 'longitude' in venue:
            preview.props.image_source_uri = 'http://maps.googleapis.com/maps/api/staticmap?center=%s,%s&zoom=11&size=600x600&markers=%s,%s&sensor=false' % (venue['latitude'], venue['longitude'], venue['latitude'], venue['longitude'])

The result_item is a Python dict containing the keys ‘uri’, ‘image’, ‘category’, ‘mime-type’, ‘title’, ‘description’, and ‘dnd-uri’, the same fields you added to the results model in your search field. The code above, added to the LoCo Teams scope, sets the Preview image to a Google Maps view of the venue’s location. You can also add additional Preview Actions from within this method.

If you want even more control, you can instead add a method called simply preview to your class, which takes the result_item and the full result_model from your scope, letting you create a Unity.Preview object yourself, and doing whatever you want with it.

def preview(self, result_item, result_model):
    preview = Unity.GenericPreview.new(result_item['title'], result_item['description'], None)
    preview.props.image_source_uri = result_item['image']

    some_action = Unity.PreviewAction.new("do_something", "Do Something", None)
    some_action.connect('activated', self.do_something)
    preview.add_action(some_action)

    return preview

Read more
Michael Hall

Well, we did it.  The six members of the Canonical Community Team stayed awake and (mostly) online for 24 straight hours, all for your entertainment and generous donations.  A lot of people gave a lot over the last week, both in terms of money and time, and every one of you deserves a big round of applause.

Team Insanity

First off, I wanted to thank (blame) our fearless leader, Jono Bacon, for bringing up this crazy idea in the first place.  He is the one who thought we should do something to give back to other organizations, outside of our FLOSS eco-system.  It’s good to remind us all that, as important as our work is, there are still things so much more important.  So thanks, Jono, for giving us a chance to focus some of our energy on the things that really matter.

I also need to thank the rest of my team, David Planella, Jorge Castro, Nick Skaggs and Daniel Holbach, for keeping me entertained and awake during that long, long 24 hours.  There aren’t many people I could put up with for that long, I’m glad I work in a team full of people like you.  And most importantly, thanks to all of our families for putting up with this stunt without killing us on-air.

Upstream Awesomeness

Before we started this 24-hour marathon, I sent a challenge to the Debian community.  I said that if I got 5 donations from their community, I would wear my Debian t-shirt during the entire broadcast.  Well, I should have asked for more, because it didn’t take long before I had more than that, so I was happily sporting the Debian logo for 24 hours (that poor shirt won’t ever be the same).

I wasn’t the only one who put a challenge to the Debian community.  Nick made a similar offer, in exchange for donations he would write missing man pages, and Daniel did the same by sending patches upstream.  As a result, the Debian community made an awesome showing in support of our charities.

All of our donors

The biggest thanks, of course, go out to all of those who donated to our charities.  Because of your generosity we raised well over £5000, with the contributions continuing to come in even after we had all finally gone to bed.  As of right now, our total stands at £ 5295.70 ($8486).  In particular, I would like to thank those who helped me raise £739.13 ($1184) for the Autism Research Trust:

And a very big thank you to my brother, Brian Hall, who’s donation put us over £5000 when we only had about an hour left in the marathon.  And, in a particularly touching gesture of brotherly-love, his donation came with this personal challenge to me:

So here it is.  The things I do for charity.

Read more
Michael Hall

The Canonical Community Team is running a week long charity fundraising drive, capped by a 24-hour live work hangout.  We all chose a different charity, and will be promoting it and encouraging donations during the week.  I chose to support the Autism Research Trust, and wanted to share a little bit about why.

Those in the open source community, or who are computer scientists, engineers or programmers, will be no strangers to Autism. Autism, and it’s associated spectrum, affect 1 out of every 88 children according to a recent study. In our geek community, the number is likely even higher than that.

Many of you may notice my blog’s banner, or read the post from when I put it up. When my first child was 2 years old, he was diagnosed with something called PDD-NOS (Pervasive Developmental Disorder, not otherwise specified), which is basically the catch-all “we don’t really know what’s wrong” category in the Autism spectrum. We were told this by a neurologist who then left the room without explaining what it was, what it would mean for our son, or what we were supposed to do about it. It was scary as hell.

What made things worse is that there is very little that anybody actually knows about Autism. Nobody knows what it actually is, or what causes it. There is no known cure or medicine to treat it. Our son needed our help, and we literally didn’t know how to give it. When he turned 3 years old he could speak only a handful of words. He was smart though, he seemed to understand everything, but we couldn’t communicate with him, or him with us. It was extremely frustrating for everyone.

The only thing that’s been proven to help children with Autism is early intervention. We were lucky, he was diagnosed at a much younger age than most kids. We found local speech and occupational therapy centers, and for over a year he went to these 3-4 times a week. Local organizations like Autism Speaks and the Central Florida Autism Institute helped us find what worked for him, because every child is different.

Early intervention has given our son his future back.  He still struggles with the effects of Autism, it doesn’t ever go away, but he’s learned how to work around it, and we’ve learned how to work around it.  That is why I have chosen Autism research as my charity for the Community Team 24-hour marathon, because there are still millions of children who need this intervention, and millions of parents struggling to understand how to help them.  And every dollar, pound or euro you give is likely to change somebody’s life.

Read more
Michael Hall

Back in San Francisco, during UDS-Q, we had a discussion about the need for better online documentation for the various APIs that application developers use to write apps for Ubuntu.  The Ubuntu App Showdown and subsequent AppDevUploadProcess spec work has consumed most of my time since then, but I was able to start putting together a spec for such a site.  The App Showdown feedback we got from our developers survey highlighted the need, as lack of good Gtk documentation for Python was one of the most common problems people experienced, giving it a little more urgency.

Fortunately, Alberto Ruiz was at UDS, and told me about a project he had started for Gnome called Gnome Developer Network (GDN for short).  Alberto had already done quite a bit of work on the database models and GObject Instropection parsing needed to populate it.  The plan is to use GDN as the database and import process, and build a user-friendly web interface on top of that, linking in external resources like tutorials and AskUbuntu questions, as well as user submitted comments and code snippets.

Now that the spec is (mostly) done, we need to get together some developers who can implement it.  There will be a lot of front-end work (mostly HTML, CSS and Javascript), but also enough backend work (Python and Django) to keep anybody occupied.  I’ve created a Launchpad project for the site, and a team you can join if you’re interested in helping out.

The GDN code and some very basic template are already available. You can get the code from bzr with bzr branch lp:ubuntu-api-website and following the instructions in the DEVELOPMENT file.  I’ll also be running a live App Developer Q&A Session at 1700 UTC today (September 19th), and would be happy to help anybody get the code up and running during that time.

Read more
Michael Hall

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.

Again, if you would like to get involved with this community, you should join #ubuntu-arb on Freenode IRC, or contact the mailing list (app-review-board at lists.ubuntu.com).

Read more
Michael Hall

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.

Read more
Michael Hall

You can watch the App Developer Q&A live stream starting at 1700 UTC (or watch the recording of it afterwards):

Questions should be asked in the #ubuntu-on-air IRC channel on freenode.

You can ask me anything about app development on Ubuntu, getting things into the Software Center, or the recent Ubuntu App Showdown competition.

Read more
Michael Hall

Due to the popularity of the Ubuntu App Showdown Workshops, I plan to start holding a weekly Q&A session for all Ubuntu app developers using the same format: A live Google+ Hangout with IRC chat.

The first of these will be Wednesday of this week, at 1700 UTC (6pm London, 1pm US Eastern, 10am US Pacific).  Because it will be an On-Air hangout, I won’t have a link until I start the session, but I will post it here on my blog before it starts.  For IRC, I plan on using the #ubuntu-on-air channel on Freenode, though again the exact details will be posted the day of the session.

So bring your questions about developing apps for Ubuntu, packaging an submitting them to the Software Center.  If I can’t answer your question myself, I’ll help you find someone who can.

Read more
Michael Hall

As part of the Ubuntu App Showdown I started on a small project to provide a nice GUI frontend to Quickly.  While I was able to get it working and submitted before the contest deadline, I unfortunately didn’t have the time to make it do everything I wanted.  Since the end of the contest, however, I was able to spend a little more time adding some nice features to it.

Project Management

The majority of the work has gone into Quickly-Gtk’s project management.  Some of this was implemented already, such as the ability to switch the “current” project. But internally it was all kind of a mess of code to track that.  So I replaced all of that with a ProjectManager class that will store both the list of projects Quickly-Gtk knows about, but also keeps track of which project is “current”.  This class also implements Observer design pattern to let other parts of the code know about changes to both the list of projects and the current project.  This made it easy to, for example, display a notification on the screen whenever the current project was changed, regardless of whether it was changed in the window, the indicator, or from a Zeitgeist event.

Zeitgeist event monitoring

The other big development was integrating Quickly-Gtk with Zeitgeist.  For those that aren’t familiar with it, Zeitgeist is an event log that tracks all kinds of user activities and system events.  Applications can read past events or monitor them as they happen.  I wanted Quickly-Gtk to be smart enough to switch to a project as soon as the user started working on it, without requiring the user to make the switch themselves.  To do that, I set a Zeitgeist monitor to listen for file system events in any of the saved project directories.  I also set it to watch for the user viewing the project’s Launchpad page.  If any of those events happen, Quickly-Gtk will automatically make that the current project.

The future of Quickly-Gtk

While I was able to get a lot done with Quickly-Gtk, the underlying Quickly API and command line really weren’t designed to support this kind of use.  However, as a result of what we learned during the App Showdown, Didier Roche has begun planning a reboot of Quickly, which will improve both it’s command-line functionality, and it’s ability to be used as a callable library for apps like Quickly-Gtk.  If you are interested in the direction of Quickly’s development, I urge you to join in those planning meetings.

 

Launchpad Project: https://launchpad.net/quickly-gtk

 

Read more
Michael Hall

Following yesterday’s announcement of the Ubuntu Webapps project, I really wanted to find a way to try it out on a website.  I chose my personal blog (this one) as my guinea pig.

Since this site is powered by WordPress, it seemed that the best way to add Ubuntu Webapps integration was to make a plugin.  Now I’m not a big fan of writing WordPress backend code, not only is it PHP but I’ve found the API documentation lacking and the actual API implementation a bit of a mess.

However, after only a few hours of work (90% of which was spent trying to get the WP API to work), I had a very basic plugin that would export all my published pages to the Unity HUD.  If you have already installed the Ubuntu Webapps preview, you should have been asked if you want to integrate this site already.  If you did, you will get this in your HUD:

The code is licensed under the AGPLv2, and can be branched from my bazaar branch.

To install it, just copy the ubuntuwebapps.php file into your wp-content/plugins/ directory, then activate the plugin from the WP admin.  And remember this is 0.1 code that is mere hours old.  You have been warned.

Read more
Michael Hall

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.

Read more
Michael Hall

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.

<a href="https://apps.ubuntu.com/cat/applications/{{pkgname}}/">
 <img src="http://developer.ubuntu.com/wp-content/uploads/2012/06/downloadonubuntubutton.png"  title="Download for Ubuntu" alt="Download for Ubuntu button" width="122" height="49" />
</a>

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.

Read more