Review Request: include KolorManager in kdegraphics

[Sven Langkamp]

On Wed, Mar 14, 2012 at 12:53 PM, Boudewijn Rempt <boud at valdyas.org> wrote:

> On Wednesday 14 March 2012 Mar, Daniel Nicoletti wrote:
> > > Request:
> >
> > > After working on KolorManager and Oyranos in the past months for the
> last
> > > Oyranos-0.4.0 release, we feel the stack is ready to review for
> inclusion into
> > > KDE.
> > > KolorManager resides currently in Playground/Graphics:
> > > http://quickgit.kde.org/?p=kolor-manager.git&a=summary
> >
> > Just a quick question, currently we have two CMS stacks, colord and
> > oyranos, while
> > I have nothing against having two of them in KDE, I wonder if this
>  would become
> > a problem for colord-kde [1] to enter in kdegraphics too?
>
> There should be only one.
>
> > In that case
> > would be better
> > to both go to kdeextragear or is there some different policy in this
> case?
>
> 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.
>

Distribution shouldn't decide that, but I think they will do it. If Fedora
and Ubuntu both push colord, then it will practically become the standard,
no matter which one is actually better. From past experience it's more than
likely that they would patch it otherwise. Beside if e.g. Krita is running
under Gnome it would have to interact with colord.

This could become the next Betamax vs VHS. My feeling is that colord
currently is on the way to win this, as it backed by more projects.

 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.
>

Well it's not nice, but it happened before e.g. DBUS/DCOP or telepathy.
Still it's sad what happened here.


> 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.
>

As can be observed in this thread both solutions have some advantages and
disadvantages. They are hardly comparable and we have no experts to look
into this.


> 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.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120315/fcab0d4a/attachment.htm>