2012/3/14 Alexander Neundorf <neund...@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