[GSoC] KWin colour management

[Thomas Zander]

On Wednesday 21 March 2012 20.34.00 Martin Gräßlin wrote:
> > Personally I would not make inclusion of code a pre condition for the
> > success of such a project. Upstream inclusion of code is a high goal for
> > contributors anywhere. Not many GSoC projects reach that immediately.
> 
> If you don't aim for inclusion into KWin, I seriously do not see why such
> a  project is needed. Given the changes inside KWin I doubt any of the
> code could be reused let's say a year later.

Thats a very good point, one that may not be quick to grasp by potential gsoc 
students.  This point should be made very clear otherwise I fear people might 
get very dissapointed if their work ends up being discarded. Discarded because 
the initial setup wasn't thought through.

I would say that the core aim of the GSOC project should be inclusion in kwins 
tree for any KDE people to spent any time on this or even support it.  
Otherwise it would be unfair to various people. Like the student and the 
hosting org and also to the kde volunteers helping with it.
 
> > > 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 ;-)

Color management in Qt is a bit of a weird statement; first of all, support is 
already possible as Krita proves.  Second, I doubt that 94% of the widgets 
actually need color correction of the type that kwin could provide. Who cares 
that their text edits and their buttons are color correct? 
Its only for canvas-like widgets that this is relevant, and apps have that 
option already by linking to LCMS. 
So, KWin support would just be a shortcut. A one-stop solution to make all 
apps suddenly get sunglasses on.  It certainly is not a 'proper' solution, its 
a shortcut. So please keep treating it as such.

When people talk about the toolkit adding support its more about convenience 
APIs. Think a QPainter method to set a color transform to do correction on 
following draws.
When people want support in the toolkit, they want the color selector widget, 
the print preview widget etc, that come with Qt to natively use the monitor 
profile.
Last, they want the printing to take color management into account.

All of those are possible and likely even welcomed in Qt.   The only thing is 
that someone has to actually do it.  So saying that it won't happen in Qt6 is 
a self-fulfilling wish, and I feel its not very fair to plant that doubt in 
peoples minds.

> > What would KWin people suggest how and where to place this feature near
> > KWin?
> 
> Well the question is whether such a feature is needed at all. I would say:
> * either correct the whole screen
> * or let the windows handle it
> 
> Now it becomes quite simple: there's an app doing color correction itself.
> In  that case we can safely assume that the user wants the app to take
> care - compositor does no longer color correct the screen.
> 
> There is no application taking care of it: compositor renders the whole 
> screen.

Sounds good to me.
-- 
Thomas Zander