Review Request: include KolorManager in kdegraphics

[Matthias Klumpp]

2012/3/14 Alexander Neundorf <neundorf at kde.org>:
> On Wednesday 14 March 2012, Thomas Zander wrote:
>> On Wednesday 14 March 2012 18.12.13 Kai-Uwe Behrmann wrote:
>> > Am 14.03.12, 17:46 +0100 schrieb Thomas Zander:
>> > > On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote:
>> > >>> Colord - just to mention that - is also not a GNOME project, it's a
>> > >>> FreeDesktop project. (Doesn't mean it's "standard", but does mean
>> > >>> that it's not GNOME)
>> > >>
>> > >> Well, no, having something on freedesktop.org doesn't mean it's not a
>> > >> gnome project;
>> > >
>> > > Little semantic confusion here :)
>> > > He said it *IS*  a freedesktop project.  Which means it is not a gnome
>> > > project, which seems to me to be true.
>> >
>> > It was developed specifically for Gnome Color Manager and then turned
>> > into a Glib depending library. So it bears all the specifics in it's
>> > concept.
>>
>> Notice I still maintain that we should judge a solution on merit, not on
>> who pushes it.
>>
>> > > That said; Cups also depends on colord. And IMO that has a bigger
>> > > impact than the gnome components that pull it in.
>> >
>> > colord print CM:
>> > CUPS does not depend in any way on colord.
>>
>> This opinion seems to conflict with the facts stated by others.  Debian for
>> instance has 'rec' (recommend) colord for cups.[1]
>> Notice that colord allows components to use it without linking it in at
>> startup using the dbus interface for instance.
>>
>> > But colord depends on CUPS to
>> > support it's concept of placing colord's session centric configuration
>> > into each job on server side.
>>
>> Which makes total technical sense. No color management system will work
>> 100% without support in the individual components.  If Cups needs to be
>> patched to support a new feature, that sounds sane to me.
>> Does it not make more sense to have color management support in cups than
>> cups support in the color management software? It certainly does to me :)
>>
>> > It does not scale well and will likely be difficult to maintain.
>>
>> As someone that is also a software developer, I disagree, with the reasons
>> I wrote above. :-)
>>
>> Bottom line for me really is that a project that has been around for a year
>> has managed to grow fast and get accepted widely.
>> Some may argue thats because of political issues, but in the end thats not
>> really relevant. The end result is still 'market' acceptance.
>>
>> As mentioned before, accepting kolormanager in kdegraphics is kind of a
>> "no" to colord. And I think thats would be cutting our own fingers.
>
> The wiki page somebody pointed to mentioned that colord is linux-only, while
> oyranos also works on Windows and OSX.
>
> If we chose colord, how does our solution for Windows and OSX look like ?
> Does kolormanager work under Windows and OSX ?
Do we need a Windows/OS-X solution if both already provide their own
color-management, deeply integrated into the stack? (ColorSync on OS-X
and ColorManager on Win)

Regards,
   Matthias