Review Request: include KolorManager in kdegraphics

[Alexander Neundorf]

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 ?

Alex