[Openicc] [argyllcms] Re: CC Profiles In X Specification and dispwin

[Frédéric Crozat]

On Jan 13, 2008 10:34 PM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> Am 13.01.08, 21:46 +0100 schrieb Frédéric Crozat:
> > On Jan 13, 2008 9:20 PM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> > > Am 12.01.08, 14:14 +0100 schrieb Frédéric Crozat:
> > > > On Jan 12, 2008 12:35 PM, Lars Tore Gustavsen <lars.tore at mulebakken.net> wrote:
> > > > > On Jan 12, 2008 11:09 AM, Frédéric Crozat <> wrote:
> > > > > > I have plans to integrate the xicc and LUT calibration data loading
> > > > > > into GNOME directly (into gnome-settings-daemon).
> > > > > >
> > > > >
> > > > > That sound nice.
> > > > > I wonder if have you looked at oyranos?
> > > >
> > > > No.  applying LUT and a X atom is not something worth adding a new
> > > > dependency on gnome-control-center. For now, I plan to do the applying
> > > > part. UI will come later.
> > >
> > > At a first glace this seems right. Just calibration and device profile
> > > selection highly depends each on the other. One monitor profile may be
> > > completely useless with not belonging calibration settings. Therefore some
> > > profilers pack the VCGT (VideoCardGammaTable) tag into the profile itself.
> > > But thats not enough.
> >
> > That is a start, which is still missing right now.
>
> What does you refer to with the word 'start'? The stuff added to Gnome?
> Work in this direction is done long time already in Oyranos. As a Co
> author of the ICC in X spec and Oyranos, this makes no wonder.

I may have been done in Oyranos but it has still not landed in any
desktop environment or merged in any distribution.

> What does you think about switching this discussion to the OpenICC email
> list? I think there are more people concered in operating systems and
> colour management.

I'm apologising for readers of this list for hijacking this thread, it
is not my intention of discussing
what should be done on Linux desktop regarding CMS. I'm cc this reply
to openicc mailing list and I think we should remove argyllcms mailing
list from future replys (cross list discussions is usually a bad idea
;).

> > > In the long run such stuff would be less work do be programmed once and
> > > consistence across desktops to make colour management for Linux (or
> > > more specifically for X11), and not just Gnome. The spot should be on the
> > > user of a computer, even if it seems harder to go beyond a operating
> > > system. As a analogy, after switching the desktop I would expect to use
> > > the same Xorg or printer configurations.
> >
> > Except that people are not switching desktop as they are switching applications.
>
> What has switching desktops to do with switching of applications?
> A user expects consistence and ease of use. This includes settings across
> desktops. The need for a user to set in KDE other than Gnome is
> complicated and a waste of time and resources. Please dont take me wrong;
> Gnome and KDE should expose a common structured CM tab in eaches
> configuration panel. To have such a tab a common logic or common device
> settings database is needed.

Since xicc and lut loading are not session persistent and desktop
dependent (they can be compared to Xsettings), once a desktop user has
configured his desktop, it won't matter if he switchs applications
(either KDE based, GNOME based or non desktop dependant ), they will
work as expected.

> What do you plan to other desktops in Mandriva than Gnome?

Nothing, I'm not doing this work as part of my Mandriva job but as
purely personnal project. I'm interested into improving my user
experience and by extension, GNOME user experience. I might try to
discuss with our Mandriva KDE hackers but I can understand they might
not have interest in this.

> > Moreover, taking Xorg or printer configuration as a example is not
> > really pertinent. Almost all desktop-neutral and non-distribution
> > configuration software for these points have failed (if they ever
> > existed) and are handled mostly by distributions (I have
> > a good experience of this at Mandriva). I don't want the same thing
> > for color management support.
>
> Well, I can not speak about print or X configuration. But for Oyranos, is
> works on all tested desktops for _ICC_PROFILE and vcgt setup. Whats the
> problem with such functionality?

I've just did a extremely fast review on Oyranos and so far, I see the
following problems :
-Not integrated in any desktop environment yet (not your fault ;)
-pull UI relying on uncommon toolkit (FLTK) => you should split the UI
dependant part to a separate package
-not autotools based
-no versioning control system for source management (maybe you should
move your project to freedesktop.org ?)
-license problem (should be LGPL or MIT for maximum usage, but it
appears you are changing this for next release)
-use elektra configuration "abstraction" => this kind of stuff is nice
on the paper but I think it is plain wrong (you can't expect desktop
environment to accept this kind of dependency). For this particular
problem, I only see two solutions : the fontconfig way ( you create
your own configuration file format (.xml based probably) and it will
be the only one supported) or adding configuration hook in the library
and desktop environment will plug their own configuration backend in
Oyranos (or maybe just ship the different configuration backends as
dlopened modules but it adds again dependency issues). But the more I
think about it, the more I prefer the fontconfig way.
-I don't like CamelCase (I'm half joking, I'm used to lower casing,
like glib/glibc and so on ;)

> But this is an other pice of short argument. So would you mind in
> elaborating in naming the differences of the examples (CM/Xorg/printing)
> or why "desktop-neutral and non-distribution configuration software for
> these points" have failed. If Xorg and CM is not comparable why do you
> expect the same to CM? You might understand, as I work on this CM stuff I
> would like to know about general hard to resolve proplems in more detail.

Because configuration for such things (Xorg / printing) is
uninteresting for 99% of unpaid hackers, extremely hard to do without
access to hardware. So far, only distributions have taken burden of
doing such tools and for historical reasons, each distribution has
done its own tool and no sharing has happen (and I don't see it
happening anytime soon). Xorg is slowly moving to autoconfiguration
but this stuff takes a lot of time and I don't really expect it to
work or 100% of graphic cards and monitors (due to uncompliant DCC
monitors for instance).

-- 
Frederic Crozat