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
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,
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
+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
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
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
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
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
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...
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
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
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
35 matches
Mail list logo
