[Development] Color Profile support on Qt

alexandros.dermenakis at nokia.com alexandros.dermenakis at nokia.com
Thu Aug 2 13:04:37 CEST 2012


I reverted the patch as requested. The change id is : Ic4a420d6ad0995810ed61d31edd28e7b603cca5e

I also created a clone of qtbase repository on gitorious. the link for that is https://qt.gitorious.org/~alexandrosdermenakis/qt/qtbase-colorprofiles

Alex
________________________________________
From: development-bounces+alexandros.dermenakis=nokia.com at qt-project.org [development-bounces+alexandros.dermenakis=nokia.com at qt-project.org] on behalf of Sletta Gunnar (Nokia-MP/Oslo)
Sent: Thursday, August 02, 2012 11:16 AM
To: Tvete Paul (Nokia-MP/Oslo)
Cc: development at qt-project.org
Subject: Re: [Development] Color Profile support on Qt

On Aug 2, 2012, at 10:58 AM, ext Paul Olav Tvete wrote:

> On Thursday 02 August 2012 10:31:59 ext Olivier Goffart wrote:
>> If that's only a documentation problem, we can workaround that with some
>> macro  magic.
>
> Very good point. For some reason I thought we would have to hack on qdoc itself,
> but creative use of \fn and \internal should be enough.

#ifdef QDOC

can also be used to hide functions from the documentation.

>
>> Should that even go in the constructor? Maybe QImage::setColorProfile.
>
> The problem with that is that it is not clear from the name whether it converts
> the image data to the new profile, or just overrides the profile. Also,
> overriding the profile is really just needed for specifying the profile when
> constructing the image.
>
>> On the other side, if we add it now, and realize this should not be pointer,
>> or should not be even in QImage. Then it is too late to change.
>
> Those are good points. Of course we could still add new constructors, and use
> qdoc magic to hide the pointer argument in that case :)
>
> The only other point I can see is saving 6 extra exported symbols in Qt 5.1, and
> I realize that that's not a very strong argument.
>
> TL;DR: I will not disagree if the consensus is to revert the change.

I say revert. We don't bind ourselves to potential future API.

>
> - Paul
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



More information about the Development mailing list