1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>colord - What is colord?</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<link rel="stylesheet" href="style.css" type="text/css" media="screen"/>
<link rel="shortcut icon" href="favicon.ico"/>
</head>
<body>
<p>Back to the <a href="index.html">main page</a></p>
<h1>How it works:</h1>
<img src="img/architecture-plan.png" alt="[logo]"/>
<p>
<i>General architecture plan</i>
</p>
<br/>
<br/>
<br/>
<img src="img/cups-plan.png" alt="[logo]"/>
<p>
<i>CUPS query architecture plan</i>
</p>
<br/>
<br/>
<img src="img/cups-detailed-plan.png" alt="[logo]"/>
<p>
<i>Detailed CUPS integration plan</i>
</p>
<br/>
<br/>
<h2>Mapping the device to the profile</h2>
<p>
The configuration of devices to profiles is stored in the colord mapping
database, which is <code>/var/lib/colord/mapping.db</code> by default.
The schema is really simple, and as follows:
</p>
<pre>
CREATE TABLE mappings (id TEXT PRIMARY KEY,device TEXT,profile TEXT, timestamp INTEGER DEFAULT 0);
</pre>
<p>
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 <code>/var/lib/colord/storage.db</code> by default.
The schema is again really simple, and as follows:
</p>
<pre>
CREATE TABLE devices (device_id TEXT PRIMARY KEY,device TEXT);
CREATE TABLE properties (device_id TEXT,property TEXT,value TEXT);
</pre>
<h2>Setting the system default</h2>
<p>
One user may want to set the default for all users.
We cannot reference files in <code>/home/foo/.icc/</code> when logged in
as user bar, as the user will not have access permissions, or in the
worst case, <code>/home/foo</code> may be encrypted and inaccessible even as root.
For this reason, colord copies the ICC profiles to a system-wide directory,
<code>/usr/lib/color</code> that is per-machine and accessible to all users.
</p>
<img src="img/polkit.png" alt="[PolicyKit authentication dialog]"/>
<p>
It is <a href="http://lists.freedesktop.org/archives/openicc/2010q2/002167.html">encouraged</a> that other CMS implementations also read ICC profiles from the per-machine
<code>/usr/lib/color</code> directory.
</p>
<h1>General points:</h1>
<p>
I think most of the CMM functionality can be (and should be) integrated
into the platform, e.g. <a href="http://www.gtk.org/">GTK</a> and Cairo.
</p>
<p>
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.
</p>
<p>
I do think the concept of a <i>monolithic CMS</i> 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
<a href="http://www.argyllcms.com/">ArgyllCMS</a>.
</p>
<p>Back to the <a href="index.html">main page</a></p>
<p class="footer">
Copyright <a href="mailto:richard@hughsie.com">Richard Hughes 2011 - 2013</a><br/>
<a href="http://validator.w3.org/check/referer">Optimized</a>
for <a href="http://www.w3.org/">standards</a>.
</p>
</body>
</html>
|
