[colord] colormgr documentation and examples

[Sanford Rockowitz]

Richard,

Thanks for the swift reply.    Comments interspersed.

On 06/18/2013 02:05 AM, Richard Hughes wrote:
> On 18 June 2013 09:53, Richard Hughes <hughsient at gmail.com> wrote:
>>> Suppose, for example, that I have a profile file myprofile.icc that I want
>>> to install into colord, make it the default for its monitor, and load.  What
>>> would the colormgr commands be?
> Well, I've just added this:
>
> commit b0faf88b59728d477b95807e53953dc4f1b9ec14
> Author: Richard Hughes <richard at hughsie.com>
> Date:   Tue Jun 18 10:01:19 2013 +0100
>
>      Add the sub-command import-profile to colormgr
>
> But for older versions you can just manually copy the .icc file to
> $HOME/.local/share/icc/ and then it will get automatically imported
> into the daemon by whatever session component you have running
> (gnome-settings-daemon or colord-kde).

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 can build it on 
Fedora 18, but not on Ubuntu 13.04 or openSuse 12.03.

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

>
> You can add the newly added profile to the device using: colormgr
> device-add-profile $device_path $profile_path
Ok, so I guess I'm showing my ignorance.  I'm a naif when it comes to 
Linux GUI programming.  The above may be obvious to an X or Gnome 
programmer, but I earn my living in a very different part of the 
software world (databases).   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.)  Can I 
construct it?  Do I interrogate it from somewhere? Is $profile_path a 
file system path, or something else?    In the absence of formal 
documentation, examples would make things clear.
>
> In newver colord versionsyou can also use the device-id and the
> profile-id rather than the long DBus paths.
>   If you tell me exactlywhat you need from colord, I'll try and improve colormgr to do what
> you need. Thanks,
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.

My use cases are two.

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), 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.)

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.   Second, it allows for easy testing without a lot of GUI 
clicking or copy and pasting.    The loading operation currently (1) 
loads the profile's VCGT into the display and (2) sets 
_ICC_PROFILE(_n).  It does not track changes to the installed profile, 
but for my purposes that doesn't matter. Currently I can specify the 
profile to load explicitly on the command line, as the one configured in 
UCMM, or have the program prompt me with a list of applicable profiles 
it has found.   It can install a profile as the configured UCMM 
profile.  I'd like to extend this program to query colord and install a 
profile into colord as the currently configured profile.


> Richard.


Best,
Sanford

>