> No. There should be color management by default in KDE, that's really
> important; and there should be only one solution by default. We shouldn't > let distributions, or even worse, users decide which solution they use. That > way > madness lies. KDE's Color management solution shouldn't be in extragear. > > As to which one is selected, there are a couple of ways to decide. > > The first is, first come, first go. Kolormanager has been in development for > quite some time now, and colord is an upstart, gnome-derived technology. > Integration of colord in kde was only started very recently. Everyone is free > to > start a competing project, even inside KDE, but to make that project block a > pre-existing project isn't the way to go. I'm not talking about blocking pre-existing projects, I'm really looking forward a solution where the two could live. Sure we don't want users/distributions to decide but they do. > The second way to decide would be on technical merits. I'm not going to go > into that discussion; I've seen too many tiresome discussions already, and I > don't feel really competent anyway. > > For me as an application developer, life sucks anyway, since I have to > support > Linux, Windows and OSX, so for the time being, the application will offer its > own way to select profiles, in addition to using the X11 display atom that > both > colord and kolormanager support. (And I don't want to think about printing > anyway.) Well if we go into the merits discussion I really think we will get nowhere, as we didn't sort this first we won't sort this out now, KDE and GNOME primary goals is Linux, so I really don't think supporting platforms where they already have good solutions for this is a way to go. So how do we go into the merit discussion without creating yet another flame war?