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
signature.asc
Description: This is a digitally signed message part.
