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