[Openicc] Fedora CM, was: Google Summer of Code . . .

[Richard Hughes]

On 20 May 2010 04:10, Chris Murphy <lists at colorremedies.com> wrote:
> Then it seems like the KDE folks and the GNOME folks should be talking...

All the CMMs (including gnome-color-manager) already abide by the same
basic specification [
http://www.oyranos.org/wiki/index.php?title=ICC_Profiles_in_X_Specification_0.4
] - we disagree on parts of it, but essentially we're already working
together.

Now, there are parts that still need standardising. For instance,
gnome-power-manager has a DBus interface org.gnome.ColorManager with
quite a few useful (IMO) methods and properties. For instance,
RenderingIntentSoftproof is a property that can be read in one line of
code in python, C, C++ or C#, on Linux, Windows and OSX as DBus has
such cross-platform and multi-language bindings. There's not many
desktop applications that don't already use DBus in one way or
another.

I do think it makes a lot of sense to standardize the DBus interface
to something like org.freedesktop.ColorManagement and decide a
standard set of properties and methods that all CMMs will support,
whether thin like GPM or full featured like Oyranos. Library deps are
painful for users and distros as they are a hard requirement, and you
need to have all the library deps installed. Libraries (especially new
libraries) have API and ABI stability issues that projects and distros
need to care about.

Using DBus we can add support to applications like GIMP which connect
to the interface at runtime, and if the interface is not supported or
not installed, the color management code can just choose good
defaults. Also, with DBus service activation you can have the color
management session component automatically start the first time it's
required, rather than at system or session start. "gcm-session" even
quits arfter a period of idle if nothing is requesting data from it.

So, I hope I've explained that it makes perfect sense to share an
specification and interface, but not necessarily to share code.

The org.gnome.ColorManagement interface is available for review here:
http://git.gnome.org/browse/gnome-color-manager/tree/src/org.gnome.ColorManager.xml
-- it's not set in stone, and I'm perfectly open to adding or removing
methods/signals/properties if anyone has any better ideas.

Richard