Month: January 2011

For three days last week I attended a conference on application installing in Germany, hosted by Vincent Untz and the other guys from Novell. There were experts sent from Fedora, Ubuntu, Debian, Suse, and Mageia. From Fedora both I and Florian Festi attended.

The idea of the conference was to talk about defining some APIs we can share, to discuss interchange formats, and talking to the UI designers to make installing and removing software on Linux suck less.

Overview:

• Lots of progress, people were willing to help solve a common problem in a unified way.
• The right people were at the meeting and we came up with a really good technical plan with action items.
• Ubuntu Software Center really kicks ass, although we really need them to drop the CLA. USC will be ported to use PackageKit in the next couple of weeks.
• Packages and packaging are not that interesting to the end user.
• We will integrate with online social services to provide features like ratings and comments using OCS. OCS needs a couple of things added to the API, which will happen in the next few weeks
• We will produce appdata.xml metadata per-repository, rather than one super-package.
• I need to talk to the fedora-infrastructure guys – it might make sense to not refresh the metadata every day for the rawhide compose.
• We will use a xapian index to query the desktop metadata, rebuilding as repos are added / removed. This supports fast stemming and other advanced features.
• Will add several new optional fields to desktop file specification upstream for the proper solution, more details to come soon. This will allows us to search for photoshop and return gimp in the search results.
• Non .desktop files as applications do make sense, e.g. firefox plugins as .xpi or Chromium style web links. This makes sense to push to OCS, rather than in the distro metadata.

What this means for Fedora:

• We add a tiny script (to be written this week) to generate the xml file and the icon tarball for the distro at compose time (similar to my earlier app-install work)
• We ship the extra optional metadata in the fedora mirrors (+~9Mb)
• We download this in PackageKit if a repo is enabled or refreshed

We’ve put a few detailed documents with architecture plan on the wiki and Vincent has also uploaded all the notes from the meeting to the same location.

For more information still, there was a presentation we gave at the end of the conference. It’s nearly an hour and gets pretty technical, so get coffee before if you click the video.

Thanks again to Red Hat for sponsoring my travel and hotel expenses.

In the last couple of months, I’ve been talking quite a bit with Tim Waugh about color management of printers, and how to achieve working CM with CUPS. At the moment, gnome-color-manager locates CUPS devices and allows the user to calibrate them and assign profiles, but CUPS doesn’t actually use the assigned profiles for printing. Oops.

Needless to say, the combination of CUPS, ghostscript and other complicated little-known parts of the printing stack make this look almost impossible. OSX uses CUPS and CM works really well on printers using Apple products — and so it must be possible. We need to make it work on Linux too before Linux can become a serious option for artists and media professionals.

OSX uses a system-wide framework called ColorSync that does all the device<->profile mapping, and allows the user to change the ICC color profile for each device, and also allows the user to choose internal profiles listed in the printer definition file. ColorSync works really well, and is an integral piece of the OSX operating system.

GCM is a session process that provides session programs access to the per-user color management settings. Because GCM is running in the session it can integrate deeply into the GNOME desktop environment and is not particularly security sensitive. But, because the framework is per-session, system frameworks like CUPS cannot access the data, and we also have to rely on cludges like naming the display ICC file to be the same as the device ID and putting it in a well know location to be able to have a color corrected GDM screen. Urgh.
So, we need a trivial device<->profile daemon that works like a subset of ColorSync that the session GCM instances can use for defaults and also set profiles system wide for projects like CUPS. Over the Christmas holidays I wrote a small dameon called colord that provides a way for applications (or other daemons) to create, destroy and assign devices and profiles.

colord doesn’t do any file parsing or anything terribly unsafe, it’s just a simple system activated system DBus PolicyKit enabled daemon that has a simple database of devices that can reference specific profiles. Profiles are optionally assigned ICC profiles, and also have qualifiers that can be used to match them. For instance, a qualifier could be Epson.RGB.300dpi, which would match from the qualifier search of “Epson*”.

One thing to note: colord isn’t anything related to systemd. The name was chosen because colordaemon was too long to type and ColorManager and ColorKit names were already taken. It’s also intentionally techy, as users are not going to have to interact with colord whatsoever.

At the moment there is a test GTK application for developers and color geeks shipped in the colord package, but long term GCM is just going to use colord and all the configuration and settings will be done in the session by GCM itself.

Tim is working on the CUPS parts as I speak, and hopefully we can have something working in a few days. Exciting times.