Review Request: include KolorManager in kdegraphics

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

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?

* 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?

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/20120314/f94bfc56/attachment.sig>