date:20120314


Request ID:
https://bugs.kde.org/show_bug.cgi?id=295987

About:
KolorManager is a front end to the Oyranos Colour Management System (CMS).

Why:
Colour Management is a important part of modern desktops. It helps 
designers to improve colour usability, artists to predict artwork 
appearance on client computers and graphic professionals to work with 
reliable colours. Oyranos is carefully designed to meet that demands. The 
KolorManager configuration front end is a KDE systemsettings panel for 
manual interaction in the otherwise automated process of configuring 
devices and providing reasonable defaults. The device configuration inside 
Oyranos CMS is a precondition to get DE colour management well working. 
Some applications like Krita or Gimp support already common OpenICC 
standards like the ICC Profile in X spec and will directly benefit from 
KolorManager being inside KDE. Other need further work to integrate 
Oyranos and ICC support.

About Oyranos: http://www.oyranos.org/about

Request:
After working on KolorManager and Oyranos in the past months for the last 
Oyranos-0.4.0 release, we feel the stack is ready to review for inclusion 
into KDE.

KolorManager resides currently in Playground/Graphics:
http://quickgit.kde.org/?p=kolor-manager.gita=summary

Someone mentioned kdegraphics would be a appropriate target place inside 
the KDE hierarchy.


kind regards
Kai-Uwe

--
Kai-Uwe Behrmann
developing for colour management 
www.behrmann.name + www.oyranos.org

Re: Review Request: include KolorManager in kdegraphics

 Request:

 After working on KolorManager and Oyranos in the past months for the last 
 Oyranos-0.4.0 release, we feel the stack is ready to review for inclusion 
 into 
 KDE.
 KolorManager resides currently in Playground/Graphics:
 http://quickgit.kde.org/?p=kolor-manager.gita=summary

Just a quick question, currently we have two CMS stacks, colord and
oyranos, while
I have nothing against having two of them in KDE, I wonder if this  would become
a problem for colord-kde [1] to enter in kdegraphics too? In that case
would be better
to both go to kdeextragear or is there some different policy in this case?

I'm actually targeting KDE SC 4.9 as gnome-color-manager is very mature and I am
pretty much just rewriting it with Qt/KDE libs.

1- http://dantti.wordpress.com/2012/03/12/coloring-you-desktop-with-colord-kde/

Best,
Daniel Nicoletti

Re: Review Request: include KolorManager in kdegraphics

On Wednesday 14 March 2012 Mar, Daniel Nicoletti wrote:
  Request:
 
  After working on KolorManager and Oyranos in the past months for the last 
  Oyranos-0.4.0 release, we feel the stack is ready to review for inclusion 
  into 
  KDE.
  KolorManager resides currently in Playground/Graphics:
  http://quickgit.kde.org/?p=kolor-manager.gita=summary
 
 Just a quick question, currently we have two CMS stacks, colord and
 oyranos, while
 I have nothing against having two of them in KDE, I wonder if this  would 
 become
 a problem for colord-kde [1] to enter in kdegraphics too? 

There should be only one.

 In that case
 would be better
 to both go to kdeextragear or is there some different policy in this case?

No. There should be color management by default in KDE, that's really 
important; and there should be only one solution by default. We shouldn't let 
distributions, or even worse, users decide which solution they use. That way 
madness lies. KDE's Color management solution shouldn't be in extragear.

As to which one is selected, there are a couple of ways to decide.

The first is, first come, first go. Kolormanager has been in development for 
quite some time now, and colord is an upstart, gnome-derived technology. 
Integration of colord in kde was only started very recently. Everyone is free 
to start a competing project, even inside KDE, but to make that project block a 
pre-existing project isn't the way to go.

The second way to decide would be on technical merits. I'm not going to go into 
that discussion; I've seen too many tiresome discussions already, and I don't 
feel really competent anyway.

For me as an application developer, life sucks anyway, since I have to support 
Linux, Windows and OSX, so for the time being, the application will offer its 
own way to select profiles, in addition to using the X11 display atom that both 
colord and kolormanager support. (And I don't want to think about printing 
anyway.)

 I'm actually targeting KDE SC 4.9 as gnome-color-manager is very mature and I 
 am
 pretty much just rewriting it with Qt/KDE libs.
 
 1- 
 http://dantti.wordpress.com/2012/03/12/coloring-you-desktop-with-colord-kde/
 
 Best,
 Daniel Nicoletti
 


-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl

Re: Review Request: include KolorManager in kdegraphics


Am 14.03.12, 04:36 -0700 schrieb Daniel Nicoletti:

Request:


After working on KolorManager and Oyranos in the past months for the last 
Oyranos-0.4.0 release, we feel the stack is ready to review for inclusion into 
KDE.

KolorManager resides currently in Playground/Graphics:
http://quickgit.kde.org/?p=kolor-manager.gita=summary


Just a quick question, currently we have two CMS stacks, colord and
oyranos, while
I have nothing against having two of them in KDE, I wonder if this  would become
a problem for colord-kde [1] to enter in kdegraphics too? In that case
would be better
to both go to kdeextragear or is there some different policy in this case?


Would it work out to link kdegraphics components to kdeextragear?


I'm actually targeting KDE SC 4.9 as gnome-color-manager is very mature and I am
pretty much just rewriting it with Qt/KDE libs.


OpenICC colour experts have then a different view of maturity.


1- http://dantti.wordpress.com/2012/03/12/coloring-you-desktop-with-colord-kde/


That including your later blog post shows a sub feature set of what is 
implemented in KolorManager / Oyranos.



Best,
Daniel Nicoletti


kind regards
Kai-Uwe

Re: Review Request: include KolorManager in kdegraphics

 No. There should be color management by default in KDE, that's really 

 important; and there should be only one solution by default. We shouldn't 
 let distributions, or even worse, users decide which solution they use. That 
 way 
 madness lies. KDE's Color management solution shouldn't be in extragear.
 
 As to which one is selected, there are a couple of ways to decide.
 
 The first is, first come, first go. Kolormanager has been in development for 
 quite some time now, and colord is an upstart, gnome-derived technology. 
 Integration of colord in kde was only started very recently. Everyone is free 
 to 
 start a competing project, even inside KDE, but to make that project block a 
 pre-existing project isn't the way to go.
I'm not talking about blocking pre-existing projects, I'm really looking 
forward a
solution where the two could live. Sure we don't want users/distributions to
decide but they do.

 The second way to decide would be on technical merits. I'm not going to go 
 into that discussion; I've seen too many tiresome discussions already, and I 
 don't feel really competent anyway.
 
 For me as an application developer, life sucks anyway, since I have to 
 support 
 Linux, Windows and OSX, so for the time being, the application will offer its 
 own way to select profiles, in addition to using the X11 display atom that 
 both 
 colord and kolormanager support. (And I don't want to think about printing 
 anyway.)
Well if we go into the merits discussion I really think we will get nowhere,
as we didn't sort this first we won't sort this out now, KDE and GNOME primary
goals is Linux, so I really don't think supporting platforms where they already
have good solutions for this is a way to go.

So how do we go into the merit discussion without creating yet another flame 
war?

Re: Review Request: include KolorManager in kdegraphics

  I'm actually targeting KDE SC 4.9 as gnome-color-manager is very mature and 
I am
  pretty much just rewriting it with Qt/KDE libs.
 
 OpenICC colour experts have then a different view of maturity.
 
 
 1- http://dantti.wordpress.com/2012/03/12/coloring-you-desktop-with-colord-kde/
 
 That including your later blog post shows a sub feature set of what is 
 implemented in KolorManager / Oyranos.

It's totally clear from my message that this is a work in progress thing, if you
want to demerit my work by saying yours is better this shouldn't be the kind
of thing to discuss in kde-core-devel. Please let's try to not offend
each others work.
About your opinion on maturity I'm talking as a developer which sees colord
as technology and still I'm really not comparing that to yours.

Best

Re: Review Request: include KolorManager in kdegraphics

On Wednesday 14 March 2012 Mar, Daniel Nicoletti wrote:
  No. There should be color management by default in KDE, that's really 
 
  important; and there should be only one solution by default. We shouldn't 
  let distributions, or even worse, users decide which solution they use. 
  That way 
  madness lies. KDE's Color management solution shouldn't be in extragear.
  
  As to which one is selected, there are a couple of ways to decide.
  
  The first is, first come, first go. Kolormanager has been in development 
  for 
  quite some time now, and colord is an upstart, gnome-derived technology. 
  Integration of colord in kde was only started very recently. Everyone is 
  free to 
  start a competing project, even inside KDE, but to make that project block 
  a 
  pre-existing project isn't the way to go.

 I'm not talking about blocking pre-existing projects, I'm really looking 
 forward a
 solution where the two could live.

Well, I am really not looking forward to that situation. Sometimes having a 
choice is a bad thing. Sometimes starting a new project instead of helping out 
an existing project is not the right thing to do.

 Sure we don't want users/distributions to
 decide but they do.
 
  The second way to decide would be on technical merits. I'm not going to go 
  into that discussion; I've seen too many tiresome discussions already, and 
  I 
  don't feel really competent anyway.
  
  For me as an application developer, life sucks anyway, since I have to 
  support 
  Linux, Windows and OSX, so for the time being, the application will offer 
  its 
  own way to select profiles, in addition to using the X11 display atom that 
  both 
  colord and kolormanager support. (And I don't want to think about printing 
  anyway.)

 Well if we go into the merits discussion I really think we will get nowhere,
 as we didn't sort this first we won't sort this out now, KDE and GNOME primary
 goals is Linux, so I really don't think supporting platforms where they 
 already
 have good solutions for this is a way to go.

No, Gnome's primary goal is Gnome, while KDE offers a framework for building 
applications on many platforms next as well as desktop environment. My own 
desktop environment is KDE's plasma, but my goal for Krita is to have it run 
everywhere, not just on the plasma desktop. 

In fact, until Gnome 3 and Unity drove them away, most of my users were on 
Gnome... And that was fine, because colord and oyranos both set the relevant 
X11 atom, so Krita is fine, as long as I explicitly don't care about scanners 
and printing.

 So how do we go into the merit discussion without creating yet another flame 
 war?

I don't know. I don't know of a extensive comparison between colord and 
oyranos. And I'm not sure it's possible anymore to find anyone who can do that 
competently, honestly and impartially. 

Realistically speaking, we'll have colord on Linux as the standard whether we 
want it or not, because it's in Fedora, and whatever Redhat puts in Fedora will 
be the standard for Linux. Of course other distributions will package it, 
because they will want to package gnome. Even if we had been faster to the 
finish line and had had kolor-manager ready for KDE 4.6 or 4.7, no way colord 
would not have replaced our own work.

Apart from all technical merits.

-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl

Re: Review Request: include KolorManager in kdegraphics


Am 14.03.12, 06:01 -0700 schrieb Daniel Nicoletti:

  I'm actually targeting KDE SC 4.9 as gnome-color-manager is very mature and I 
am
  pretty much just rewriting it with Qt/KDE libs.

 
OpenICC colour experts have then a different view of maturity.
 

 

1- http://dantti.wordpress.com/2012/03/12/coloring-you-desktop-with-colord-kde/
 
That including your later blog post shows a sub feature set of what is 
implemented in KolorManager / Oyranos.


It's totally clear from my message that this is a work in progress thing, if you
want to demerit my work by saying yours is better this shouldn't be the kind
of thing to discuss in kde-core-devel. Please let's try to not offend
each others work.


I welcome anyone, who works on Linux CM in a open minded way, including 
you.


But you used GCM as a reference for your own project and surely know 
the controversial issues around colord. My answere was in response to the

later.


About your opinion on maturity I'm talking as a developer which sees colord
as technology and still I'm really not comparing that to yours.


As you want to work with that project, how about reading the according 
threads on the OpenICC ml [1] ?



Best



kind regards
Kai-Uwe

[1] http://lists.freedesktop.org/mailman/listinfo/openicc

Re: Review Request: include KolorManager in kdegraphics

Em Wednesday 14 March 2012, Boudewijn Rempt escreveu:
 On Wednesday 14 March 2012 Mar, Daniel Nicoletti wrote:
   No. There should be color management by default in KDE, that's really
   
   important; and there should be only one solution by default. We
   shouldn't let distributions, or even worse, users decide which
   solution they use. That way madness lies. KDE's Color management
   solution shouldn't be in extragear.
   
   As to which one is selected, there are a couple of ways to decide.
   
   The first is, first come, first go. Kolormanager has been in
   development for quite some time now, and colord is an upstart,
   gnome-derived technology. Integration of colord in kde was only
   started very recently. Everyone is free to start a competing project,
   even inside KDE, but to make that project block a pre-existing project
   isn't the way to go.
  
  I'm not talking about blocking pre-existing projects, I'm really looking
  forward a solution where the two could live.
 
 Well, I am really not looking forward to that situation. Sometimes having a
 choice is a bad thing. Sometimes starting a new project instead of helping
 out an existing project is not the right thing to do.

I agree.
 
  Sure we don't want users/distributions to
  decide but they do.
  
   The second way to decide would be on technical merits. I'm not going to
   go into that discussion; I've seen too many tiresome discussions
   already, and I don't feel really competent anyway.
   
   For me as an application developer, life sucks anyway, since I have to
   support Linux, Windows and OSX, so for the time being, the application
   will offer its own way to select profiles, in addition to using the
   X11 display atom that both colord and kolormanager support. (And I
   don't want to think about printing anyway.)
  
  Well if we go into the merits discussion I really think we will get
  nowhere, as we didn't sort this first we won't sort this out now, KDE
  and GNOME primary goals is Linux, so I really don't think supporting
  platforms where they already have good solutions for this is a way to
  go.
 
 No, Gnome's primary goal is Gnome, while KDE offers a framework for
 building applications on many platforms next as well as desktop
 environment. My own desktop environment is KDE's plasma, but my goal for
 Krita is to have it run everywhere, not just on the plasma desktop.
 
 In fact, until Gnome 3 and Unity drove them away, most of my users were on
 Gnome... And that was fine, because colord and oyranos both set the
 relevant X11 atom, so Krita is fine, as long as I explicitly don't care
 about scanners and printing.
 
  So how do we go into the merit discussion without creating yet another
  flame war?
 
 I don't know. I don't know of a extensive comparison between colord and
 oyranos. And I'm not sure it's possible anymore to find anyone who can do
 that competently, honestly and impartially.

Personally, what I think is really important is a community (not ony 
one 
person) commited to maintain the software. We already have problems with KDE 
software that lost the maintainer or nobody is willing to develop it anymore, 
those software are fated to disappear when we move to Qt 5.
 
 Realistically speaking, we'll have colord on Linux as the standard
 whether we want it or not, because it's in Fedora, and whatever Redhat
 puts in Fedora will be the standard for Linux. Of course other
 distributions will package it, because they will want to package gnome.
 Even if we had been faster to the finish line and had had kolor-manager
 ready for KDE 4.6 or 4.7, no way colord would not have replaced our own
 work.

Yes, I think oyranos needs more support from distributions or at least 
be easier to install. Of course, by the features oyranos includes there must 
be scenarios where colord does not help. The fact that colord is going to be 
the standard also does not mean we should drop oyranos. As long as oyranos 
team maintain the software and the KDE support in it we are ok.

-- 
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br

Re: Review Request: include KolorManager in kdegraphics

Em Wednesday 14 March 2012, Kai-Uwe Behrmann escreveu:
 Am 14.03.12, 06:01 -0700 schrieb Daniel Nicoletti:
I'm actually targeting KDE SC 4.9 as gnome-color-manager is very
  mature and I am pretty much just rewriting it with Qt/KDE libs.
  
   
  OpenICC colour experts have then a different view of maturity.
   
  
   
  
  1- http://dantti.wordpress.com/2012/03/12/coloring-you-desktop-with-colo
  rd-kde/ 
  That including your later blog post shows a sub feature set of what is 
  implemented in KolorManager / Oyranos.
  
  It's totally clear from my message that this is a work in progress thing,
  if you want to demerit my work by saying yours is better this shouldn't
  be the kind of thing to discuss in kde-core-devel. Please let's try to
  not offend each others work.

I do not read a demerit of your work the words above. Unless you are 
talking about something Kai-Uwe Behrmann wrote outside this mailling list I 
think we should not be that agressive in a response.
 
 I welcome anyone, who works on Linux CM in a open minded way, including
 you.

 But you used GCM as a reference for your own project and surely know
 the controversial issues around colord. My answere was in response to the
 later.

And you should also help make things calm, ok?
 
  About your opinion on maturity I'm talking as a developer which sees
  colord as technology and still I'm really not comparing that to yours.

That is partially wrong. A KDE developer is already working on the 
project that your project is meant to replace, you must really talk about why 
you want that in technical terms. Kai-Uwe is right about your work is 
controversional by nature and also because you do not even consulted the KDE 
developer that is already working on color management in KDE. That is at least 
impolite in my oppinion.

-- 
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br

Re: Review Request: include KolorManager in kdegraphics


Quoting Daniel Nicoletti dantti85-...@yahoo.com.br:
So how do we go into the merit discussion without creating yet  
another flame war?


I'm sorry, but merit has to be the metric, that's the basis of both  
open source in general and KDE specifically. I'd like KDE to avoid  
sliding towards a social support group ;)


We had a little talk about those two projects recently on k-c-d as  
well, where colord was proposed and Kai used that opportunity to plug  
his project.


I then went and downloaded both codebases and looked at them.

First thing that I'm worried about is that the whole project is  
designed around user roles (called policies).  As I have been involved  
with KDE usability I have seen discussions and concepts of user roles  
a lot. Frankly, they don't work. There is almost no research to  
support them, there is plenty of research stating they don't work.
Then there is the technical dependency tree of Oyranos;  this shows a  
subsection of its deps;

http://pkgs.org/fedora-16/fedora-x86_64/oyranos-libs-0.3.1-1.fc16.x86_64.rpm.html
Thats a lot of dependencies;  some of them anything but easy to find packaged.
Compare to http://packages.debian.org/wheezy/colord

All of this could be ignored, as long as there is real cooperation and  
willingness to work together; so I looked at how lively the Oyranos  
community is.

http://sourceforge.net/mailarchive/forum.php?forum_name=oyranos-devel

I don't know why  colord was created instead of working with Kai on  
his mostly one-man project, it may have been for very good reasons, it  
may have been just not-invented-here.  But the end result is that the  
new project is quickly replacing the longer existing one both in  
developer community and in usage.


And thats a good point; how many people use it in the wild?  I find  
the debian popularity contest insightful;

http://qa.debian.org/popcon.php?package=colord
If you don't have a good idea what those numbers are, compare to;  
http://qa.debian.org/popcon.php?package=k3b or  
http://qa.debian.org/popcon.php?package=kdebase-workspace both of  
which have a lower install score than colord.



So, last time the colord and oyranos projects where mentioned on  
kde-core-devel, this amounts to the data I looked through and got my  
impressions on.
I personally came to the conclusion that KDE is probably better off by  
focusing on colord, even if there is currently no KDE gui for it.


--
Thomas Zander

Re: Review Request: include KolorManager in kdegraphics

On 2012-03-14, Daniel Nicoletti dantti85-...@yahoo.com.br wrote:
 Request:

 After working on KolorManager and Oyranos in the past months for the last 
 Oyranos-0.4.0 release, we feel the stack is ready to review for inclusion 
 into 
 KDE.
 KolorManager resides currently in Playground/Graphics:
 http://quickgit.kde.org/?p=kolor-manager.gita=summary

 Just a quick question, currently we have two CMS stacks, colord and
 oyranos, while
 I have nothing against having two of them in KDE

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 wonder if this  would become
 a problem for colord-kde [1] to enter in kdegraphics too? In that case
 would be better
 to both go to kdeextragear or is there some different policy in this case?

I hope that we aren't going to select a solution based on who is a month
faster than the other.

/Sune

Re: Review Request: include KolorManager in kdegraphics


Quoting Kai-Uwe Behrmann k...@gmx.de:
I'm actually targeting KDE SC 4.9 as gnome-color-manager is very  
mature and I am

pretty much just rewriting it with Qt/KDE libs.


OpenICC colour experts have then a different view of maturity.


Kai,

the two projects clearly have a different set of ideas about what they  
should do. Which is fine.
What is not fine is write statements like the one I quoted above, you  
imply bad things about Daniel personally (his view of what is mature)  
which makes this a personal attack.


In KDE we want to focus on the facts. We talk about merit.
While its fine to give an opinion on a (technical) idea, the above is  
not acceptable.


Please respect these values we hold dear here in KDE :)
--
Thomas Zander

Re: Review Request: include KolorManager in kdegraphics

Hi!
Colord - just to mention that - is also not a GNOME project, it's a
FreeDesktop project. (Doesn't mean it's standard, but does mean that
it's not GNOME) So everyone is free to contribute to it, and the
maintainer is interested in collaborating with KDE. (which he already
does very nicely)

There's one thing about Oryanos I'd like to mention: I wanted to find
out why Oryanos is not packaged yet on many distributions. Reasons are
the strange build system it uses (looks like a custom thing to me),
which makes it difficult to build it on multiple architectures. It
also has dependencies like Elektra, which looks dead to the public.
(But is still developed, as it's maintainer says) Oryanos requires a
special version of Elektra packaged. There's also some other stuff
going on which needs to be clearified before Oryanos can be shipped in
distributions easily. It also has some legacy stuff, like Compiz
plugins - a KWin plugin would be better for KDE, IMHO ;-)

On the other hand, colord has a clean codebase, less dependencies and
it just works for GNOME. Although I don't have experience in color
management, seeing the younger project replacing the older one so fast
shows me that colord at least provides enough and well-working
functionality for color management on Linux.
Therefore, it might be a good thing for KDE to choose it.
(Maybe do some tests with it first)

I also want to point you to this comparison colord against Oryanos:
= http://www.freedesktop.org/software/colord/faq.html#oyranos
Maybe also interesting, this comment of the Oryanos maintainer
(regarding the FAQ):
=
http://blog.tenstral.net/2012/02/wanted-kde-color-management-kcm.html/comment-page-1#comment-48661

Kind regards,
Matthias Klumpp

2012/3/14 Thomas Zander zan...@kde.org:
Quoting Kai-Uwe Behrmann k...@gmx.de:

I'm actually targeting KDE SC 4.9 as gnome-color-manager is very mature
and I am
pretty much just rewriting it with Qt/KDE libs.

OpenICC colour experts have then a different view of maturity.

Kai,

the two projects clearly have a different set of ideas about what they
should do. Which is fine.
What is not fine is write statements like the one I quoted above, you imply
bad things about Daniel personally (his view of what is mature) which makes
this a personal attack.

In KDE we want to focus on the facts. We talk about merit.
While its fine to give an opinion on a (technical) idea, the above is not
acceptable.

Please respect these values we hold dear here in KDE :)
--
Thomas Zander

Re: Review Request: include KolorManager in kdegraphics


Am 14.03.12, 15:14 +0100 schrieb Thomas Zander:
We had a little talk about those two projects recently on k-c-d as well, 
where colord was proposed and Kai used that opportunity to plug his project.


I then went and downloaded both codebases and looked at them.

First thing that I'm worried about is that the whole project is designed 
around user roles (called policies).  As I have been involved with KDE


Policies are grouped preferences for rendering intents and default profile 
settings. The advantage is, they can be stored instead of switching each 
single option. The policies feature was recommended to implement. 
What would you suggest to improve that feature to gain more simplicity?


usability I have seen discussions and concepts of user roles a lot. Frankly, 
they don't work. There is almost no research to support them, there is plenty 
of research stating they don't work.


The policies in Oyranos are not forced other than normal settings. So each 
user is free to choose what she/he likes. There is no artificial 
limitation.


Then there is the technical dependency tree of Oyranos;  this shows a 
subsection of its deps;

http://pkgs.org/fedora-16/fedora-x86_64/oyranos-libs-0.3.1-1.fc16.x86_64.rpm.html


That comes from the device plugins being included inside the Oyranos 
source tree. However users can install a minimal Oyranos library and add 
X11, CUPS or othe device plugins later. KolorManager panel has no direct 
dependency to these device modules. The advantage is that the CMS can care 
about even complex device configuration and needs minimal device driver 
interaction.


Thats a lot of dependencies;  some of them anything but easy to find 
packaged.

Compare to http://packages.debian.org/wheezy/colord


I guess components needs device access somewhere in the stack to obtain 
informations about the actual device. The advantage is a small core, but 
on the other side the components need to do all device interaction themself.


All of this could be ignored, as long as there is real cooperation and 
willingness to work together; so I looked at how lively the Oyranos community 
is.

http://sourceforge.net/mailarchive/forum.php?forum_name=oyranos-devel


When talking about cooperation, then it is appropriate to look at the 
OpenICC channel. That is the place where colour management project 
interaction happens and many Oyranos developers, write there directly to 
get opinions from the community and discuss technical ideas.

http://lists.freedesktop.org/mailman/listinfo/openicc

I don't know why  colord was created instead of working with Kai on his 
mostly one-man project, it may have been for very good reasons, it may have 
been just not-invented-here.  But the end result is that the new project is 
quickly replacing the longer existing one both in developer community and in 
usage.


It might be that Oyranos core appears slow evolving. But that is as well 
due to being involved in following other ICC related projects:

OpenICC default profiles - research, creation, quality control
basICColor default printing profiles - tals with many vendors, licensing
CinePaint - ~second open source ICC graphics editor, 3 year maintainance
ICC Examin - profile viewer
KolorManager - you know
libCmpx - long long discussions for relyable print concept, implementation
CompICC - idea, mentoring, maintainance, many improvements
Taxi - idea, concept, new standards

These projects and some others belong to the Oyranos path of finding out,
what might be useful for good colour management support on Linux. Of 
course other projects can continue more easy and faster based on that 
previous work and on the experiences made. And surely they do.


And thats a good point; how many people use it in the wild?  I find the 
debian popularity contest insightful;

http://qa.debian.org/popcon.php?package=colord


It was pointed out that such results are influenced by colord being 
mandatory inside Gnome.


How does that relate to (?):
http://qa.debian.org/popcon.php?package=nautilus

If you don't have a good idea what those numbers are, compare to; 
http://qa.debian.org/popcon.php?package=k3b or 
http://qa.debian.org/popcon.php?package=kdebase-workspace both of which have 
a lower install score than colord.


So, last time the colord and oyranos projects where mentioned on 
kde-core-devel, this amounts to the data I looked through and got my 
impressions on.
I personally came to the conclusion that KDE is probably better off by 
focusing on colord, even if there is currently no KDE gui for it.


--
Thomas Zander


kind regards
Kai-Uwe

--
Kai-Uwe Behrmann
http://www.oyranos.org

Re: Review Request: include KolorManager in kdegraphics


On Wed, 14 Mar 2012, Matthias Klumpp wrote:


Hi!
Colord - just to mention that - is also not a GNOME project, it's a
FreeDesktop project. (Doesn't mean it's standard, but does mean that
it's not GNOME)


Well, no, having something on freedesktop.org doesn't mean it's not a 
gnome project; it is a gnome project, and it's widening its scope. The 
reason it's used at all is that is is used inside gnome.



So everyone is free to contribute to it, and the
maintainer is interested in collaborating with KDE. (which he already
does very nicely)

There's one thing about Oryanos I'd like to mention: I wanted to find
out why Oryanos is not packaged yet on many distributions. Reasons are
the strange build system it uses (looks like a custom thing to me),
which makes it difficult to build it on multiple architectures. It
also has dependencies like Elektra, which looks dead to the public.
(But is still developed, as it's maintainer says) Oryanos requires a
special version of Elektra packaged. There's also some other stuff
going on which needs to be clearified before Oryanos can be shipped in
distributions easily.


It's easy enough to package -- the opensuse packages I use work perfectly 
fine, so I cannot imagine that there are any real and relevant problems 
for other distributions.



It also has some legacy stuff, like Compiz
plugins - a KWin plugin would be better for KDE, IMHO ;-)


So that is irrelevant -- it used to be relevant some years ago, which sort 
of shows that oyranos is a project that has been going already for quite 
some time and has made several transitions already. Which is a good thing.




On the other hand, colord has a clean codebase, less dependencies and
it just works for GNOME.


And oyranos + kolormanager just works for KDE.


Although I don't have experience in color
management,


Well, that's the issue really: nearly nobody has a real and thorough 
understanding of color management. I've been working with color management 
in Krita since 2004, and I still have to admit that I don't have a good 
overview of all issues.



seeing the younger project replacing the older one so fast
shows me that colord at least provides enough and well-working
functionality for color management on Linux.


The only reason colord spreads is because it's by default part of gnome3. 
That in itself doesn't show anything about its technical merits. And 
within gnome, it is actually barely used. In the end, it's the 
applications that make the difference.



Therefore, it might be a good thing for KDE to choose it.
(Maybe do some tests with it first)

I also want to point you to this comparison colord against Oryanos:
= http://www.freedesktop.org/software/colord/faq.html#oyranos


Given the extremely tense and nasty discussions we've had, with Alexandre 
Prokoudine calling Kai-UWe a liar and so on, I am not sure that relying on 
one project's assesment of the other project is a good idea. In fact, I am 
sure it is not.


I'm also sure unless people are prepared to spend some time on figuring 
out what color management is all about instead of posting lists of 
statistics, the question is not being considered on its technical 
merits. pop-contests, lines-of-code, dependencies and so on are all 
non-technical when it comes to determining whether the color management 
works.


But then, as I've said before, for me, as the author of an application 
for which color management is actually essential, both colord and oyranos 
work fine.


Boudewijn

Re: Review Request: include KolorManager in kdegraphics

On 2012-03-14, Boudewijn Rempt b...@valdyas.org wrote:
 It's easy enough to package -- the opensuse packages I use work perfectly 
 fine, so I cannot imagine that there are any real and relevant problems 
 for other distributions.

Sure it can be done. but it is just useless churn if it doesn't really
provide anything that matters to the end user that colord doesn't.

I could package oyranos and the weird things it requires. but in the
same time I_could probably fix 20 small annoyances for all users and
package the new nice nepomuk ioslaves. What is the best use of my time?

/Sune

Re: Review Request: include KolorManager in kdegraphics


On Wed, 14 Mar 2012, Sune Vuorela wrote:


On 2012-03-14, Boudewijn Rempt b...@valdyas.org wrote:

It's easy enough to package -- the opensuse packages I use work perfectly
fine, so I cannot imagine that there are any real and relevant problems
for other distributions.


Sure it can be done. but it is just useless churn if it doesn't really
provide anything that matters to the end user that colord doesn't.


And, of course, the other way around -- but that's the point isn't it? 
Until a library is used, it isn't packaged. And until we actually have 
input from people who know what they are talking about, or listen to them,

we cannot decide whether anything provides anything that matters to the
end user.

I think it's true, though that What _is_ missing is a clear list of what 
oyranos provides right now -- apart from making it possible to select the

display profile for X11.

And then, if that list is available, it's of course very much the question 
whether enough people can understand it properly.



I could package oyranos and the weird things it requires.


I wish we could do without being pejorative.


but in the
same time I_could probably fix 20 small annoyances for all users and
package the new nice nepomuk ioslaves. What is the best use of my time?


That depends. If KDE uses kolor-manager, then oyranos needs to be 
packaged. Should we let that decision depend on whether it's already 
packaged? Sounds like the wrong way around.


Boudewijn

Re: Review Request: include KolorManager in kdegraphics

Am 14.03.12, 15:54 +0100 schrieb Matthias Klumpp:

That is correct. I would appreciate any help to get that cleared, as some
packagers mentioned it to me. One offerd already a helping hand and
started converting libXcm, which is now autotooled. Oyranos might go
better cmakified.

which makes it difficult to build it on multiple architectures. It

Which on did not work? The recent released stack compiles on i586,
xf86_64, armv7l, osX and win32, the later being not yet very functional.

also has dependencies like Elektra, which looks dead to the public.
(But is still developed, as it's maintainer says) Oryanos requires a

Please Oyranos, like my nick, which is oy ;-)

special version of Elektra packaged. There's also some other stuff

Where do you get that information from? Oyranos build fine with the
last released Elektra version. For easy of build it is included in the
source tar ball. Sorry for repeating that.

going on which needs to be clearified before Oryanos can be shipped in
distributions easily. It also has some legacy stuff, like Compiz
plugins - a KWin plugin would be better for KDE, IMHO ;-)

That is a different topic. But basically I agree. It is maybe for an other
thread?

I also want to point you to this comparison colord against Oryanos:
= http://www.freedesktop.org/software/colord/faq.html#oyranos

Matthias, you help spreading false assertions here.

Maybe also interesting, this comment of the Oryanos maintainer
(regarding the FAQ):
=
http://blog.tenstral.net/2012/02/wanted-kde-color-management-kcm.html/comment-page-1#comment-48661

http://www.oyranos.org/2012/03/kde-end-to-end-colour-management/

Kind regards,
Matthias Klumpp

kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org

Re: Review Request: include KolorManager in kdegraphics

Em Wednesday 14 March 2012, Sune Vuorela escreveu:
 On 2012-03-14, Boudewijn Rempt b...@valdyas.org wrote:
  It's easy enough to package -- the opensuse packages I use work perfectly
  fine, so I cannot imagine that there are any real and relevant problems
  for other distributions.
 
 Sure it can be done. but it is just useless churn if it doesn't really
 provide anything that matters to the end user that colord doesn't.

You are talking as if colord is the default standard and well used in 
KDE and then out of a suden comes oyranoes trying to replace it. Colord is not 
wide used in KDE and since oyranos includes a wider feature set I guess it is 
more usefull for a wider range of users. As said in other e-mails colord is 
required in Gnome3, so why not add oyranos to kdegraphics since other KDE 
software already work with it?
 
 I could package oyranos and the weird things it requires. but in the
 same time I_could probably fix 20 small annoyances for all users and
 package the new nice nepomuk ioslaves. What is the best use of my time?

You devide what is the best use of your time. I still commit patches to 
Kopete from time to time even though I know it is going to fade away once we 
move to Qt 5 (Kopete still uses Qt3Support in several places).

-- 
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br

Re: Review Request: include KolorManager in kdegraphics

On 2012-03-14, Lamarque V. Souza lamar...@kde.org wrote:
   You are talking as if colord is the default standard and well used in 
 KDE and then out of a suden comes oyranoes trying to replace it. Colord is 
 not 
 wide used in KDE and since oyranos includes a wider feature set I guess it is 

No. colord seems to be the default standard for linux. unless we have a
good reason, I don't see why we should go for anything else.

 more usefull for a wider range of users. As said in other e-mails colord is 
 required in Gnome3, so why not add oyranos to kdegraphics since other KDE 
 software already work with it?

erm. kolor-manager is currently the only tool working with oyranos as I
understood it. so we should add it because it is already there?


/Sune

Re: Review Request: include KolorManager in kdegraphics

On Wednesday 14 March 2012 16.59.55 Lamarque V. Souza wrote:
 Colord is not wide used in KDE and since oyranos includes a wider feature
 set I guess it is more usefull for a wider range of users. 

This assumption seems to not be supported by the documentation. The specific 
set of user-groups also speaks against this assumption.

 As said in
 other e-mails colord is required in Gnome3, so why not add oyranos to
 kdegraphics since other KDE software already work with it?

I'm not following this sentence; becaues gnome uses X, kde should not use X. 
If thats what you are saying, I want to say I disagree.

Could you explain what you mean with the
  since other KDE already works with it
part?
AFAIK there is no KDE software that would function better with oyranos than 
with colord.  Which means there is no clear advantage on that basis.  Am I 
missing some piece of software?

-- 
Thomas Zander

Re: Review Request: include KolorManager in kdegraphics

Hi!

2012/3/14 Kai-Uwe Behrmann k...@gmx.de:
Am 14.03.12, 15:54 +0100 schrieb Matthias Klumpp:
[...]
I also want to point you to this comparison colord against Oryanos:
= http://www.freedesktop.org/software/colord/faq.html#oyranos

Matthias, you help spreading false assertions here.
Then please clarify these! ;-) I find the FAQ very convincing :)
I also linked your commend, so everyone can read both views (and not
only colord FAQ)
About Elektra: The last release is from 2008, it will definitely be
difficult to convince distributors to packqage it if there's no
visible upstream activity. From Richard, who contaced the Elektry guy,
I know Elektra is alive, but thereÄs no sign of life ^^

Please do a similar table for Oryanos vs. colord than the colord
maintainer did, so we can compare them. I guess that might be helpful
even for people who don't understand color management very well.

Best,
Matthias

2012/3/14 Kai-Uwe Behrmann k...@gmx.de:
Am 14.03.12, 15:54 +0100 schrieb Matthias Klumpp:

That is correct. I would appreciate any help to get that cleared, as some
packagers mentioned it to me. One offerd already a helping hand and started
converting libXcm, which is now autotooled. Oyranos might go better
cmakified.

which makes it difficult to build it on multiple architectures. It

Which on did not work? The recent released stack compiles on i586, xf86_64,
armv7l, osX and win32, the later being not yet very functional.

also has dependencies like Elektra, which looks dead to the public.
(But is still developed, as it's maintainer says) Oryanos requires a

Please Oyranos, like my nick, which is oy ;-)

special version of Elektra packaged. There's also some other stuff

Where do you get that information from? Oyranos build fine with the last
released Elektra version. For easy of build it is included in the source tar
ball. Sorry for repeating that.

going on which needs to be clearified before Oryanos can be shipped in
distributions easily. It also has some legacy stuff, like Compiz
plugins - a KWin plugin would be better for KDE, IMHO ;-)

That is a different topic. But basically I agree. It is maybe for an other
thread?

I also want to point you to this comparison colord against Oryanos:
= http://www.freedesktop.org/software/colord/faq.html#oyranos

Matthias, you help spreading false assertions here.

Maybe also interesting, this comment of the Oryanos maintainer
(regarding the FAQ):
=
http://blog.tenstral.net/2012/02/wanted-kde-color-management-kcm.html/comment-page-1#comment-48661

http://www.oyranos.org/2012/03/kde-end-to-end-colour-management/

Kind regards,
Matthias Klumpp

kind regards
Kai-Uwe Behrmann
--
developing for colour management www.behrmann.name + www.oyranos.org

Re: Review Request: include KolorManager in kdegraphics

2012/3/14 Lamarque V. Souza lamar...@kde.org:
 Em Wednesday 14 March 2012, Sune Vuorela escreveu:

 On 2012-03-14, Boudewijn Rempt b...@valdyas.org wrote:
  It's easy enough to package -- the opensuse packages I use work
  perfectly
  fine, so I cannot imagine that there are any real and relevant problems
  for other distributions.
 Sure it can be done. but it is just useless churn if it doesn't really
 provide anything that matters to the end user that colord doesn't.

 You are talking as if colord is the default standard and well used in KDE
 and then out of a suden comes oyranoes trying to replace it. Colord is not
 wide used in KDE and since oyranos includes a wider feature set I guess it
 is more usefull for a wider range of users. As said in other e-mails colord
 is required in Gnome3, so why not add oyranos to kdegraphics since other KDE
 software already work with it?
Colord is also integrated with many other parts of the stack. And that
Oryanos includes a wider feature-set doesn't necessarily mean it's the
better choice. Which other KDE software works with Oryanos already?

And btw. colord is a XDG project, not a GNOME project. Yes, it was
started by a GNOME developer, but this doesn't make it a GNOME
project. It is developed independent from GNOME.

Regards,
   Matthias

 I could package oyranos and the weird things it requires. but in the
 same time I_could probably fix 20 small annoyances for all users and
 package the new nice nepomuk ioslaves. What is the best use of my time?
 You devide what is the best use of your time. I still commit patches to
 Kopete from time to time even though I know it is going to fade away once we
 move to Qt 5 (Kopete still uses Qt3Support in several places).



 --

 Lamarque V. Souza

 KDE's Network Management maintainer

 http://planetkde.org/pt-br

Re: Review Request: include KolorManager in kdegraphics

On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote:
  Hi!
  Colord - just to mention that - is also not a GNOME project, it's a
  FreeDesktop project. (Doesn't mean it's standard, but does mean that
  it's not GNOME)
 
 Well, no, having something on freedesktop.org doesn't mean it's not a 
 gnome project; 

Little semantic confusion here :)
He said it *IS*  a freedesktop project.  Which means it is not a gnome 
project, which seems to me to be true. 

 it is a gnome project, and it's widening its scope. The 
 reason it's used at all is that is is used inside gnome.

Projects should be judged on merit, irregardless of who pushes it.
If gnome is using it and that makes it grow acceptance, thats a good thing in 
my book.  Why; *because* acceptance is growing. I don't care if its gnome or 
any other player pushing it.

That said; Cups also depends on colord. And IMO that has a bigger impact than 
the gnome components that pull it in.

-- 
Thomas Zander

Re: Review Request: include KolorManager in kdegraphics

Em Wednesday 14 March 2012, Sune Vuorela escreveu:
 On 2012-03-14, Lamarque V. Souza lamar...@kde.org wrote:
  You are talking as if colord is the default standard and well used in
  
  KDE and then out of a suden comes oyranoes trying to replace it. Colord
  is not wide used in KDE and since oyranos includes a wider feature set I
  guess it is
 
 No. colord seems to be the default standard for linux. unless we have a
 good reason, I don't see why we should go for anything else.

I should stop working in Plasma NM then since for distributions that 
ships Gnome as default desktop nm-applet is the standard.

If colord has a small dependency set and Dantii created the kcm is a 
couple of weeks, why not add support to colord in kolor-manager and add 
oyranos to kdegraphics. You already talked about that to Kai-Uwe and he ageed 
with that.
 
I usually in favor of the most versatile project, that is why I started 
to use KDE in the first place. Oyranos seems more versatile than colord, 
although I am also not an expert in color management.

  more usefull for a wider range of users. As said in other e-mails colord
  is required in Gnome3, so why not add oyranos to kdegraphics since other
  KDE software already work with it?
 
 erm. kolor-manager is currently the only tool working with oyranos as I
 understood it. so we should add it because it is already there?

Krita too as says the other guy in the list. We do not know who is 
using 
oyranos, if oyranos is importnat to big part of KDE users then I am in favor 
of adding it to kdegraphics and since there is willingness to add support to 
colord in kolor-manager then why not?

-- 
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br

Re: Review Request: include KolorManager in kdegraphics

Em Wednesday 14 March 2012, Thomas Zander escreveu:
 On Wednesday 14 March 2012 16.59.55 Lamarque V. Souza wrote:
  Colord is not wide used in KDE and since oyranos includes a wider feature
  set I guess it is more usefull for a wider range of users.
 
 This assumption seems to not be supported by the documentation. The
 specific set of user-groups also speaks against this assumption.

Which documentation and which user-groups?
 
  As said in
  other e-mails colord is required in Gnome3, so why not add oyranos to
  kdegraphics since other KDE software already work with it?
 
 I'm not following this sentence; becaues gnome uses X, kde should not use
 X. If thats what you are saying, I want to say I disagree.
 
 Could you explain what you mean with the
   since other KDE already works with it
 part?
 AFAIK there is no KDE software that would function better with oyranos than
 with colord.  Which means there is no clear advantage on that basis.  Am I
 missing some piece of software?

I meant that there are other KDE software that works with oyranos. I 
did 
not mean they have it as dependency.

-- 
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br

Re: Review Request: include KolorManager in kdegraphics

Em Wednesday 14 March 2012, Thomas Zander escreveu:
 On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote:
   Hi!
   Colord - just to mention that - is also not a GNOME project, it's a
   FreeDesktop project. (Doesn't mean it's standard, but does mean that
   it's not GNOME)
  
  Well, no, having something on freedesktop.org doesn't mean it's not a
  gnome project;
 
 Little semantic confusion here :)
 He said it *IS*  a freedesktop project.  Which means it is not a gnome
 project, which seems to me to be true.

That controversional. Do you know how freedesktop is working in the 
last 
years? If you did then you would not say that.
 
  it is a gnome project, and it's widening its scope. The
  reason it's used at all is that is is used inside gnome.
 
 Projects should be judged on merit, irregardless of who pushes it.
 If gnome is using it and that makes it grow acceptance, thats a good thing
 in my book.  Why; *because* acceptance is growing. I don't care if its
 gnome or any other player pushing it.
 
 That said; Cups also depends on colord. And IMO that has a bigger impact
 than the gnome components that pull it in.

I use cups here and no colord.

-- 
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br

Re: Review Request: include KolorManager in kdegraphics

On 2012-03-14, Lamarque V. Souza lamar...@kde.org wrote:
   I should stop working in Plasma NM then since for distributions that 
 ships Gnome as default desktop nm-applet is the standard.

erm. you are aware that colord better can be compared to NetworkManager
than to Plasma NM ?

/Sune

Re: Review Request: include KolorManager in kdegraphics


Am 14.03.12, 17:46 +0100 schrieb Thomas Zander:

On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote:

Colord - just to mention that - is also not a GNOME project, it's a
FreeDesktop project. (Doesn't mean it's standard, but does mean that
it's not GNOME)


Well, no, having something on freedesktop.org doesn't mean it's not a
gnome project;


Little semantic confusion here :)
He said it *IS*  a freedesktop project.  Which means it is not a gnome
project, which seems to me to be true.


It was developed specifically for Gnome Color Manager and then turned into 
a Glib depending library. So it bears all the specifics in it's concept.



it is a gnome project, and it's widening its scope. The
reason it's used at all is that is is used inside gnome.


Projects should be judged on merit, irregardless of who pushes it.
If gnome is using it and that makes it grow acceptance, thats a good thing in
my book.  Why; *because* acceptance is growing. I don't care if its gnome or
any other player pushing it.

That said; Cups also depends on colord. And IMO that has a bigger impact than
the gnome components that pull it in.


CUPS has a own CM spec, which works for vendor side profiles. That 
CMS exists completely outside of any DE or other CMS.


colord print CM:
CUPS does not depend in any way on colord. But colord depends on CUPS to 
support it's concept of placing colord's session centric configuration 
into each job on server side. I do not know how to support per session 
configuration remotely or how to assign to the proper users.
It does not scale well and will likely be difficult to maintain. That is 
one of the major and long standing critique points. The colord author 
repeatedly said it is fine, without delivering arguments, except it is 
the fastest way to implement.


OpenICC print CM:
One idea of OpenICC members is to let users configure a per queue 
device profile with CUPS' own means. Thus it is best support inside CUPS. 
We would like to support that in KolorManager or where appropriate
The worked on alternative is libCmpx, which embedds the user selected 
device profile inside the print job PDF/X-3. PDF/X-3 as a standard will 
likely work cross platform, which will be important to scale clouds and 
elsewhere. These two concepts appear much robuster and are proven to work 
on other operating systems. Mike Sweet confirmed that for the later, while 
the other concept is deployed on Windows by some drivers.


Here some more details about the later aproach:
http://www.oyranos.org/2012/02/linux-printing/

kind regards
Kai-Uwe
--
http://www.oyranos.org

Re: Review Request: include KolorManager in kdegraphics

Em Wednesday 14 March 2012, Sune Vuorela escreveu:
 On 2012-03-14, Lamarque V. Souza lamar...@kde.org wrote:
  I should stop working in Plasma NM then since for distributions that
  
  ships Gnome as default desktop nm-applet is the standard.
 
 erm. you are aware that colord better can be compared to NetworkManager
 than to Plasma NM ?

I am not comparing colord to Plasma NM, I am comparing oyranos to 
Plasma 
NM.

-- 
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br

Re: Review Request: include KolorManager in kdegraphics

Em Wednesday 14 March 2012, Alexander Neundorf escreveu:
 On Wednesday 14 March 2012, Lamarque V. Souza wrote:
  Em Wednesday 14 March 2012, Thomas Zander escreveu:
   On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote:
 Hi!
 Colord - just to mention that - is also not a GNOME project, it's a
 FreeDesktop project. (Doesn't mean it's standard, but does mean
 that it's not GNOME)

Well, no, having something on freedesktop.org doesn't mean it's not a
gnome project;
   
   Little semantic confusion here :)
   He said it *IS*  a freedesktop project.  Which means it is not a gnome
   project, which seems to me to be true.
  
  That controversional. Do you know how freedesktop is working in the last
  
  years? If you did then you would not say that.
 
 I agree.
 Stuff which is needed for Gnome is put on xdg, and because it doesn't link
 to libgnome or something like this they say it is independent from gnome.

It was not that I was refering to.
 
 Just the same way as all the other stuff coming from RedHat for the desktop
 is independent from Gnome ;-)

What happens if the stuff does not please RedHat?

-- 
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br

Re: Bugzilla upgrade.

2012-03-14 Thread Dawit A

Am I the only one that finds the new KDE bugzilla front end utterly
confusing ? All the conveient shortcuts in the front page that showed
things like weekly summary broken down by product are no longer
available. Will those things available in the old front page be
restored in the future or are they gone for good ?

KDE at the next Qt Contributors' Summit

2012-03-14 Thread Lydia Pintscher

Heya folks,

Is anyone taking care of KDE's presence at the next Qt Contributors'
Summit? http://wiki.qt-project.org/Events/Qt_Contributors_Summit  If
not it'd be really great if someone could step up. We should show up
again. I don't have the time to help with the planning. I might
however have a couch to crash on by that time for someone.


Cheers
Lydia

-- 
Lydia Pintscher - http://about.me/lydia.pintscher
KDE Community Working Group / KDE e.V. board member
http://kde.org - http://open-advice.org

Re: Review Request: include KolorManager in kdegraphics

On Wednesday 14 March 2012 18.12.13 Kai-Uwe Behrmann wrote:
 Am 14.03.12, 17:46 +0100 schrieb Thomas Zander:
  On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote:
  Colord - just to mention that - is also not a GNOME project, it's a
  FreeDesktop project. (Doesn't mean it's standard, but does mean that
  it's not GNOME)
  
  Well, no, having something on freedesktop.org doesn't mean it's not a
  gnome project;
  
  Little semantic confusion here :)
  He said it *IS*  a freedesktop project.  Which means it is not a gnome
  project, which seems to me to be true.
 
 It was developed specifically for Gnome Color Manager and then turned into
 a Glib depending library. So it bears all the specifics in it's concept.

Notice I still maintain that we should judge a solution on merit, not on who 
pushes it.

  That said; Cups also depends on colord. And IMO that has a bigger impact
  than the gnome components that pull it in.
 
 colord print CM:
 CUPS does not depend in any way on colord. 

This opinion seems to conflict with the facts stated by others.  Debian for 
instance has 'rec' (recommend) colord for cups.[1]
Notice that colord allows components to use it without linking it in at 
startup using the dbus interface for instance.

 But colord depends on CUPS to
 support it's concept of placing colord's session centric configuration
 into each job on server side.

Which makes total technical sense. No color management system will work 100% 
without support in the individual components.  If Cups needs to be patched to 
support a new feature, that sounds sane to me.
Does it not make more sense to have color management support in cups than cups 
support in the color management software? It certainly does to me :)

 It does not scale well and will likely be difficult to maintain. 
As someone that is also a software developer, I disagree, with the reasons I 
wrote above. :-)

Bottom line for me really is that a project that has been around for a year 
has managed to grow fast and get accepted widely.
Some may argue thats because of political issues, but in the end thats not 
really relevant. The end result is still 'market' acceptance. 

As mentioned before, accepting kolormanager in kdegraphics is kind of a no 
to colord. And I think thats would be cutting our own fingers.


1) http://packages.debian.org/wheezy/cups
-- 
Thomas Zander

Re: Review Request: include KolorManager in kdegraphics

2012-03-14 Thread Alexander Neundorf

On Wednesday 14 March 2012, Thomas Zander wrote:
 On Wednesday 14 March 2012 18.12.13 Kai-Uwe Behrmann wrote:
  Am 14.03.12, 17:46 +0100 schrieb Thomas Zander:
   On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote:
   Colord - just to mention that - is also not a GNOME project, it's a
   FreeDesktop project. (Doesn't mean it's standard, but does mean
   that it's not GNOME)
   
   Well, no, having something on freedesktop.org doesn't mean it's not a
   gnome project;
   
   Little semantic confusion here :)
   He said it *IS*  a freedesktop project.  Which means it is not a gnome
   project, which seems to me to be true.
  
  It was developed specifically for Gnome Color Manager and then turned
  into a Glib depending library. So it bears all the specifics in it's
  concept.
 
 Notice I still maintain that we should judge a solution on merit, not on
 who pushes it.
 
   That said; Cups also depends on colord. And IMO that has a bigger
   impact than the gnome components that pull it in.
  
  colord print CM:
  CUPS does not depend in any way on colord.
 
 This opinion seems to conflict with the facts stated by others.  Debian for
 instance has 'rec' (recommend) colord for cups.[1]
 Notice that colord allows components to use it without linking it in at
 startup using the dbus interface for instance.
 
  But colord depends on CUPS to
  support it's concept of placing colord's session centric configuration
  into each job on server side.
 
 Which makes total technical sense. No color management system will work
 100% without support in the individual components.  If Cups needs to be
 patched to support a new feature, that sounds sane to me.
 Does it not make more sense to have color management support in cups than
 cups support in the color management software? It certainly does to me :)
 
  It does not scale well and will likely be difficult to maintain.
 
 As someone that is also a software developer, I disagree, with the reasons
 I wrote above. :-)
 
 Bottom line for me really is that a project that has been around for a year
 has managed to grow fast and get accepted widely.
 Some may argue thats because of political issues, but in the end thats not
 really relevant. The end result is still 'market' acceptance.
 
 As mentioned before, accepting kolormanager in kdegraphics is kind of a
 no to colord. And I think thats would be cutting our own fingers.

The wiki page somebody pointed to mentioned that colord is linux-only, while 
oyranos also works on Windows and OSX.

If we chose colord, how does our solution for Windows and OSX look like ?
Does kolormanager work under Windows and OSX ?

Alex

Re: Review Request: include KolorManager in kdegraphics

2012/3/14 Alexander Neundorf neund...@kde.org:
 On Wednesday 14 March 2012, Thomas Zander wrote:
 On Wednesday 14 March 2012 18.12.13 Kai-Uwe Behrmann wrote:
  Am 14.03.12, 17:46 +0100 schrieb Thomas Zander:
   On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote:
   Colord - just to mention that - is also not a GNOME project, it's a
   FreeDesktop project. (Doesn't mean it's standard, but does mean
   that it's not GNOME)
  
   Well, no, having something on freedesktop.org doesn't mean it's not a
   gnome project;
  
   Little semantic confusion here :)
   He said it *IS*  a freedesktop project.  Which means it is not a gnome
   project, which seems to me to be true.
 
  It was developed specifically for Gnome Color Manager and then turned
  into a Glib depending library. So it bears all the specifics in it's
  concept.

 Notice I still maintain that we should judge a solution on merit, not on
 who pushes it.

   That said; Cups also depends on colord. And IMO that has a bigger
   impact than the gnome components that pull it in.
 
  colord print CM:
  CUPS does not depend in any way on colord.

 This opinion seems to conflict with the facts stated by others.  Debian for
 instance has 'rec' (recommend) colord for cups.[1]
 Notice that colord allows components to use it without linking it in at
 startup using the dbus interface for instance.

  But colord depends on CUPS to
  support it's concept of placing colord's session centric configuration
  into each job on server side.

 Which makes total technical sense. No color management system will work
 100% without support in the individual components.  If Cups needs to be
 patched to support a new feature, that sounds sane to me.
 Does it not make more sense to have color management support in cups than
 cups support in the color management software? It certainly does to me :)

  It does not scale well and will likely be difficult to maintain.

 As someone that is also a software developer, I disagree, with the reasons
 I wrote above. :-)

 Bottom line for me really is that a project that has been around for a year
 has managed to grow fast and get accepted widely.
 Some may argue thats because of political issues, but in the end thats not
 really relevant. The end result is still 'market' acceptance.

 As mentioned before, accepting kolormanager in kdegraphics is kind of a
 no to colord. And I think thats would be cutting our own fingers.

 The wiki page somebody pointed to mentioned that colord is linux-only, while
 oyranos also works on Windows and OSX.

 If we chose colord, how does our solution for Windows and OSX look like ?
 Does kolormanager work under Windows and OSX ?
Do we need a Windows/OS-X solution if both already provide their own
color-management, deeply integrated into the stack? (ColorSync on OS-X
and ColorManager on Win)

Regards,
   Matthias

Re: Review Request: include KolorManager in kdegraphics

On Wednesday 14 March 2012 21.29.09 Alexander Neundorf wrote:
 The wiki page somebody pointed to mentioned that colord is linux-only,
 while  oyranos also works on Windows and OSX.
 
 If we chose colord, how does our solution for Windows and OSX look like ?
 Does kolormanager work under Windows and OSX ?

Matthias answered your question very well, and I agree with him.
Let me ask you a return question;  with the heavy dependency on X11 in oyranos 
but with colord already starting work on wayland, how will we support wayland 
soon?
-- 
Thomas Zander

Re: Review Request: include KolorManager in kdegraphics

 The wiki page somebody pointed to mentioned that colord is linux-only, while 

 oyranos also works on Windows and OSX.
 
 If we chose colord, how does our solution for Windows and OSX look like ?
 Does kolormanager work under Windows and OSX ?
 The wiki page somebody pointed to mentioned that colord is linux-only, while
 oyranos also works on Windows and OSX.

 If we chose colord, how does our solution for Windows and OSX look like ?
 Does kolormanager work under Windows and OSX ?
Imagine you put your software on OSX with windows/oxygen style wouldn't it look 
awful?

To have your application properly integrated there you need to integrate a bit
deeper sometimes, a plugable layer might be nice to have? not sure, and this is 
not what
is being proposed by any of the discussed solutions.

Re: Review Request: include KolorManager in kdegraphics

2012-03-14 Thread Alexander Neundorf

On Wednesday 14 March 2012, Thomas Zander wrote:
 On Wednesday 14 March 2012 21.29.09 Alexander Neundorf wrote:
  The wiki page somebody pointed to mentioned that colord is linux-only,
  while  oyranos also works on Windows and OSX.
  
  If we chose colord, how does our solution for Windows and OSX look like ?
  Does kolormanager work under Windows and OSX ?
 
 Matthias answered your question very well, and I agree with him.
 Let me ask you a return question;  with the heavy dependency on X11 in
 oyranos but with colord already starting work on wayland, how will we
 support wayland soon?

I know basically nothing about color management systems.
Don't some applications needs some kind of interface to use the color 
management system ?
Or is it only for setting up X, the printer, Wayland, etc.

In the first case, if applications (e.g. krita) need some way to work with the 
color management system, wouldn't it be good if KDE provided one interface on 
all platforms ?

Alex

Re: Review Request: include KolorManager in kdegraphics


Am 14.03.12, 21:10 +0100 schrieb Thomas Zander:

On Wednesday 14 March 2012 18.12.13 Kai-Uwe Behrmann wrote:

Am 14.03.12, 17:46 +0100 schrieb Thomas Zander:

That said; Cups also depends on colord. And IMO that has a bigger impact
than the gnome components that pull it in.


colord print CM:
CUPS does not depend in any way on colord.


This opinion seems to conflict with the facts stated by others.  Debian for
instance has 'rec' (recommend) colord for cups.[1]


CUPS is a cross platform solution. It works with colour management on osX 
fine. IMO that recommendation on Debian has to do with colord in Gnome and 
that colord needs compiled in support inside CUPS. No more no less.



Notice that colord allows components to use it without linking it in at
startup using the dbus interface for instance.


That is non relevant to the fact, that CUPS vendor colour management works 
since years and without colord.



But colord depends on CUPS to
support it's concept of placing colord's session centric configuration
into each job on server side.


Which makes total technical sense. No color management system will work 100%


I still do not see merit in the user session in CUPS server hook concept.
I would really like to understand why it is a good design, but no one gave 
so far a satisfying answere on OpenICC. Maybe it can be found here?


Look at the details. colord is called inside CUPS server. CUPS servers can 
be remote without any DBus connection, which colord relies upon. The CUPS 
server is, well, a server, not client software. It takes print jobs 
through a well defined communication path after lots of security checks. 
Now colord breaks these security check on a local host and says to CUPS to 
use a certain ICC profiles. colord needs special rights to take the user
configuration from a central DB. As long as the actual user is printing a 
actual job with a actual colord profile it is fine. Laptop and one 
person systems might work this way. But imagine that now on a multi user 
system. A remote print jobs comes in. CUPS prints that with the profile of 
the local user. These users are likely not the same person or account. 
That is why the Oyranos project did reject the offer to place a similiar 
Oyranos hook inside CUPS and why it is criticised inside OpenICC without 
sufficient answeres.


The colord printing configuration architecture fits maybe to a one person 
system like Android, provided that it uses a direct connection to the 
actual printing device. Ironically Android does not allow for DBus.



without support in the individual components.  If Cups needs to be patched to
support a new feature, that sounds sane to me.


There is a half new feature. The other half cuts into existing well 
defined behaviour. Colour Management for vendor configured profiles 
resides inside CUPS since quite some years. The rastertoprinter 
filters do colour correction through the respective poppler and 
ghostscript filters. The CUPS CMS configures that fine. Again CUPS does 
not need colord to do robust CM. It looses robustnes through colord 
introduced ambiguity. See above.



Does it not make more sense to have color management support in cups than cups
support in the color management software? It certainly does to me :)


That sentence covers only part of the conditions needed to judge. See 
above.



It does not scale well and will likely be difficult to maintain.

As someone that is also a software developer, I disagree, with the reasons I
wrote above. :-)


My impression is, here are made assumptions that are based on abstract 
ideas, which do only in parts fit to the situation. That is irritating.



Bottom line for me really is that a project that has been around for a year
has managed to grow fast and get accepted widely.
Some may argue thats because of political issues, but in the end thats not
really relevant. The end result is still 'market' acceptance.

As mentioned before, accepting kolormanager in kdegraphics is kind of a no
to colord. And I think thats would be cutting our own fingers.


You are broadly speculating. May I ask for what reason?


1) http://packages.debian.org/wheezy/cups
--
Thomas Zander



regards
Kai-Uwe Behrmann
--
http://www.oyranos.org

Re: Review Request: include KolorManager in kdegraphics


Am 14.03.12, 21:29 +0100 schrieb Alexander Neundorf:

On Wednesday 14 March 2012, Thomas Zander wrote:

On Wednesday 14 March 2012 18.12.13 Kai-Uwe Behrmann wrote:

Am 14.03.12, 17:46 +0100 schrieb Thomas Zander:

On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote:

Colord - just to mention that - is also not a GNOME project, it's a
FreeDesktop project. (Doesn't mean it's standard, but does mean
that it's not GNOME)


Well, no, having something on freedesktop.org doesn't mean it's not a
gnome project;


Little semantic confusion here :)
He said it *IS*  a freedesktop project.  Which means it is not a gnome
project, which seems to me to be true.


It was developed specifically for Gnome Color Manager and then turned
into a Glib depending library. So it bears all the specifics in it's
concept.


Notice I still maintain that we should judge a solution on merit, not on
who pushes it.


That said; Cups also depends on colord. And IMO that has a bigger
impact than the gnome components that pull it in.


colord print CM:
CUPS does not depend in any way on colord.


This opinion seems to conflict with the facts stated by others.  Debian for
instance has 'rec' (recommend) colord for cups.[1]
Notice that colord allows components to use it without linking it in at
startup using the dbus interface for instance.


But colord depends on CUPS to
support it's concept of placing colord's session centric configuration
into each job on server side.


Which makes total technical sense. No color management system will work
100% without support in the individual components.  If Cups needs to be
patched to support a new feature, that sounds sane to me.
Does it not make more sense to have color management support in cups than
cups support in the color management software? It certainly does to me :)


It does not scale well and will likely be difficult to maintain.


As someone that is also a software developer, I disagree, with the reasons
I wrote above. :-)

Bottom line for me really is that a project that has been around for a year
has managed to grow fast and get accepted widely.
Some may argue thats because of political issues, but in the end thats not
really relevant. The end result is still 'market' acceptance.

As mentioned before, accepting kolormanager in kdegraphics is kind of a
no to colord. And I think thats would be cutting our own fingers.


The wiki page somebody pointed to mentioned that colord is linux-only, while
oyranos also works on Windows and OSX.

If we chose colord, how does our solution for Windows and OSX look like ?
Does kolormanager work under Windows and OSX ?


The printing concept, which we discussed in OpenICC and which we are 
intessted to introduce into Oyranos / KolorManager are design to be cross 
platform. We think that is important as we work daily in heterogenous 
environments. So we need to rely on

A) CUPS doing the right thing in the right place. And CUP's own CM appears
   fine. We can adapt our behaviour to use it for vendor and in parts for
   user configured profiles.
B) or we rely on standards for print job transportation. PDF is choosen by
   Linux as print format. PDF/X-3 is a international standard providing
   print profile embedding. That is used by osX as well. And let me
   speculate for good reasons. It is cross platform.


Alex


kind regards
Kai-Uwe
--
http://www.oyranos.org

Re: Review Request: include KolorManager in kdegraphics


Am 14.03.12, 22:03 +0100 schrieb Alexander Neundorf:

On Wednesday 14 March 2012, Thomas Zander wrote:

On Wednesday 14 March 2012 21.29.09 Alexander Neundorf wrote:

The wiki page somebody pointed to mentioned that colord is linux-only,
while  oyranos also works on Windows and OSX.

If we chose colord, how does our solution for Windows and OSX look like ?
Does kolormanager work under Windows and OSX ?


Matthias answered your question very well, and I agree with him.
Let me ask you a return question;  with the heavy dependency on X11 in
oyranos but with colord already starting work on wayland, how will we
support wayland soon?


That might be a missconception. Oyranos core itself does link against 
libc, libxml2, yajl, libdl and depending on the availability to 
elektra/ltdl. The X11 device support comes inside a module. So you can 
select on osX X11 or ColorSync depending on your needs. Same will work out 
for a separate Wayland module once a spec is available to implement that.



I know basically nothing about color management systems.
Don't some applications needs some kind of interface to use the color
management system ?
Or is it only for setting up X, the printer, Wayland, etc.


It can do both. Provide profile lookup, options for rendering and defaults 
and device setup.



In the first case, if applications (e.g. krita) need some way to work with the
color management system, wouldn't it be good if KDE provided one interface on
all platforms ?


Oyranos has platform abstraction for two Linux/BSD and osX. We would be 
glad to add win32 support in the not too distant future and provide a 
similar crossplatform support like e.g. ArgyllCMS.



Alex


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

Re: Review Request: include KolorManager in kdegraphics

 I know basically nothing about color management systems.

 Don't some applications needs some kind of interface to use the color
 management system ?
 Or is it only for setting up X, the printer, Wayland, etc.

 In the first case, if applications (e.g. krita) need some way to work with the
 color management system, wouldn't it be good if KDE provided one interface on
 all platforms ?

Applications need a CMM, lcms2, AngryCMS, those libraries do the color 
correction,
the application has just to know 2 things*: Which profile the whole screen is 
using,
and which profiles are available that it could use. With this information it 
calls
what is best lcms2 or AngryCMS, be it on Windows/OSX... now imagine if
you are on Windows and there something conflicting there, which stack will
you trust the native one or a third part software?

*basically before someone kills me...
Best

Re: KDE at the next Qt Contributors' Summit

2012-03-14 Thread David Faure

On Wednesday 14 March 2012 21:00:32 Lydia Pintscher wrote:
 Heya folks,
 
 Is anyone taking care of KDE's presence at the next Qt Contributors'
 Summit? http://wiki.qt-project.org/Events/Qt_Contributors_Summit  If
 not it'd be really great if someone could step up. We should show up
 again. I don't have the time to help with the planning. I might
 however have a couch to crash on by that time for someone.

I'm pretty sure I'll be going.

(Too bad it's on 21/06, I usually play music on that day)

Thanks for your couch offer, but I have other options in Berlin :-)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5

Re: Bugzilla upgrade.

2012-03-14 Thread Burkhard Lück

Am Mittwoch, 14. März 2012, 20:13:18 schrieb Dawit A:
 Am I the only one that finds the new KDE bugzilla front end utterly
 confusing ? 

No, me too.

 All the conveient shortcuts in the front page that showed
 things like weekly summary broken down by product are no longer
 available. 

I really miss them.

And to have the Additional Comments field above the BR and all comments is 
like tofu (http://en.wikipedia.org/wiki/Top-posting#Top-posting)

The new front end / layout is really disturbing  for my daily workflow looking 
for all bugs related to documentation, i18n, l10n and reports I can quickly 
check in master/branch/my distribution packages reported the last day.. 

-- 
Burkhard Lück

Re: Bugzilla upgrade.

I don't think so, I think it has some huge icons but I thought
it was my browsers problem, the huge header and footer
it's real hard to see the content on my small screen,
the new version fews snappier but the theme needs polishing
imo. I also renders the footer strange using Chrome,
but I hope someone is still working on this... :D

2012/3/14 Dawit A ada...@kde.org:
 Am I the only one that finds the new KDE bugzilla front end utterly
 confusing ? All the conveient shortcuts in the front page that showed
 things like weekly summary broken down by product are no longer
 available. Will those things available in the old front page be
 restored in the future or are they gone for good ?

Re: Review Request: include KolorManager in kdegraphics

 I know basically nothing about color management systems.

 Don't some applications needs some kind of interface to use the color
 management system ?
 Or is it only for setting up X, the printer, Wayland, etc.

 In the first case, if applications (e.g. krita) need some way to work with the
 color management system, wouldn't it be good if KDE provided one interface on
 all platforms ?

Applications need a CMM, lcms2, AngryCMS, those libraries do the color 
correction,
the application has just to know 2 things*: Which profile the whole screen is 
using,
and which profiles are available that it could use. With this information it 
calls
what is best lcms2 or AngryCMS, be it on Windows/OSX... now imagine if
you are on Windows and there something conflicting there, which stack will
you trust the native one or a third part software?

*basically before someone kills me...
Best

Re: Review Request: include KolorManager in kdegraphics

2012/3/14 Kai-Uwe Behrmann k...@gmx.de:

 CUPS is a cross platform solution. It works with colour management on osX
 fine. IMO that recommendation on Debian has to do with colord in Gnome and
 that colord needs compiled in support inside CUPS. No more no less.
This sentence is hard to read but Recommends in Debian means recommends,
it is not required to run, so no there is no linking, no link by CUPS to colord 
and
no link by colord to CUPS. All DBus magic.

 Notice that colord allows components to use it without linking it in at
 startup using the dbus interface for instance.

 That is non relevant to the fact, that CUPS vendor colour management works
 since years and without colord.
It is indeed relevant because now we have a central place to configure it.

 But colord depends on CUPS to
 support it's concept of placing colord's session centric configuration
 into each job on server side.

 Which makes total technical sense. No color management system will work
 100%

 I still do not see merit in the user session in CUPS server hook concept.
 I would really like to understand why it is a good design, but no one gave
 so far a satisfying answere on OpenICC. Maybe it can be found here?

 Look at the details. colord is called inside CUPS server. CUPS servers can
 be remote without any DBus connection, which colord relies upon. The CUPS
 server is, well, a server, not client software. It takes print jobs through
 a well defined communication path after lots of security checks. Now colord
 breaks these security check on a local host and says to CUPS to use a
There is no security break, sorry, I know CUPS, CUPS is the one calling
an extra thing not the other way.

I'm not sure if this is what happens currently so I'm going to say what I would 
do:
First regular users don't touch /etc/cups/client.conf - The file that makes
your cups calls go away. They don't need that to talk to remote printers
CUPS is smart enough to talk to another CUPS over the network.
So a process that uses less than 1MB can just be installed on each Linux
machine (as is the case today).
If CUPS is locally installed this means it can just send the job color 
corrected!
Plain simple...

 The colord printing configuration architecture fits maybe to a one person
 system like Android, provided that it uses a direct connection to the actual
 printing device. Ironically Android does not allow for DBus.

I see no irony we do not target Android instead our users which lack CM.

Re: Review Request: include KolorManager in kdegraphics

2012-03-14 Thread Weng Xuetian

On Thu, Mar 15, 2012 at 12:46 AM, Thomas Zander zan...@kde.org wrote:
 On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote:
  Hi!
  Colord - just to mention that - is also not a GNOME project, it's a
  FreeDesktop project. (Doesn't mean it's standard, but does mean that
  it's not GNOME)

 Well, no, having something on freedesktop.org doesn't mean it's not a
 gnome project;

 Little semantic confusion here :)
 He said it *IS*  a freedesktop project.  Which means it is not a gnome
 project, which seems to me to be true.

 it is a gnome project, and it's widening its scope. The
 reason it's used at all is that is is used inside gnome.

 Projects should be judged on merit, irregardless of who pushes it.
 If gnome is using it and that makes it grow acceptance, thats a good thing in
 my book.  Why; *because* acceptance is growing. I don't care if its gnome or
 any other player pushing it.

 That said; Cups also depends on colord. And IMO that has a bigger impact than
 the gnome components that pull it in.

No, colord guys push CUPS to add API that they need, I thought that's
why CUPS depends on colord.

http://libregraphicsworld.org/blog/entry/richard-hughes-on-color-management-in-linux-and-gnome

Which oyranos don't like to, to be more concrete, use existing
protocol / interface.

No offense on both side. Just for more information.

Re: Review Request: include KolorManager in kdegraphics

2012/3/14 Kai-Uwe Behrmann k...@gmx.de:
 Am 14.03.12, 21:10 +0100 schrieb Thomas Zander:

 On Wednesday 14 March 2012 18.12.13 Kai-Uwe Behrmann wrote:

 Am 14.03.12, 17:46 +0100 schrieb Thomas Zander:
 That said; Cups also depends on colord. And IMO that has a bigger impact
 than the gnome components that pull it in.
 colord print CM:
 CUPS does not depend in any way on colord.

 This opinion seems to conflict with the facts stated by others.  Debian
 for
 instance has 'rec' (recommend) colord for cups.[1]

 CUPS is a cross platform solution. It works with colour management on osX
 fine. IMO that recommendation on Debian has to do with colord in Gnome and
 that colord needs compiled in support inside CUPS. No more no less.
No. Cups uses the Color Management system provided by the OS. On
MacOS-X it uses ColorSync, for example. Cups itself has a patch
included which makes it use colord DBus-API to talk to colord. That's
the reason for CUPS recommending colord on Debian.

 Notice that colord allows components to use it without linking it in at
 startup using the dbus interface for instance.
 That is non relevant to the fact, that CUPS vendor colour management works
 since years and without colord.
It does - on MacOS-X, because it uses ColorSync there :P

Regards,
   Matthias

 But colord depends on CUPS to
 support it's concept of placing colord's session centric configuration
 into each job on server side.
 Which makes total technical sense. No color management system will work
 100%


 I still do not see merit in the user session in CUPS server hook concept.
 I would really like to understand why it is a good design, but no one gave
 so far a satisfying answere on OpenICC. Maybe it can be found here?

 Look at the details. colord is called inside CUPS server. CUPS servers can
 be remote without any DBus connection, which colord relies upon. The CUPS
 server is, well, a server, not client software. It takes print jobs through
 a well defined communication path after lots of security checks. Now colord
 breaks these security check on a local host and says to CUPS to use a
 certain ICC profiles. colord needs special rights to take the user
 configuration from a central DB. As long as the actual user is printing a
 actual job with a actual colord profile it is fine. Laptop and one person
 systems might work this way. But imagine that now on a multi user system. A
 remote print jobs comes in. CUPS prints that with the profile of the local
 user. These users are likely not the same person or account. That is why the
 Oyranos project did reject the offer to place a similiar Oyranos hook inside
 CUPS and why it is criticised inside OpenICC without sufficient answeres.

 The colord printing configuration architecture fits maybe to a one person
 system like Android, provided that it uses a direct connection to the actual
 printing device. Ironically Android does not allow for DBus.


 without support in the individual components.  If Cups needs to be patched
 to
 support a new feature, that sounds sane to me.


 There is a half new feature. The other half cuts into existing well defined
 behaviour. Colour Management for vendor configured profiles resides inside
 CUPS since quite some years. The rastertoprinter filters do colour
 correction through the respective poppler and ghostscript filters. The CUPS
 CMS configures that fine. Again CUPS does not need colord to do robust CM.
 It looses robustnes through colord introduced ambiguity. See above.


 Does it not make more sense to have color management support in cups than
 cups
 support in the color management software? It certainly does to me :)


 That sentence covers only part of the conditions needed to judge. See above.


 It does not scale well and will likely be difficult to maintain.

 As someone that is also a software developer, I disagree, with the reasons
 I
 wrote above. :-)


 My impression is, here are made assumptions that are based on abstract
 ideas, which do only in parts fit to the situation. That is irritating.


 Bottom line for me really is that a project that has been around for a
 year
 has managed to grow fast and get accepted widely.
 Some may argue thats because of political issues, but in the end thats not
 really relevant. The end result is still 'market' acceptance.

 As mentioned before, accepting kolormanager in kdegraphics is kind of a
 no
 to colord. And I think thats would be cutting our own fingers.


 You are broadly speculating. May I ask for what reason?


 1) http://packages.debian.org/wheezy/cups
 --
 Thomas Zander


 regards
 Kai-Uwe Behrmann
 --
 http://www.oyranos.org

Re: Review Request: include KolorManager in kdegraphics

On Wednesday 14 March 2012 Mar, Alexander Neundorf wrote:
 On Wednesday 14 March 2012, Thomas Zander wrote:
  On Wednesday 14 March 2012 21.29.09 Alexander Neundorf wrote:
   The wiki page somebody pointed to mentioned that colord is linux-only,
   while  oyranos also works on Windows and OSX.
   
   If we chose colord, how does our solution for Windows and OSX look like ?
   Does kolormanager work under Windows and OSX ?
  
  Matthias answered your question very well, and I agree with him.
  Let me ask you a return question;  with the heavy dependency on X11 in
  oyranos but with colord already starting work on wayland, how will we
  support wayland soon?
 
 I know basically nothing about color management systems.

Well, that's true for nearly everyone in this discussion. It's not a discussion 
based on facts, it's a discussion based on impressions, guesses, hunches and 
misconceptions. 

 Don't some applications needs some kind of interface to use the color 
 management system ?

Yes. Right now, the only interface Krita uses is the X11 atom to set the 
monitor profile, and for the rest, we let people select profiles from disk. 
This is very limited. We're not interested yet in printing or scanning, but 
once that comes we need to talk to the platform color management system 
directly.

Unless there is something cross-platform that we can talk to instead. That's 
worth any amount of dependencies in my book.

 Or is it only for setting up X, the printer, Wayland, etc.
 
 In the first case, if applications (e.g. krita) need some way to work with 
 the 
 color management system, wouldn't it be good if KDE provided one interface on 
 all platforms ?

That is definitely true. If oyranos papers over the differences between the 
Linux, Windows and OSX color management systems, that is absolutely fantastic. 
I don't want to write my own abstraction library to query colorsync, colord and 
so on.

I actually started doing that last year, in fact, and then decided not to 
continue. It was when I tried to implement colord support during LGM, and 
figured that I'd need to implement similar support on Windows and OSX since my 
cross-platform app now was using platform-dependent things.

-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl

Re: Review Request: include KolorManager in kdegraphics

Em Wednesday 14 March 2012, Daniel Nicoletti escreveu:
 2012/3/14 Kai-Uwe Behrmann k...@gmx.de:
  CUPS is a cross platform solution. It works with colour management on osX
  fine. IMO that recommendation on Debian has to do with colord in Gnome
  and that colord needs compiled in support inside CUPS. No more no less.
 
 This sentence is hard to read but Recommends in Debian means recommends,
 it is not required to run, so no there is no linking, no link by CUPS to
 colord and no link by colord to CUPS. All DBus magic.

Debian applies a patch to add colord support to cups, that is what Kai-
Uwe is talking about. Cups itself does not require colord, so it cannot be 
used in favor of colord.
 
  Notice that colord allows components to use it without linking it in at
  startup using the dbus interface for instance.
  
  That is non relevant to the fact, that CUPS vendor colour management
  works since years and without colord.
 
 It is indeed relevant because now we have a central place to configure it.

As long as you patch cups and all other applications to use. Oyranos is 
also a central place to do color management as far as I know, this argument is 
valid for both.
 
-- 
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br

Re: Review Request: include KolorManager in kdegraphics


As long as you patch cups and all other applications to use. Oyranos is also a 
central place
 to do color management as far as I know, this argument is valid for both.

It is valid once it's written, once there is a line of code doing it's job. Or 
we can just play politics.
You say you want the best one, have you tried them both?

Re: Review Request: include KolorManager in kdegraphics

Em Wednesday 14 March 2012, Daniel Nicoletti escreveu:
 As long as you patch cups and all other applications to use. Oyranos is
 also a central place
 
  to do color management as far as I know, this argument is valid for both.
 
 It is valid once it's written, once there is a line of code doing it's job.
 Or we can just play politics. You say you want the best one, have you
 tried them both?

So you are saying your original argument is not valid anymore?

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.

And no, I have not tested either of them and how computer color 
management is supposed to work for a daltonian (like me)? Even if I had tested 
by what everybody already said here, nobody is an expert in color managament 
to judge the merits of either project, so let's add support to both. As I 
wrote before, as long as the project has a community to maintain it, I do not 
see why not use it.

-- 
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br

Re: Review Request: include KolorManager in kdegraphics

 So you are saying your original argument is not valid anymore?
Where is the Oyranos CUPS patch? All I see is a planning since as
far as I can tell he didn't decide the best way to do it, OTOH we have
something that already works for a bunch of people.

 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 never said a word on dropping Oyranos development, but I do believe from
a technological point of view it hasn't succeed in all these years. We now
have telepathy. Who will be willing to keep kopete which has far more years
than even Oyranos in favor of a nicer user experience? Or even dolphin why
stop using konqueror file management when a file driven experience has come
in place?

 And no, I have not tested either of them and how computer color management
 is supposed to work for a daltonian (like me)? Even if I had tested by what
 everybody already said here, nobody is an expert in color managament to
 judge the merits of either project, so let's add support to both. As I wrote
 before, as long as the project has a community to maintain it, I do not see
 why not use it.
Surely even daltonians would like to see on their computers colors more
close to reality, I don't see why this have to be different if you are 
daltonian or not.
I don't believe anyone needs to be a color expert to tell which is best, we
are developers we know development if you need to maintain a piece of software
what matters is your development skills. I can't maintain a complex piece
of software few people understand.

Best.

Re: Review Request: include KolorManager in kdegraphics

Speaking of project activity:
= https://www.ohloh.net/p/colord
= https://www.ohloh.net/p/oyranos
Of course there metrics are unfair to both projects (metrics always
are), but they might provide some information about activity,
contributors and codebase. (although I don't think we should pay too
much attention on these)

2012/3/15 Lamarque V. Souza lamar...@kde.org:
 Em Wednesday 14 March 2012, Daniel Nicoletti escreveu:

 As long as you patch cups and all other applications to use. Oyranos is

 also a central place

 

  to do color management as far as I know, this argument is valid for
  both.



 It is valid once it's written, once there is a line of code doing it's
 job.

 Or we can just play politics. You say you want the best one, have you

 tried them both?



 So you are saying your original argument is not valid anymore?



 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.



 And no, I have not tested either of them and how computer color management
 is supposed to work for a daltonian (like me)? Even if I had tested by what
 everybody already said here, nobody is an expert in color managament to
 judge the merits of either project, so let's add support to both. As I wrote
 before, as long as the project has a community to maintain it, I do not see
 why not use it.



 --

 Lamarque V. Souza

 KDE's Network Management maintainer

 http://planetkde.org/pt-br

Re: Review Request: include KolorManager in kdegraphics

Em Wednesday 14 March 2012, Daniel Nicoletti escreveu:
  So you are saying your original argument is not valid anymore?
 
 Where is the Oyranos CUPS patch? All I see is a planning since as
 far as I can tell he didn't decide the best way to do it, OTOH we have
 something that already works for a bunch of people.

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

 I never said a word on dropping Oyranos development, but I do believe from
 a technological point of view it hasn't succeed in all these years. We now
 have telepathy. Who will be willing to keep kopete which has far more years
 than even Oyranos in favor of a nicer user experience? Or even dolphin why
 stop using konqueror file management when a file driven experience has come
 in place?

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.
 
  And no, I have not tested either of them and how computer color
  management is supposed to work for a daltonian (like me)? Even if I had
  tested by what everybody already said here, nobody is an expert in color
  managament to judge the merits of either project, so let's add support
  to both. As I wrote before, as long as the project has a community to
  maintain it, I do not see why not use it.
 
 Surely even daltonians would like to see on their computers colors more
 close to reality, I don't see why this have to be different if you are
 daltonian or not. I don't believe anyone needs to be a color expert to
 tell which is best, we are developers we know development if you need to
 maintain a piece of software what matters is your development skills. I
 can't maintain a complex piece of software few people understand.

You tell me, I do not know how to test color management. How did you 
test colord for instance? You are saying colord is best based on your personal 
use of color management (and the number of colord users, which is mandatory 
for Gnome3 by what I know). Have you ever considered that your personal use is 
not what other users of color management software need? I am maintaining a 
complex piece of software few people (fully) understand.

-- 
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br

Re: Review Request: include KolorManager in kdegraphics

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.

Re: Review Request: include KolorManager in kdegraphics

2012-03-14 Thread Sven Langkamp

On Wed, Mar 14, 2012 at 12:53 PM, Boudewijn Rempt b...@valdyas.org wrote:

 On Wednesday 14 March 2012 Mar, Daniel Nicoletti wrote:
   Request:
 
   After working on KolorManager and Oyranos in the past months for the
 last
   Oyranos-0.4.0 release, we feel the stack is ready to review for
 inclusion into
   KDE.
   KolorManager resides currently in Playground/Graphics:
   http://quickgit.kde.org/?p=kolor-manager.gita=summary
 
  Just a quick question, currently we have two CMS stacks, colord and
  oyranos, while
  I have nothing against having two of them in KDE, I wonder if this
  would become
  a problem for colord-kde [1] to enter in kdegraphics too?

 There should be only one.

  In that case
  would be better
  to both go to kdeextragear or is there some different policy in this
 case?

 No. There should be color management by default in KDE, that's really
 important; and there should be only one solution by default. We shouldn't
 let distributions, or even worse, users decide which solution they use.
 That way madness lies. KDE's Color management solution shouldn't be in
 extragear.


Distribution shouldn't decide that, but I think they will do it. If Fedora
and Ubuntu both push colord, then it will practically become the standard,
no matter which one is actually better. From past experience it's more than
likely that they would patch it otherwise. Beside if e.g. Krita is running
under Gnome it would have to interact with colord.

This could become the next Betamax vs VHS. My feeling is that colord
currently is on the way to win this, as it backed by more projects.

 As to which one is selected, there are a couple of ways to decide.

 The first is, first come, first go. Kolormanager has been in development
 for quite some time now, and colord is an upstart, gnome-derived
 technology. Integration of colord in kde was only started very recently.
 Everyone is free to start a competing project, even inside KDE, but to make
 that project block a pre-existing project isn't the way to go.


Well it's not nice, but it happened before e.g. DBUS/DCOP or telepathy.
Still it's sad what happened here.


 The second way to decide would be on technical merits. I'm not going to go
 into that discussion; I've seen too many tiresome discussions already, and
 I don't feel really competent anyway.


As can be observed in this thread both solutions have some advantages and
disadvantages. They are hardly comparable and we have no experts to look
into this.


 For me as an application developer, life sucks anyway, since I have to
 support Linux, Windows and OSX, so for the time being, the application will
 offer its own way to select profiles, in addition to using the X11 display
 atom that both colord and kolormanager support. (And I don't want to think
 about printing anyway.)

Re: Review Request: include KolorManager in kdegraphics

2012-03-14 Thread 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

signature.asc
Description: This is a digitally signed message part.

Re: Review Request: include KolorManager in kdegraphics

Em Wednesday 14 March 2012, Daniel Nicoletti escreveu:
 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 did not know about that problem with Apple. That's going to be a big 
problem for Linux users.
 
   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).

Like I also help with Wicd support in KDE, Kopete, and other areas of 
interests for KDE users. I do not use Wicd, but I help KDE users of Wicd even 
before I was the Network Management maintainer. By the way, I am not driven by 
FDO interests. We are using upower/udisks because there is no other choice in 
Linux, hal is unmaintained as you probably know. That is why I think we should 
have a community to maintain the software we depend upon.
 
 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?

That's too personal oppinion and you sound like nobody likes oyranos.
 
 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.

I have never used PackageKit and said nothing about it. Are you talking 
about PakcageKit or colord here? If it is about Gnome without colord I am not 
sure if that is possible, anyway, why would they patch cups to add support to 
colord if it is not going to be used in the desktops? Users can help with 
patches from time to time, that is important, and I was only a Knetworkmanager 
user before I started to contribute. Your statement is completely wrong in an 
opensource world.

-- 
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br

Re: Review Request: include KolorManager in kdegraphics

Like I also help with Wicd support in KDE, Kopete, and other areas of 
interests for KDE users. I do not use Wicd, but I help KDE users of Wicd even 
before I was the Network Management maintainer. By the way, I am not driven by 
FDO interests. We are using upower/udisks because there is no other choice in 
Linux, hal is unmaintained as you probably know. That is why I think we should 
have a community to maintain the software we depend upon.

Right so which community you are talking about, because
Kai likes KDE, it seems that you are putting FDO/Gnome as things we should
get away, instead of actually looking at how maintainable these two things are
and yet share code which is really important.

 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?
 
That's too personal oppinion and you sound like nobody likes oyranos.

It's a personal opinion indeed but this doesn't mean nobody likes Oyranos,
it simply means that looking at the code there won't be much devs willing
to maintain that. The deps speak for themselves. 


 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.
 
If it is about Gnome without colord I am not sure if that is possible, anyway, 
why would they patch cups to add support to colord if it is not going to be 
used in the desktops?

Gnome works pretty much the same way as KDE we have modules, so the do,
you can just remove/disable and Gnome will run without it, but why remove
a cool feature? It's non sense, it's obvious that every distro would push 
because
they want the missing feature, if Oyranos was there first maybe colord didn't 
had
to exist.


I have never used PackageKit and said nothing about it. Are you talking about 
PakcageKit or colord here? Users can help with patches from time to time, that 
is important, and I was only a Knetworkmanager user before I started to 
contribute. Your statement is completely wrong in an opensource world.


You don't get it, I'm giving an example of how good projects dies because
from a technical point of view they become unmaintainable.
Sure, pretty much everyone is first an user then a developer but this doesn't 
mean
you can expect from users of a software to maintain that, otherwise most of 
these
projects wouldn't go into an end.

Re: Review Request: include KolorManager in kdegraphics