From kde-core-devel Fri Mar 23 16:10:35 2012 From: =?utf-8?Q?Thomas_L=C3=BCbking?= Date: Fri, 23 Mar 2012 16:10:35 +0000 To: kde-core-devel Subject: Re: Re: Re: [GSoC] KWin colour management Message-Id: X-MARC-Message: https://marc.info/?l=kde-core-devel&m=133251913032710 Am 23.03.2012, 06:27 Uhr, schrieb Kai-Uwe Behrmann : > 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