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
