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 mea

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 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

Re: [Development] New Qt5.2 snapshot available

same issue with the Mac Desktop package since some days 2013/11/8 Yang Fan > 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

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 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

[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

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

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 li

Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats

On Fri, Nov 8, 2013 at 3:21 PM, Albert Astals Cid 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 a

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" wrote: >Actu

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_LI

[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_

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 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 betw

[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] New 5.2.0 beta1 snapshot... Segfault when clicking Create AndroidManifest.xml

Hi, for me the QtCreator bundled in the newest beta1 snapshot just segfaults when I click Create AndroidManifest.xml. Debian 64 bit. Am I the only one? Guido ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/lis

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 > 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 jus

Re: [Development] Weird offseting in QDataStream

On 08 Nov 2013, at 12:41, Yves Bailly 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

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 wrot

Re: [Development] Weird offseting in QDataStream

On 8 November 2013 12:41, Yves Bailly 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 >

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 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 strea

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 Bailly wrote: As a float is 4 bytes, I would expect the second f.pos() to displ

Re: [Development] Weird offseting in QDataStream

On 08 Nov 2013, at 11:32, André Somers 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 wit

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 co

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 writ

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::AutoPreci

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

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 so

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 :

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 wrote: > As a float is 4 bytes, I would expect the second f.

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 th

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 wrote: As a float is 4 bytes, I would expect the second f.pos() to display "4"... but it displays "8", as if QDataSt

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 wrote: As a float is 4 bytes, I would expect the second f.pos() to display "4"... but it disp

Re: [Development] Weird offseting in QDataStream

On 08 Nov 2013, at 10:15, Yves Bailly 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 thi

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 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 instea

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 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 flo

Re: [Development] Weird offseting in QDataStream

On 8 November 2013 10:01, Yves Bailly 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

Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats

On Fri, Nov 8, 2013 at 8:45 AM, Rutledge Shawn 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