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.

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.

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.

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.

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.