Review Request: include KolorManager in kdegraphics

[Michael Pyne]

On Thursday, March 15, 2012 12:11:34 Kai-Uwe Behrmann wrote:
> Am 14.03.12, 22:15 -0400 schrieb Michael Pyne:
> > The problem is that the software is /like/ KDE but doesn't use any KDE
> > technologies. To best utilize a given subsystem we would typically use at
> > least a light abstraction layer, using Oyranos (at this stage) entails a
> > KDE abstraction layer on top of a KDE-like abstraction layer (unless KDE
> > apps code to Oyranos directly, which I don't see as likely in general).
> > This API impedance mismatch is undesirable for much the same reasons that
> > we don't typically code to glib or gobject APIs.
> 
> Do you suggest a KDE wrapper for Oyranos objects and functions?

Well, I suggest that if KDE is to support color management at essentially any 
level deeper than just providing a UI to e.g. select a color profile for a 
display and printer, that it would be done with a KDE-style API, that could 
wrap Oyranos, or could wrap any other feasible implementation. Something like 
Phonon or Solid.

> I hope to have adressed that already from my side.
> http://lists.kde.org/?l=kde-core-devel&m=133180205024971&w=2

Thanks for the link straight to the relevant email. :)

> Oyranos makes sense to user, who have no idea that colour management
> exists. So they have no idea that it would be good for them.

Well your link says that Oyranos "just works", and your statement here seems 
to suggest that Oyranos does this without much (if any) user intervention. 
Given all the other features supported by Oyranos I have to assume that this 
requires at least some support from the application and/or toolkit level, no?

Keeping that in mind it would seem that to get the full benefit of Oyranos 
that there would need to be deeper integration work than just adding 
KolorManager (which I understand is separate from this thread's topic).

Returning to the topic at-hand, I will say (and this is just my opinion) that 
I think this application would be best suited for extragear/graphics when it 
moves out of playground, based on the low level of integration (both with 
KDE's desktop and the other toolkit/infra work needed). If/when color 
management becomes more supported in Qt and KDE then it would make more sense 
to have CMS configuration in kdegraphics for the available CMS system(s). But 
until then having this in kdegraphics without support from skanlite, Qt, our 
printing layer, etc. really seems to promise more than a KDE desktop can 
deliver right now. Even if it were to be in kdegraphics it should be an 
optional build item (dependent on whether oyranos is available or not).

Like I said, that's just my opinion... I'm neither involved in kdegraphics 
development nor the kdegraphics module maintainer.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120315/15b442ea/attachment.sig>