[colord] colormgr documentation and examples

[Richard Hughes]

On 18 June 2013 19:30, Sanford Rockowitz <rockowitz at minsoft.com> wrote:
> But there may not be a session component.   My preferred desktop is Mate.
> There's the Mate fork for the 2.x version of gnome-color-manager, but it's a
> work in progress.

I don't think gnome-color-manager 2.x provided a session client to colord.

> I've assumed that I can still use colormgr in this situation to at least
> interrogate colord, but perhaps that's incorrect.

Well, colord is a daemon, and so to access and monitor files in the
session you need a small session component to register file
descriptors with the process.

> So an explanation like the above leads to a bunch of other questions for me.
> What does $device_path look like?  (I surmise from the following paragraph
> that it's a DBus path.)

$ colormgr get-devices
Object Path:   /org/freedesktop/ColorManager/devices/xrandr_Hewlett_Packard_HP_LP2480zx_3CM82200KV_hughsie_1000
...

> Mainly what I'm looking for right now is more documentation on the --help
> options and man pages.  Much of the help looks like it was generated
> automatically and not completed   So, for example, the --help option for
> gcm-import shows lots of options for GTK debugging, but no reference to the
> fact that it takes a file name as an argument.  I'm still trying to
> understand how everything hangs together.

At least with modern versions gcm-import does an async version of
colormgr import-profile, i.e. copies it to the session location and
waits for the daemon to register the filename and parse the file, and
when this happens (few tens of ms) it returns details to the user,
e.g. translated titles and stuff like that.

> The first is a program that explores the color management environment.   It
> finds all ICC profiles on the system (there are duplicates all over the
> place)

colord ignores duplicates if the md5 sum matches.

>, determines which (if any) are loaded, examines _ICC_PROFILE(_n) and
> probes the various color management configuration systems it can find
> (colord, ucmm) using multiple tools (dispcalGUI, colormgr, etc.)

Well, there are a lots of layers there. _ICC_PROFILE is set in the
session as it's an x atom. ucmm can either be per-session or
per-system, and ucmm isn't compatible with colord. Note, the next
version of argyllcms will probably also be able to query colord and
fall back to ucmm, so at least on distros where colord is used for
everything ucmm isn't a variable anymore. dispcalGUI also loads the
profiles from colord and sets the new profile using colord for quite a
few releases, so that's less of a worry.

> The second is a command-line (Python) program for loading and installing
> profiles.   Why yet another such program?  First, it works in all my
> environments, irrespective of which distro I'm booted into and which UI I'm
> running.

Any reason why a script? I think colormgr would be suitable here, and
even if you want python there are GIR bindings for colord so it's easy
to access colord details:
https://github.com/hughsie/colord/blob/master/examples/cd-find-device-by-property.py

> I'd like to extend this program to query
> colord and install a profile into colord as the currently configured
> profile.

Whilst that's certainly possible, I'm not overly keen on another
abstraction layer on top of colord. I think learning how to use the
python API and writing a colord session component[1] for mate is
probably a good idea.

Richard

[1] There used to be a standalone binary in old versions of g-c-m, so
it could be rescued from there. I don't want to maintain such a thing
as I'm already maintaining the gnome 3 stuff, but I don't mind if
someone else does.