GNOME Software overall plan

I’ve been asked by a few people now to outline my plans for improving software installation in GNOME. I’ve started to prototype a new app called ‘GNOME Software’. It exists in gnome git and currently uses PackageKit to manage packages. It’s alpha quality, but basically matches the mockups done by the awesome guys in #gnome-design. It’s designed to be an application management application. GNOME PackageKit lives on for people that know what a package is and want a pointy-clicky GUI, so I’m not interested in showing low level details for power users.

Of course, packages are so 2012. It’s 2013, and people want to play with redistributable things like listaller and glick2 static blobs. People want to play with updating an OS image like ostree and that’s all awesome. Packages are pretty useful in some situations, but we don’t want to limit ourselves to being just another package installer. From a end-user point of view, packages are just an implementation detail.

So, I’ve been designing gnome-software to be pluggable. This means you can write an AppStream plugin to provide things like icons and screenshots for not-yet-installed software. You can write a plugin to ask ostree to update itself, and also a plugin to ask PackageKit to update a specific package. The idea is that we just run all the plugins in parallel when the user opens the dialog, and hide all the gutty details about the application update/install/removal itself. If installing packages falls out of favour we drop the PackageKit plugin, and instead write a plugin for ${distribution_system_of_the_year}.

I’ve done a quick technical outline below:

System Design

There are a few sticky issues I’ve not yet solved, like what happens if inksape is installed locally using Glick2 and also installed as a package. I suppose you’d get two entries in the results, and two things to update. Not sure. Ideas welcome.

There’s quite a bit of working code in git, but I didn’t want to write too much until I’d had some feedback from the community. Comments, suggestions and flames very welcome. Thanks.


ColorMunki Smile

I’ve just purchased a ColorMunki Smile so I can write a native colord driver for the i1 display class of hardware. I’ll base this on the Argyll CMS driver which is also GPLv2+ and this will mean we can get faster and more reliable readings by not spawning /usr/bin/spotread and trying to screen scrape the output. It also means we can support the newer LED backlights in the client UIs, which the smile supports.