Review Request: include KolorManager in kdegraphics

[Kai-Uwe Behrmann]

Am 14.03.12, 22:15 -0400 schrieb Michael Pyne:
> On Wednesday, March 14, 2012 14:22:54 Sune Vuorela wrote:
>> I would really prefer to at least have one common gui. preferably just
>> one stack. But if we have to have two competing stacks until one of them
>> dies, then I guess we will just have to live with it. But do it with a
>> common gui. pretty please.
>
> I agree that whatever we do there should be only one main KDE GUI to an
> underlying color management system (CMS).
>
> Going off-topic to discuss the thread in general, I have some thoughts on the
> matter:
>
> First off, I'm quite sympathetic to the plight of the Oyranos devs. Much like
> KDE, they have tried to make a user-customizable, modular, extensible,
> feature-complete system with efforts made at cross-platform functionality,
> standards development and compliance, and feature implementation in a "as
> correct as possible" fashion.
>
> 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?

> Additionally I don't see any good reason to /not/ support colord. Ignoring the
> other parallel about KDE-like software being reimplemented by a glib-based
> "simpler application", the fact is that colord is widely distributed on Linux
> and can (AFAICT) be driven over a fairly simple DBus API. If KDE is going to
> support CMS at all there's no reason not to support that if it's present and
> installed.
>
> However this by itself doesn't mean KDE necessarily shouldn't or can't support
> Oyranos. There's a few major points which I think if can be answered would
> help clarify what that would look like:
>
> * What feature(s) does Oyranos support over and above colord? I think we're
> all in agreement that Oyranos does /more/, but what specifically does that
> mean?

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

> * What of those extra features are "a big deal" for a desktop environment
> (i.e. would specifically would we *not* be providing our users by supporting
> colord and not supporting Oyranos).
>
> If these extra features are things that are ONLY "professional grade" then it
> may make more sense to have Oyranos configuration be an e.g.
> extragear/graphics type of thing that software like Digikam and Krita could
> use and/or depend on.
>
> On the other hand if there are things that a mere 'power user' might find
> useful (that colord will not be supporting due to scope) then it might make
> sense to have extra U/I if Oyranos is available. Perhaps multi-monitor CMS
> would fit the bill (assuming colord will not support).
>
> * Finally, assuming no direct support for Oyranos in a KCM, what would be
> needed to allow a user to use Oyranos in a KDE Desktop? E.g. let's assume that
> colord is always available on Ubuntu and so KDE can interact with it, but the
> user wants to use Oyranos... what does KDE have to do to allow the user to
> manually control their color profiles without a KDE daemon interfering?

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.

> Regards,
> - Michael Pyne

kind regards
Kai-Uwe

-- 
Kai-Uwe Behrmann
www.oyranos.org