Back to the main page

How it works:


General architecture plan


CUPS query architecture plan


Detailed CUPS integration plan

Mapping the device to the profile

The configuration of devices to profiles is stored in the colord mapping database, which is /var/lib/colord/mapping.db by default. The schema is really simple, and as follows:

CREATE TABLE mappings (id TEXT PRIMARY KEY,device TEXT,profile TEXT, timestamp INTEGER DEFAULT 0);

Multiple profiles can of course be assigned to the same device. Persistent devices and profiles can also be saved to the storage database, which is /var/lib/colord/storage.db by default. The schema is again really simple, and as follows:

CREATE TABLE devices (device_id TEXT PRIMARY KEY,device TEXT);
CREATE TABLE properties (device_id TEXT,property TEXT,value TEXT);

Setting the system default

One user may want to set the default for all users. We cannot reference files in /home/foo/.icc/ when logged in as user bar, as the user will not have access permissions, or in the worst case, /home/foo may be encrypted and inaccessible even as root. For this reason, colord copies the ICC profiles to a system-wide directory, /usr/lib/color that is per-machine and accessible to all users.

[PolicyKit authentication dialog]

It is encouraged that other CMS implementations also read ICC profiles from the per-machine /usr/lib/color directory.

General points:

I think most of the CMM functionality can be (and should be) integrated into the platform, e.g. GTK and Cairo.

It's my opinion that it's best to have two different applications for something that share a common specification, rather than trying to be a jack-of-all-trades. It's a cliché, but KDE users do want options, and GNOME users do want things to 'just work'. You can't design a library, or even an application for those different user types.

I do think the concept of a monolithic CMS is flawed. Color management has to be integral to the stack, so Xorg, GTK, Cairo, etc. all have to play their part. You can't really push a monolithic library when you need to interface with so many parts of the stack. I see all the heavy lifting being done by cairo, lcms and ArgyllCMS.

Back to the main page