Year: 2008

Jumping over the wall

Quite a few people have been saying we need to break major versions for GNOME, and create something new and exciting to increase our userbase for 3.0. Nonsense. There’s nothing saying you have to develop big new features in one release cycle. Something large like the new gdm2 rewrite can be done over a couple of release cycles, fixing the other broken bits along the way. The only slight problem is the deprecated (and broken) code in GTK, but that’s an argument for another day.

People don’t use GNOME because they can see cool OpenGL widgets whoosh around a screen. People use GNOME to actually do things. People use GNOME to write letters, edit photos, surf the net and read some news. For instance, I run without compiz turned on, as I find I work faster without any of the wizzy visual effects. The 0.1% of uber geeks (I’m not sure if I include myself in that number) that want to write cool new stuff need to remember that just because it’s possible, doesn’t always mean it’s a good idea.

I see this effect a lot with the new KDE, with it’s abstractions on abstractions and also visual widgets that can be spun, twisted and shaped. For example, I saw a preview of KDE 4.1 where there was a circular analogue clock widget. Hover over it, and you can rotate the analogue clock to any arbitrary angle. Just because it can be done, don’t mean it should be done.

So, all those of you who say we need radically new designs in GNOME 3.0, keep that moto in mind.

PackageKit bundles?

There’s one use case that I’m very interested in, and that is getting new users with the correct environment to build and start hacking on software or using other software tools. For instance, on www.packagekit.org in the FAQ section, we can have a link to install build files to start hacking on PackageKit.

Now, this .bundle file is handled by gpk-install-bundle that parses this file and causes the appropriate packages to be installed if they are not already installed. This rocks as we can get GTK+, Xorg hackers up to speed with the minimum of fuss and confusion. It also lets people put links on webpages to “install all the stuff you need” when writing a “how to use a scanner in GIMP” howto.

So, what does a .bundle file look like?

[PackageKit Bundle]

# Just a package on all versions of fedora that can provide the dependency.
# If there are multiple packages then the user will be asked to choose
InstallProvides(fedora)=audio/QCELP

# Just for Fedora 9, install two development files
InstallPackages(fedora-9)=glib2-devel;PolicyKit-gnome-devel

# On any distro, install the package with this file
InstallFiles=/usr/bin/fontinst

# For each architecture on Fedora 8, install one of the two different compat files
InstallFiles(fedora-8-i686)=/usr/lib/pango/1.6.0/modules/pango-arabic-fc.so
InstallFiles(fedora-8-x64)=/usr/lib64/pango/1.6.0/modules/pango-arabic-fc.so

You’ll notice the distro-id in between the ()’s – this lets a packager fine tune the package name, where for instance in Debian the package is called policykit and Fedora PolicyKit. You can specify a granularity of distribution, distribution-version or distribution-version-architecture – PackageKit will process all the entries that apply. It’s of course better to not specify a () if possible, as this lets the file work on as many distributions as possible out of the box.

There’s also no version checking – intentionally – the distro should be specified and have the correct data. If there’s an optional package not in earlier versions then you can do something like this:

[PackageKit Bundle]

# Fedora 9 does not have Unique
InstallPackages(fedora-9)=glib2-devel;PolicyKit-gnome-devel

# Rawhide is fedora 9.90
InstallPackages(fedora-9.90)=glib2-devel;PolicyKit-gnome-devel;unique-devel

There’s also no description of the bundle that needs translating and verifying – they are just lists of packages, files and provides that might be useful. All the translations come from the distributions metadata, and it’s up to the user to verify the package lists that are asked to be installed, so there are no signing or trust issues.

Note: this isn’t designed to replace one click install, it just does something that is similar in a different way.

Comments? Suggestions?

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