Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats
On Fri, Nov 8, 2013 at 8:45 AM, Rutledge Shawn shawn.rutle...@digia.com wrote: Still, I don't see a good reason to try to avoid making it available on the other platforms. I agree. As long as we ensure that when the library is missing, the ability to decode the larger versions of the icons is missing (or the ability to decode the icons at all is missing), and that doesn't cause any other problems at runtime, is there any other reason not to have it available? Agreed, again. The code already handles this case. It checks for the presence of the jp2k Qt image format plugin, and only then will it attempt to decode the larger sized representations of the icon. It's not like we'd have to include the JPEG2000 decoder source with Qt, just have the ability to detect the library and compile the plugin only if it's there, right? That's how I'm imagining it working as well. No 3rdparty source tree needs to be bundled (it isn't bundled in qt-solutions either, at the moment) - but link against the JasPer lib if it's present on the system, or JASPER_CFLAGS and JASPER_LIBS are specified to configure (or however we want it to function). Mikkel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
On 8 November 2013 10:01, Yves Bailly yves.bai...@sescoi.fr wrote: As a float is 4 bytes, I would expect the second f.pos() to display 4... but it displays 8, as if QDataStream had moved 8 bytes ahead instead of just 4. Needless to say, the read float is wrong... Am I missing something here, or is it a bug? See QDataStream::setFloatingPointPrecision. The default is double. HTH, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
Le 08/11/2013 10:05, Giuseppe D'Angelo a écrit : On 8 November 2013 10:01, Yves Bailly yves.bai...@sescoi.fr wrote: As a float is 4 bytes, I would expect the second f.pos() to display 4... but it displays 8, as if QDataStream had moved 8 bytes ahead instead of just 4. Needless to say, the read float is wrong... Am I missing something here, or is it a bug? See QDataStream::setFloatingPointPrecision. The default is double. That's pretty strange... what if I want to read a float then a double? do I have to switch between the two each time? Does this means it's impossible to use code like this: float f; double d; datastream f d; ? -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
Am 08.11.2013 10:15, schrieb Yves Bailly: Le 08/11/2013 10:05, Giuseppe D'Angelo a écrit : On 8 November 2013 10:01, Yves Bailly yves.bai...@sescoi.fr wrote: As a float is 4 bytes, I would expect the second f.pos() to display 4... but it displays 8, as if QDataStream had moved 8 bytes ahead instead of just 4. Needless to say, the read float is wrong... Am I missing something here, or is it a bug? See QDataStream::setFloatingPointPrecision. The default is double. That's pretty strange... what if I want to read a float then a double? do I have to switch between the two each time? Does this means it's impossible to use code like this: float f; double d; datastream f d; ? setFloatingPointPrecision does only change the way the floating point numbers are stored in the data stream, not what you read from it. Also I think you're wrong in what you want to do. You can't read data from a file which was not stored with QDataStream before! See http://qt-project.org/doc/qt-5.0/qtcore/qdatastream.html#details Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
On 08 Nov 2013, at 10:15, Yves Bailly yves.bai...@sescoi.fr wrote: Le 08/11/2013 10:05, Giuseppe D'Angelo a écrit : See QDataStream::setFloatingPointPrecision. The default is double. That's pretty strange... what if I want to read a float then a double? do I have to switch between the two each time? Does this means it's impossible to use code like this: float f; double d; datastream f d; QDataStream stores your content in a portable binary format. Specifying the floating point precision makes it clear that real numbers, be them represented in floats or doubles in C++, are stored as floats or doubles in file. If you want to store a float as a float, and then a double as a double, you need to change the precision of QDataStream in between calls. Plus, the code that reads the file must match the code that wrote the stream. Andreas ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
Le 08/11/2013 10:29, Christian Ehrlicher a écrit : Am 08.11.2013 10:15, schrieb Yves Bailly: Le 08/11/2013 10:05, Giuseppe D'Angelo a écrit : On 8 November 2013 10:01, Yves Bailly yves.bai...@sescoi.fr wrote: As a float is 4 bytes, I would expect the second f.pos() to display 4... but it displays 8, as if QDataStream had moved 8 bytes ahead instead of just 4. Needless to say, the read float is wrong... Am I missing something here, or is it a bug? See QDataStream::setFloatingPointPrecision. The default is double. That's pretty strange... what if I want to read a float then a double? do I have to switch between the two each time? Does this means it's impossible to use code like this: float f; double d; datastream f d; ? setFloatingPointPrecision does only change the way the floating point numbers are stored in the data stream, not what you read from it. Sorry but this seems wrong to me... as soon as I used setFloatingPointPrecision(SinglePrecision), magically I can read the floats correctly. So setFloatingPointPrecision() *also* changes the way numbers are read. Also I think you're wrong in what you want to do. You can't read data from a file which was not stored with QDataStream before! See http://qt-project.org/doc/qt-5.0/qtcore/qdatastream.html#details I can understand this for high-level Qt objects, but what about lower-level data? Does this mean I can't use QDataStream to read a file written by some other program, and/or can't use it to *write* a file which could be read back by some other program? Again, only using low-level data, ints, floats, and so on. If that is true, then it's a huge step backward in the ease of use provided by Qt in the realm of reading/writing binary files. Just to give a context, the goal here is to read and write binary STL (stereolithography) or PLY files. I have old Qt3 code which works like a charm, reading and writing files usable to and from other soft (e.g. Blender). Now moving that old code to Qt5 it seems to not work as expected, despite using only basic, low-level data types. -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
Christian Ehrlicher schreef op 8-11-2013 10:29: Am 08.11.2013 10:15, schrieb Yves Bailly: Le 08/11/2013 10:05, Giuseppe D'Angelo a écrit : On 8 November 2013 10:01, Yves Bailly yves.bai...@sescoi.fr wrote: As a float is 4 bytes, I would expect the second f.pos() to display 4... but it displays 8, as if QDataStream had moved 8 bytes ahead instead of just 4. Needless to say, the read float is wrong... Am I missing something here, or is it a bug? See QDataStream::setFloatingPointPrecision. The default is double. That's pretty strange... what if I want to read a float then a double? do I have to switch between the two each time? Does this means it's impossible to use code like this: float f; double d; datastream f d; ? setFloatingPointPrecision does only change the way the floating point numbers are stored in the data stream, not what you read from it. Also I think you're wrong in what you want to do. You can't read data from a file which was not stored with QDataStream before! See http://qt-project.org/doc/qt-5.0/qtcore/qdatastream.html#details That sounds very unlikely. It would mean that you cannot use symetric code for reading and writing data: //writing float f(3.14159); double d(2.71828); datastream f d; //reading, would not work according to Christian float f; double d; datastream f d; //would not work according to you //reading, according to Christian float f; double df, d; datastream df d; f = static_castfloat(d); I'm quite sure that you _can_ use the symetric (first) version. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats
From what I can see, though, the real blocker here is the JasPer dep. I wholeheartedly agree that including JasPer as a dependency just for an icon engine seems like a rather insane requirement. But if there Yes, and that's why I asked if it was relevant for OSX only, since then I believe the dependency to JasPer wouldn't be necessary then. But regardless of that, I realize that it is better to just depend on the jp2k image plugin. That plugin might depend on JasPer or not (on Mac it can probably be done differently if people feel there is a good reason for it). (Also, it's worth noting that the JP2K image format is not a hard dependency. For many use cases, including mine, displaying a small icon in a dropdown or list view might be sufficient - and the JP2K image format might not be needed at all. In fact, I'm not even building the JP2K image format myself at present - I only display the small variants of the .icns.) True, I didn't think about that. Jan Arve Sæther ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
Yves Bailly schreef op 8-11-2013 10:42: Le 08/11/2013 10:29, Christian Ehrlicher a écrit : Am 08.11.2013 10:15, schrieb Yves Bailly: Le 08/11/2013 10:05, Giuseppe D'Angelo a écrit : On 8 November 2013 10:01, Yves Bailly yves.bai...@sescoi.fr wrote: As a float is 4 bytes, I would expect the second f.pos() to display 4... but it displays 8, as if QDataStream had moved 8 bytes ahead instead of just 4. Needless to say, the read float is wrong... Am I missing something here, or is it a bug? See QDataStream::setFloatingPointPrecision. The default is double. That's pretty strange... what if I want to read a float then a double? do I have to switch between the two each time? Does this means it's impossible to use code like this: float f; double d; datastream f d; ? setFloatingPointPrecision does only change the way the floating point numbers are stored in the data stream, not what you read from it. Sorry but this seems wrong to me... as soon as I used setFloatingPointPrecision(SinglePrecision), magically I can read the floats correctly. So setFloatingPointPrecision() *also* changes the way numbers are read. Indeed. Also I think you're wrong in what you want to do. You can't read data from a file which was not stored with QDataStream before! See http://qt-project.org/doc/qt-5.0/qtcore/qdatastream.html#details I can understand this for high-level Qt objects, but what about lower-level data? Does this mean I can't use QDataStream to read a file written by some other program, and/or can't use it to *write* a file which could be read back by some other program? Again, only using low-level data, ints, floats, and so on. If that is true, then it's a huge step backward in the ease of use provided by Qt in the realm of reading/writing binary files. It is not a step backwards. It has been like this before Qt 5 too. I'm not sure when this change was introduced though, but probably early in Qt 4. Did you notice that you can set the version QDataStream is using to an earlier one? According to the docs, QDataStream::FloatingPointPrecision has no effect if the data stream version is below Qt_4_6, so perhaps that's when the change was introduced. Just to give a context, the goal here is to read and write binary STL (stereolithography) or PLY files. I have old Qt3 code which works like a charm, reading and writing files usable to and from other soft (e.g. Blender). Now moving that old code to Qt5 it seems to not work as expected, despite using only basic, low-level data types. I think it would not be very hard to write your own wrapper for QDataStream that does the switching of type automatically, but it seems to me that even setting the data stream version to something before Qt_4_6 before starting to read should work as well. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8.6 Release Plans
Hi! Dunno if this has been brought up before, but there's also this weird bug still present in Qt 4.8.5 for Mac OS X: https://bugreports.qt-project.org/browse/QTBUG-23673 The simple patch I attached to the bug fixes it for me and others... anyway, it would be great if that got fixed in 4.8.6 :). Cheers, René ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
On Friday 08 November 2013 10:42:16 Yves Bailly wrote: I can understand this for high-level Qt objects, but what about lower-level data? Does this mean I can't use QDataStream to read a file written by some other program, and/or can't use it to *write* a file which could be read back by some other program? Again, only using low-level data, ints, floats, and so on. If that is true, then it's a huge step backward in the ease of use provided by Qt in the realm of reading/writing binary files. Just to give a context, the goal here is to read and write binary STL (stereolithography) or PLY files. I have old Qt3 code which works like a charm, reading and writing files usable to and from other soft (e.g. Blender). Now moving that old code to Qt5 it seems to not work as expected, despite using only basic, low-level data types. You can use stream.setVersion(QDataStream::Qt_3_3); To get back to the Qt3 behaviour. Else, yes, you will have to change the floating point precision before every call. It was changed in Qt 4.6 for compatibility with qreal that can be float or double depending on the platform. Perhaps one could add a QDataStream::FloatingPointPrecision::AutoPrecision, that would not be a bad idea. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
Olivier Goffart schreef op 8-11-2013 10:57: On Friday 08 November 2013 10:42:16 Yves Bailly wrote: I can understand this for high-level Qt objects, but what about lower-level data? Does this mean I can't use QDataStream to read a file written by some other program, and/or can't use it to *write* a file which could be read back by some other program? Again, only using low-level data, ints, floats, and so on. If that is true, then it's a huge step backward in the ease of use provided by Qt in the realm of reading/writing binary files. Just to give a context, the goal here is to read and write binary STL (stereolithography) or PLY files. I have old Qt3 code which works like a charm, reading and writing files usable to and from other soft (e.g. Blender). Now moving that old code to Qt5 it seems to not work as expected, despite using only basic, low-level data types. You can use stream.setVersion(QDataStream::Qt_3_3); To get back to the Qt3 behaviour. Else, yes, you will have to change the floating point precision before every call. It was changed in Qt 4.6 for compatibility with qreal that can be float or double depending on the platform. Perhaps one could add a QDataStream::FloatingPointPrecision::AutoPrecision, that would not be a bad idea. What would that mode do, exactly? Isn't the whole point that qreal may be defined as float or double, and thus you don't know how it will be stored in QDataStream? You cannot detect which meaning of qreal was used when the file was written... Or do you mean that it should be something like MixedPrecision or TypePrecision that would always use 4 bytes for float and 8 for double again (and wreck havoc if you try to use qReal for reading or writing)? That indeed would be good, I think. I think it's a bit weird that in order to support streaming qreal, you basicaly stop supporting reading and writing floats or doubles. André -- You like Qt? I am looking for collegues to join me at i-Optics! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
On Friday 08 November 2013 11:03:40 André Somers wrote: Olivier Goffart schreef op 8-11-2013 10:57: It was changed in Qt 4.6 for compatibility with qreal that can be float or double depending on the platform. Perhaps one could add a QDataStream::FloatingPointPrecision::AutoPrecision, that would not be a bad idea. What would that mode do, exactly? Isn't the whole point that qreal may be defined as float or double, and thus you don't know how it will be stored in QDataStream? You cannot detect which meaning of qreal was used when the file was written... Or do you mean that it should be something like MixedPrecision or TypePrecision that would always use 4 bytes for float and 8 for double again (and wreck havoc if you try to use qReal for reading or writing)? That indeed would be good, I think. I think it's a bit weird that in order to support streaming qreal, you basicaly stop supporting reading and writing floats or doubles. Yes, what I called AutoPrecision would be 8 bytes when passed a double, and 4 bytes when passed float. It would be a bad idea to use that mode with qreal typedef which can vary on the platform. (But qreal defaults to double on all the platform from Qt 5.2) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
On 11/08/2013 11:03 AM, André Somers wrote: Olivier Goffart schreef op 8-11-2013 10:57: On Friday 08 November 2013 10:42:16 Yves Bailly wrote: I can understand this for high-level Qt objects, but what about lower-level data? Does this mean I can't use QDataStream to read a file written by some other program, and/or can't use it to *write* a file which could be read back by some other program? Again, only using low-level data, ints, floats, and so on. If that is true, then it's a huge step backward in the ease of use provided by Qt in the realm of reading/writing binary files. Just to give a context, the goal here is to read and write binary STL (stereolithography) or PLY files. I have old Qt3 code which works like a charm, reading and writing files usable to and from other soft (e.g. Blender). Now moving that old code to Qt5 it seems to not work as expected, despite using only basic, low-level data types. You can use stream.setVersion(QDataStream::Qt_3_3); To get back to the Qt3 behaviour. Else, yes, you will have to change the floating point precision before every call. It was changed in Qt 4.6 for compatibility with qreal that can be float or double depending on the platform. Perhaps one could add a QDataStream::FloatingPointPrecision::AutoPrecision, that would not be a bad idea. What would that mode do, exactly? Isn't the whole point that qreal may be defined as float or double, and thus you don't know how it will be stored in QDataStream? You cannot detect which meaning of qreal was used when the file was written... Or do you mean that it should be something like MixedPrecision or TypePrecision that would always use 4 bytes for float and 8 for double again (and wreck havoc if you try to use qReal for reading or writing)? That indeed would be good, I think. I think it's a bit weird that in order to support streaming qreal, you basicaly stop supporting reading and writing floats or doubles. QDataStream supports reading and writing floats and doubles, but it might use more bytes than necessary to represent them in the stream. The main use case of QDataStream is to serialize Qt data in a portable, binary form with the convenience that the code used to write and read the file are inverses of each other. One objective is that you get predictable results when moving your existing code and data to new platforms, and this was not at all the case before we standardized on a floating point precision for all floating point values in QDataStream for Qt 4.6. (For the same reason, QDataStream also assumes a particular endianness of the input data, and this also might have to be overridden manually if you want to read data that is not written by QDataStream.) It's pretty easy to read four bytes from a QIODevice if you do not worry about portability. Personally, having MixedPrecision/AutoPrecision seems unnecessary, since you would still have to be aware of the issue before you can make the decision to set this mode, and once you are aware of the issue, you can use setFloatingPointPrecision() to achieve the results you want and your code will still be cross-platform. -- Eskil ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
Eskil Abrahamsen Blomfeldt schreef op 8-11-2013 11:20: QDataStream supports reading and writing floats and doubles, but it might use more bytes than necessary to represent them in the stream. The main use case of QDataStream is to serialize Qt data in a portable, binary form with the convenience that the code used to write and read the file are inverses of each other. One objective is that you get predictable results when moving your existing code and data to new platforms, and this was not at all the case before we standardized on a floating point precision for all floating point values in QDataStream for Qt 4.6. (For the same reason, QDataStream also assumes a particular endianness of the input data, and this also might have to be overridden manually if you want to read data that is not written by QDataStream.) It's pretty easy to read four bytes from a QIODevice if you do not worry about portability. Personally, having MixedPrecision/AutoPrecision seems unnecessary, since you would still have to be aware of the issue before you can make the decision to set this mode, and once you are aware of the issue, you can use setFloatingPointPrecision() to achieve the results you want and your code will still be cross-platform. I find the case Yves make to be quite convincing. I know the main purpose of QDataStream is to serialize and deserialize data in a portable, binary form. But that does not exclude the usecase where you want to read and write to a format defined outside our ecosystem, right? If you have to deal with such an outside format, and that format uses both 4-byte floats and 8-byte doubles in its specs, then it really is quite inconveneant to have to switch back and forth during reading. As Yves points out, it makes chaining the operations impossible for instance. Also, it results in less readable code. I don't see what's wrong with such a mode, as long as the documentation warns that it won't work reliably with qreal (before 5.2, I read). You can already duplicate it by setting the version back to something old. If qreal really is a double on all platforms now by default from 5.2, perhaps a new version would even be in order that reverts the effect of setDoublePrecision completely? Just like it has no effect for versions Qt_4_6, it could have no effect for versions = Qt_5_2. What else is it needed for if qreal translates to double anyway? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
On 08 Nov 2013, at 11:32, André Somers an...@familiesomers.nl wrote: Eskil Abrahamsen Blomfeldt schreef op 8-11-2013 11:20 QDataStream supports reading and writing floats and doubles, but it might use more bytes than necessary to represent them in the stream. the main ... I don't see what's wrong with such a mode, as long as the documentation warns that it won't work reliably with qreal (before 5.2, I read). You To me it sounds like Qt needs a new lower-level class for serializing and deserializing stuff. QDataStream is for Qt only, it’s incompatible with all other binary formats out there, with the undocumented exception for cases where primitive types match. I would recommend against using QDataStream for anything else than reading back what was written using QDataStream. Andreas ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
Am 08.11.2013 10:42, schrieb André Somers: Christian Ehrlicher schreef op 8-11-2013 10:29: Am 08.11.2013 10:15, schrieb Yves Bailly: Le 08/11/2013 10:05, Giuseppe D'Angelo a écrit : On 8 November 2013 10:01, Yves Baillyyves.bai...@sescoi.fr wrote: As a float is 4 bytes, I would expect the second f.pos() to display 4... but it displays 8, as if QDataStream had moved 8 bytes ahead instead of just 4. Needless to say, the read float is wrong... Am I missing something here, or is it a bug? See QDataStream::setFloatingPointPrecision. The default is double. That's pretty strange... what if I want to read a float then a double? do I have to switch between the two each time? Does this means it's impossible to use code like this: float f; double d; datastream f d; ? setFloatingPointPrecision does only change the way the floating point numbers are stored in the data stream, not what you read from it. Also I think you're wrong in what you want to do. You can't read data from a file which was not stored with QDataStream before! See http://qt-project.org/doc/qt-5.0/qtcore/qdatastream.html#details That sounds very unlikely. It would mean that you cannot use symetric code for reading and writing data: //writing float f(3.14159); double d(2.71828); datastream f d; //reading, would not work according to Christian float f; double d; datastream f d; //would not work according to you //reading, according to Christian float f; double df, d; datastream df d; f = static_castfloat(d); I'm quite sure that you _can_ use the symetric (first) version. You're correct - you understood me wrong. :) Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
On 08/11/2013 11:37, Andreas Aardal Hanssen wrote: On 08 Nov 2013, at 11:32, André Somers an...@familiesomers.nl wrote: Eskil Abrahamsen Blomfeldt schreef op 8-11-2013 11:20 QDataStream supports reading and writing floats and doubles, but it might use more bytes than necessary to represent them in the stream. the main ... I don't see what's wrong with such a mode, as long as the documentation warns that it won't work reliably with qreal (before 5.2, I read). You To me it sounds like Qt needs a new lower-level class for serializing and deserializing stuff. A QRawDataStream class, but keeping the ease-of-use :-) mostly the setByteOrder() in my case. Otherwise there's no added value compared to the standard std::fstream. QDataStream is for Qt only, it’s incompatible with all other binary formats out there, with the undocumented exception for cases where primitive types match. Then maybe it should be stated more clearly in the doc? A big red blinking warning don't use QDataStream for anything else than to and from itself... I would recommend against using QDataStream for anything else than reading back what was written using QDataStream. This is what I called a step backward. Regards, -- (o | Yves Bailly | -o) //\ | Linux Dijon : http://www.coagul.org | //\ \_/ | | \_/` ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
On 8 November 2013 12:41, Yves Bailly yves.bai...@laposte.net wrote: QDataStream is for Qt only, it’s incompatible with all other binary formats out there, with the undocumented exception for cases where primitive types match. Then maybe it should be stated more clearly in the doc? A big red blinking warning don't use QDataStream for anything else than to and from itself... I won't be that drastic. QDataStream's binary format is public and documented, and as such, it can't be changed. As long as you're fine with its not-so-flexible API, you can use it with any other reader/writer which manages the same format. -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt5.2 snapshot available
I have tried to run /Volumes/qt-mac-opensource-5.2.0-beta1-ios-x86_64-offline/qt-mac-opensource-5.2.0-beta1-ios-x86_64-offline.app/Contents/MacOS$ ./qt-mac-opensource-5.2.0-beta1-ios-x86_64-offline in the terminal directly, the executable hangs. On Fri, Nov 8, 2013 at 5:10 PM, Heikkinen Jani jani.heikki...@digia.comwrote: Hi, Yes, it is known issue. As I wrote: With mac installers there might be some installation issues, workaround seems to be “run the installer.app/Contents/MacOS/installer from the command line”. Did you try that? Br, Jani *From:* Yang Fan [mailto:missd...@gmail.com] *Sent:* 8. marraskuuta 2013 2:51 *To:* Heikkinen Jani *Cc:* development@qt-project.org *Subject:* Re: [Development] New Qt5.2 snapshot available Build#134 dmg packages are broken. On Fri, Nov 1, 2013 at 2:05 PM, Heikkinen Jani jani.heikki...@digia.com wrote: Hi all, We got qt5.git integrated! It means we have now new content in latest snapshot in http://download.qt-project.org/snapshots/qt/5.2/5.2.0-beta1/ Unfortunately MAC packages are missing, hoping we could get those during today as well.. Build #123, Qt5 changes after Beta1 release: * qtactiveqt de09a6d...71fc126 (2): fix doc build path remove pointless #ifndef QT_NO_WIN_ACTIVEQT * qtandroidextras c1d9cc6...df30d67 (1): Update documentation * qtbase 690cf42...fe220f3 (133): Dont use NO_DEFAULT_PATH on mac when finding GL headers and libraries. bring the windows configure -qconfig handling in line with the unix one turn makeabs into a proper cleanPath() duplicate less work while handling -qconfig iOS: Add standard paths implementation for iOS Windows: Do not use blend function for GL windows with alpha. iOS: Fix logic for determining whether to exit the root event loop Update the ICC spec on Linux to actually compile stuff xcode generator: resolve QMAKE_INFO_PLIST from source dir Consider multi-monitor setups in QPlatformWindow::initialGeometry(). Fix QSpinBox size calculation problem with empty stylesheets dbuscommon.pri: Fix source file dependency Android: Dont rely on QIcon::isNull() to validate icon data. Android: Fix problem with leaking local refs. remove compiler warning xcb: Compilefix #ifdef glx code xcb: Act on the _NET_ACTIVE_WINDOW event iOS: Build libs (including Qt itself) for both simulator and device Fix the network proxy code for windows to detect properly services Adding CI utilities to Android test script Test that Qt tools can handle as a digit separator. Use Q_UNLIKELY in qCDebug, qCTrace Fix finding cursor position in words with accents Silence the _COMPIZ_DECOR_* warnings on Ubuntu Add QGuiApplication::sync() function iOS: Build simulator libraries with suffix Doc: Fix miscellaneous typos Issue correct warnings with QObject::startTimer() Doc: Remove unofficial Qt Concurrent headers Different native Cocoa menu fixes. Keep web fontdata alive as long as CG uses it Dont support threaded GL on chromium (virtual box GL) QNX: Manage foreign mmrenderer windows Fix msvc project dependencies as specificed by .depends remove qt_windows.h include from qwineventnotifier.h Cocoa: Fix mouse event coordinates transform to window space MacGui tests: Remove references to CGPostMouseEvent qdbusxml2cpp: Fix warnings about writing to closed devices. fix /SAFESEH linker option for VS = 2010 QLocale: Add auto tests for Poruguese(Brazil) and Greek locales Make the localHostName() copy function return QByteArray Fix QCommonStyle::subControlRect(SC_GroupBoxCheckBox) validate qconfig-*.h against qfeatures.txt dont emit comments to generated qfeatures.h generate qfeatures.h at build time give XMLSTREAM a Name fix markup purge references to non-features purge vestiges of dead QT_NO_* defines remove remaining non-concurrent branches from concurrent samples remove dead code Android: handle keyPress event for Key_Back Fix the show/hide logic. Allow the user to specify a theme list. Re-enable NonFullScreenWindows on Android Fail when QT_POINTER_SIZE is not set eglfs: Make backingstore handle unexpected scenarios gracefully Fix compilation with MinGW gcc 64 bit Android: Dont crash if the screen is not yet initialized. Android: Remove unneeded dependency iOS: Set ARCHS in Xcode project for both simulator and device SDKs Doc: Update boost::bind()/std::tr1::bind() to std::bind() Remove unused static function systemtimeToMsecs() QWizard: provoke enum value not handled in switch warnings in object_name_for_button QWizard: give all buttons an objectName Doc: Added a new Qt Creator \externalpage network: fix multi-phased NTLM authentication Add QMAKE_PKGCONFIG_VERSION variable to allow version overriding remove some vestiges of QFontEngineQPF Fix - psql driver must format qdatetime using iso eglfs:
Re: [Development] Weird offseting in QDataStream
On 08 Nov 2013, at 12:41, Yves Bailly yves.bai...@laposte.net wrote: ]I would recommend against using QDataStream for anything else than reading back what was written using QDataStream. This is what I called a step backward. It’s just stating a fact. QDataStream isn’t a generic cross-framework class, it’s not based on any standard. Its internal structure is completely undocumented. It’s compatible only with itself, and then, only with specific versions of itself. It even encodes the QDataStream format version in the stream itself. So it’s not a step backward. It’s just a special-purpose class used for more than it’s designed for. Personally I think using fstream or htons is perfectly fine. Both are portable, beyond what QDataStream does. Andreas ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
Andreas Aardal Hanssen schreef op 8-11-2013 13:28: On 08 Nov 2013, at 12:41, Yves Bailly yves.bai...@laposte.net mailto:yves.bai...@laposte.net wrote: ]I would recommend against using QDataStream for anything else than reading back what was written using QDataStream. This is what I called a step backward. It's just stating a fact. QDataStream isn't a generic cross-framework class, it's not based on any standard. Its internal structure is completely undocumented. Wrong. It *is* documented: http://qt-project.org/doc/qt-4.8/datastreamformat.html It's compatible only with itself, and then, only with specific versions of itself. It even encodes the QDataStream format version in the stream itself. No, it does not. You actually should set the version used explicitly in both the reader and the writer code especially _because_ the version is not in the data stream. So it's not a step backward. It's just a special-purpose class used for more than it's designed for. Personally I think using fstream or htons is perfectly fine. Both are portable, beyond what QDataStream does. I think that creating some raw class is ridiculous. It will end up looking very, very much like QDataStream, only supporting less data types. Seems like a pointless excersise to me. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 5.2 header diff
Hi all, What is the situation with reviews especially potential fixes? Is all needed now done and so on can we start merge on Monday morning? Br, Jani -- Jani Heikkinen Release Manager ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ABI change on arm*, call to distros' maintainers
On Wed, Nov 6, 2013 at 6:01 PM, Lisandro Damián Nicanor Pérez perezme...@gmail.com wrote: In Debian we are considering if the problem of breaking ABI without a soname bump is worth the effort for armhf, but it would be also good to try and coordinate between distros so as to try to keep binary compatibility between us. What are you thinking about this? At least from a Sailfish perspective, the change came too late. We already released our ARM SDK, and as a result, we'll be sticking with qreal == float (until such time as we can safely make a proper transition, whenever that will be). I should probably add that I find it a bit surprising that this change happened without any real heads-up or warning, given how Qt normally strives to *not* change ABI. BR, Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] The Qt-components ML has been closed
Hi all, As previously discussed here and there, we have decided to shut down the obsolete Qt-components mailing list. The mailing list no longer served a purpose, but mainly caused confusion especially amongst new Qt users. The substituting lists are: * Interest - List for developers who _use_ Qt http://lists.qt-project.org/mailman/listinfo/interest * Development - List for developers _of_ Qt http://lists.qt-project.org/mailman/listinfo/development PS. The Qt-components archives remain accessible at http://lists.qt-project.org/pipermail/qt-components. -- J-P Nurmi ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats
On 8 Nov 2013, at 9:59 AM, Mikkel Krautz wrote: That's how I'm imagining it working as well. No 3rdparty source tree needs to be bundled (it isn't bundled in qt-solutions either, at the moment) - but link against the JasPer lib if it's present on the system, or JASPER_CFLAGS and JASPER_LIBS are specified to configure (or however we want it to function). Why should it use jasper instead of OpenJPEG? I'm not familiar with either one but wikipedia seems to say OpenJPEG implements more of the spec. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats
+1 to moving the plugins to qtimageformats. That¹s what we have the module for. And I don¹t think moving ICNS is an issue neither, as long as we have a configure test in qtimageformats to detect whether we can compile the plugin. Cheers, Lars On 06/11/13 11:27, Saether Jan-Arve jan-arve.saet...@digia.com wrote: Actually I support moving qtjp2k to qtimageformats. However, I'm still not convinced if there is a need for ICNS plugin outside OSX (It's not common on Windows, I have no idea about Linux). As for your cross platform icon editor, why can't it use ICO files? Although the ICO file format itself is somewhat weird, ICO files are much more likely to be supported on all platforms, since it won't rely on any 3rdparty library. It can also store PNG files, which Qt already have built-in support for. Jan Arve From: development-bounces+jan-arve.saether=digia@qt-project.org [mailto:development-bounces+jan-arve.saether=digia@qt-project.org] On Behalf Of Jake Petroules Sent: 5. november 2013 17:48 To: Thiago Macieira Cc: development@qt-project.org Subject: Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats I do. Qt is by nature a cross platform framework, limiting support for ICNS files only to OS X doesn't really make sense. What if you want to create a cross platform icon editor or some other app that deals with image files? Or reuse your OS X icon(s) on Windows and other platforms, saving time and space not having to create multiple versions of everything? If you don't want to build the ICNS plugin, simply disable it when you configure qtimageformats. It's a common and well known format and it should be supported on all platforms Qt supports, just as ICO is supported on OS X, Linux and others. I could understand refusing to include it in QtCore, but we're talking about QtImageFormats here, the perfect place where something like this belongs. -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com http://www.petroules.com Email: jake.petrou...@petroules.com On Nov 5, 2013, at 11:37 AM, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 5 de novembro de 2013 08:57:12, Saether Jan-Arve wrote: Is there any big benefits in having ICNS support on other platforms than OSX? I don't think anyone wants ICNS outside OS X. But JPEG2000 might be useful. -- Thiago Macieira - thiago.macieira (AT) intel.com http://intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats
On Fri, Nov 8, 2013 at 3:21 PM, Albert Astals Cid albert.ast...@canonical.com wrote: On Friday 08 November 2013 14:18:24 Rutledge Shawn wrote: Why should it use jasper instead of OpenJPEG? I'm not familiar with either one but wikipedia seems to say OpenJPEG implements more of the spec. And it's actually has an active upstream, while Jasper doesn't seem to be maintained at all. I wasn't really picking sides. :-) It's just my understanding that the jp2k image format currently in qt-solutions currently only builds against JasPer. OpenJPEG seems preferable if it has more features and is actively maintained. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats
On Friday 08 November 2013 14:18:24 Rutledge Shawn wrote: On 8 Nov 2013, at 9:59 AM, Mikkel Krautz wrote: That's how I'm imagining it working as well. No 3rdparty source tree needs to be bundled (it isn't bundled in qt-solutions either, at the moment) - but link against the JasPer lib if it's present on the system, or JASPER_CFLAGS and JASPER_LIBS are specified to configure (or however we want it to function). Why should it use jasper instead of OpenJPEG? I'm not familiar with either one but wikipedia seems to say OpenJPEG implements more of the spec. And it's actually has an active upstream, while Jasper doesn't seem to be maintained at all. Cheers, Albert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Virtual GUI framework
On 7 November 2013 19:40:59, David Boddie wrote: The minimal case can be done with QPA, as Friedemann mentioned in his reply. For my use case, I build minimal Qt libraries with only the features I need and use a dummy screen plugin to keep everything happy. The resulting library appears to run fine on servers without displays. I'll try to put the code up somewhere tomorrow. This is what I did - it's really just a set of patches that are applied within a Debian package building framework: https://github.com/david-boddie-met-no/qt4-headless/tree/4.8-qpa The configuration removes as much as possible from the build, so you wouldn't want to try and use it to build a virtual GUI framework. The use case for this is a library that renders images for a server. There are various patches in there to fix some Qt headers - it seems that some feature-sensitive code is not properly wrapped in #ifdef checks. Are the cut-down Qt builds still tested these days? David ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Asking for review: webp support in qtimageformats
Hi, all, Just see many people are interest in JP2 and ICNS things. I want to ask for review about webp support in qtimageformats again. There are changes available since May and June, https://codereview.qt-project.org/54689 https://codereview.qt-project.org/54690 https://codereview.qt-project.org/54691 https://codereview.qt-project.org/56026 Best Regards, Liang -- http://www.qiliang.net ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
On sexta-feira, 8 de novembro de 2013 10:34:00, Andreas Aardal Hanssen wrote: On 08 Nov 2013, at 10:15, Yves Bailly yves.bai...@sescoi.fr wrote: Le 08/11/2013 10:05, Giuseppe D'Angelo a écrit : See QDataStream::setFloatingPointPrecision. The default is double. That's pretty strange... what if I want to read a float then a double? do I have to switch between the two each time? Does this means it's impossible to use code like this: float f; double d; datastream f d; QDataStream stores your content in a portable binary format. Specifying the floating point precision makes it clear that real numbers, be them represented in floats or doubles in C++, are stored as floats or doubles in file. If you want to store a float as a float, and then a double as a double, you need to change the precision of QDataStream in between calls. Plus, the code that reads the file must match the code that wrote the stream. We could provide an iomanipulator like QTextStream and iostream: ds qSetSinglePrecision f qSetDoublePrecision d; ds qSetSinglePrecision f qSetDoublePrecision d; -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt5.2 snapshot available
same issue with the Mac Desktop package since some days 2013/11/8 Yang Fan missd...@gmail.com I have tried to run /Volumes/qt-mac-opensource-5.2.0-beta1-ios-x86_64-offline/qt-mac-opensource-5.2.0-beta1-ios-x86_64-offline.app/Contents/MacOS$ ./qt-mac-opensource-5.2.0-beta1-ios-x86_64-offline in the terminal directly, the executable hangs. On Fri, Nov 8, 2013 at 5:10 PM, Heikkinen Jani jani.heikki...@digia.comwrote: Hi, Yes, it is known issue. As I wrote: With mac installers there might be some installation issues, workaround seems to be “run the installer.app/Contents/MacOS/installer from the command line”. Did you try that? Br, Jani *From:* Yang Fan [mailto:missd...@gmail.com] *Sent:* 8. marraskuuta 2013 2:51 *To:* Heikkinen Jani *Cc:* development@qt-project.org *Subject:* Re: [Development] New Qt5.2 snapshot available Build#134 dmg packages are broken. On Fri, Nov 1, 2013 at 2:05 PM, Heikkinen Jani jani.heikki...@digia.com wrote: Hi all, We got qt5.git integrated! It means we have now new content in latest snapshot in http://download.qt-project.org/snapshots/qt/5.2/5.2.0-beta1/ Unfortunately MAC packages are missing, hoping we could get those during today as well.. Build #123, Qt5 changes after Beta1 release: * qtactiveqt de09a6d...71fc126 (2): fix doc build path remove pointless #ifndef QT_NO_WIN_ACTIVEQT * qtandroidextras c1d9cc6...df30d67 (1): Update documentation * qtbase 690cf42...fe220f3 (133): Dont use NO_DEFAULT_PATH on mac when finding GL headers and libraries. bring the windows configure -qconfig handling in line with the unix one turn makeabs into a proper cleanPath() duplicate less work while handling -qconfig iOS: Add standard paths implementation for iOS Windows: Do not use blend function for GL windows with alpha. iOS: Fix logic for determining whether to exit the root event loop Update the ICC spec on Linux to actually compile stuff xcode generator: resolve QMAKE_INFO_PLIST from source dir Consider multi-monitor setups in QPlatformWindow::initialGeometry(). Fix QSpinBox size calculation problem with empty stylesheets dbuscommon.pri: Fix source file dependency Android: Dont rely on QIcon::isNull() to validate icon data. Android: Fix problem with leaking local refs. remove compiler warning xcb: Compilefix #ifdef glx code xcb: Act on the _NET_ACTIVE_WINDOW event iOS: Build libs (including Qt itself) for both simulator and device Fix the network proxy code for windows to detect properly services Adding CI utilities to Android test script Test that Qt tools can handle as a digit separator. Use Q_UNLIKELY in qCDebug, qCTrace Fix finding cursor position in words with accents Silence the _COMPIZ_DECOR_* warnings on Ubuntu Add QGuiApplication::sync() function iOS: Build simulator libraries with suffix Doc: Fix miscellaneous typos Issue correct warnings with QObject::startTimer() Doc: Remove unofficial Qt Concurrent headers Different native Cocoa menu fixes. Keep web fontdata alive as long as CG uses it Dont support threaded GL on chromium (virtual box GL) QNX: Manage foreign mmrenderer windows Fix msvc project dependencies as specificed by .depends remove qt_windows.h include from qwineventnotifier.h Cocoa: Fix mouse event coordinates transform to window space MacGui tests: Remove references to CGPostMouseEvent qdbusxml2cpp: Fix warnings about writing to closed devices. fix /SAFESEH linker option for VS = 2010 QLocale: Add auto tests for Poruguese(Brazil) and Greek locales Make the localHostName() copy function return QByteArray Fix QCommonStyle::subControlRect(SC_GroupBoxCheckBox) validate qconfig-*.h against qfeatures.txt dont emit comments to generated qfeatures.h generate qfeatures.h at build time give XMLSTREAM a Name fix markup purge references to non-features purge vestiges of dead QT_NO_* defines remove remaining non-concurrent branches from concurrent samples remove dead code Android: handle keyPress event for Key_Back Fix the show/hide logic. Allow the user to specify a theme list. Re-enable NonFullScreenWindows on Android Fail when QT_POINTER_SIZE is not set eglfs: Make backingstore handle unexpected scenarios gracefully Fix compilation with MinGW gcc 64 bit Android: Dont crash if the screen is not yet initialized. Android: Remove unneeded dependency iOS: Set ARCHS in Xcode project for both simulator and device SDKs Doc: Update boost::bind()/std::tr1::bind() to std::bind() Remove unused static function systemtimeToMsecs() QWizard: provoke enum value not handled in switch warnings in object_name_for_button QWizard: give all buttons an objectName Doc: Added a new Qt Creator \externalpage network: fix multi-phased NTLM authentication Add QMAKE_PKGCONFIG_VERSION variable to allow version overriding
Re: [Development] Color Management support in Qt 5?
Am 08.11.2013 14:17, schrieb Sorvig Morten: On 07 Nov 2013, at 12:48, Kai-Uwe Behrmann k...@gmx.de wrote: Detecting a colour space and converting to device colour spaces is around the same amount of developer time as for special casing sRGB. Detecting sRGB among hundrets of ICC profiles is not trivial or fast, while such a detection does not matter in a generic colour managed environment. EXT_texture_sRGB provides only sRGB gamma to linear gamma conversions. That is a thiny bit of grafic processing, which is needed for handling colour space conversions. The spec is clear to not doing anything about dislpaying sRGB images on a monitor. So this OpenGL extension does not help much with colour management. Short term support for sRGB only would make Qt a pretty limiting choice for many colour managed applications. IMHO, limiting support to RGB in a first development stage is a more sound target. Hello! You did not give me much wiggle room with this reply - did you simply want to end the discussion? Oh, I joined the discussion to keep it alive. Sorry, if my reply was perceived in a different mode. For example, the existance of EXT_framebuffer_sRGB supports my argument that limiting support to sRGB will be simpler, but you don’t mention it at all. As I mentioned, the GL extension does no complete colour space conversion as it handles only gamma and not colour primaries. It is intented for memory storage savings, which are unrelated to any colour management concerns. In fact a small shader can do a similar gamma correction. On the other hand a different shader could do as well a full colour space conversion. sRGB is other than for storage not of much value. Nonetheless sRGB is traditionally used as factual blending space. But e.g. wayland devs think seriously around linear gamma blending spaces, which give lesser artefacts. If one plans for mobile only, then a single blending colour space with low bit depth storage might be an option. But I wanted to point out, that this appears to me like a serious regression on desktop. The implications are certainly up to decide by the Qt community. kind regards Kai-Uwe Behrmann ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Management support in Qt 5?
Allow me jump into this topic to contribute to its liveliness :) The term Color Management has been used in different ways here on the list. Lately, it was about how to blend images in a non-linear color space. That is IMHO perhaps a small and not that typical part of what color management means for imaging applications. I like the idea of re-starting small, and quite a bit of what was done in Nokia times can certainly be re-used. What if Qt started by simply *enabling* color management. I.e. giving access to the information that an application needs to perform color management tasks itself. In a much later iteration Qt could perhaps perform color management operations. Qt should IMHO avoid automatic color management under the hood, especially without providing API to control it. Milestones could be: 1) QImage[Reader] gives access to image color profile. Either whole profile or just an identifier in case of standard spaces such as sRgb. 2) QScreen gives access to the current display color profile for that specific screen. 3) There are notifications (signals?) when the a window changes to another screen, or when a screen profile is changed in the system. 4) Same as 2 but for installed Printers on the system. ... 99) QColorEngine can do color conversions using an input profile, a source Image an output profile plus different parameters. Ideas? Kai-Uwe, what color management feature (or enabler) are you missing most in Qt? Br, Alessandro On Fri, Nov 8, 2013 at 11:53 PM, Kai-Uwe Behrmann k...@gmx.de wrote: Am 08.11.2013 14:17, schrieb Sorvig Morten: On 07 Nov 2013, at 12:48, Kai-Uwe Behrmann k...@gmx.de wrote: Detecting a colour space and converting to device colour spaces is around the same amount of developer time as for special casing sRGB. Detecting sRGB among hundrets of ICC profiles is not trivial or fast, while such a detection does not matter in a generic colour managed environment. EXT_texture_sRGB provides only sRGB gamma to linear gamma conversions. That is a thiny bit of grafic processing, which is needed for handling colour space conversions. The spec is clear to not doing anything about dislpaying sRGB images on a monitor. So this OpenGL extension does not help much with colour management. Short term support for sRGB only would make Qt a pretty limiting choice for many colour managed applications. IMHO, limiting support to RGB in a first development stage is a more sound target. Hello! You did not give me much wiggle room with this reply - did you simply want to end the discussion? Oh, I joined the discussion to keep it alive. Sorry, if my reply was perceived in a different mode. For example, the existance of EXT_framebuffer_sRGB supports my argument that limiting support to sRGB will be simpler, but you don’t mention it at all. As I mentioned, the GL extension does no complete colour space conversion as it handles only gamma and not colour primaries. It is intented for memory storage savings, which are unrelated to any colour management concerns. In fact a small shader can do a similar gamma correction. On the other hand a different shader could do as well a full colour space conversion. sRGB is other than for storage not of much value. Nonetheless sRGB is traditionally used as factual blending space. But e.g. wayland devs think seriously around linear gamma blending spaces, which give lesser artefacts. If one plans for mobile only, then a single blending colour space with low bit depth storage might be an option. But I wanted to point out, that this appears to me like a serious regression on desktop. The implications are certainly up to decide by the Qt community. kind regards Kai-Uwe Behrmann ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
