User: Password:
|
|
Subscribe / Log in / New account

Developing applications "Quickly"

Please consider subscribing to LWN

Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.

September 9, 2009

This article was contributed by Nathan Willis

Quickly is a new utility to simplify Linux application development by bootstrapping repetitive project setup, user interface, packaging, and release chores. It targets both new application developers and those who simply want to speed up recurring tasks. Quickly is a product of the Ubuntu project, but is flexible enough to be used in other distributions and for other types of tasks — the real power of Quickly lies in the templates that automate different aspects of project configuration and maintenance.

An application built using Quickly has no dependency on Quickly itself, said developer Didier Roche, "there is no Quickly runtime or base class library." The goal, he said, is to speed up the process for regular developers and help new developers get past the barrier of deciding which tools and approaches to use.

It can be difficult to get into GNU/Linux programming as there are a whole bunch of available technologies. Let's think about using GTK/QT, language, which library do I need? Add to this some tools decisions like the IDE, the VCS, hosting the project, etc. Too many choices kills the choice itself. [...] For instance, learning Debian packaging just to create a package to share with people can be tedious. Quickly (with ubuntu-project template) does it for you. Consequently, opportunistic developers can focus only on precise things and do it quickly, easily and right!

Canonical's Rick Spencer came up with the initial idea for Quickly after a series of false starts with missing documentation — including the deprecated tool libglade that did not point him towards its replacement gtkbuilder — and packaging guides that were so generalized that they provided little concrete help:

It took me a long time and a lot of digging to put together a set of tools for myself that worked for me. [...] This was partly due to the fact that there was no definitive source of information, or any credible expert. So threads in Ubuntu Forums where newcomers asked "how do I write an app for Ubuntu" get a pile of different options, and no way to know what is best. I very much wanted to solve this problem, and create a pipeline that made it easy to go from conceiving an app to have people using it.

The latest version of Quickly is 0.2.2 and is packaged only for Ubuntu 9.10, in which it is slated to be part of the official release. The authors note, however, that it could easily be packaged for Ubuntu 9.04 or for other distributions. Quickly is a command-line only tool that developers can use to execute discrete steps of the form:

    quickly command [options]
It has commands that create a new project, start an editing session, package it, make a public release, and so on.

Most of these commands are defined in a template tailored to a specific scenario; running "quickly commands" will list the built-in commands and those associated with each installed template. So far, the only released template is ubuntu-project, which automates working with Ubuntu-compatible code (using Bazaar for version control, Debian packaging, and Launchpad.net Personal Package Archives (PPA) for releases).

In addition, the ubuntu-project template makes what Roche called "opinionated choices" for the tools and technologies used by the new application: using Python for the language, PyGTK for the user interface, Glade for the UI design, Gedit for the editor, and Desktop CouchDB for (optional) data storage. Using the template's project creation routines to start a new project, Quickly creates a subdirectory for the project and set of skeleton files, including necessary Python and Glade files, plus auxiliary icon and licensing files. Quickly also creates Python classes to encapsulate basic windows and dialogs, and a separate Glade file for each class and window. These decisions are designed to make it simple to edit the application with Quickly, even though they might not be the design choices other programmers would make.

Example Quickly usage

The Ubuntu wiki features a basic tutorial on writing code with Quickly, and Roche has started a series of blog entries to document its usage and options. On August 31, Roche and Spencer hosted an IRC talk during Ubuntu Developer Week that delved into further detail.

The process starts by running:

    quickly create ubuntu-project myapp
Quickly then creates a ./myapp directory, and fills it with:
    bin/
    Copyright
    data/
    myapp/
    myapp.desktop.in
    setup.py

The Python files are placed in myapp/myapp, and the Glade files in myapp/data. After that, the developer must cd into the myapp directory. From there, quickly run will launch the new application, quickly edit will open the key Python files in Gedit, and quickly glade will open the UI files with Glade. Because the focus of the ubuntu-project template is on graphical applications, a quickly dialog command is available to create a new dialog window and associated class in Glade and Python.

Running quickly save will save the code to Bazaar, quickly license some_license will add license headers, and quickly package will calculate dependencies and generate a .deb package. Public releases are made with quickly share and quickly release. Both commands require the user to have a working account on Launchpad.net, complete with a PPA. The difference between the two commands is that share does not assign a version number or allow for a change log; release automatically increments version numbers, although they can be overridden.

Quickly design: core and templates

At its core, Roche explained, the quickly tool itself is essentially a parser and command processor. It checks context (for example, whether the working directory is a Quickly project directory), provides command completion, help, and a few low-level hooks, but most of the logic resides in the templates. Templates are written in Python, and although there is no documentation for template writing available yet, interested parties can browse the code used in the ubuntu-project template, which is installed by the package at /usr/share/quickly/templates/ubuntu-project.

Roche said that the Quickly team decided to separate as much of the "intelligence" as possible from the quickly core in order to make it more useful. "If anyone wants to make templates for other platforms, we would gladly merge those into our project," he said, perhaps separating Quickly templates into its own subproject from Quickly Core. "We would love to see, for instance, a fedora-project template, gnome-project one, plasmoid-project, [or a] zeitgeist-plugin."

Quickly even makes it simple to duplicate an existing template in order to customize it; the built-in command:

    quickly quickly template

creates a duplicate. The user can then modify the new template for use with other editors, other version control systems, or make more substantial changes without starting from scratch. "If someone likes the ubuntu-project template but doesn't agree on, let's say, couchdb but prefers gconf, he is able to create his own template based on ubuntu-project with $ quickly quickly ubuntu-project ubuntu-project-with-gconf and then hack in ~/quickly-templates/ubuntu-project-with-gconf/ to tweak what interests him," said Roche.

Quickly's core/template separation means that it is not limited to standalone GUI Linux application development. As the project's Launchpad page states, developers could easily create a template to kick-start creation of a conforming plugin for a specific application, for working with rendering systems like LaTeX, or for non-coding projects like documentation tasks.

As additional templates are written by Quickly users, Roche said, the team will coordinate with template authors to see what shared functionality deserves to be rolled up into built-in commands. Regardless of the task, some operations like file upload are generic enough for reuse. Quickly's Launchpad access is one such example; it began as part of the ubuntu-project template, but is now accessible to other template authors through Quickly's core — abstracting sign-in, reconnections, and other tasks.

Quickly in practice

Quickly is on track to ship with Ubuntu "Karmic Koala" 9.10, though Spencer said he does not know of any official Karmic applications written with Quickly. A few developers have started using the package to build small applications; Jono Bacon blogged about his use of Quickly while working on a tool for managing Amazon Kindle content, and Bryce Harrington has started developing a GUI front-end to Quickly — using Quickly itself.

Roche said that the near-term plans for the ubuntu-project template include adding some important features like GPG and SSH key creation for use with package signing and Launchpad upload. The team is also interested in adding new templates, including an ubuntu-game template that incorporates PyGame, and a gedit-plugin template that would demonstrate Quickly's applicability for application-specific plugin project development.

In the long term, Roche said that Quickly should be able to scale up to large projects in addition to the modest single-developer examples shown so far. It already supports concurrent Bazaar access, but the ubuntu-project template does not support Launchpad's "teams" collaboration feature because it is not accessible via the Launchpadlib library. Nevertheless, he said, the Quickly team is actively working on the issue and hopes to be able to tackle it in the future.

An early review of Quickly at Ars Technica compared it to Rails, which also uses a command-line to automate set-up for non-command-line projects. Readers responded that it also bears similarity to Django and Maven project creation, but it may be a first for desktop applications. Although, as Roche said, nothing about Quickly's core or its templating system limit it to desktop application development. Any repetitive task could be sped up by being adapted into a Quickly template; which templates the world sees depends entirely on who picks up Quickly and experiments with it.


(Log in to post comments)

Developing applications "Quickly"

Posted Sep 9, 2009 19:11 UTC (Wed) by flewellyn (subscriber, #5047) [Link]

Interesting idea. Though, I would of course hope that they add more templates for other kinds of projects!

I wonder how useful such a thing would be for non-Linux systems, as well?

Developing applications "Quickly"

Posted Sep 9, 2009 19:35 UTC (Wed) by felixrabe (guest, #50514) [Link]

It is for sure not the first command line tool to set up and manage a project structure, but it might be the first one that will catch on, based on broader awareness and the neat concept.

I'm seeing a serious flaw

Posted Sep 10, 2009 4:06 UTC (Thu) by jmorris42 (guest, #2203) [Link]

In the quest to make it simple it just might have been made too simple. Defining an entire project's workflow in a simgle template is asking for trouble.

Already discussing having ubuntu-project and ubuntu-project-with-gconf but it will quickly devolve into:

ubuntu-project
ubuntu-project-with-gconf
ubuntu-project-with-emacs
ubuntu-project-with-emacs-and-gconf
ubuntu-project-with-gvim
ubuntu-project-with-gvim-and-gconf

The KDE users will have nothing to do with the defaults being GTK so

kubuntu-project
kubuntu-project-with-gconf
kubuntu-project-with-emacs
kubuntu-project-with-emacs-and-gconf
kubuntu-project-with-vim
kubuntu-project-with-vim-and-gconf

Then somebody who has an existing project adopts this to manage the ubuntu version while maintaining contact with an existing project repo.... A few more people do likewise an repeat all of the above with:

-and-git
-and-cvs
-and-subversion

And so on. Then a few Fedora folk pick up on it and repeat all of the above replacing ubuntu with fedora.... then debian, suse, etc. Bug fixes and improvements to base templates will start failing to make it into the more obscure variants and everything blows up.

The word for this is combinational explosion and the solution is to realize what is going to happen and break the template into pieces now and have the project sane default along with user local preferences for things like editors, default UI toolkit for new projects, etc.

I'm seeing a serious flaw

Posted Sep 10, 2009 5:22 UTC (Thu) by drag (guest, #31333) [Link]

It does not necessarily have to be like that. The nice thing about having a templating system done right means that you can have a mixture of templates.

As far as the editor stuff goes... the easy thing to do there is honor the $EDITOR variable, or the XDG .desktop specifications for mime types, like every other decent program does.

As long as the developers concentrate on maintaining core templates and making sure those always work and not to do anything really wild and break backwards compatibility to much, AND keep the templating system as simple as possible and well documented then the rest of everybody can fend for themselves for their little nit picks like favorite editor or preferred DCS. You'll end up with something that is easily extensible like Firefox, Emacs, or Vim.

It does not have to be everything to everybody. Remember the point is to get something up and running quickly. That is 90% of the work.. after that then it's just a matter of customizing the last 10%. and only really experienced people are going to give a damn. :)

I'm seeing a serious flaw

Posted Sep 10, 2009 6:41 UTC (Thu) by didrocks (guest, #57449) [Link]

>As far as the editor stuff goes... the easy thing to do there is honor the $EDITOR variable, or the XDG .desktop specifications for mime types, like every other decent program does.

-> That's already the case in fact (it's using sensible-editor too). We had a comment from an user telling us "sweet, I typed quickly edit and it opened emacs" :).
The failsafe if nothing is specified is gedit

>It does not have to be everything to everybody. Remember the point is to get something up and running quickly. That is 90% of the work.. after that then it's just a matter of customizing the last 10%. and only really experienced people are going to give a damn. :)

->Exactly, that's why we made default choices and as usual, choices are controversial. But people can help and ship their own default, starting from an existing base.
As of today, Quickly core and Quickly ubuntu-project template are two separate packages. We could imagine one package by template and playing on the plugin side as you mentioned.

I'm seeing a serious flaw

Posted Sep 10, 2009 21:53 UTC (Thu) by jspaleta (subscriber, #50639) [Link]

Before I move on to criticism let me say that I think quickly looks like a reasonable good approach for rapid development for interpreted languages. It will be interesting to see how it develops and there is pressure to build up a more feature rich IDE interface on top of its core functionality.

But on to the criticism....I think name spacing at the distribution level is probably short sighted as a policy model to follow. Now GNOME and KDE namespaces for templates make sense...as these upstream projects do define a framework on which to hang applications. What does it mean to be a fedora project or an ubuntu project or a debian project really?

Distributions do not define a technology framework. I understand that Canonical is pushing launchpad backed bzr and desktopcouch pretty hard because they think they are best of breed technologies...and I respect that. But does it make sense to brand that combination of technologies as Ubuntu specific? And then to encourage other distributors to brand a different stack of technologies as yet another template and have competing technology frameworks? I don't think it does. For new projects, a distribution specific namespace is an arbitrary definition at best. At worst its going to end up being a barrier to adoption across distribution boundaries. What independent project writer really wants to see their end-user application bound up in distribution specific naunces or dependant on distribution patches to upstream codebases? Amd what I would really hope that Canonical realizes is that pushing technologies like desktopcouch needs to be done in a brand agnostic fashion. The last thing Canonical needs is for a competitor to think of desktopcouch as Ubuntu-centric...and then introduce a competing framework for application writers to choose.

-jef

I'm seeing a serious flaw

Posted Sep 11, 2009 6:01 UTC (Fri) by drag (guest, #31333) [Link]

The only really Ubuntu-specific things I noticed was the integration into
Launchpad and PPA's... both of which do not really have a equivalent in other
distributions. Sure you have bug track and things like that, but PPA allows
people to setup their own personal repositories easily and have other people
use them. I can't really see that as anything but a nice feature.

Otherwise everything else seems to be distro agnostic, except you'd have to
replace debs with rpms, but that should not be a big deal.

Corporate

Posted Sep 11, 2009 0:27 UTC (Fri) by ncm (subscriber, #165) [Link]

When I think of who will use this, I keep coming back to corporate IT. The department lead architect provides the corporate template, and his or her charges use it when they make a project. This means that the template explosion problem doesn't happen, because the lead chooses one, or alters one to fit local needs, and the users don't even see any others. They'll just type "quickly create corp-dept-template" and the project is set up according to CorpDeptInc's local conventions.

Corporate

Posted Sep 11, 2009 6:08 UTC (Fri) by drag (guest, #31333) [Link]

I could see that, if it matures quite a bit.

The thing that struck me in the past about Gnome is how people complained
that there was no alternative to things like Visual Studio. (we now have
Eclipse, obviously)

But if you want a IDE I always saw as the entire Gnome/Linux desktop as a
IDE. You have nice integration with the command line, with a wealth of
powerful tools and easy to use scripting languages. There are GUI builders
and source code control and top-notch editors and everything you'd ever need.
But it was never presented as a entire product.

Maybe something like this is what was needed to make it all cohesive.

Corporate

Posted Sep 14, 2009 5:38 UTC (Mon) by DDevine (guest, #60717) [Link]

You are definitely right about the whole desktop being an IDE.
However I would like to add that there is actual IDEs (in the Windows sense) available such as the excellent KDevelop, Anjuta, Eclipse and a handful of others. Its annoying that so many people do not bother to actually look at alternatives. Do they really expect Microsoft Word to be installed in the Linux desktop by default? It's like expecting your kitchen microwave to browse the internet.

Going out further, the CLI is also a great IDE and if you set it up well and learn tricks it can absolutely blitz any graphical setup in terms of productivity, but this is a setup that should be approached willingly and not kicking and screaming.


Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds