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