Review Request: include KolorManager in kdegraphics

[Kai-Uwe Behrmann]

Am 15.03.12, 07:34 +0100 schrieb Stas Verberkt:
>> On Wednesday, March 14, 2012 14:22:54 Sune Vuorela wrote:
>> There's a few major points which I think if can be answered would
>> help clarify what that would look like:
> Indeed, this discussion is going places, but does not really come up with
> answers. As someone who has no understanding of colour managemant
> whatsoever
> and without any bias, I, indeed, see some questions to be answered, in the
> hope this will provide us with some structure.
>
> * First of all, how expensive would it be to provide a small abstraction
> allowing drop-in replacement of Oyranos by colord and the other way
> around, e.g. have one interface and two backends?

For device configuration a decission would have to be made to eiher 
simplify and thus cripple Oyranos or to extent colord for a common API
wrapper.

Profile lookup would be pretty simple. Many settings could be shared, but 
do not completely overlap. I do not know about caching in colord.

A colour conversion CMM wrapper API is only in Oyranos available. So you 
would have to recode that completely of you want complete independence 
from. All modern platforms, except Linux, support now multi monitor 
colour correction in their basic image viewers. You might loose 
partitially the ability to support that.

For cross platform support, KDE would need code rewritten for each 
platform. This includes nearly all non pure ICC components, like profile 
paths, settings, device backends and so on.

> * If the platforms supported by the backend are different from the
> platforms targetted by KDE, how do we cope on these other targets? Should
> we answer question one with: indeed one interface, however, four backends
> -- given whatever Windows, MacOSX, or whatever platform you like and KDE
> targets uses.
>
>> * 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).
>>
> * Maybe reformulated to: What are the target audiences of the
> applications? If one is more aimed at the default user and another at
> certain professionals this calls for a different view at the situation. As

It is not that a strong division. Oyranos at least supports both mentioned 
user groups.

> some people tend to say: one size does not always fits all.
> Furthermore, I expect that there should be some communication between the
> goals of KDE and those of the solution we prefer.

I be here around.

>> * 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?
>>
> * A feature-wise comparison, although that quite easily gives a false
> impression. For example, a product may have way more features, but because
> of some fundamental design decisions we do not like, or the other way
> around, something may be over simplified. Thus, such a comparison requires
> real expertise and no bias.
> It would probably be best if the developers explained what makes there
> software great and not so much what makes other software less worthy.

agreed. Again my link inside this thread to do so.
http://lists.kde.org/?l=kde-core-devel&m=133180205024971&w=2

>> * 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?
>>
> * Maybe this should be asked for all possible solutions? Also, given the
> fact that there are people working or willing to work on KDE integration
> of both, this hould not be too much of a problem, I would guess.
>
> As a final remark, please note that the diversity in the open source world
> in general and the Linux world specific is, most of the time, considered a
> good thing. Competing projects are generally responsible for more
> innovation than monopolies.
> If we can embrace this, it would be wonderful.
>

kind regards
Kai-Uwe
-- 
Kai-Uwe Behrmann
www.oyranos.org