gpk-application multiple package selection

In 0.1.x PackageKit had a restriction it could operate on only one package at a time. This sucked for a multitude of reasons, the main one being that to install a few packages you had to wait for the preceding one to finish.

In an ideal world, we could still query a software list while we are updating, but a lot of the backends do not allow that, giving unpredictable results or ‘just‘ corrupting caches.

One of the main feature requests for 0.2.x was to handle multiple packages in one transaction. The API was slightly changed in PackageKit to support this in 0.2.1, and now the client tools like pkcon and gpk-install-package-name all accept more than one package at a time. Yay for the command line.

This left gpk-application, aka “Add/Remove Software” – which was much trickier to do in a sane way. Now, I’m not saying the screenshot below is sane, but it certainly works, and we can improve it in the few weeks before 0.2.2 is released.

Comments welcome.

KDE love!

Recently, Daniel and Adrien have been rocking with KPackageKit and QPackageKit.
The library is coming on nicely, and the tools are starting to look very KDE like. They could do with a hand, so if you want to get involved, jump on the mailing list and introduce yourself to those two dudes.

See here for a sneak preview. There’s also a screenshot of the OpenSuse updater, which is also working with a PackageKit backend now.

Next step, world domination. Seriously, rock on.

How about something like this?

Okay, I’ve added the needed stuff in desktop-file-utils for the yum backend to pick up the virtual mime-type provides in rpm with the help of hadess. Now all we need is a new rpm version with support for this, and then for rpm based distros (e.g. Fedora) it should just work. For Ubuntu the data is already present in the ton of desktop files that are shipped in gnome-app-install – and I’m sure it will be easy to get at this data in the apt2 backend. Other distros will have to work out how to do this, although I’m sure one of the existing methods will be easy to adapt.

So, enough of the geeky. What do you all think of this:

Code about to hit master…

Comments?

No application for this file type…

Anyone know how I could hook PackageKit into this UI so that it handles some recognised formats?

For instance, in this case, we could prompt to install Inkscape to view the file. But I don’t want to do lots of waiting if PackageKit can’t find anything that matches the mimetype. Ideas welcome, as I’m really not sure how this code works at all. I’m guessing nautilus, but it could be gio for all I know….

Transifex and PackageKit

I asked for translations a few days ago for the dameon, and got a fantastic response. Thanks go out to Vojtěch Smejkal, Piotr Drąg, Daniele Costarella, Marc-André Lureau, Arnout Lok, Alon Zakai, jcome, Lubomir Kundrak, Stephan Sachse and Javier Castro for all the new .po files.

I’ve also asked Dimitris Glezos to setup Transifex for translators to alternatively use. This is an “upstream” solution, as Transifex syncs with our private development server rather than putting a layer on top such as Launchpad translations. So I can update translations directly, or get people to use Transifex – it’s a win-win situation as far as the uni-lingual maintainer (me) is concerned.

I’ve been very impressed with Transifex so far, and it seems there are over 300 people willing to use it to translate various modules. You don’t need to use Fedora to use it, and seems to make doing translations pretty trivial.