Am 22.03.12, 07:34 +0100 schrieb Martin Gräßlin:
On Thursday 22 March 2012 07:02:27 Kai-Uwe Behrmann wrote:
Am 21.03.12, 20:34 +0100 schrieb Martin Gräßlin:
Do you have any references showing that it is impossible to add color
correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't
base
technical decisions on "my feeling says".
That would mean colour management appears earliest inside Qt 6. But it is
at the moment not clear if that happens at all.
Any proof for these bold statements? Anything from Qt where I can see that
this is the case (also for Wayland)? Remember nobody wants to develop for
X
anymore ;-)
As we discuss a equivalent of colour management in KWin, we talk about
default colour management of all displayed Qt widgets. That is a high goal
and likely coming with some API changes. Such changes need quite some
preparation.
What signs are visible that with the first release of Qt 5 will have full
CM? Even if people would put CM now high on the Qt develpers or similar
agendas, CM will likely not get included soon to be ready for the first
Qt 5 release. Then logically the next feature window is Qt 6.
Sorry but I don't follow that logic. Just because it won't make it into 5.0
(which is impossible) does not mean that it won't enter any 5.x release.
And that's what I asked for: is there any reference stating that it won't be
possible to add CM to Qt in the lifetime of Qt 5?
Here my thoughts, why I think CM in Qt is not easily introduced during a
minor Qt 5 release. [Preparation of CM for Qt 6 is a different story.]
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. There is currently no API to know that. They will play
freestyle as before and colour correct to monitor space without knowing
how to tell anything to Qt. These old style apps will colour correct to
monitor and Qt will colour correct from sRGB to monitor as Qt does not
better know. That is called double colour correction and would be a real
design bug.
The conflict is solveable by making the new drawing API incompatible with
the old one, e.g. requiring a colour space argument. An other way is
verbally declaring sRGB as the default colour space in Qt, which would be
a major API change as well and only reasonable possible during major
version change.
Both is not easy before Qt 5. After the fist Qt 5 release a new drawing
API could theoretically be introduced in parallel to the old one. But old
Qt apps would then look inconsistent compared to ones using the new API.
Not sure if that transition path would be a good option regarding code
complexity. IMO best would be to wait for Qt 6 and then switch completely.
kind regards
Kai-Uwe Behrmann
--
www.oyranos.org
