This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323584-42682900-1332440341=:8311 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: Am 22.03.12, 18:41 +0100 schrieb Thomas Lübking: > Am 22.03.2012, 08:55 Uhr, schrieb Kai-Uwe Behrmann : > >> Lets hypothetical assume some effort is initiated to bring CM to Qt and >> that happens during Qt 5 life time. The new design says by default all >> content is considered sRGB, which is by itself reasonable. However >> existing applications will initially not know about that changed >> convention. > Errrmmm... how is that please different from opting out of the compositor? > Except that latter does not only hit Qt applications but also *every* > "legacy" stuff around? I was tould by the graphics community to keep the X Color Management spec backward compatible with the ICC Profile in X spec, so we did. Thus old style applications see a sRGB profile through the ICC Profile in X spec, and they continue to work by converting to sRGB. >> The conflict is solveable by making the new drawing API incompatible with >> the old one, e.g. requiring a colour space argument. > Or by making user code color correction calls (QApplication::setColorSpec(int > spec)?) invalidate/override library settings? Something like that is technical possible. But let me repeat, you get then a mixture of colour managed and non colour managed apps with the same toolkit, which is completely non understandable for users. kind regards Kai-Uwe Behrmann -- www.oyranos.org --8323584-42682900-1332440341=:8311--