[GSoC] KWin colour management

[Thomas Lübking]

Am 23.03.2012, 06:27 Uhr, schrieb Kai-Uwe Behrmann <ku.b at gmx.de>:

> Where would be a competing system on Linux?
Well, I certainly did not read all of that "colord ./. oyranos" flamewar  
on k-c-d where supporters of either basically tagged the other like  
incapable and/or irrelevant s..tufff, but I as certain did not dream about  
it.

So while this might just have been kindergarten s...tuff about "xyz uses  
mono and we hate mono", I was under the impression that those were  
conflicting approaches to CM.

If it indeed only is about implementation details on the very same  
protocol, thus whether colord or oyranos is in use does absolutely not  
make any difference regarding the compositor, I wish apologize and  
withdraw that particular concern.



>> screen actually could do WG ... but the delete icon in dolphin looks  
>> correct?
> That is correctly described and expected behaviour as developers said.

Ok, so let me please complete my former question by its implications:
"Does that actually mean that if I have a WG screen and an application  
which does not support the opt-out protocol [...], it will be reduced to  
sRGB while the application and the screen actually could do WG ..."
... unless I suspend compositing or switch to another window manager what,  
because I'm just a user and don't know what a window manager is, likely  
means to switch to another DE, because "it just works" on - let's say -  
"Trinity"?

> We discussed that with Wayland people and the last spec revision was
> adapted to meet their concerns. So the transition from X Color
> Management to W(ayland) Color Management should be relativele smooth.
>
> http://lists.freedesktop.org/archives/openicc/2012q1/004595.html
> http://www.oyranos.org/2012/02/x-color-management-0-4-draft1

Many thanks.
But that seams clearly away from per-region opt-out but into per-window  
opt-out, doesn't cover different screens anyway and require toolkits "to  
colour correct the whole window" what -if did not terribly misunderstood-  
also means that if Qt & Gtk+ support such, but TCL/TK does not (just  
examples here), the result would be that w/ or w/o a color correcting  
compositor, my Qt & Gtk apps just work fine whereas my very important  
professional offset print preview "POPP" (tm) tool written in TCL/TK only  
works WITHOUT such compositor (because the canvas is corrected internally  
and the buttons are all gray anyway) and fails with one.

Is that correct?

Cheers,
Thomas