Review Request: include KolorManager in kdegraphics

[Daniel Nicoletti]

>Oyranos were against the patch, Kai-Uwe already said that and explained why. The fact that 
>there is patch does not mean it is the correct way to do things. The fact that it is not integrated
>upstream can also mean cups developers to do not like it. Do you know what they think about the patch?
If you follow the news you'd now how CUPS is driven, Apple doesn't like Linux,
they are currently removing all non-OSX filters, which is why a fork idea is surrounding us.
So yes, they won't accept patches for Linux only things.

>> > I said I wanted the most versatile, which means one that satisfies my
>> > needs *and* somebody else's needs. You are completey ignoring the fact
>> > that there are people using oyranos too, it has been developed for
>> > years, do you think it's fair to drop all that work now? I am in favor
>> > of adding support to both colord and oyranos in kdegraphics. One way of
>> > doing that is adding support to colord to kolor-manager, which talks has
>> > already started.
>> 
>> Tell me, who is using besides Cine Paint?
> 
>I was talking about people using oyranos, not programs. I think people matters more than programs (that is what the rebranding of "KDE" to mean the community was all about). I do not how many programs use oyranos, I am very new to this color management world. I know Krita can use it, then so far two programs. Not counting compiz because most KDE users (people) use kwin instead. I really think oyranos should integrate better with cups and kwin, which I think are the most used programs that can benefit from it.

Well PackageKit, upower, NM all integrates well in KDE all of them are FDO and you
even help one of these with a frontend, I myself help PackageKit and now colord since
Dario is already doing awesome work with upower.
(except from NM, colord, packagekit and upower comes from Richard).


>What do you think is going to happen if Oyranos lose support from all major desktops? That is a dead end for any user-oriented opensource project. I still commit patches to Kopete, but I already know and said that its fate is to disappear. OBS: I am going to use Kopete until there is no metacontact implementation in telepathy-kde :-P or until I can keep it working. By the way, telepathy-kde was meant to be a KDE 4 project. Before KDE 4.0.0 was released most Kopete developers tried to implement a KDE telepathy client and failed. I do not know if that was the cause of Kopete developers lose interest in Kopete but that for sure made Kopete 4.0.0 sub-par to 3.5.10 feature wise speaking. That was why I started to commit patches to Kopete, I wanted to implement the missing features from 3.5.10, that was in 2009. I do not use file managers, so I did not try to make Konqueror still work :-D but I am in charge of Plasma NM, which has less features than
 nm-applet. If I followed your examples I would be using MacOS or even Windows by now instead of helping develop KDE sofware.

Again the story is simple QtDBus didn't had support for some features
Telepathy needed, I don't know when the patches got accepted Qt upstream,
but that was actually the problem. I tryied too give Kopete new life but felt
like Richard trying to change a rock. Some people tho being open minded
can still reject your ideas, and I myself find it easier to gave up or to start a new
project than keep arguing with something that won't change.

>You tell me, I do not know how to test color management. How did you test colord for instance?
First you need to build the software or use the packaged version, see how things work,
now I started a replacement for system-config-printer because it has authentication
problems and is written in python. when I go to Oyranos I found a bunch of tech I don't
like, not just I don't like but many developers don't, so who will maintain those technologies
if few people like/use it?

sytem-config-printer is better than print-manager but no one fixed the authentication
bug till today, and will likely never do, print-manager in a few months got real acceptance.

I don't want to kill Oyranos but I do think the choices based on wrong use cases might
lead to an end, a good project done with a wrong design won't succeed. Take smart for
example, PackageKit in a few years was able to do what they tried for many years,
and stop saying that Gnome or Red Hat is pushing it, you can have Gnome without it,
FDO also plays by it's own rules, let's focus on what really matters which is the code. No user
will help you maintain a line of code, they will use what we best choose to them.