Re: [Development] Not stripping our binaries by default

[simon.hausmann]

I think that our default configure and make rules should be tailored towards 
developers
deliberately building Qt from source, so IMHO it should not strip by default. 
When you build
Qt from source I'm not sure you care about the binary size (you're installing 
on your local
drive) and you might appreciate getting some useful backtraces when they happen.

I think in automake this is usually solved by make install _not_ stripping and 
then there being also
a "make install-strip" target that installs and strips.

Quote from the automake manual:

"
make install
Install what needs to be installed, copying the files from the package's 
tree to system-wide directories. 
make install-strip
Same as make install, then strip debugging symbols. Some users like to 
trade space for useful bug reports... 
"



Just my two øre :)

Simon


From: development-bounces+simon.hausmann=nokia@qt-project.org 
[development-bounces+simon.hausmann=nokia@qt-project.org] on behalf of ext 
Thiago Macieira [thiago.macie...@intel.com]
Sent: Thursday, September 13, 2012 22:21
To: development@qt-project.org; releas...@qt-project.org
Subject: [Development] Not stripping our binaries by default

I was trying to make Qt 5 packages for Tizen when I realised that the
automated build scripts that generate debuginfo packages were failing, saying
that our libraries are already stripped.

Turns out that qmake generates "strip --strip-unneeded" commands when in
release mode. There's a way to turn it off by passing an extra CONFIG to qmake,
but that is not accessible from the configure command-line.

Either way, stripping by default sounds wrong to me. Distributions already
have their own tools to strip. So I'm proposing that we stop doing that. See

https://codereview.qt-project.org/34835

For our own SDK, we might need to add the stripping at the appropriate
place(s).

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt5 Beta1: MSVC2010SP1_64bit + WSDK7.5, Using '-ltcg' lead all gui-tools crash!

[Loaden]

Only Crash on 64bit Library.
e.g.
assistant.exe
designer.exe

-- 
Best Regards
Yuchen
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt5 Beta1: Can't run assistant.exe / designer.exe / linguist.exe on Windows 7 64 bit OS

[Loaden]

Because I am using -ltcg configure option for MSVC 2010SP1 + Windows SDK
7.5.
Remove -ltcg then running well.
在 2012年9月12日 下午12:25，Loaden 写道：

> 64bit MSVC2010SP1+SDK7.5 + 64bit Qt library + 64bit OS:
> Application Error
> 0x01d
>
> 32bit MSVC2010SP1+SDK7.5 + 32bit Qt library + 64bit OS:
> Everything works well.
>
> Any comments?
>
> 问题签名:
>   问题事件名称: APPCRASH
>   应用程序名: designer.exe
>   应用程序版本: 1.0.0.0
>   应用程序时间戳: 504ec1a8
>   故障模块名称: QtGui5.dll
>   故障模块版本: 5.0.0.0
>   故障模块时间戳: 504eb30e
>   异常代码: c01d
>   异常偏移: 0028b790
>   OS 版本: 6.1.7601.2.1.0.256.1
>   区域设置 ID: 2052
>   其他信息 1: 14bd
>   其他信息 2: 14bd3a5532c8f045c550a0948d6875f1
>   其他信息 3: 0d05
>   其他信息 4: 0d054ff90c44a45eb3e7775c27bf9d3c
>
> 联机阅读隐私声明:
>   http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0804
>
> 如果无法获取联机隐私声明，请脱机阅读我们的隐私声明:
>   C:\Windows\system32\zh-CN\erofflps.txt
>
>
> --
> Best Regards
> Yuchen
>
>


-- 
Best Regards
Yuchen
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] ExtendedSelection in 5.0 has no effect on Mac OS X

[Stephen Chu]

OK. Here's the show stopper:



It works on Windows build. :(
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Not stripping our binaries by default

[lars.knoll]

On Sep 13, 2012, at 11:21 PM, ext Thiago Macieira 
 wrote:

> On quinta-feira, 13 de setembro de 2012 20.57.58, lars.kn...@nokia.com wrote:
>> Depends on who we're optimising for. If we don't strip by default we might
>> get lots of complaints from people compiling source packages on their own
>> that wonder about huge binaries in release mode.
> 
> At this point, there's no way to stop qmake from generating the stripping 
> rules. Distributions need to apply the patch I created…

Agree that there should be a way. But the patch doesn't look correct neither.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Not stripping our binaries by default

[Thiago Macieira]

On quinta-feira, 13 de setembro de 2012 20.57.58, lars.kn...@nokia.com wrote:
> Depends on who we're optimising for. If we don't strip by default we might
> get lots of complaints from people compiling source packages on their own
> that wonder about huge binaries in release mode.

At this point, there's no way to stop qmake from generating the stripping
rules. Distributions need to apply the patch I created...

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


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] Not stripping our binaries by default

[lars.knoll]

On Sep 13, 2012, at 10:21 PM, ext Thiago Macieira  
wrote:

> I was trying to make Qt 5 packages for Tizen when I realised that the 
> automated build scripts that generate debuginfo packages were failing, saying 
> that our libraries are already stripped.
> 
> Turns out that qmake generates "strip --strip-unneeded" commands when in 
> release mode. There's a way to turn it off by passing an extra CONFIG to 
> qmake, 
> but that is not accessible from the configure command-line.
> 
> Either way, stripping by default sounds wrong to me. Distributions already 
> have their own tools to strip. So I'm proposing that we stop doing that. See
> 
>   https://codereview.qt-project.org/34835

Depends on who we're optimising for. If we don't strip by default we might get 
lots of complaints from people compiling source packages on their own that 
wonder about huge binaries in release mode.

Cheers,
Lars
> 
> For our own SDK, we might need to add the stripping at the appropriate 
> place(s).
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> Intel Sweden AB - Registration Number: 556189-6027
> Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
> ___
> 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] Not stripping our binaries by default

[Thiago Macieira]

I was trying to make Qt 5 packages for Tizen when I realised that the
automated build scripts that generate debuginfo packages were failing, saying
that our libraries are already stripped.

Turns out that qmake generates "strip --strip-unneeded" commands when in
release mode. There's a way to turn it off by passing an extra CONFIG to qmake,
but that is not accessible from the configure command-line.

Either way, stripping by default sounds wrong to me. Distributions already
have their own tools to strip. So I'm proposing that we stop doing that. See

https://codereview.qt-project.org/34835

For our own SDK, we might need to add the stripping at the appropriate
place(s).

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


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] Proposal: reorganization of QtSystems module, since Qt5.x

[Lorn Potter]

Hi Denis,

On 13/09/2012, at 8:27 PM, Denis Shienkov  wrote:

> Hello all.
> 
> As I'm concerned, at the moment Qt5 contains fragmented set of classes to 
> obtain information about the devices:
> 
> QPrinterInfo   -> QtBase/src/printsupport
> others info's  -> QtSystems/
> 

Because printing is a common and basic thing to want to add to applications. 
Getting info and notifications about cellId changes is more of a fringe use 
case.


> Since all of these entities are devices, it is logical to make the base
> class QDeviceInfo, from which derive all of the specific types of devices
> infos, like:

No, these aren't devices, they are peripherals.


> 
> class QDeviceInfo : public QObject
> {
> ...
> }
> 
> class QStorageInfo : public QDeviceInfo
> {
> ...
> }
> 
> ...
> ...
> 
> class QNetworkAdapterInfo : public QDeviceInfo
> {
> ...
> }

I don't understand why I would need information about manufacturer, model of 
the computer (from QDeviceInfo) when I want to get information about the 
network or storage?


> 
> Next, can create a separate class - watcher type QDeviceManeger (singleton), 
> which could provide a list of all available devices to send signals about 
> connecting/disconnecting devices, etc.

I think you may misunderstand 'device' in DeviceInfo. It is one computer - 
desktop, laptop, or mobile phone, and not really a peripheral like you are 
proposing.

> 
> class QDeviceManager : public QObject
> {
> public:
> 
>enum DeviceType {
>SerialPort,
>LptPort,
>MidiPort,
>NetworkAdapter,
>VideoAdapter,
>AudioAdapter,
>Monitor,
>Drive,
>...
>AllTypes
>};
> 
>QList devicesInfo(DeviceType dt = AllTypes);
>void enableWatchForType(DeviceType dt = AllTypes);
>bool isEnabledWatchForType(DeviceType dt = AllTypes);
> 
>// Maybe add another methods
> 
> signals:
>void connected(const QDeviceInfo &info);
>void disconnected(const QDeviceInfo &info);
> 
>// Maybe add another signals
> }
> 
> For a start here can add only the basic types of devices (already 
> implemented), 
> and then on future can add new supported device types (step-by-step).
> 
> This is just pseudocode, I know that it contains errors. I just proposed the 
> idea, 
> so please do not judge strictly.
> 
> Pros:
> + QtSystems module is already available, you just need to extend it.

This is more than extended it.

> + This solution will integrate all the disparate components of information in 
> one place.

Even though they are distinct types and use-cases for this information?
Having one grand class/signal for all this information is too much, and not 
object oriented.



> + Flexibility: you want - include the module, and you want - not.
> + Common notifier for all devices in which you can register and subscribe to 
> events on the desired device type.
> 
> Cons:
> - To use printing support need for a separate module QtSystems. Although 
> previously
> it was not required.
> - Implementation is complex.
> 
> I'm waiting for comments and suggestions. :)
> 
> 
> Best regards,
> Denis
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Lorn Potter
Senior Software Engineer, QtSensors/QtSensorGestures/QtSystemInfo




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposing reversal of the Math3D qreal->float change

[Romain Pokrzywka]

On Thursday, September 13, 2012 07:14:50 AM lars.kn...@nokia.com wrote:
> On Sep 13, 2012, at 2:07 AM, ext Romain Pokrzywka 
 wrote:
> > On Wednesday, September 12, 2012 07:10:52 AM lars.kn...@nokia.com wrote:
> >> On Sep 12, 2012, at 12:27 AM, ext André Pönitz
> >>  
> > chemnitz.de> wrote:
> >>> On Tue, Sep 11, 2012 at 10:34:50PM +0100, Sean Harmer wrote:
>  On 11/09/2012 13:34, Thiago Macieira wrote:
> > I propose we revert it.
>  
>  I propose we (I) fix the affected classes in QtMultimedia
>  and Qt3D. I'm away on business this week but I will make a
>  start asap.
> >>> 
> >>> I believe I mentioned that before. Anyway:
> >>> 
> >>> I think there are (medium term) only two acceptable solutions,
> >>> none of them perfect:
> >>> (a) keep everything as it is (or, rather, "was")
> >>> (b) have fully functional real/double "verticals"
> >> 
> >> (c) Turn qreal into a double everywhere
> >> 
> >> This was rejected before by some, because it might make things slower on
> >> ARM, but would have the advantage that it's fully source compatible with
> >> Qt
> >> 4, solves the mess and would allow us to introduce floating point types
> >> where required later.
> >> 
> >> Only minuses I can see are
> >> (c1) the names of QXxxF classes which are double and not float based
> >> (c2) possibly slower execution on ARM
> >> (c3) Somewhat higher memory consumption on ARM
> >> 
> >> (c1) is not easily fixed. But (c2) seems to be less of an issue these
> >> days.
> >> At least for the Cortex A9 ARM claims very good double precision support.
> >> Older CPUs also have some support through VFPv2/3. (c3) should also
> >> become
> >> less and less of an issue moving forward.
> >> 
> >> So to bring this up again: How about turning qreal into a typedef for
> >> double on all platforms and remove the mess this way? Whereever we need
> >> (or want to use) floats, let's use them explicitly.
> > 
> > I think the statements "might make things slower on ARM" and  "seems to be
> > less of an issue these days" are a little misleading and too optimistic.
> > 
> > From my own experience, using double on ARM has a serious impact on
> > performance at many levels: data size, code generation, and even FPU
> > options.
> > 
> > Indeed, from what I've read it seems like the Cortex-A9 is significantly
> > closing the gap between float and double (although not eliminating it),
> > but's it's really the only platform that does. [1]
> 
> True, but more and more embedded systems will start using that platform. My
> main proposal is that the default (and supported) build of Qt on ARM uses
> doubles for qreal. If we keep the typedef, you could still typedef it to
> use float at your own risk :)

True, that would be a good enough solution, e.g. as an option to configure

> > Every other platform, Cortex-A8 and previous ARM architectures, and even
> > Intel Atom, will suffer badly from switching from floats to doubles, even
> > though they have VFP.
> > 
> > This is mainly due to the crappy VFP abilities in those platforms,
> > combined
> > with the Cortex-A8 allowing use of the NEON co-processor as the FPU, with
> > massive performance improvements over VFP, but only available for floats.
> > [2]
> > 
> > And it gets even worse when using -mfloat-abi=softfp. [3]
> 
> Yes, but softfp doesn't make sense with Qt Quick 2 anyway.
> 
> > Now, considering that most usage of Qt on embedded platforms is either
> > through QGraphicsView or Qt Quick (1 and 2), both of them relying heavily
> > on floating point calculations (coordinate systems, painting with AA...),
> > this is definitely a decision with a potentially serious impact on most
> > embedded platforms.
> 
> One solution here is to explicitly use floats internally in Qt wherever
> possible and where it's critical to performance.
> > One may still argue that Qt5 should be targeting the latest and future
> > platforms instead of legacy and current ones. Fair enough. But I think the
> > consequences should be stressed more. Some extensive benchmarking would be
> > nice too, before deciding on one solution against the other.
> 
> As said above: It's about the default build that the Qt Project tests and
> supports.
> 
> We can keep the option of forcing qreal to float at least for now or until
> we've proven that the performance impact is acceptable.

Yep, I'm happy with that :)

Thx,
Romain

> 
> Cheers,
> Lars
> 
> > [1] http://www.360doc.com/content/12/0806/14/350555_228637047.shtml
> > [2]
> > http://processors.wiki.ti.com/index.php/Cortex_A8#Neon_and_VFP_both_suppor
> > t_floating_point.2C_which_should_I_use.3F [3]
> > http://wiki.debian.org/ArmHardFloatPort/VfpComparison
> > 
> > Regards,
> > Romain
> > 
> >> Cheers,
> >> Lars
> >> 
> >>> Version (a) means the current mess will go on. but it has the
> >>> distict charme of (a.1) not breaking anyones existing code and
> >>> (a.2) sticking to feature freeze rules.
> >>> 
> >>> Version (b) is somewhat closer to a proper solution, 

Re: [Development] Proposing reversal of the Math3D qreal->float change

[André Pönitz]

On Wed, Sep 12, 2012 at 07:10:52AM +, lars.kn...@nokia.com wrote:
> 
> On Sep 12, 2012, at 12:27 AM, ext André Pönitz 
>  wrote:
> 
> > On Tue, Sep 11, 2012 at 10:34:50PM +0100, Sean Harmer wrote:
> >> On 11/09/2012 13:34, Thiago Macieira wrote:
> >>> I propose we revert it.
> >> I propose we (I) fix the affected classes in QtMultimedia
> >> and Qt3D. I'm away on business this week but I will make a
> >> start asap.
> > 
> > I believe I mentioned that before. Anyway:
> > 
> > I think there are (medium term) only two acceptable solutions,
> > none of them perfect:
> > (a) keep everything as it is (or, rather, "was")
> > (b) have fully functional real/double "verticals"
> 
> (c) Turn qreal into a double everywhere

Not sure this would be acceptable to everyone, but it would be fine with
me _personally_. The case I absolutely want to avoid is turning anything
that was a double into single precision as this can render existing 
applications useless.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Completed: JIRA Maintenance September 13 - bugreports.qt-project.org

[Matias Rand]

JIRA / bugreports.qt-project.org is up and running again. Upgraded to 5.0.7.


Regards

--
Matias Rand
Nokia
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Building Qt5 on windows

[Алексей Павлов]

For Thiago:
mkspecs/qmodule.pri listing:
#paths
QT_BUILD_TREE   = C:/SDK/srcs/qt5/qtbase
QT_SOURCE_TREE  = C:/SDK/srcs/qt5/qtbase
QT_BUILD_PARTS += libs tools

#Qt for Windows CE c-runtime deployment
QT_CE_C_RUNTIME = no
CONFIG += create_prl link_prl sse2 sse3 ssse3 sse4_1 sse4_2 avx avx2 largefile


For  Jonathan Liu: if you list configure.log in first mesage you see
that during configuration LIB and INCLUDE added in configuration
normally. When I run ming32-make to build qt, qtbase makefiles
contains LIB and INCLUDE but not next modules.




2012/9/13 Jonathan Liu 
>
> On 13/09/2012 8:57 PM, Алексей Павлов wrote:
>
> set 
> INCLUDE=%MINGW_HOME%\%MINGW_HOST%\include;%EXTRA%\include;%QTINSTDIR%\databases\firebird\include;%QTINSTDIR%\databases\mysql\include;%QTINSTDIR%\databases\pgsql\include
> set 
> LIB=%MINGW_HOME%\%MINGW_HOST%\lib;%EXTRA%\lib;%QTINSTDIR%\databases\firebird\lib;%QTINSTDIR%\databases\mysql\lib;%QTINSTDIR%\databases\pgsql\lib
>
> GCC uses CPATH with paths separated by colons instead of INCLUDE.
> GCC uses LIBRARY_PATH with paths separated by colons instead of LIB.
>
> INCLUDE and LIB are used by Microsoft Visual C++ Compiler not GCC.
>
> Regards,
> Jonathan
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Accelerated/OpenGL drawing under Qt 5.0

[Chris Meyer]

On Thu, Sep 13, 2012 at 1:57 AM, Samuel Rødal  wrote:
> On 09/12/2012 04:33 PM, ext Chris Meyer wrote:
>> On Tue, Sep 11, 2012 at 9:52 PM, Chris Meyer  wrote:
>>> My software makes use of accelerated drawing using the techniques with
>>> QGraphicsView and QGraphicsScene shown in this article:
>>>
>>> http://doc.qt.nokia.com/qq/qq26-openglcanvas.html
>>>
>>> Unfortunately things don't work smoothly under Qt 5.0.
>>>
>>> Is this technique expected to work? If not, what is the suggested way
>>> to get accelerated drawing under Qt 5.0?
>
> It should still work, though there could still be bugs at this stage.
>
>>> Also, QGLPixelBuffer::hasOpenGLPbuffers() always returns false, where
>>> it returned it true under 4.8. Is this also expected?
>
> Hmm, I see that for now the QGLPixelBuffer implementation is stubbed out
> in Qt 5. I'd recommend using QOpenGLFramebufferObject instead, as pixel
> buffers are a pretty deprecated way of doing offscreen rendering with
> OpenGL these days.
>
>> As a further isolation of this problem... I'm finding that adding a
>> QGLWidget (not even customized) into my view hierarchy (QMainWindow ->
>> QWidget/QVBoxLayout -> QStackedWidget -> QWidget/QVBoxLayout ->
>> QGLWidget) makes bad things happen to layouts, displays and mouse
>> handling.
>>
>> Anyone have success with QGLWidget in a complex hierarchy on Qt 5.0 /
>> Mac OS 10.8.1? Any known issues?
>>
>> This issue looks similar, but I'm seeing it on the Mac:
>> https://bugreports.qt-project.org/browse/QTBUG-26826
>
> I'd suggest you create a separate task for it, with a simplified example.
>
> --
> Samuel

I've filed a bug and built a short test program to demonstrate on bug
with QGLWidget:

https://bugreports.qt-project.org/browse/QTBUG-27214
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QJsonPrivate::Parser::parseObject broken on big endian

[Konstantin Tokarev]

13.09.2012, 18:03, "Konstantin Tokarev" :
> 13.09.2012, 15:23, "lars.kn...@nokia.com" :
>
>>  As to why this would fail: The only reason I can see is if either dest is 
>> invalid, or b->size contains garbage.
>
> Indeed, b->size is 201326592 for emptyArray object.

I.e. 1100

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QJsonPrivate::Parser::parseObject broken on big endian

[Konstantin Tokarev]

13.09.2012, 15:23, "lars.kn...@nokia.com" :
> As to why this would fail: The only reason I can see is if either dest is 
> invalid, or b->size contains garbage.

Indeed, b->size is 201326592 for emptyArray object.

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: reorganization of QtSystems module, since Qt5.x

[Denis Shienkov]

> Alberto Mardegan wrote:

> BTW, one small thing you might want to change in your proposed
> implementation is switching from "device type" to "capability". It's
> sometimes very difficult to say what kind of device something is, but
> you can always say that it's capable of this and that (for example, a
> graphics card which provides HDMI audio).

Why? After all, if the video card has HDMI audio, then the OS will be two 
entities: 
one - the video card, 
other - audio device with capability HDMI. 

So I disagree with you.

The more so that the device OS divided into separate classes. Here is 
information 
on these classes of devices and need to displayed. I.e. divide the devices by 
classes, 
but not types, like:

enum ClassOfDevice {    }

For example, 
on Windows: 
http://msdn.microsoft.com/en-us/library/windows/hardware/ff553426%28v=vs.85%29.aspx
on Linux, like: 
http://www.mjmwired.net/kernel/Documentation/driver-model/class.txt
on MacOSX, like: similary

Regards,
Denis






13.09.2012, 16:47, "Alberto Mardegan" :
> On 09/13/2012 01:27 PM, Denis Shienkov wrote:
>
>>  For a start here can add only the basic types of devices (already 
>> implemented),
>>  and then on future can add new supported device types (step-by-step).
>>
>>  This is just pseudocode, I know that it contains errors. I just proposed 
>> the idea,
>>  so please do not judge strictly.
>
> Your API seems ideal for someone who has to implement a device manager
> application; however, as an application developer I'd expect that if I
> have to use a printer, mouse, or access the network, I would find all
> the needed functionality in the modules that handle these classes.
>
> I would expect to need to use QtSystems only if I need to access some
> very low-level data about the hardware.
>
> BTW, one small thing you might want to change in your proposed
> implementation is switching from "device type" to "capability". It's
> sometimes very difficult to say what kind of device something is, but
> you can always say that it's capable of this and that (for example, a
> graphics card which provides HDMI audio).
>
> Ciao,
>   Alberto
>
> --
> http://blog.mardy.it <- geek in un lingua international!
> ___
> 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] Building Qt5 on windows

[Jonathan Liu]

On 13/09/2012 8:57 PM, Алексей Павлов wrote:
/set 
INCLUDE=%MINGW_HOME%\%MINGW_HOST%\include;%EXTRA%\include;%QTINSTDIR%\databases\firebird\include;%QTINSTDIR%\databases\mysql\include;%QTINSTDIR%\databases\pgsql\include/
/set 
LIB=%MINGW_HOME%\%MINGW_HOST%\lib;%EXTRA%\lib;%QTINSTDIR%\databases\firebird\lib;%QTINSTDIR%\databases\mysql\lib;%QTINSTDIR%\databases\pgsql\lib/

GCC uses CPATH with paths separated by colons instead of INCLUDE.
GCC uses LIBRARY_PATH with paths separated by colons instead of LIB.

INCLUDE and LIB are used by Microsoft Visual C++ Compiler not GCC.

Regards,
Jonathan
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: reorganization of QtSystems module, since Qt5.x

[Alberto Mardegan]

On 09/13/2012 01:27 PM, Denis Shienkov wrote:
> For a start here can add only the basic types of devices (already 
> implemented), 
> and then on future can add new supported device types (step-by-step).
> 
> This is just pseudocode, I know that it contains errors. I just proposed the 
> idea, 
> so please do not judge strictly.

Your API seems ideal for someone who has to implement a device manager
application; however, as an application developer I'd expect that if I
have to use a printer, mouse, or access the network, I would find all
the needed functionality in the modules that handle these classes.

I would expect to need to use QtSystems only if I need to access some
very low-level data about the hardware.

BTW, one small thing you might want to change in your proposed
implementation is switching from "device type" to "capability". It's
sometimes very difficult to say what kind of device something is, but
you can always say that it's capable of this and that (for example, a
graphics card which provides HDMI audio).

Ciao,
  Alberto

-- 
http://blog.mardy.it <- geek in un lingua international!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Building Qt5 on windows

[Thiago Macieira]

On quinta-feira, 13 de setembro de 2012 14.57.50, Алексей Павлов wrote:
> *configure -prefix %QTINSTDIR% -opensource -confirm-license
> -developer-build -debug-and-release -no-fast -plugin-sql-ibase
> -plugin-sql-mysql -plugin-sql-psql -no-dbus -no-iconv -icu -fontconfig
> -system-pcre -fully-process -openssl -platform win32-g++ -nomake tests
> -nomake examples -I %EXTRA%\include -I %EXTRA%\include\libxml2 -L
> %EXTRA%\lib > %CURRDIR%qt5-configure.log*
>
> I have next configuration: http://tny.cz/b6b968d0
> Than I build with command mingw32-make and get error on QtSvg module:
> *qsvgtinydocument.cpp:58:18: fatal error: zlib.h: No such file or directory*
> compilation terminated.
> *qsvgtinydocument.cpp:58:18: fatal error: zlib.h: No such file or directory*
> compilation terminated.
> *mingw32-make[4]: *** [release/qsvgtinydocument.o] Error 1*
> *mingw32-make[4]: *** Waiting for unfinished jobs*
> *mingw32-make[4]: *** [debug/qsvgtinydocument.o] Error 1*
> *mingw32-make[4]: *** Waiting for unfinished jobs*
> *mingw32-make[3]: *** [debug-all] Error 2*
> *mingw32-make[3]: *** Waiting for unfinished jobs*
> *mingw32-make[3]: *** [release-all] Error 2*
> *mingw32-make[2]: *** [sub-svg-make_first-ordered] Error 2*
> *mingw32-make[1]: *** [sub-src-make_first] Error 2*
> *mingw32-make: *** [module-qtsvg-make_first] Error 2*
>
> But zlib.h present in c:\sdk\ported64\include. Why configure script not add
> INCLUDE and LIB to include paths and libs paths of svg module?
> Build log: http://tny.cz/b3ea0a8b

Can you attach the qtbase/mkspecs/qmodule.pri file that is generated? The
configure output includes:
INCLUDE  C:\SDK\mingw64\x86_64-w64-mingw32\include
  C:\SDK\ported64\include

So it seems correct, but I want to be sure.

Also, how did you run qmake in the qtsvg module? There's a gap in your
description.

Finally, please don't post HTML emails. As you can see above, your plain text
output is corrupted by having lots of * where there shouldn't be.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


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

[Development] Qt 4.8.3 released

[lars.knoll]

Hi!

I'm happy to announce that Qt 4.8.3 has just been released. 

See the blog on http://labs.qt.nokia.com/2012/09/13/qt-4-8-3-released/
and the changes file at 
http://qt-project.org/uploads/community_updates/changes-4.8.3 for details.

Enjoy!
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QJsonPrivate::Parser::parseObject broken on big endian

[lars.knoll]

On Sep 13, 2012, at 12:56 PM, ext Konstantin Tokarev  wrote:

> 03.09.2012, 15:21, "Olivier Goffart" :
> 
>>  On Sunday 02 September 2012 23:10:18 Konstantin Tokarev wrote:
>>>   Hi all,
>>> 
>>>   When building Qt 5 on big endian host (PPC) I've found moc breaking on Qt
>>>   classes containing Q_PLUGIN_METADATA with
>>> 
>>>   ASSERT: "idx >= 0 && idx < s" in file
>>>   ../../../include/QtCore/../../src/corelib/tools/qvarlengtharray.h, line 
>>> 111
>>> 
>>>   It turned out to be a fault of QJsonPrivate::Parser::parseObject which has
>>>   different code for handling of big endian and little endian cases:
>>> 
>>>   if (parsedObject.offsets.size()) {
>>>   int tableSize = parsedObject.offsets.size()*sizeof(uint);
>>   ^
>> 
>>  The error is there:  one should multiply tableSize by sizeof(uint) only if 
>> one
>>  do a memcpy.
>>>   table = reserveSpace(tableSize);
>>>   #if Q_BYTE_ORDER == Q_LITTLE_ENDIAN
>>>   memcpy(data + table, parsedObject.offsets.constData(), tableSize);
>>>   #else
>>>   offset *o = (offset *)(data + table);
>>>   for (int i = 0; i < tableSize; ++i)
>>>   o[i] = parsedObject.offsets[i];
>>> 
>>>   #endif
>>>   }
>>> 
>>>   Could anyone explain why memcpy cannot be used for big endian case here?
>>  I guess that's because the offsets needs to be stored in little endian.
>>  offset is a typedef to a class that has an assignement operator which swap 
>> the
>>  bytes.
> 
> It turned out to be not the only place where memcpy is working incorrectly.
> Unit test segfaults on memcpy in Value::copyData 
> 
> 404 case QJsonValue::Array:
> 405 case QJsonValue::Object: {
> 406 const QJsonPrivate::Base *b = v.base;
> 407 if (!b)
> 408 b = (v.t == QJsonValue::Array ? &emptyArray : &emptyObject);
> 409 memcpy(dest, b, b->size);
> 410 break;
> 411 }
> 
> I tried to understand why memcpy fails here and how to replace it for BE case,
> but still don't have a clue. I'm also quite disappointed to see so heavily 
> endian-
> dependent code written nowadays.

That's what you have to do when doing binary formats unfortunately. I think the 
main problem is that we currently don't have a big endian machine at hand for 
testing. I've tried to make it as endian independent as possible already, but 
without being able to test you're bound to have bugs in such code.

As to why this would fail: The only reason I can see is if either dest is 
invalid, or b->size contains garbage.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Building Qt5 on windows

[Алексей Павлов]

Hi!
I try to build Qt5 with mingw64 from
https://sourceforge.net/projects/mingwbuilds/ .
First I install strawberry perl 5.16.1, mingw64-4.7.1, build some libs
(openssl icu, fontconfig, libxml2,libxslt,zlib).
Than I wrote script:

*@echo on*
*
*
*set PWD=%~dp0*
*
*
*echo Seting up a Qt-64bit Environment...*
*echo -- QTINSTDIR set to %PWD%Qt64*
*
*
*set CURRDIR=%PWD%*
*set QTDIR=*
*set QTINSTDIR=%PWD%Qt64*
*set QTSRC=%PWD%srcs\Qt5*
*set EXTRA=%PWD%ported64*
*set MINGW_HOST=x86_64-w64-mingw32*
*set MINGW_HOME=%PWD%mingw64*
*
*
*set
INCLUDE=%MINGW_HOME%\%MINGW_HOST%\include;%EXTRA%\include;%QTINSTDIR%\databases\firebird\include;%QTINSTDIR%\databases\mysql\include;%QTINSTDIR%\databases\pgsql\include
*
*set
LIB=%MINGW_HOME%\%MINGW_HOST%\lib;%EXTRA%\lib;%QTINSTDIR%\databases\firebird\lib;%QTINSTDIR%\databases\mysql\lib;%QTINSTDIR%\databases\pgsql\lib
*
*set PYTHON_HOME=C:\SDK\Python27*
*set PERL_HOME=C:\SDK\strawberry*
*set MAKE_COMMAND=mingw32-make -j3*
*
*
*echo -- Adding %MINGW_HOME%\bin;%EXTRA%\bin to PATH*
*set
PATH=%QTSRC%\qtbase\bin;%QTSRC%\qtrepotools\bin;%MINGW_HOME%\bin;%EXTRA%\bin;%PERL_HOME%\perl\bin;%PERL_HOME%\perl\site\bin;%PATH%;
*
*
*
*cd %QTSRC%*
*configure -prefix %QTINSTDIR% -opensource -confirm-license
-developer-build -debug-and-release -no-fast -plugin-sql-ibase
-plugin-sql-mysql -plugin-sql-psql -no-dbus -no-iconv -icu -fontconfig
-system-pcre -fully-process -openssl -platform win32-g++ -nomake tests
-nomake examples -I %EXTRA%\include -I %EXTRA%\include\libxml2 -L
%EXTRA%\lib > %CURRDIR%qt5-configure.log*

I have next configuration: http://tny.cz/b6b968d0
Than I build with command mingw32-make and get error on QtSvg module:
*qsvgtinydocument.cpp:58:18: fatal error: zlib.h: No such file or directory*
*compilation terminated.*
*qsvgtinydocument.cpp:58:18: fatal error: zlib.h: No such file or directory*
*compilation terminated.*
*mingw32-make[4]: *** [release/qsvgtinydocument.o] Error 1*
*mingw32-make[4]: *** Waiting for unfinished jobs*
*mingw32-make[4]: *** [debug/qsvgtinydocument.o] Error 1*
*mingw32-make[4]: *** Waiting for unfinished jobs*
*mingw32-make[3]: *** [debug-all] Error 2*
*mingw32-make[3]: *** Waiting for unfinished jobs*
*mingw32-make[3]: *** [release-all] Error 2*
*mingw32-make[2]: *** [sub-svg-make_first-ordered] Error 2*
*mingw32-make[1]: *** [sub-src-make_first] Error 2*
*mingw32-make: *** [module-qtsvg-make_first] Error 2*

But zlib.h present in c:\sdk\ported64\include. Why configure script not add
INCLUDE and LIB to include paths and libs paths of svg module?
Build log: http://tny.cz/b3ea0a8b

I have successfully build qt5 in the end, but I have many errors that Ifix
in make files by hand.
I want to make Qt5 better)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QJsonPrivate::Parser::parseObject broken on big endian

[Konstantin Tokarev]

03.09.2012, 15:21, "Olivier Goffart" :

>  On Sunday 02 September 2012 23:10:18 Konstantin Tokarev wrote:
>>   Hi all,
>>
>>   When building Qt 5 on big endian host (PPC) I've found moc breaking on Qt
>>   classes containing Q_PLUGIN_METADATA with
>>
>>   ASSERT: "idx >= 0 && idx < s" in file
>>   ../../../include/QtCore/../../src/corelib/tools/qvarlengtharray.h, line 111
>>
>>   It turned out to be a fault of QJsonPrivate::Parser::parseObject which has
>>   different code for handling of big endian and little endian cases:
>>
>>   if (parsedObject.offsets.size()) {
>>   int tableSize = parsedObject.offsets.size()*sizeof(uint);
>   ^
>
>  The error is there:  one should multiply tableSize by sizeof(uint) only if 
> one
>  do a memcpy.
>>   table = reserveSpace(tableSize);
>>   #if Q_BYTE_ORDER == Q_LITTLE_ENDIAN
>>   memcpy(data + table, parsedObject.offsets.constData(), tableSize);
>>   #else
>>   offset *o = (offset *)(data + table);
>>   for (int i = 0; i < tableSize; ++i)
>>   o[i] = parsedObject.offsets[i];
>>
>>   #endif
>>   }
>>
>>   Could anyone explain why memcpy cannot be used for big endian case here?
>  I guess that's because the offsets needs to be stored in little endian.
>  offset is a typedef to a class that has an assignement operator which swap 
> the
>  bytes.

It turned out to be not the only place where memcpy is working incorrectly.
Unit test segfaults on memcpy in Value::copyData 

404 case QJsonValue::Array:
405 case QJsonValue::Object: {
406 const QJsonPrivate::Base *b = v.base;
407 if (!b)
408 b = (v.t == QJsonValue::Array ? &emptyArray : &emptyObject);
409 memcpy(dest, b, b->size);
410 break;
411 }

I tried to understand why memcpy fails here and how to replace it for BE case,
but still don't have a clue. I'm also quite disappointed to see so heavily 
endian-
dependent code written nowadays.

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Proposal: reorganization of QtSystems module, since Qt5.x

[Denis Shienkov]

Hello all.

As I'm concerned, at the moment Qt5 contains fragmented set of classes to 
obtain information about the devices:

QPrinterInfo   -> QtBase/src/printsupport
others info's  -> QtSystems/

Since all of these entities are devices, it is logical to make the base
class QDeviceInfo, from which derive all of the specific types of devices
infos, like:

class QDeviceInfo : public QObject
{
...
}

class QStorageInfo : public QDeviceInfo
{
...
}

...
...

class QNetworkAdapterInfo : public QDeviceInfo
{
...
}

Next, can create a separate class - watcher type QDeviceManeger (singleton), 
which could provide a list of all available devices to send signals about 
connecting/disconnecting devices, etc.

class QDeviceManager : public QObject
{
public:

enum DeviceType {
SerialPort,
LptPort,
MidiPort,
NetworkAdapter,
VideoAdapter,
AudioAdapter,
Monitor,
Drive,
...
AllTypes
};

QList devicesInfo(DeviceType dt = AllTypes);
void enableWatchForType(DeviceType dt = AllTypes);
bool isEnabledWatchForType(DeviceType dt = AllTypes);

// Maybe add another methods

signals:
void connected(const QDeviceInfo &info);
void disconnected(const QDeviceInfo &info);

// Maybe add another signals
}

For a start here can add only the basic types of devices (already implemented), 
and then on future can add new supported device types (step-by-step).

This is just pseudocode, I know that it contains errors. I just proposed the 
idea, 
so please do not judge strictly.

Pros:
+ QtSystems module is already available, you just need to extend it.
+ This solution will integrate all the disparate components of information in 
one place.
+ Flexibility: you want - include the module, and you want - not.
+ Common notifier for all devices in which you can register and subscribe to 
events on the desired device type.

Cons:
- To use printing support need for a separate module QtSystems. Although 
previously
it was not required.
- Implementation is complex.

I'm waiting for comments and suggestions. :)


Best regards,
Denis
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qmake qt5

[Joerg Bornemann]

On 12/09/2012 23:44, ext Sylvain Pointeau wrote:

> QMAKE_TARGET and TARGET in the makefile were blank.
> once I changed them, it was ok, at least trying to compile.

You should not need to specify TARGET. qmake chooses a default value.
But .pro files that explicitely set TARGET to be empty will produce 
empty TARGET variables in Qt 5.

Cheers,

Jörg

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Accelerated/OpenGL drawing under Qt 5.0

[Samuel Rødal]

On 09/12/2012 04:33 PM, ext Chris Meyer wrote:
> On Tue, Sep 11, 2012 at 9:52 PM, Chris Meyer  wrote:
>> My software makes use of accelerated drawing using the techniques with
>> QGraphicsView and QGraphicsScene shown in this article:
>>
>> http://doc.qt.nokia.com/qq/qq26-openglcanvas.html
>>
>> Unfortunately things don't work smoothly under Qt 5.0.
>>
>> Is this technique expected to work? If not, what is the suggested way
>> to get accelerated drawing under Qt 5.0?

It should still work, though there could still be bugs at this stage.

>> Also, QGLPixelBuffer::hasOpenGLPbuffers() always returns false, where
>> it returned it true under 4.8. Is this also expected?

Hmm, I see that for now the QGLPixelBuffer implementation is stubbed out
in Qt 5. I'd recommend using QOpenGLFramebufferObject instead, as pixel
buffers are a pretty deprecated way of doing offscreen rendering with
OpenGL these days.

> As a further isolation of this problem... I'm finding that adding a
> QGLWidget (not even customized) into my view hierarchy (QMainWindow ->
> QWidget/QVBoxLayout -> QStackedWidget -> QWidget/QVBoxLayout ->
> QGLWidget) makes bad things happen to layouts, displays and mouse
> handling.
> 
> Anyone have success with QGLWidget in a complex hierarchy on Qt 5.0 /
> Mac OS 10.8.1? Any known issues?
> 
> This issue looks similar, but I'm seeing it on the Mac:
> https://bugreports.qt-project.org/browse/QTBUG-26826

I'd suggest you create a separate task for it, with a simplified example.

--
Samuel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposing reversal of the Math3D qreal->float change

[Giuseppe D'Angelo]

On 13 September 2012 09:39, Jedrzej Nowacki  wrote:
> I would love to kill qreal but... please go for (a). The discussion was
> already finished once with conclusion that we should not do anything about
> it for Qt5. Let's stick to the decision. The feature freeze was in February.
> It is time to release not to do major changes.

How about at least unifying the internal storages to qreal instead of
having QVector* using floats internally and qreals in the API?
-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtDus Problem

[Thiago Macieira]

On quarta-feira, 12 de setembro de 2012 20.40.28, Sandro Andrade wrote:
> > when i execute Quit() from d-feet, my RootAdapter Quit() funciton gets
> > called, but i get this error:
> > Warning: QMetaObject::invokeMethod: No such method QObject::Quit()
>
> Is the Quit() method a slot or was declared with Q_INVOKABLE ?

I also recommend running qdbusxml2cpp using the -l option. This will make the
adaptor place a direct call, instead of QMetaObject::invokeMethod.

PS: your question is not a QtDBus development issue. Let's continue this on
the interest@ mailing list.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


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] Proposing reversal of the Math3D qreal->float change

[Jedrzej Nowacki]

On Wednesday 12. September 2012 09.10.52 ext lars.kn...@nokia.com wrote:
> On Sep 12, 2012, at 12:27 AM, ext André Pönitz  wrote:
> > On Tue, Sep 11, 2012 at 10:34:50PM +0100, Sean Harmer wrote:
> >> On 11/09/2012 13:34, Thiago Macieira wrote:
> >>> I propose we revert it.
> >> 
> >> I propose we (I) fix the affected classes in QtMultimedia
> >> and Qt3D. I'm away on business this week but I will make a
> >> start asap.
> > 
> > I believe I mentioned that before. Anyway:
> > 
> > I think there are (medium term) only two acceptable solutions,
> > none of them perfect:
> > (a) keep everything as it is (or, rather, "was")
> > (b) have fully functional real/double "verticals"
> 
> (c) Turn qreal into a double everywhere

I would love to kill qreal but... please go for (a). The discussion was 
already finished once with conclusion that we should not do anything about it 
for Qt5. Let's stick to the decision. The feature freeze was in February. It 
is time to release not to do major changes.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposing reversal of the Math3D qreal->float change

[Alberto Mardegan]

On 09/13/2012 11:27 AM, marco.bu...@nokia.com wrote:
[...]
> Q*F and Q*D like QRectF and QRectD? But the first step would be in my
> opinion the removal of qreal. It should be really KISS!

OTOH, having a typedef which you can change to be either float or double
according to your precision needs (and hardware possibilities) can be
quite handy.

Ciao,
  Alberto

-- 
http://blog.mardy.it <- geek in un lingua international!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposing reversal of the Math3D qreal->float change

[Thiago Macieira]

On terça-feira, 11 de setembro de 2012 22.44.52, Sean Harmer wrote:
> On 11/09/2012 22:39, Thiago Macieira wrote:
> > On terça-feira, 11 de setembro de 2012 22.34.50, Sean Harmer wrote:
> >> I propose we (I) fix the affected classes in QtMultimedia and Qt3D. I'm
> >> away on business this week but I will make a start asap.
> >
> > Qt3D is now passing.
>
> Yes it is passing. I will prepare a patch to remove the usage of qreal
> and see if the maintainer of that module agrees with it or not and take
> it from there.
>
> > I'll correct the compilation errors for QtMultimedia, but not the tests.
> > If
> > tests show failures, we'll wait for you or someone else.
>
> OK, thank you. I'll do my best to address any failures in a timely manner.

QtMultimedia compiled and passed the tests.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


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] Proposing reversal of the Math3D qreal->float change

[marco.bubke]

No, it changed the expectations. People develop with qreal as double, and than 
magic things happen on ARM. My proposal is, that we change most interfaces to 
double, there it really costs, we switch to float. 

Otherwise we break our interfaces. For example, a application is saving world 
coordiantes in qreal(QPointF), this is fine with qreal as double, but you get 
in trouble if qreal is float(I was told so). So, this application can only run 
cross platform, if we stick to our interface and don't change it magically. 
Maybe we should introduce Q*F and Q*D like QRectF and QRectD? But the first 
step would be in my opinion the removal of qreal. It should be really KISS!

From: ext Romain Pokrzywka [romain.pokrzy...@kdab.com]
Sent: Thursday, September 13, 2012 2:10 AM
To: development@qt-project.org
Cc: Bubke Marco (Nokia-MP/Berlin); Knoll Lars (Nokia-MP/Oslo); 
andre.poen...@mathematik.tu-chemnitz.de; sean.har...@kdab.com
Subject: Re: [Development] Proposing reversal of the Math3D qreal->float change

On Wednesday, September 12, 2012 09:20:15 AM marco.bu...@nokia.com wrote:
> On Sep 12, 2012, at 12:27 AM, ext André Pönitz  wrote:
> > Version (a) means the current mess will go on. but it has the
> > distict charme of (a.1) not breaking anyones existing code and
> > (a.2) sticking to feature freeze rules.
>
> If somebody porting his app to ARM he will be surprised, because we change
> qreal to float. Sorry, this is cross platform magic. Actually change qreal
> explicitly to double is much better, because it is explicit.

No this won't change anything, because qreal is already float on ARM
platforms.

>
> I would opt for a explicit removal of qreal and exchange it with double!
>
> ___
> 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] Proposing reversal of the Math3D qreal->float change

[lars.knoll]

On Sep 13, 2012, at 2:07 AM, ext Romain Pokrzywka  
wrote:

> On Wednesday, September 12, 2012 07:10:52 AM lars.kn...@nokia.com wrote:
>> On Sep 12, 2012, at 12:27 AM, ext André Pönitz  chemnitz.de> wrote:
>>> On Tue, Sep 11, 2012 at 10:34:50PM +0100, Sean Harmer wrote:
 On 11/09/2012 13:34, Thiago Macieira wrote:
> I propose we revert it.
 
 I propose we (I) fix the affected classes in QtMultimedia
 and Qt3D. I'm away on business this week but I will make a
 start asap.
>>> 
>>> I believe I mentioned that before. Anyway:
>>> 
>>> I think there are (medium term) only two acceptable solutions,
>>> none of them perfect:
>>> (a) keep everything as it is (or, rather, "was")
>>> (b) have fully functional real/double "verticals"
>> 
>> (c) Turn qreal into a double everywhere
>> 
>> This was rejected before by some, because it might make things slower on
>> ARM, but would have the advantage that it's fully source compatible with Qt
>> 4, solves the mess and would allow us to introduce floating point types
>> where required later.
>> 
>> Only minuses I can see are
>> (c1) the names of QXxxF classes which are double and not float based
>> (c2) possibly slower execution on ARM
>> (c3) Somewhat higher memory consumption on ARM
>> 
>> (c1) is not easily fixed. But (c2) seems to be less of an issue these days.
>> At least for the Cortex A9 ARM claims very good double precision support.
>> Older CPUs also have some support through VFPv2/3. (c3) should also become
>> less and less of an issue moving forward.
>> 
>> So to bring this up again: How about turning qreal into a typedef for double
>> on all platforms and remove the mess this way? Whereever we need (or want
>> to use) floats, let's use them explicitly.
> 
> I think the statements "might make things slower on ARM" and  "seems to be 
> less of an issue these days" are a little misleading and too optimistic.
> 
> From my own experience, using double on ARM has a serious impact on 
> performance at many levels: data size, code generation, and even FPU options.
> 
> Indeed, from what I've read it seems like the Cortex-A9 is significantly 
> closing the gap between float and double (although not eliminating it), but's 
> it's really the only platform that does. [1]

True, but more and more embedded systems will start using that platform. My 
main proposal is that the default (and supported) build of Qt on ARM uses 
doubles for qreal. If we keep the typedef, you could still typedef it to use 
float at your own risk :)
> 
> Every other platform, Cortex-A8 and previous ARM architectures, and even 
> Intel 
> Atom, will suffer badly from switching from floats to doubles, even though 
> they have VFP.
> 
> This is mainly due to the crappy VFP abilities in those platforms, combined 
> with the Cortex-A8 allowing use of the NEON co-processor as the FPU, with 
> massive performance improvements over VFP, but only available for floats. [2]
> 
> And it gets even worse when using -mfloat-abi=softfp. [3]

Yes, but softfp doesn't make sense with Qt Quick 2 anyway.
> 
> Now, considering that most usage of Qt on embedded platforms is either 
> through 
> QGraphicsView or Qt Quick (1 and 2), both of them relying heavily on floating 
> point calculations (coordinate systems, painting with AA...), this is 
> definitely a decision with a potentially serious impact on most embedded 
> platforms.

One solution here is to explicitly use floats internally in Qt wherever 
possible and where it's critical to performance.
> 
> One may still argue that Qt5 should be targeting the latest and future 
> platforms instead of legacy and current ones. Fair enough. But I think the 
> consequences should be stressed more. Some extensive benchmarking would be 
> nice too, before deciding on one solution against the other.

As said above: It's about the default build that the Qt Project tests and 
supports.

We can keep the option of forcing qreal to float at least for now or until 
we've proven that the performance impact is acceptable.

Cheers,
Lars

> 
> [1] http://www.360doc.com/content/12/0806/14/350555_228637047.shtml
> [2] 
> http://processors.wiki.ti.com/index.php/Cortex_A8#Neon_and_VFP_both_support_floating_point.2C_which_should_I_use.3F
> [3] http://wiki.debian.org/ArmHardFloatPort/VfpComparison
> 
> Regards,
> Romain
> -- 
> Romain Pokrzywka | rom...@kdab.com | Senior Qt Software Engineer & Trainer
> 650-632-4409
> 303 Twin Dolphin Dr., Redwood City, CA-94065
> KDAB (USA) LLC, a KDAB Group company
> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - Qt Experts - Platform-independent software solutions
> 
>> 
>> Cheers,
>> Lars
>> 
>>> Version (a) means the current mess will go on. but it has the
>>> distict charme of (a.1) not breaking anyones existing code and
>>> (a.2) sticking to feature freeze rules.
>>> 
>>> Version (b) is somewhat closer to a proper solution, but fails
>>> (a.1) and (a.2). It has also the disadvantage of requiring real
>>> work,