Re: [Development] 5.7 new features and 5.6 changelog

[Peter Kümmel]

Am 16.02.2016 um 08:29 schrieb Knoll Lars:

Hi everybody,

It would be great if those of you who haven’t done so yet fill in the 5.7 new 
features page on the wiki (https://wiki.qt.io/New_Features_in_Qt_5.7), so that 
we can get a good overview over the bigger new features in 5.7.

In addition, I’d like to ask every maintainer to have a look at the 5.6 
changelog files, and checks that everything ok and the changelog is complete 
for your area.

Thanks,
Lars


A question about the new license-feature:

- projects under the GPLv2 can not use a LGPLv3 library (Qt only as GPLv2)
- LGPLv2.1 projects that want to use an LGPLv3 library. They must be upgraded 
to LGPLv3

( http://nmav.gnutls.org/2013/03/the-perils-of-lgplv3.html )


Don't you fear a lot of projects will only use 5.6 and never upgrade to higher 
versions?

Peter




___
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] HEADS-UP: Qt 5.4.2 release coming

[Peter Kümmel]

On 23.04.2015 14:30, René J.V. Bertin wrote:
> On Thursday April 23 2015 11:13:41 Peter Kuemmel wrote:
>> René, maybe this helps you a bit:
>>
>> https://codereview.qt-project.org/#/c/111056/
>>
>> It's only a incomplete copy and paste of your Qt 4 patch,
>> but it could show you the direction.
>
> Hi Peter,
>
> Thanks!
>
> Why an incomplete copy/paste? I see it's missing the changes to 
> tools/qtconfig/mainwindow.cpp, did you omit other changes as well?

Wasn't qtconfig removed from Qt5?

>
> R.
>

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

Re: [Development] HEADS-UP: Qt 5.4.2 release coming

[Peter Kümmel]

On 23.04.2015 20:31, René J.V. Bertin wrote:
> On Thursday April 23 2015 16:58:05 Peter Kuemmel wrote:
>
>> Because the gerrit code is Qt5 not Qt4.
>
> Doh ... I wondered about that and should have realised it was the case seeing 
> the dialoghelper file on the list.
>
>> So it needs a complete review and test by you if it works on Mac,
>
> Actually, I am still working on a Qt 5 version. Porting the OS X specific 
> changes of the Qt 4 patch was relatively straightforward, but the Linux code 
> needs some attention as well. That's a bit problematic because I don't 
> currently have a Linux rig powerful enough to build Qt, but also I can't find 
> the x11/xcb/freetype equivalent to qcocoafontdialoghelper.mm ...
> Anyway, the current patch for Qt 5 (5.4.1) is here: 
> https://github.com/RJVB/mp-port-repository/blob/master/aqua/qt5-mac-devel/files/patch-improve-fontweight-support.diff

I would start only with the Mac changes, and if they get accepted, you/one 
could change the other systems
(where the folk is not that sensitive on font stuff ;) )

>
>
> I looked at the gerrit comments, and one made me wonder: is Qt no longer the 
> product of a European company? I'm pretty sure trolls are a EU species, who 
> if they could write without errors would use an EU language and spelling ;)
>
> R.
>

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

Re: [Development] Qmake Ninja generator

[Peter Kümmel]

On 19.05.2014 10:57, Oswald Buddenhagen wrote:
> On Sun, May 18, 2014 at 05:29:56PM +0200, Adam Strzelecki wrote:
>> Hello,
>>
>> I wonder if there was any work done in regards of making Ninja Qmake 
>> generator. From my experience Ninja vastly improves (re)build time.
>
>> I wonder if it would be hard to make such generator,
>>
> yes. you'd need to do *massive* refactoring to make this feasible.

And nobody wanna dive into the qmake code ...
So I assume there will be never ninja support in qmake.

A compromise would be that cmake could read Qbs files. Then you get
all CMake generators for free. And it is a step in the direction of
adding a (declarative) language to cmake.

>
>> or if anyone tried to do it already.
>>
>> Cheers,
>> --
>> Adam
>> ___
>> 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] Qmake Ninja generator

[Peter Kümmel]

On 30.05.2014 23:59, Adam Strzelecki wrote:
> Moreover it takes more to build qt-creator with Qbs (20min) than Qmake+make 
> (18min). Also it doesn't support precompiled headers, at least not for 
> qt-creator, where Qmake+make+PCH goes down to 9min.

Strange, I thought qbs improves build times.

>
>> Neither cmake nor qmake build anything, they just generate makefiles or 
>> project files. In that respect qmake and cmake are quite alike. Qbs is a 
>> full-featured build tool: it takes care of generating the DAG *and* 
>> executing it. It’s like qmake and ninja in one.
>
> Qbs doing both configure & build isn't really advantage to me. Once Qbs have 
> similar feature coverage as CMake and (re)builds faster than ninja, or maybe 
> generates less bloated ninja/Makefile/Xcode projects, supports some caching, 
> or distributed build and finally has decent documentation, then it may be 
> considered as new promising alternative.
>
> Opposite, I take as advantage ninja being little independent build only tool, 
> because anyone can decide how to generate build files for Ninja.
>
>> In the long run I think Qt either need Qbs as the default build system, or 
>> ninja support in qmake.
>
> Agreed.
>
>> Ninja makes all the difference when building llvm. On a modern system I can 
>> get null llvm rebuild times on the order of 100ms with ninja, and under a 
>> second with a single changed .cpp file - and that’s a big project. The 1 
>> second single-file rebuilds on fairly small make-based projects (like 
>> examples bundled with Qt) are really bad. With cmake+ninja, a single changed 
>> .cpp rebuild of a small Qt example on OS X takes about 250ms.
>
> Yes, this was whole point starting this thread. Working on big project with 
> ninja is awesome if you rebuild and run many times.
>
> Also I wish to express my thanks to Qt developers for great CMake+ninja 
> support in Qt Creator, as IMHO Qt Creator is best C++ editor (IDE) around the 
> globe. Working with such huge codebase like LLVM/Clang is a pleasure in QtC.
>
> Regards,
>

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

Re: [Development] Question about Qt's future

[Peter Kümmel]

On 28.04.2014 18:01, Tony Van Eerd wrote:
>>
>> On 25.04.2014 12:18, Joerg Bornemann wrote:
>>>
>>> Yep, I hear people keep repeating the mantra "QML is declarative. It's
>>> just QML/JS that isn't."
>>
>> I think the "declarative-mantra" is a good idea, especially when used for
>> _specifying_ (not programming) the GUI.
>>
>> At Adobe they tried it with pure C++
>>
>> http://stlab.adobe.com/group__asl__overview.html#asl_overview_adam_a
>> nd_eve_architecture
>> which consequently ended up in a template/boost massacre. Looks like is is
>> dead now.
>>
>
> https://github.com/stlab
>
> "I'm not dead.  I'm getting better.  I think I'll go for a walk."
>
> Sean Parent left Adobe for a while (was at Google) but now is back at Adobe, 
> and there seems to be life in ASL again (and it wasn't exactly dead when he 
> was gone either).

Thanks, didn't noticed they moved to github.

>
> The code might be templates/boost (is that a bad thing?) but the declarative 
> language is pretty straightforward.
>
>
>

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

Re: [Development] Question about Qt's future

[Peter Kümmel]

On 28.04.2014 16:00, Roland Winklmeier wrote:
> 2014-04-27 13:31 GMT+02:00 Peter Kümmel  <mailto:syntheti...@gmx.net>>:
>
> On 21.04.2014 13 :39, Roland Winklmeier wrote:
>  > - Memory consumption: Even a mini example took about 70 MB of memory,
>  > QtWidgets need a lot less. This is not a complain, I know the JS 
> runtime
>  > needs its initial memory. It was just one factor, because our
>  > application is running as an addon to Flight Simulators and they usally
>  > consum a lot memory. This is especially a major problem with MS Flight
>  > Simulator since it is only available as 32 bit application. Therefore
>  > every any MegaByte is important.
>
> Especially on "non-fat" embedded systems this is a problem:
> When you wanna use Linux you need some MBs Ram for the kernel,
> some to get a running system, and some MBs for your application.
> So you end at minimum 5-32MBs.
> Then adding 100MB just to run QML really hurts, and you start
> looking for alternatives, like using only QWidgets with very
> limited OpenGL support or not to use a Qt-GUI at all.
>
> Maybe such systems are also interesting from a business perspective.
>
>
> I did a test with Qt 5.3 beta using an nearly empty dialog and the numbers 
> aren't that bad:
>
> Dialog with two buttons and one menu (release build)
> QtWidgets: about 15 MB
> QML: about 29 MB.

Thanks, looks much better than 70MB.

Peter

>
> The numbers came from TaskManager, so no idea how reliable they are.
> The 70 MB came from a more complex application. I cannot tell how memory 
> increase is associated with the complexity of a
> QML project. So one would really need to perform a more sophisticated 
> benchmark. But its definitely not 100 MB just for
> the JS engine. Sorry if I caused confusion or mixed the numbers in my head.
>
>
>
> ___
> 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] Question about Qt's future

[Peter Kümmel]

On 28.04.2014 09:32, Gunnar Sletta wrote:
>> ATM the problem is to get started because I don't know much about the
>> current architecture of the graphic stack.
>
> http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html
> http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph-renderer.html
>
>> Any hints where to start for a first hello world?
>
> I started on this some time ago, but it has been sitting there ever since as 
> the interest for splitting it out has been non-existent. It will for sure not 
> compile, but it contains the "general idea" :)
>
> https://codereview.qt-project.org/#change,52682

Many thanks, this is more than I hoped to see in a reply!
I will definitely have a look at it.

Peter

>
> cheers,
> Gunnar
>
>

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

Re: [Development] Question about Qt's future

[Peter Kümmel]

On 28.04.2014 09:26, Thiago Macieira wrote:
> Em seg 28 abr 2014, às 08:33:23, Peter Kümmel escreveu:
>>>> ATM the problem is to get started because I don't know much about the
>>>> current architecture of the graphic stack.
>>>> Any hints where to start for a first hello world?
>>>
>>> Maybe a translation from QML to a .ui file could be a first step? That
>>> could work if you use QtWidgets in the QML file.
>> I think we should start on top of the C/C++ part of current QMLv2 stack (if
>> such a thing exists), with some handwritten widget code. Otherwise we have
>> a QPainter based system which we already have with QWidgets.
>
> Forget about QPainter.

Yes, this I wanted to say.

>
> Your first step, it seems to me, would be to add the necessary C++ public API
> to QtQml so you can instantiate new items in the QML graph, then manipulate
> their properties and bindings, as well as set new JavaScript code and
> expressions. This simply replaces the QML parser, keeping all the benefits 
> (and
> problems) of the QML language. In particular, it does not extricate the JS
> interpreter and engine.
>
> If you want to extricate the JS engine, you probably need to move the Scene

Initially I thought this would be important, but if JS is just another
foreign language (like OpenGL shaders) deep in the drawing stack invisible
to the C++ developer it doesn't hurt.
At least it seems to me this is the only way to see some progress
within the time frame of a after-work project.

> Graph classes out of QtQuick and into a module that depends only on QtGui,
> bypassing the QtQml dependency. You'll need a way to insert generic items into
> the graph. But, at this point, I question: why don't you just use an existing
> OpenGL scene graph, like Ogle3D?

Goal is still to have desktop widgets within the Qt framework.

>
> Once you've got the base API, you can start thinking of writing widgets again,
> the platform look and feel. If the QtQml dependency was maintained, it might
> be possible to reuse the code from Qt Quick Components. If not, you'll
> probably need to start from scratch.

This would be the tedious part.

Peter


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

Re: [Development] Question about Qt's future

[Peter Kümmel]

On 28.04.2014 08:10, Kurt Pattyn wrote:
>
>
>> On 28 Apr 2014, at 07:53, Peter Kümmel  wrote:
>>
>>> On 27.04.2014 22:40, Thiago Macieira wrote:
>>>> Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu:
>>>>> On 26.04.2014 17:39, André Pönitz wrote:
>>>>> You could have made the point "declarative structures are good for GUI
>>>>> description" for Qt Widget's .ui files, after all, .ui files contents
>>>>> pretty much _is_ declaring layout nesting and property values.
>>>>
>>>> Just an idea:
>>>> Declarative-only QML files could be translated to C++ by a tool similar
>>>> to uic, and then used by a C++-only successor of QtWidgets.
>>>>
>>>> Or are there any technical reasons why all the state-of-the-features
>>>> provided by QML v2 could not be implemented on the C++ side assuming
>>>> there is a QML-to-C++ code generation step?
>>>
>>> It's possible, but there's no API in the C++ side to create the graph. Until
>>> such an API exists, you can't write the generator.
>>
>> I know that currently there is no support for this in Qt, also no plans
>> to add it, all I wanted to hear is "It's possible".
>>
>> I assume it would be only a community-driven long-term project, which takes
>> years until it is on par with QtWidgets. But hey, I'm fascinated by the idea,
>> and maybe I'm not alone.
>>
>> ATM the problem is to get started because I don't know much about the
>> current architecture of the graphic stack.
>> Any hints where to start for a first hello world?
>
> Maybe a translation from QML to a .ui file could be a first step? That could 
> work if you use QtWidgets in the QML file.

I think we should start on top of the C/C++ part of current QMLv2 stack (if 
such a thing exists), with some handwritten
widget code. Otherwise we have a QPainter based system which we already have 
with QWidgets.

>>
>>
>>>
>>> Care to contribute the C++ side, including passing all the reviews? Note 
>>> that
>>> this is a major undertaking and will probably take two or three releases to
>>> get a minimal functional API out there. Plus the maintenance effort.
>>
>> ___
>> 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] Question about Qt's future

[Peter Kümmel]

On 28.04.2014 00:55, André Pönitz wrote:
> On Sun, Apr 27, 2014 at 01:37:33PM -0700, Thiago Macieira wrote:
>> Em dom 27 abr 2014, às 12:55:58, Peter Kümmel escreveu:
>>> Having imperative code on the JS side is also the root of the rejection of
>>> QML for many C++ developers. If QML would have been just a improved .ui
>>> nobody would have complained.
>>
>> We'd end up with one of the problems of CSS which is that you can't do
>> calculations in the bindings. I can't do
>>
>>  width: 50% - 10em
>>
>> The moment you start adding some math, you need stuff like Math.random() and
>> you end up again in JS.
>
> Not true. Some (basic) math fits the "declarative" needs, and would
> be toolable. Math.random() does obviously not fit the bill.

Yes, isn't math by definition only functional, all they talk about is
"Given A and B with ... then exists F(A)->B.   ... q.e.d." ;)

Sorry to all mathematician.

>
> Andre'
> ___
> 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] Question about Qt's future

[Peter Kümmel]

On 27.04.2014 22:41, Thiago Macieira wrote:
> Em dom 27 abr 2014, às 13:31:33, Peter Kümmel escreveu:
>> Then adding 100MB just to run QML really hurts, and you start
>> looking for alternatives, like using only QWidgets with very
>> limited OpenGL support or not to use a Qt-GUI at all.
>
> Of those 100 MB, 30 MB are taken by QtCore and QtGui (including ICU data). The
> rest, I'm guessing you pulled the numbers out of thin air without a benchmark.
>

Yes, only a wild guess based on the numbers provided by Roland.
Currently I have a QWidget based system which runs with 32MB,
and I would not even try QML on this board, but maybe I'm too
pessimistic. (hint: here Digia's marketing has to jump in ;) )

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

Re: [Development] Question about Qt's future

[Peter Kümmel]

On 27.04.2014 22:40, Thiago Macieira wrote:
> Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu:
>> On 26.04.2014 17:39, André Pönitz wrote:
>>> You could have made the point "declarative structures are good for GUI
>>> description" for Qt Widget's .ui files, after all, .ui files contents
>>> pretty much _is_ declaring layout nesting and property values.
>>
>> Just an idea:
>> Declarative-only QML files could be translated to C++ by a tool similar
>> to uic, and then used by a C++-only successor of QtWidgets.
>>
>> Or are there any technical reasons why all the state-of-the-features
>> provided by QML v2 could not be implemented on the C++ side assuming
>> there is a QML-to-C++ code generation step?
>
> It's possible, but there's no API in the C++ side to create the graph. Until
> such an API exists, you can't write the generator.

I know that currently there is no support for this in Qt, also no plans
to add it, all I wanted to hear is "It's possible".

I assume it would be only a community-driven long-term project, which takes
years until it is on par with QtWidgets. But hey, I'm fascinated by the idea,
and maybe I'm not alone.

ATM the problem is to get started because I don't know much about the
current architecture of the graphic stack.
Any hints where to start for a first hello world?


>
> Care to contribute the C++ side, including passing all the reviews? Note that
> this is a major undertaking and will probably take two or three releases to
> get a minimal functional API out there. Plus the maintenance effort.
>

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

Re: [Development] Question about Qt's future

[Peter Kümmel]

On 21.04.2014 13:39, Roland Winklmeier wrote:
> - Memory consumption: Even a mini example took about 70 MB of memory,
> QtWidgets need a lot less. This is not a complain, I know the JS runtime
> needs its initial memory. It was just one factor, because our
> application is running as an addon to Flight Simulators and they usally
> consum a lot memory. This is especially a major problem with MS Flight
> Simulator since it is only available as 32 bit application. Therefore
> every any MegaByte is important.

Especially on "non-fat" embedded systems this is a problem:
When you wanna use Linux you need some MBs Ram for the kernel,
some to get a running system, and some MBs for your application.
So you end at minimum 5-32MBs.
Then adding 100MB just to run QML really hurts, and you start
looking for alternatives, like using only QWidgets with very
limited OpenGL support or not to use a Qt-GUI at all.

Maybe such systems are also interesting from a business perspective.

>
> ___
> 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] Question about Qt's future

[Peter Kümmel]

On 26.04.2014 17:39, André Pönitz wrote:
>
> You could have made the point "declarative structures are good for GUI
> description" for Qt Widget's .ui files, after all, .ui files contents
> pretty much _is_ declaring layout nesting and property values.

Just an idea:
Declarative-only QML files could be translated to C++ by a tool similar
to uic, and then used by a C++-only successor of QtWidgets.

Or are there any technical reasons why all the state-of-the-features
provided by QML v2 could not be implemented on the C++ side assuming
there is a QML-to-C++ code generation step?


Having a clear cut between declarative and imperative QML would
also improve visibility of specification- and implementation-parts
of a QML file.

> ___
> 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] Question about Qt's future

[Peter Kümmel]

On 25.04.2014 12:18, Joerg Bornemann wrote:
>
> Yep, I hear people keep repeating the mantra "QML is declarative. It's
> just QML/JS that isn't."

I think the "declarative-mantra" is a good idea, especially when used for
_specifying_ (not programming) the GUI.

At Adobe they tried it with pure C++
  
http://stlab.adobe.com/group__asl__overview.html#asl_overview_adam_and_eve_architecture
which consequently ended up in a template/boost massacre. Looks like is is dead 
now.

QML is also a nice try, but it got messed up with the imperative part.
Maybe because the temptation was too overwhelming to use the already integrated
JS engine for more stuff than running declarative part.

Having imperative code on the JS side is also the root of the rejection of QML
for many C++ developers. If QML would have been just a improved .ui nobody would
have complained.


> ___
> 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] Question about Qt's future

[Peter Kümmel]

On 24.04.2014 21:15, Attila Csipa wrote:
> solutions to cross platform mobile development :( After playing a bit
> with Xamarin (yes, I know, but put aside the C# hate for a minute), it's
> quite striking what different approaches can result in (and it also made
> it quite clear what Qt is doing better - but also worse than other cross
> platform solutions).

Recently I also has to write some non-GUI code  in C# (a simple class
to connect to a server written in C++/Qt using Google's protobuf).

First I was a bit annoyed about this, but after "putting away the C# hate"
it wasn't that bad. He some impressions:
- for my use case it was cross-platform out-of-the box (Windows/Linux)
- you don't have to care about the build system, just use the .sln files
- you have the feeling to write code in a hurry because everything is placed in 
the headers
- you realize that C++ compilers/language is much more powerful, especially 
when using generics
- you've lost the contact to the real hardware, all feels so smooth
- you don't see what's going on because of all the stuff in the background (ok 
until there are problems)

As said I didn't build a GUI, what are your experiences with the GUI part C#?

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

Re: [Development] New Qt5.3 RC snapshot available

[Peter Kümmel]

On 22.04.2014 07:17, Heikkinen Jani wrote:
> Hi all,
>
> We have new RC snapshot available in 
> http://download.qt-project.org/snapshots/qt/5.3/5.3.0-RC/2014-04-21_65/

I tried to update my build scripts, but there are no source packages available.
Isn't a RC a simulation of the release?

Thanks,
Peter


>
> Mirroring is ongoing but all installers should be available later today. 
> Please test these & verify your fixes!
>
> Qt5 changes in these packages:
>
> https://codereview.qt-project.org/#change,83700 :
>
> Patch Set 4:
>
> * qtbase 8b0fd78...13e3f26 (7):
>
>  > QPrintDialog - Fix Mac reference counting error.
>
>  > QPrintDialog - Fix mac change of printer name
>
>  > Android input method fix
>
>  > Revert "Automatically link printsupport plugins to static applications."
>
>  > When a window loses focus to a popup, event has PopupFocusReason
>
>  > Restore Qt 4 behavior in default double click handler
>
>  > Remove internal public function from QOpenGLFunctions
>
> * qtdeclarative fc634cb...0076835 (6):
>
>  > qmlplugindump: correctly merge composite types
>
>  > QQuickItemView/QQuickPathView: Fix creation of delegates
>
>  > Make sure the clipPath is retained as state of Context2D
>
>  > Prevent a crash when the item is deleted but not removed from cache
>
>  > Refine fix for dynamic properties on QObjects wrapped in JavaScript
>
>  > V4: fix register usage on ARM.
>
> * qtdoc e006b84...66ade86 (2):
>
>  > Doc: Various fixes to Enginio related links.
>
>  > Doc: command line tools need not be installed separately
>
> * qtlocation 8ff60b5...4f2990d (1):
>
>  > Add Qt 5.3.0 change log for QtPositioning.
>
> * qtmultimedia af73d55...4c8284d (1):
>
>  > Rework qmlvideofx example
>
> * qtquickcontrols f067a73...786164e (2):
>
>  > Update plugins.qmltypes for QtQuick.PrivateWidgets
>
>  > Update plugins.qmltypes for QtQuick.Dialogs
>
> * qtrepotools ee57020...04c900d (1):
>
>  > ignore symlinks
>
> * qtsensors e60743e...8a0da79 (3):
>
>  > ios: skip accelerometer, gyroscope and magnetomenter updates if NaN
>
>  > accelbubble: disable rotation on iOS
>
>  > accelbubble: avoid updating position if NaN.
>
> * qttranslations 6e972b4...d56737b (3):
>
>  > Update Japanese translations.
>
>  > Russian translation update
>
>  > Ukrainian translation update
>
> https://codereview.qt-project.org/#change,83673 :
>
> Patch Set 2:
>
> * qtbase 3f9ad1e...8b0fd78 (2):
>
>  > WinRT: Dont use the native thread handle for waiting
>
>  > iOS: fix crash in auto correction when using unknown font family
>
> * qtconnectivity d755d1e...9b11226 (1):
>
>  > Fix discovery hanging in unrecoverable state due to incorrect error 
> handling
>
> * qtdeclarative 1b3a930...fc634cb (1):
>
>  > Doc: Improved Qt Quick Demos documentation
>
> * qtmacextras abbb6d3...ddbbc1f (1):
>
>  > Doc: Improved example documentation.
>
> * qtquickcontrols 6d438f3...f067a73 (1):
>
>  > Docs: fix QtQuick.Controls.Styles import version
>
> Br,
>
> Jani
>
>
>
> ___
> 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] Qt5 documentation for Embedded Linux

[Peter Kümmel]

http://qt-project.org/doc/qt-5/supported-platforms.html

"Embedded Linux (DirectFB, EGLFS, KMS, and Wayland)"

Am I right that this sentence is the complete documentation
for using Qt 5 on an embedded system?

Nothing about how to build, what's needed for QML,
what for QWidgets, how to replace qws, a word about Wayland,
hardware acceleration, OpenGL, ...

Or have I just missed a link?

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

Re: [Development] Visual C++ 2013 binaries

[Peter Kümmel]

On 19.10.2013 17:17, Hausmann Simon wrote:
> Looks good to me. (although I would prefer the more
> descriptive Qt msvc version macros‎)
>
> Can you submit this to gerrit stable branch and Cc me?

stable for qt4? I had already pushed 2 patches to 4.8.

>
> Simon
>
> *Fra: *Yuchen Deng
> *Sendt: *15:37 lørdag 19. oktober 2013
> *Til: *Peter Kuemmel
> *Kopi: *development@qt-project.org
> *Emne: *Re: [Development] Visual C++ 2013 binaries
>
>
> It's can be fixed by this patch.
>
>  From d15fbb867f0b0041bd74297792ddac0e00b898fe Mon Sep 17
> 00:00:00 2001
> From: Yuchen Deng mailto:loa...@gmail.com>>
> Date: Sat, 19 Oct 2013 11:55:20 +0800
> Subject: [PATCH] Fix MSVC2013 compilation
>
> ---
>   src/3rdparty/masm/wtf/MathExtras.h | 2 ++
>   src/qml/jsruntime/qv4global_p.h| 2 ++
>   2 files changed, 4 insertions(+)
>
> diff --git a/src/3rdparty/masm/wtf/MathExtras.h
> b/src/3rdparty/masm/wtf/MathExtras.h
> index b08ee67..600a9c7 100644
> --- a/src/3rdparty/masm/wtf/MathExtras.h
> +++ b/src/3rdparty/masm/wtf/MathExtras.h
> @@ -123,6 +123,7 @@ inline bool signbit(double x) { struct
> ieee_double *p = (struct ieee_double *)&x
>   #if COMPILER(MSVC)
> +#if _MSC_VER < 1800
>   // We must not do 'num + 0.5' or 'num - 0.5' because they
> can cause precision loss.
>   static double round(double num)
>   {
> @@ -138,6 +139,7 @@ static float roundf(float num)
>   return integer - num > 0.5f ? integer - 1.0f :
> integer;
>   return integer - num >= 0.5f ? integer - 1.0f : integer;
>   }
> +#endif
>   inline long long llround(double num) { return
> static_cast(round(num)); }
>   inline long long llroundf(float num) { return
> static_cast(roundf(num)); }
>   inline long lround(double num) { return
> static_cast(round(num)); }
> diff --git a/src/qml/jsruntime/qv4global_p.h
> b/src/qml/jsruntime/qv4global_p.h
> index 3569247..f96a48d 100644
> --- a/src/qml/jsruntime/qv4global_p.h
> +++ b/src/qml/jsruntime/qv4global_p.h
> @@ -55,7 +55,9 @@ namespace std {
>   inline bool isinf(double d) { return !_finite(d) &&
> !_isnan(d); }
>   inline bool isnan(double d) { return !!_isnan(d); }
>   inline bool isfinite(double d) { return _finite(d); }
> +#if _MSC_VER < 1800
>   inline bool signbit(double d) { return _copysign(1.0, d) <
> 0; }
> +#endif
>   } // namespace std
> --
> 1.8.4.msysgit.0
>
>
>
> 2013/10/19 Peter Kuemmel  >
>
> MSVC 2013 now supports ISO C11 language features (also
> breaks Qt4 ATM).
> *Gesendet:* Samstag, 19. Oktober 2013 um 14:54 Uhr
> *Von:* "Nagy-Egri Máté Ferenc"  >
> *An:* "development@qt-project.org
> "
>  >
> *Betreff:* Re: [Development] Visual C++ 2013 binaries
> I have tried to build Qt 5.0 alpha with Visual Studio
> 2013 RTM and I got the following errors:
> c:\qt-src\qtdeclarative\src\qml\jsruntime\qv4global_p.h(58)
> : error C2883: 'std::signbit' : function declaration
> conflicts with 'signbit' introduced by using-declaration
> (util\qqmladaptormodel.cpp)
>  C:\Kellekek\Microsoft Visual Studio
> 12.0\VC\INCLUDE\math.h(324) : see declaration of 'signbit'
> c:\qt-src\qtdeclarative\src\qml\jsruntime\qv4global_p.h(58)
> : error C2084: function 'bool signbit(double)' already
> has a body (util\qqmladaptormodel.cpp)
>  C:\Kellekek\Microsoft Visual Studio
> 12.0\VC\INCLUDE\math.h(324) : see previous definition of
> 'signbit'
> c:\qt-src\qtdeclarative\src\qml\jsruntime\qv4global_p.h(58)
> : error C2883: 'std::signbit' : function declaration
> conflicts with 'signbit' introduced by using-declaration
> (util\qqmllistaccessor.cpp)
>  C:\Kellekek\Microsoft Visual Studio
> 12.0\VC\INCLUDE\math.h(324) : see declaration of 'signbit'
> c:\qt-src\qtdeclarative\src\qml\jsruntime\qv4global_p.h(58)
> : error C2084: function 'bool signbit(double)' already
> has a body (util\qqmllistaccessor.cpp)
>  C:\Kellekek\Microsoft Visual Studio
> 12.0\VC\INCLUDE\math.h(324) : see previous definition of
> 'signbit'
> qqmlpropertymap.cpp
> NMAKE : fatal error U1077: '"C:\Kellekek\Microsoft
> Visual Studio 12.0\VC\BIN\amd64\cl.EXE"' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:\Kellekek\Microsoft
> Visual Studio 12.0\VC\BIN\amd64\nmake.exe"' : return
> code '0x2'
> Seems as if some declarations made to compensate for
> lack of STL conformance on VS2012 are no longer needed.
> I have encountered trivial functions missing from VS2012
> STL as well. Some of these whould be revisited.
> Configuration is:
> configure.bat -platform win32-msvc2013 -opensource
> -debug-and-release -c++11 -mp -opengl desktop -nomake
> examples -prefix C:\Kellekek\Qt\5.2-alpha -bindir
> C:\Kellekek\Qt\5.2-alpha\bin\x64 -libdir
> C:\Kellekek\Qt\5.2-alpha\lib\x64
> R

Re: [Development] A QtCore class for event-driven jobs

[Peter Kümmel]

On 10.09.2013 08:16, Knoll Lars wrote:
>
> Develop it in a playground project, show why it makes sense and once you have 
> a stable API let's discuss into which module it should go.

An idea I already had when I saw the QUniquePoiner implementation:

Couldn't we add a new branch to dev/stable/release, which is open for very 
experimental code?
Creating a playground project just for one class is too complicated, and most 
people would not give them a try,
but only switching a branch lowers the barrier a lot.

We could base the branch on stable, so it is a good starting point for 
experiments, and
it would be easy to try out these new features without the hassle of checking 
out (multiple) other repositories,
or by cherry-picking stuff.

Peter

>
> Cheers,
> Lars
>
> From: Konstantin Ritt mailto:ritt...@gmail.com>>
> Date: tirsdag 10. september 2013 00:40
> To: "development@qt-project.org " 
> mailto:development@qt-project.org>>
> Subject: Re: [Development] A QtCore class for event-driven jobs
>
>
> 2013/9/9 Sune Vuorela mailto:nos...@vuorela.dk>>
>
> The api has been stabilized and well tested since like forever.
>
> Let's get a QAbstractJob heavily inspired by KJob in now.
>
> A nice side effect of getting it in now is that the myriad of nice
> frameworks KDE is preparing for ship could be built on QAbstractJob and
> KDE could skip shipping KJob and move everything over to QAbstractJob
> now and not after we in KDE has made our first release where we promise
> to keep ABI and API stability.
>
>
> That's indeed what I was afraid of. Your goal is KJob in Qt 5.2 so you can 
> use it by only linking to QtCore.
> Once released, it's API become frozen up until 6.0...and you don't really 
> care about all others who may disagree with it's design or simply can not use 
> it due to it's limited API and so on.
> All I've seen so far (following by David's links) is a piece of KIO where 
> some API is still hardcoded to be used by KIO. I'd say this is not a 5.2 
> material at all.
>
> Let us see those nice QProcessJob and/or QThreadJob, that QDBusCallJob...or 
> usable drafts at very least.
> Until then, I'm all in doubts about how useful would that be to the user.
> In example, David said job's doStart() enqueues the runnable in the thread 
> pool; now looking at the code - it seems like we could have then "started()" 
> signal emitted, say, 5 seconds earlier than the runnable gets dequeued and 
> executed. So `for (int i = 0; i < 100; ++i) (job = 
> someoperation(params))->start();` gives us 100
> "started" jobs where only few of them got dequeued and really started; and 
> thus all other jobs can not report their actual execution state change 
> because they were "started" and become "started", once dequeued by worker 
> thread...weird, isn't it?
>
> First of all, put the initial implementation to Qt-project as a module.
> Let's then gather such a use-cases and see where the current API is not 
> sufficient, then polish the API to make QJob usable in all those cases; let's 
> write some QJob-s based demonstration framework and polish the API once 
> again, if needed... and only then we'll see if it is good enough for QtCore.
>
> Kind regards,
> Konstantin
>
>
> ___
> 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] A QtCore class for event-driven jobs

[Peter Kümmel]

On 06.09.2013 19:52, David Faure wrote:
>
> connect(job, SIGNAL(result(QJob*)),
> this, SLOT(handleResult(QJob*)));

This looks so old-school like in times of futures and monads.

Couldn't such a class be part of the hopefully coming QtConcurrent replacement?

Peter

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

Re: [Development] Making QScopedPointer scoped (again)

[Peter Kümmel]

On 05.09.2013 12:10, Daniel Teske wrote:
> QScopedPointer has never been a scoped pointer. It has always had a .reset()
> method. That should never have been part of QScopedPointer.

I wonder if this would happen again with the current review process.

>
> daniel#

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

Re: [Development] Making QScopedPointer scoped (again)

[Peter Kümmel]

On 04.09.2013 17:54, Thiago Macieira wrote:
> On quarta-feira, 4 de setembro de 2013 10:20:39, Peter Kümmel wrote:
>>> What's that something else? Remember that QScopedPointer was created to
>>> simplify handling of exceptions (when we tried to care about exceptions).
>>> If we have to take the pointer out and handle it manually, it defeats the
>>> entire purpose of QScopedPointer -- simplifying exception management.
>>
>> This "something else" we have to introduce in Qt (it would be very similar
>> to QScopedPointer), because initially QScopedPointer wasn't made for it,
>> and all "escaping from scope" questions if QScopedPointer is the right
>> choice at this place.
>
> You're confusing QScopedPointer's purpose.

I don't confuse it, I only insisted on correct naming.
Passing around a "scoped pointer" is just plain stupid.

You also got the problem by your own:
"Despite its name, it's not just about scope",
so what is the "Scope" in the name good for?

After all I would prefer QXPointer over QScopedPointer,
because I could not trust the naming any more, and it's less to type.

I wonder which features I haven't discovered in QWidget ;)

  It's about simplifying the handling of the pointer's deletion
> when an exception is thrown.
>
> Taking the pointer out via take() and storing it in a raw pointer defeats that
> purpose.
>
>   q.reset(p.take()); is exception-safe
>   return p.take();  isn't
>
> if we want to return exception-safely, we need this.
>
> Note: we don't care anymore about exceptions.
>
>
>
> ___
> 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] Making QScopedPointer scoped (again)

[Peter Kümmel]

On 04.09.2013 09:16, Thiago Macieira wrote:
> On quarta-feira, 4 de setembro de 2013 09:00:14, Peter Kümmel wrote:
>> But then you could use take() add wrap the pointer with something else,
>> only this way I would call "explicit".
>
> What's that something else? Remember that QScopedPointer was created to
> simplify handling of exceptions (when we tried to care about exceptions). If
> we have to take the pointer out and handle it manually, it defeats the entire
> purpose of QScopedPointer -- simplifying exception management.

This "something else" we have to introduce in Qt (it would be very similar to
QScopedPointer), because initially QScopedPointer wasn't made for it,
and all "escaping from scope" questions if QScopedPointer is the right
choice at this place.

And in RAII you should make it as hard as possible to let the resource "escape"
because this escaping breaks the pattern.

>
> To ensure proper RAII, we need to have a hand-off to another object. What 
> class
> is that other object that allows returning or passing?
>
>> Do we really wanna pollute Qt's API with QScopedPointer-s?
>
> No, I don't. I'm just presenting arguments.

But when it is possible, I assume people wanna use it.

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

Re: [Development] Making QScopedPointer scoped (again)

[Peter Kümmel]

On 03.09.2013 22:12, Oswald Buddenhagen wrote:
> On Tue, Sep 03, 2013 at 09:20:20PM +0200, Peter Kümmel wrote:
>>>> Adding a move contructor to QScopedPointer makes no sense, because moving
>>>> means 'escaping the scope', which breaks the fundamental point of
>>>> QScopedPointer. QScopedPointer is different to std::unique_ptr and should
>>>> remain so.
>>
>> I have to agree with Steven. After allowing moving, the semantic is
>> different to the naming: after this change we could write in the docs
>>
>>   "QScopedPointer sometimes deletes when it leaves the scope."
>>
>> Which makes it obvious that "QScopedPointer" is the wrong name for such a 
>> behavior.
>>
> actually, it is
>
>  "A non-null QScopedPointer deletes when it leaves the scope."
>
> which sounds quite reasonable to me.
>

QScopedPointer returnScopedPointer()
{
 QScopedPointer p(new int);
 return p;
}

Does 'p' look like a null QScopedPointer? I don't think so.
It only becomes null behind the scenes.

Peter

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

Re: [Development] Making QScopedPointer scoped (again)

[Peter Kümmel]

On 03.09.2013 22:47, Thiago Macieira wrote:
> On terça-feira, 3 de setembro de 2013 22:12:58, Oswald Buddenhagen wrote:
>>  "A non-null QScopedPointer deletes when it leaves the scope."
>>
>> which sounds quite reasonable to me.
>
> It still does that.
>
> Moving out of a QScopedPointer simply means taking the pointer out of it
> before it goes out of scope.

But then you could use take() add wrap the pointer with something else,
only this way I would call "explicit".

Do we really wanna pollute Qt's API with QScopedPointer-s?

Peter

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

Re: [Development] Making QScopedPointer scoped (again)

[Peter Kümmel]

On 04.09.2013 07:36, Olivier Goffart wrote:
> On Tuesday 03 September 2013 21:20:20 Peter Kümmel wrote:
>> It is of great benefit that you never had to think about if
>> QScopedPointer(5.1) will delete when leaving scope.
>
> That's not true.
>
>   QScopedPointer<...> myPtr(foo());
>   myPtr.take();

Sure, but then you don't pass a QScopedPointer and have to care about the plain 
pointer.

>
> And it does not delete when leaving the scope.
>
> Think of qMove(myPtr) of a safer convenience to the already existing take()
>
>> The main point is that in Qt is nothing like std::unique_ptr,
>
> False again.

only when QScopedPointer is movable


  QScopedPointer is almost exactly the same as unique_ptr. They
> have the same API.

> Compare http://en.cppreference.com/w/cpp/memory/unique_ptr and 
> http://qt-project.org/doc/qt-5.0/qtcore/qscopedpointer.html and tell me again 
> they are
> nothing like eachother.

The point of the thread is not functionality but naming.

>
> The documentation of unique_ptr even starts with: "std::unique_ptr is a smart
> pointer that retains sole ownership of an object through a pointer and
> destroys that object when the unique_ptr goes out of scope."
>
> It is unfortunate that the standard did not choose the name
> std::scoped_pointer,  but that's not the first time the standard and Qt are
> using different name (QByteArray <> std::string, QLinkedList <> std::list, 
> ...)
>
> (I assume you meant s/Qt/QScopedPointer/)
>
>> so when it is needed and we can't use std::unique_ptr, we have to introduce
>> a QUniquePointer. This is better than to add features to classes which are
>> contradictorily to their naming.
>
> Based on all the false assumptions in your mail, I think it's safe to discard
> your conclusion.
>

Maybe boost is also some sort of reference; there the scoped pointer is also 
not movable:
http://www.boost.org/doc/libs/1_54_0/libs/smart_ptr/scoped_ptr.htm


With making QScopedPointer movable we cemented the bad naming.

Peter

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

Re: [Development] Making QScopedPointer scoped (again)

[Peter Kümmel]

>> Adding a move contructor to QScopedPointer makes no sense, because moving
>> means 'escaping the scope', which breaks the fundamental point of
>> QScopedPointer. QScopedPointer is different to std::unique_ptr and should
>> remain so.

I have to agree with Steven. After allowing moving, the semantic is
different to the naming: after this change we could write in the docs

 "QScopedPointer sometimes deletes when it leaves the scope."

Which makes it obvious that "QScopedPointer" is the wrong name for such a 
behavior.

It is of great benefit that you never had to think about if QScopedPointer(5.1)
will delete when leaving scope.

>
> I disagree.  The fact that you can exit the scope explicitly is perfectly 
> fine.
>
> I would even go further and add conversions operators for STL compatibility:
>
> inline QScopePointer::QScopePointer(std::unique_ptr other)
> inline QScopePointer::operator std::unique_ptr()
>

The main point is that in Qt is nothing like std::unique_ptr, so when it is
needed and we can't use std::unique_ptr, we have to introduce a QUniquePointer.

This is better than to add features to classes which are contradictorily to 
their naming.

Peter




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

Re: [Development] Signals/slots for class templates (Was: Evolving Qt's multithreading API)

[Peter Kümmel]

On 10.03.2013 16:54, Sze Howe Koh wrote:
>
> Olivier started implementing this:
> https://codereview.qt-project.org/#change,49864

Last year I gave it also a try,

 http://lists.qt-project.org/pipermail/development/2012-June/004580.html
 http://lists.qt-project.org/pipermail/development/2012-June/004536.html

and in meantime I've ported it to Qt5:

 https://codereview.qt-project.org/#change,41468

Another problem is that you have to moc before you compile any file which
needs the moc generated headers.

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

Re: [Development] Qt 4.6.5 and 4.7.6 release candidates available

[Peter Kümmel]

On 21.02.2013 14:00, Turunen Tuukka wrote:
>
> Unfortunately we do not have unlimited resources in the release team, so
> pointlessly redoing the packages is not something I want to do.
>

I would release the already packaged versions as they are as a
Digia-only release, and skip 4.8.5/4.7.6 in the official counting, like 4.7.5.

Then we could start working on the qt-project version 4.8.6/4.7.7 without
much pressure of time. Then we also have more time to discuss and adjust the
processes on qt-project's  and Digia's side (maybe the "Qt Commercial 
Integration"
guys get more involved into the review process).


There is still the announcement
===
This problem is solved in Qt 5.0.1 and the forthcoming 4.8.5, and the 4.7.6
patch releases. For other releases, apply the patch below:
===

But when qt-project never releases a 4.8.5/4.7.6 but 4.8.6/4.7.7
we still have released the fix with the next patch release, only
the version number is different to the announced one. And nobody
could use by accident a not security-fixed Qt version.

Peter

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

Re: [Development] Qt 4.6.5 and 4.7.6 release candidates available

[Peter Kümmel]

On 19.02.2013 20:29, Turunen Tuukka wrote:
>
> We have the packages ready and tested with minor
 > fixes compared to RC1 (21st Dec). If we re-do these
 > packages it is a significant effort with very limited benefits.
>

It seems to me this already happens before:
you first do the packaging and then ask on the list for a go.

I would say this is the wrong order, you should first coordinate with
the qt-project and then invest Digia's time.

This mainly saves YOUR time and budget.

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

Re: [Development] : Test Application Failing to load QtCore Lib of qt-4.8.4 Event Dispatcher Assertion

[Peter Kümmel]

On 21.02.2013 06:04, Amogh Kudari wrote:
> Hi All,
>
> Any idea on how to proceed to remove this assertion mentioned  below.
> Please provide any inputs/suggestions.
>
> Thanks and Regards,
> Amogh.
>

I've tested your program on Windows with msvc12 and wit  the 4.8 branch.
It starts here without problems. Only when quitting an assert is triggered 
because
of the widgets are created on stack.

Have you compiled Qt yourself?

Peter

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

Re: [Development] abandoning stale changes on gerrit

[Peter Kümmel]

>
> The problem with the original request to simply make all changes
> "abandoned" is that it will destroy the differentiation between
> "trash" and "not interested in atm".

Another problem is that some touches your changes you've invested
time and motivation and simply moves it into the trash can.

Please give more respect others work.

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

Re: [Development] abandoning stale changes on gerrit

[Peter Kümmel]

On 01.02.2013 01:37, Alan Alpert wrote:
>
> That said, I'd prefer it for us to reach a consensus that the
> abandoned state should mean abandoned (adj 2 of
> http://en.wiktionary.org/wiki/abandoned) instead of destroyed (past
> participle of verb 1, http://en.wiktionary.org/wiki/destroy). Then
> abandoning stale changes is simply changing the gerrit state to more
> accurately reflect the state of reality.

This points in the right direction.

The problem with the original request to simply make all changes
"abandoned" is that it will destroy the differentiation between
"trash" and "not interested in atm".

I prefer to introduce a new change-state in gerrit: backlog
backlog it is currently the common name for things which are
valid but nobody is busy on currently.

After each release, we could automatically move ALL changes
to backlog. To reactivate the owner only needs to click
"Restore Change" which is acceptable.

This way we have a real trash with abandoned stuff, a backlog
with interesting things, and a only active changes in
the review board.

Peter




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

Re: [Development] Design review: Adapter layer, C++ to QML

[Peter Kümmel]

On 30.01.2013 19:23, Charley Bay wrote:
> I've implemented a C++ "adapter-layer" (mostly template-based) to expose
> C++ objects to QML.
>
> We are in the "early-stages" for its use, and (of course) the "final-API"
> will significantly impact how we expose our (domain-specific) C++ classes
> to QML.
>
> My manager suggested I ask others what they are doing to solve similar
> problems (C++/QML adapter layer).  IMHO, this could reasonably be a
> "standardized" adapter-API for generalized use in applications with rich
> C++ classes that must be exposed to QML (that's us).
>
> --
> Design goals:
>
>   (a)- Expose individual C++ objects with minimal code
>
>   (b)- Individual "QML-instances" can "contain" a "C++ back-end-instance"
> that is not shared with other QML instances.
>
>   (c)- Multiple "QML-instances" can "share" access to the same C++ back-end
> instance, with coordinated updates (e.g., as one QML-instance triggers a
> C++ object "property-value-change", all QML instances are "notified" of
> that change)
>
>   (d)- Enable nested QML-wrapped-object-access to nested C++ instances that
> are natively stored (e.g., no refactoring of C++ code to incrementally
> expose nested C++ objects to QML)
>
>   (e)- Expose "sets" of C++ instances to QML (e.g., through
> "QAbstractListModel") with add/remove notifications to QML
>
> --
> Conceptual design:
>
> Each "C++ instance" is "wrapped" by a "singleton-QmlBoxBack" instance with
> application-specific properties exposed.  Many "QmlBox" instances will
> "reference" that single "QmlBoxBack" instance for "ultimate-state", and the
> "QmlBoxBack" will maintain the "registered-set" of "QmlBox" instances, so
> that when one "QmlBox" changes a property-value, all "QmlBox" instances are
> "notified" of the change.  Similarly, the "QmlBoxBack" instance is
> charged-with explicit notification of all "QmlBox" instances when the
> back-end C++ model changes asynchronously.  (We are using this for
> monitoring back-end instrumentation.)
>
> For logistical reasons, a "QmlBoxBacksManager<>" is needed to manage the
> (registered) "QmlBoxBack" instances, to preserve the "singleton" nature of
> the "QmlBoxBack" for a give C++ instance.
>
> --
> High level design is:
>
>   (1) The following C++ key abstractions are implemented:
>
>  - QmlBox (derives from QObject)
>  - QmlBoxBack (derives from nothing)
>  - QmlBoxBacksManager<> (template base class)
>
>   (2) Application-specific type definition:
>
>  - Implement your C++ class (e.g., "MyDog")
>  - Derive "MyQmlDogBox" from "QmlBox" to expose type-specific properties
>  - Derive "MyQmlDogBoxBack" from "QmlBoxBack" to propagate type-specific
> properties
>  - Use macro to define "MyQmlBoxBacksManagerDog" (which parameterizes
> "QmlBoxBacksManager<>")
>
>   (3) Application-specific use:
>
>  - QML can instantiate instances, or reference instances on the C++ side
>  - QML is "notified" when items are added/removed from the C++ side,
> which triggers instantiation of QML instances (e.g., through
> "QAbstractListModel" semantics)
>
>   (4) Internal details:
>
>  - Each C++ instance is "wrapped-by" a SINGLE "QmlBoxBack" instance,
> which "owns" or "references" that C++ instance (e.g., like a
> "smart-pointer")
>  - Many "QmlBox" instances are "registered" within a given "QmlBoxBack";
> when property values "change", all "QmlBox" instances are "notified" of
> that property-change
>  - All "QmlBoxBack" instances for a given "type" are "registered" with
> the "QmlBoxBacksManager<>" for that type, which deletes the "QmlBoxBack"
> instances when the C++ object is "destroyed", and un-registeres "QmlBox"
> instances as-needed.
>
>SUMMARY:
>  - One "QmlBoxBack" for each C++ instance
>  - Many "QmlBox" instances "reference" a given "QmlBoxBack"
>

I would try to avoid the necessity of a new class only to bind the C++ code.
JS uses prototypes, so all you need on the JS side are callbacks to C++ to
build your prototypes. Once I used this approach for QScriptEngine

cmakescript.git.sourceforge.net/git/gitweb.cgi?p=cmakescript/cmakescript;a=blob;f=Source/cmJsUtilities.h

But I haven't tried it with QML.

>   (5) Practical use:
>
>  - ...where "myInstrument", "laser", and "wavelength" are implemented
> through application-specific C++ types:
>
>  Item {
> color:  myInstrument.laser.wavelength.color
>  }
>
>  - ...where a "list-model" exists to expose many instances of the
> application-specific type "detector", which has properties "channel" and
> "filter":
>
>  ListView {
>model:  myInstrument.detectors
>delegate: Text { text: "(" + channel + ")" + filter.text }
>  }
>
> --
>
> QUESTIONS:
>
>   (1) Are you doing "heavy-duty-wrapping" of rich C++ models, without
> refactoring the C++ code?  What was the design, and did it work for you?
>
>   (2) Have you a critique for the design liste

Re: [Development] Repository is too open

[Peter Kümmel]

On 29.01.2013 13:12, Jason McDonald wrote:
> On Tue, Jan 29, 2013 at 10:00 PM, Sergio Ahumada
>  wrote:
>> On 01/29/2013 12:57 PM, Jason McDonald wrote:
>>> I think there is a problem here.  The announcement in the link seems
>>> to indicate that the intention was only to present non-approvers with
>>> a "Merge patchset x to Staging" button once the commit has at least
>>> one +2.  I'm now seeing the merge button on commits without any +2's,
>>> and even on commits where the only score is a -1.  For example, see
>>> https://codereview.qt-project.org/#change,43299.
>>>
>>> IMO, we don't want over-eager contributors pressing that button and
>>> staging a change before an approver has approved it.
>>
>> I sort of remember that if you try to stage/submit a change that doesnt
>> have at least one +2 it should fail and give you an error message.
>>
>>> Granted, I am an approver, so I may not be seeing the same thing that
>>> a non-approver does, but even so, I don't think an approver should be
>>> able to stage an unapproved commit either.
>>
>> Maybe you can try and see if you get the error message .. if it gets
>> staged ping me on IRC and I can unstage it :)
>
> I wasn't game to press the button before, in case I staged something
> that I couldn't then unstage right away.
>
> Attempting to stage gives
>
> Application Error
> Server Error
> Requires Code Review
>
> ...so it seems safe.
>
> Still seems strange to present a button that the system already knows
> is a dead-end, but I guess that's a P3, not a P1.

I also verified that a change without a positive review is rejected.

And I'm allowed to stage an already reviewed change, which, for example,
failed at the first stage attempt of the reviewer.

Peter


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

Re: [Development] abandoning stale changes on gerrit

[Peter Kümmel]

On 29.01.2013 13:05, Oswald Buddenhagen wrote:
> moin *,
>
> 5.0 is out and the 5.1 feature freeze isn't that far off any more.
> seems like the best time for some serious house cleaning.
> therefore i'd like to urge everyone to give their pending changes which
> haven't seen activity for a long time a honest look.
> please explicitly mark the ones you still want to work on by adding a
> comment. everything which has no indication of (planned) activity in a
> few weeks will be abandoned by administrative action.
> if you are an ex-troll/-nokian, please also check the dashboard of your
> alter ego.
> if you are a maintainer, give identified drive-by contributors a ping.
> i'd also like to encourage everyone to adopt orphaned changes they have
> an interest in.
>

What about WIP changes? Could they stay open?
It is obvious that they don't need a review.

Peter

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

[Development] Repository is too open

[Peter Kümmel]

Seems currently everybody could merge to staging.
I as non-approver have a merge button in gerrit.

Or is this only a new feature to see if the
request passes all tests?

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

Re: [Development] Proposal - QtSerialPort graduation from the Playground

[Peter Kümmel]

On 26.01.2013 07:34, Laszlo Papp wrote:
>
> Good question; we discussed this issue before. This is unfortunately also a 
> real problem for us to test the module with
> all the combinations for each factor. It requires (semi-)manual testing and 
> hence a bit of effort. I see two ways to
> improve the automated test coverage:
>
> * I requested the QtMock module in April for a playground initiation to 
> extend the test capability of the Qt Project for
> such cases like this, but I did not get around to it, unfortunately, to get 
> anything done for that yet.

For ideal testing a mock would be good which simulates the complete serial 
port. Is there a interface in front of
the native calls which could be implemented by a mock and could be used as a 
drop in for the real serial port?

And it would also be very helpful when there is a recorder which listens to a 
real serial communication and
writes it down, so it can be used later as input for the mock.

It's not necessary to have such things now, but the internal interfaces should 
make it possible to implement it later.

Such a mock is sometimes the only way to test error cases which are often hard 
to reproduce on real hardware.

>
> * The CI machines could be using a loopback cable, and test it that way. It 
> would be even better to use a pandaboard or
> raspberry pi (with gserial in that case). The board could be used for 
> receiving and sending data back for instance, but
> this requires a special hardware setup.
>
> Perhaps, there are other alternatives to address this, but these have just 
> come to my mind for the moment.
>
> Laszlo
>
>
> ___
> 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] Cannot compile QT4.8.4 with nmake Linker error

[Peter Kümmel]

Try without -no-iconv, the error is related to unicode stuff.

On 22.01.2013 08:50, Amogh Kudari wrote:
> Hi Thiago,
>
>   Thanks for your quick response.
>
> Now I reconfigured without -qpa option but *still I am getting the same 
> errors.*
>
> Now configuration looks something like this...
>
> ConfigureOption=
> configure.exe -debug -opensource -confirm-license -little-endian 
> -no-accessibility -no-stl -no-sql-sqlite -no-qt3support
> -no-nis -no-cups -no-iconv -no-3dnow -no-openssl -no-dbus -no-phonon 
> -no-xmlpatterns -no-multimedia -no-script
> -no-scripttools -no-declarative -no-exceptions -nomake tests -nomake examples 
> -nomake demos -webkit-debug
> ConfigureOption=
>
> Any suggestions...
>
> Regards,
> Amogh.
>
>
>
> On Tue, Jan 22, 2013 at 12:06 PM, Thiago Macieira  > wrote:
>
> On terça-feira, 22 de janeiro de 2013 11.46.28, Amogh Kudari wrote:
> > I am compiling QT-4.8.4 with the following configure 
> options on
> > Windows(Using Visual Studio 2008 command prompt).
> >
> > =Configure ===
> > configure.exe -debug -opensource -little-endian -no-accessibility 
> -no-stl
> > -no-sql-sqlite -no-qt3support -no-nis -no-cups -no-iconv -no-largefile
> > -no-3dnow -no-gtkstyle -no-openssl -no-dbus -no-phonon -no-xmlpatterns
> > -no-svg -no-multimedia -no-script -no-scripttools -no-declarative
> > -no-exceptions -nomake tests -nomake examples -nomake demos -qpa
> > -webkit-debug
>
> Drop the -qpa argument.
>
> We told you before that QPA on Windows on Qt 4 is entirely unsupported and
> plainly does not work. You have now confirmed what we told you: the QPA 
> code
> works on Unix systems only.
>
> --
> Thiago Macieira - thiago.macieira (AT) 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] Qt 5.0.1 -- Release Testing

[Peter Kümmel]

On 18.01.2013 14:37, Motyka Rafal wrote:
> Hello,
>
> Qt 5.0.1 release testing has been started. We would like to kindly ask the Qt 
> Community for help by testing the new
> packages.
>
>  1. Installer packages are available here: 
> http://releases.qt-project.org/digia/5.0.1/backups/2013-01-18-412/
>
>  2. Qt bug reports should be reported in JIRA: 
> https://bugreports.qt-project.org/
>
> Thank you.

I tested the mingw binaries and wondered why you don't install MinGW too.
There a are so much different mingw versions and if the precompiled
libraries should work the compiler must match.
At least you should document which mingw version you've used and maybe
provide a link to the binaries,  I assume
http://origin.releases.qt-project.org/prebuilt/mingw_32/x32-4.7.2-release-posix-sjlj-rev1.7z

Any special reason to use sjlj? Or just because it is the default?

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

Re: [Development] Qt 5.0.1 release branching is ongoing

[Peter Kümmel]

On 10.01.2013 23:31, Sergio Ahumada wrote:
> On 01/10/2013 11:29 PM, Peter Kümmel wrote:
>> On 09.01.2013 17:11, Salovaara Akseli wrote:
>>> Hi,
>>>
>>> Qt 5.0.1 release branching is ongoing and there are already around 300 
>>> commits available since Qt 5.0.0 release.
>>
>> Ahm, what was the difference between release and a tag, and  between release 
>> and stable?
>>
>
> cd qtbase
> git checkout release
> git pull --rebase
>
> git log --oneline v5.0.0..release # between release and tag
>
> git checkout stable
> git pull --rebase
>
> git log --oneline release..stable # between release and stable
>
>
> or something like it ..
>

Thanks ;)  but the question was more like this:

Is the release branch only for cherry-picking from stable patches?
Or under what circumstances should I push a merge request to 'release'
and not to 'stable'?

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

Re: [Development] Qt 5.0.1 release branching is ongoing

[Peter Kümmel]

On 09.01.2013 17:11, Salovaara Akseli wrote:
> Hi,
>
> Qt 5.0.1 release branching is ongoing and there are already around 300 
> commits available since Qt 5.0.0 release.

Ahm, what was the difference between release and a tag, and  between release 
and stable?

>
> There are also quite many bugs reported from Qt 5, some of them already 
> triaged but some requiring attention. Could
> everyone please go through important bug reports in 
> https://bugreports.qt-project.org/browse/QTBUG , check if there are
> some bugs which should be fixed for Qt 5.0.1 patch release and link those 
> bugs to “Qt 5.0.1 release tasks”
> (https://bugreports.qt-project.org/browse/QTBUG-29016 ) ?
>
> We are especially looking for P0\P1 bugs feasible to be fixed for Qt 5.0.1 
> patch release but other priorities can be
> proposed as well. There is filter 
> https://bugreports.qt-project.org/secure/IssueNavigator.jspa?mode=hide&requestId=13526
> available for Qt 5 - Unresolved bugs not evaluated yet.
>
> It would be really great to get these fixes into the 5.0.1 release to make it 
> a solid base to develop and deploy on Qt 5.
>
> Br,
>
> Akseli
>
> --
>
> Akseli Salovaara
>
> Digia, Qt
>
>
>
> ___
> 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] Playground: Crypto module

[Peter Kümmel]

On 10.01.2013 19:56, Ruslan Nigmatullin wrote:
> Botan, as I see is C++ wrapper around OpenSSL itself.

Are you sure? It looks different on their site: 
http://botan.randombit.net/index.html

> Qt already has OpenSSL dependency. What's are benefits of using it if Botan 
> is just additional dependancy?
> Also neither Botan or OpenSSL have SASL and GPG support.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Non-movable Qt build

[Peter Kümmel]

On 04.01.2013 12:27, Thiago Macieira wrote:
> On sexta-feira, 4 de janeiro de 2013 09.35.33, Peter Kümmel wrote:
>> Isn't on Windows only PATH used to figure out which Dll to load?
>
> Correct.
>
>> Then
>> qt.conf in the same dir as QtCore/qmake should be enough on Windows, or
>> missed I something?
>
> You missed something. The question is: when running app.exe from a given
> directory, how do you tell Windows to load Qt5Core.dll or QtCore4.dll from a
> different directory?
>
> The only answer is what you gave above: change PATH. Because qt.conf isn't
> used at this point.

Still don't get it: when PATH is the only way to tell the app
which Qt dlls to load, why do we need to patch the dlls?
Or is PATH changed by app.exe before it loads the Qt dlls and has the
paths compiled in?

>
>> BTW, one thing which becomes at least more complicated by this binary
>> patching is the signing of a shared library. I don't know if it is
>> necessary (I only know that you can sign a dll in .NET), but I could
>> imagine some day it will be used, e.g. to verify a program only uses by a
>> specific build.
>> (I already see the discussions because of LGPL  )
>
> Since we're talking about LGPL, signing the library is unnecessary. And maybe
> even illegal, depending on your reading of the LGPL and how you consider that
> the GPLv3 applies.
>
> The Windows installers are signed, as a whole, to ensure that they weren't
> tampered with.
>
>
>
> ___
> 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] Non-movable Qt build

[Peter Kümmel]

On 02.01.2013 14:18, Thiago Macieira wrote:
> On quarta-feira, 2 de janeiro de 2013 14.01.02, Peter Kümmel wrote:
>> On 02.01.2013 13:50, Yves Bailly wrote:
>>> Le 02/01/2013 13:42, Thiago Macieira a écrit :
>>>> On quarta-feira, 2 de janeiro de 2013 10.53.03, Yves Bailly wrote:
>>>>> Does anyone knows where I could find the source code of the "official"
>>>>> installer, or at least some information about what it does? Because the
>>>>> installer does relocate the binaries, that would be a good starting
>>>>> point
>>>>> to relocate my own binaries...
>>>>
>>>> It simply edits the qmake and QtCore DLL binaries, plus maybe some files
>>>> in
>>>> mkspecs, changing a placeholder prefix to the installation dir.
>>>
>>> Editing binaries? hu, havent't done that since... a long time ;-) Changing
>>> some
>> Sounds like a really bad hack. And this was not changed in Qt 5?
>
> No.
>
> I know how to make a relocatable shared library on Linux (find the calling
> function's address in /proc/self/maps) and I know it's possible with some
> Win32 API, but I have no clue how to do it elsewhere. Therefore, I won't do
> it.

Isn't the discussion here only about paths, different to how memory mapping is 
handled?

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

Re: [Development] Non-movable Qt build

[Peter Kümmel]

On 02.01.2013 14:33, Lincoln Ramsay wrote:
> On 2/01/13 11:01 PM, Peter Kümmel wrote:
>> On 02.01.2013 13:50, Yves Bailly wrote:
>>> Le 02/01/2013 13:42, Thiago Macieira a écrit :
>>>> On quarta-feira, 2 de janeiro de 2013 10.53.03, Yves Bailly wrote:
>>>>> Does anyone knows where I could find the source code of the "official"
>>>>> installer, or at least some information about what it does? Because the
>>>>> installer does relocate the binaries, that would be a good starting point
>>>>> to relocate my own binaries...
>>>> It simply edits the qmake and QtCore DLL binaries, plus maybe some files in
>>>> mkspecs, changing a placeholder prefix to the installation dir.
>>> Editing binaries? hu, havent't done that since... a long time ;-) Changing 
>>> some
>> Sounds like a really bad hack. And this was not changed in Qt 5?
>>
>
> QTDIR was a hack. You'd end up with the libs from one version of Qt and
> the plugins from another. Plus, Qt installations couldn't have parts in
> arbitrary locations like they can now.
>
> qt.conf is a hack because your app doesn't read it before it's found
> QtCore (so it can't change the Qt libs your app pulls in, only the
> plugins and data paths).

Isn't on Windows only PATH used to figure out which Dll to load? Then
qt.conf in the same dir as QtCore/qmake should be enough on Windows, or
missed I something?


BTW, one thing which becomes at least more complicated by this binary patching
is the signing of a shared library. I don't know if it is necessary (I only know
that you can sign a dll in .NET), but I could imagine some day it will be used,
e.g. to verify a program only uses by a specific build.
(I already see the discussions because of LGPL ;) )

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

Re: [Development] Non-movable Qt build

[Peter Kümmel]

On 02.01.2013 13:50, Yves Bailly wrote:
> Le 02/01/2013 13:42, Thiago Macieira a écrit :
>> On quarta-feira, 2 de janeiro de 2013 10.53.03, Yves Bailly wrote:
>>> Does anyone knows where I could find the source code of the "official"
>>> installer, or at least some information about what it does? Because the
>>> installer does relocate the binaries, that would be a good starting point
>>> to relocate my own binaries...
>>
>> It simply edits the qmake and QtCore DLL binaries, plus maybe some files in
>> mkspecs, changing a placeholder prefix to the installation dir.
>
> Editing binaries? hu, havent't done that since... a long time ;-) Changing 
> some

Sounds like a really bad hack. And this was not changed in Qt 5?

> internal strings I guess? any idea which one or how they can be spotted?
>
> Regards,
>

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

Re: [Development] branch commit policy (Was: Branches)

[Peter Kümmel]

On 04.12.2012 12:28, Oswald Buddenhagen wrote:
> On Mon, Dec 03, 2012 at 04:29:24PM +, Knoll Lars wrote:
>> Dev is the branch where you can land anything that's supposed to go into 
>> 5.1. The following policies apply:
>>
>> Stable:
>>
>> This branch will be the basis for Qt 5.0 and subsequent patch level 
>> releases. The following policies apply here:
>>
> as clearly some people are *already* doing it wrong, i'd like to remind
> everyone of the obvious other side of branching: merging.
>
> in all clarity: we have a merge-only policy between long-living branches
> in the same repository. there are *no* cherry-picks (you get slapped
> hard for every single one). submit fixes to the lowest applicable branch
> (generally stable, later release for release-critical problems) and wait
> for them being forward-merged to dev by a qualified merge master.

A "merge-diode" ;)

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

Re: [Development] Private headers are needed for

[Peter Kümmel]

On 08.10.2012 18:07, Thiago Macieira wrote:
> On segunda-feira, 8 de outubro de 2012 16.37.46, Peter Kümmel wrote:
>> Currently on Windows private headers are needed when
>> #include  is used.
>>
>> \include\QtGui\QtGui
>> \include\QtGui\QPlatformNativeInterface
>>
>> which needs 5.0.0\qpa\qplatformnativeinterface.h
>>
>> Is this by design?
>
> No.
>
> Please try erasing include and re-generating it.

My qtbase/master installation is only a couple days old,
do you think this is already fixed in master?

>syncqt & qmake don't always
> recreate them properly if you don't run them in the right order (beats me what
> the right order is).
>
>
>
> ___
> 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] Private headers are needed for

[Peter Kümmel]

Currently on Windows private headers are needed when
#include  is used.

\include\QtGui\QtGui
   \include\QtGui\QPlatformNativeInterface

which needs 5.0.0\qpa\qplatformnativeinterface.h

Is this by design?

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

Re: [Development] Preparing to release repackaged version of Qt 4.8.3 with Digia copyrights

[Peter Kümmel]

This discussion shows another problem.

ATM it is not possible to release a Qt4 version
(has Qt5 the same problem?) with a proper version
number based on an already released version and
containing only some patches.

This is not only a scenario when the Qt copyright
changes. It could happen all the time for security
related fixes.

So I think it is worth to change the current
release/tagging procedure in a way that a Qt4
release with a incremented patch level release
number doesn't depend on the current state of
the 4.8 branch.

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

[Development] C++11 ABI GCC 4.7.2

[Peter Kümmel]

"The ABI incompatibilities have been fixed for GCC version 4.7.2
but as a result C++11 code compiled with GCC 4.7.0 or 4.7.1 may
be incompatible with C++11 code compiled with different GCC
versions and with C++98/C++03 code compiled with any version."

Did they know what they were doing with 4.7.0/1?

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

Re: [Development] [Mingw-w64-public] Fwd: Choosing a new MinGW for Qt 5

[Peter Kümmel]

On 11.09.2012 16:55, kai.koe...@nokia.com wrote:
>
> There's nothing wrong with cross-compilation. But what we need first and 
> foremost is a reliable, native MinGW environment for developing Qt 
> applications, since the vast majority of Qt developers that develop for 
> Windows also develop _on_ Windows. Now one can argue that Qt itself could 
> still be compiled using a cross-compiler. But if we're not able to compile Qt 
> ourselves with the native toolchain, how can we be sure other complex apps 
> will work?
>
> I haven't found a stock native MinGW 64 bit package yet that can compile Qt 5 
> + Qt Creator. Peter seems willing to experiment with a custom package, but I 
> personally do not see this for 5.0 .

This is more a long term goal because atm no common way of cross compiling a 
custom mingw version is available (only 
scripts "here and there").

>
> I think for 5.0 , we should therefore only put MinGW 32 bit gcc 4.7 as Tier 2 
> or (preferably) Tier 1 platform. Support for MinGW 64 bit would be on a best 
> effort basis (Tier 3).
>
> Now for 5.1 (that is, earliest May 2013) we should definitely reevaluate 
> MinGW 64 bit as Tier 1 or Tier 2.
>
> What do you all think? I certainly don't want to discourage any effort in 
> getting MinGW-64 bit and Qt 5 to work, but rather want to be realistic in  
> what we should aim for with 5.0.

Depends on the release date of Qt5, if it happens in 3 months I think it is 
possible.
But Qt5 should not be delayed only because of MinGW, most Windows developers 
don't care about mingw.

>
> Kai
>
> PS: Added development@qt-project.org again to the thread.
> ___
> 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] Choosing a new MinGW for Qt 5

[Peter Kümmel]

On 03.09.2012 16:10, kai.koe...@nokia.com wrote:
>>
>> My suggestion on how to proceed is to choose one that offers the following or
>> most of the following:
>>
>>   - most recent GCC (4.7 preferably, 4.6 if not)
>
> Latest mingw-builds and latest rubenv packages both provide 4.7.1
>
>>   - *working* GDB and tested with Creator, with Python support
>
> A quick test didn't show any problems with either gdb (7.5.0 in both cases, 
> with python on board)
>
>>   - large file support
>
> Both check for _FILE_OFFSET_BITS in headers, and also have lseek64 symbol 
> defined.
>
>> -threading
>
> mingw-builds: gcc -v says 'posix'
> rubenv: gcc -v says 'win32' . There's extra packages labeled 
> gcc-4.7-experimental-stdthread/

Maybe the reason way mingw32-amke is broken in rubenv's build.

>
>>   - zero-overhead exceptions (no SJLJ exceptions)
>
> At the moment both use  SJLJ. SEH (zero overhead) exceptions for 64 bit will 
> come with 4.7.2, I assume.
>
>>   - standard win32 headers, if possible using the Platform SDK headers
>
> I don't think that's offered by either one at the moment (and actually would 
> be harmful, given that Microsoft won't ship a full platform sdk any more 
> outside of Visual Studio ...)
>
>>   - large set of win32 import libraries
>
> I just compared the list of .a files they offer in addition to each other:
> rubenv: libgfortran, libgomp, libquadmath, libssp, libstdc++, libsupc++
> mingw-builds: libcharset, libiconv, libksguid, libportabledeviceguids, 
> libsensorsapi, libwindowscodecs, libwinhttp
>
>>   - 32 and 64-bit in one package
>
> That's the biggest difference between the packages: mingw-builds offer a 32 
> bit and a 64 compiler (host) generating either 32 bit or 64 bit programs. For 
> rubenv you've to select the host/target architecture by downloading the right 
> package ...
>
>>   - make with -j support
>
> mingw32-make is broken in the rubenv packages I tested. Mingw32-make -j 2 
> from mingw-builds worked for me (though I didn't check whether they truly 
> parallelized... but my machine was quite busy ;)
>
>>   - if this exists: can link to .dll directly, instead of import libs
>
> No idea about this one .
>
>> We should choose one version to be the reference platform and work on
>> making it Tier 1. We shouldn't have two versions, that duplicates work.
>
> I had two issues with the rubenv packages: mingw32-make didn't work, and 
> ld.exe crashing for me in the 
> x86_64-w64-mingw32-gcc-4.7.1-2-release-win64_rubenvb package . That's why I 
> personally will  stick to the mingw-builds package. But then again things 
> might easily change in the near future: Both are updated quite frequently, 
> and I don't think either of the packages get a lot of testing before being 
> released ... Maybe we have to bite the bullet and provide our own, 'official' 
> packages with a future Qt 5.0 SDK.
>
> Regards
>
> Kai
>

So our wishlist looks like this:

- winthreads
- 32 bit target: dwarf2
- 64 bit target: SEH with 4.7.2 or also dwarf2
- multilib


Mingwbuilds http://sourceforge.net/projects/mingwbuilds/  also mentions
- OpenMP
- LTO
- Graphite
- std Concurrency
- Native TLS Callbacks
- Wide-Character Startup (-municode)

something we should also care about?


And yes, it looks like we have to build it by our own mingw.
(But it seems to be straightforward)

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

Re: [Development] Choosing a new MinGW for Qt 5

[Peter Kümmel]

On 30.08.2012 18:16, Thiago Macieira wrote:
> On quinta-feira, 30 de agosto de 2012 17.25.24, Pau Garcia i Quiles wrote:
>> There are more differences than that. There are differences in
>> features, such as threading support, large-file support, etc.
>> Mingw-w64 is usually ahead of any other in terms of features.
>
> My suggestion on how to proceed is to choose one that offers the following or
> most of the following:
>
>   - most recent GCC (4.7 preferably, 4.6 if not)
>   - *working* GDB and tested with Creator, with Python support
>   - large file support, threading

What is the problem with the current thread support in mingw?

>   - zero-overhead exceptions (no SJLJ exceptions)
>   - standard win32 headers, if possible using the Platform SDK headers

Is this possible? Aren't these headers full with MS's extensions to C++?

>   - large set of win32 import libraries

Has nothing to do with the compiler.
But maybe we could work together with KDE on Windows.

>   - 32 and 64-bit in one package

Not released by mingw-w64.

>   - make with -j support
>   - if this exists: can link to .dll directly, instead of import libs
>
> We should choose one version to be the reference platform and work on making
> it Tier 1. We shouldn't have two versions, that duplicates work.
>
>
>
> ___
> 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] Choosing a new MinGW for Qt 5

[Peter Kümmel]

On 31.08.2012 09:02, Pau Garcia i Quiles wrote:
>
>> All those MinGW and forks contain mingw32-make.exe util which does have -j
>> option, but in fact this option doesn't make the real parallel build. Maybe
>> sh.exe is needed, but this shell util will pass the incompatible path string
>> so that the build process will be interrupted.
>
> Are you sure of that? I remember reading a thread in the mingw.org
> mailing list in which Earnie Boyd explained MSYS did the path string
> translation and in most cases it worked fine. Or are you talking about
> the cases where it fails? (recursive spawns, overinterpretation of the
> path string, etc)
>

I'm not 100% sure, but only for a mingw-w64 version using the new 'winpthreads'
instead of 'pthreads-win32' library '-j N' did work.

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

Re: [Development] Choosing a new MinGW for Qt 5

[Peter Kümmel]

On 01.09.2012 12:52, Thiago Macieira wrote:
> On sábado, 1 de setembro de 2012 12.47.15, Peter Kümmel wrote:
>> So you think it is possible to use DW2 for 32 bit binaries?
>
> Yes.
>
>> What happens if a binary compiled with GCC/DW2 calls a
>> C++ function in a Dll compiled with MSVC and this function
>> throws an exception?
>
> First of all, how did you manage to compile that call?
>
> Remember that the C++ ABIs are incompatible. That means you made the call
> through an extern "C" function. Assume that all C functions do not throw.

Yes, that's the reason why I assume such is not a real-world setup, one
had to translate the msvc mangling into the gcc one's.

>
> [For now; on Linux and some other systems, exceptions in C are used to mark
> thread cancellation points]
>
>
>
> ___
> 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] Choosing a new MinGW for Qt 5

[Peter Kümmel]

On 01.09.2012 12:47, Peter Kümmel wrote:
> On 01.09.2012 12:39, Thiago Macieira wrote:
>> On sábado, 1 de setembro de 2012 12.23.31, Peter Kümmel wrote:
>>>"As a general rule, you should choose the default SJLJ packages,
>>> unless you know you need faster exception handling and can guarantee
>>> you'll never need to unwind through non-DW2-compiled stack frames
>>> (such as a Windows callback)"
>>>Using SJLJ "can work across code that has not been compiled with
>>>GCC or that does not have call-stack unwinding information."
>>
>> We don't need that.
>>
>> Unwinding the stack through C functions and code that isn't exception-safe in
>> the first place is stupid. The only sane outcome of doing that is a crash.
>>
>> What's more, all Qt libraries aside from QtCore and QtXmlPatterns are built
>> with exceptions disabled. That means that if your code leaks an exception
>> through a GUI event loop or a signal from one of those classes, the
>> application will crash.
>>
>> So we don't need SJLJ.
>>
>
> So you think it is possible to use DW2 for 32 bit binaries?
>
> What happens if a binary compiled with GCC/DW2 calls a
> C++ function in a Dll compiled with MSVC and this function
> throws an exception?

The exception could not be catched?

But is this a valid scenario? Catching exceptions
from a 3rd party C++ library compiled with a
different compiler?

> ___
> 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] Choosing a new MinGW for Qt 5

[Peter Kümmel]

On 01.09.2012 12:39, Thiago Macieira wrote:
> On sábado, 1 de setembro de 2012 12.23.31, Peter Kümmel wrote:
>>   "As a general rule, you should choose the default SJLJ packages,
>>unless you know you need faster exception handling and can guarantee
>>you'll never need to unwind through non-DW2-compiled stack frames
>>(such as a Windows callback)"
>>   Using SJLJ "can work across code that has not been compiled with
>>   GCC or that does not have call-stack unwinding information."
>
> We don't need that.
>
> Unwinding the stack through C functions and code that isn't exception-safe in
> the first place is stupid. The only sane outcome of doing that is a crash.
>
> What's more, all Qt libraries aside from QtCore and QtXmlPatterns are built
> with exceptions disabled. That means that if your code leaks an exception
> through a GUI event loop or a signal from one of those classes, the
> application will crash.
>
> So we don't need SJLJ.
>

So you think it is possible to use DW2 for 32 bit binaries?

What happens if a binary compiled with GCC/DW2 calls a
C++ function in a Dll compiled with MSVC and this function
throws an exception?

>
>
> ___
> 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] Choosing a new MinGW for Qt 5

[Peter Kümmel]

On 30.08.2012 18:16, Thiago Macieira wrote:
> On quinta-feira, 30 de agosto de 2012 17.25.24, Pau Garcia i Quiles wrote:
>> There are more differences than that. There are differences in
>> features, such as threading support, large-file support, etc.
>> Mingw-w64 is usually ahead of any other in terms of features.
>
> My suggestion on how to proceed is to choose one that offers the following or
> most of the following:
>
>   - most recent GCC (4.7 preferably, 4.6 if not)
>   - *working* GDB and tested with Creator, with Python support
>   - large file support, threading
>   - zero-overhead exceptions (no SJLJ exceptions)

Seems to be a complicated topic.
There are three implementations SJLJ, Dwraf-2, SEH (not SEH
support but C++ exceptions implemented with SEH)
and on two systems Win32 and Win64

http://sourceforge.net/mailarchive/message.php?msg_id=29651219
http://www.nynaeve.net/?p=113
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-August/052339.html
http://gcc.gnu.org/wiki/WindowsGCCImprovements
http://tdm-gcc.tdragon.net/start
http://sourceforge.net/tracker/?func=detail&aid=3019861&group_id=202880&atid=983357
http://sourceforge.net/apps/trac/mingw-w64/wiki/Exception%20Handling

Using Dwarf-2 (a zero-overhead implementation) is problematic:
 "As a general rule, you should choose the default SJLJ packages,
  unless you know you need faster exception handling and can guarantee
  you'll never need to unwind through non-DW2-compiled stack frames
  (such as a Windows callback)"
 Using SJLJ "can work across code that has not been compiled with
 GCC or that does not have call-stack unwinding information."


In summary:

SJLJ  & 32 : to much overhead
SJLJ  & 64 : to much overhead
Dwarf & 32 : no general stack unwinding
Dwarf & 64 : no general stack unwinding
SEH   & 32 : patented by MSFT
SEH   & 64 : only in GCC >= 4.7.2(4.8?)


>   - standard win32 headers, if possible using the Platform SDK headers
>   - large set of win32 import libraries
>   - 32 and 64-bit in one package
>   - make with -j support
>   - if this exists: can link to .dll directly, instead of import libs
>
> We should choose one version to be the reference platform and work on making
> it Tier 1. We shouldn't have two versions, that duplicates work.
>
>
>
> ___
> 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] Choosing a new MinGW for Qt 5

[Peter Kümmel]

On 30.08.2012 18:16, Thiago Macieira wrote:
>
> My suggestion on how to proceed is to choose one that offers the following or
> most of the following:
>
>   - most recent GCC (4.7 preferably, 4.6 if not)
>   - *working* GDB and tested with Creator, with Python support
>   - large file support, threading
>   - zero-overhead exceptions (no SJLJ exceptions)
>   - standard win32 headers, if possible using the Platform SDK headers
>   - large set of win32 import libraries
>   - 32 and 64-bit in one package
>   - make with -j support
>   - if this exists: can link to .dll directly, instead of import libs

 - should be also available in common distros as cross-compiler


In Ubuntu 12.04 we have this:
$ apt-cache search mingw
gcc-mingw-w64-i686 - GNU C compiler for MinGW-w64 targeting Win32
gcc-mingw-w64-x86-64 - GNU C compiler for MinGW-w64 targeting Win64
gcc-mingw32 - GNU Compiler Collection for MinGW32 (transition package)

I assume gcc-mingw32 is the official mingw32, it is only 32bit.

Fedora uses mingw-w64:
https://fedoraproject.org/wiki/MinGW/CrossCompilerFramework

So I would say mingw-w64 is the choice.

And if the Windows mingw-w64 setup misses some features we
should ask if this could be changed by the mingw-w64 project.

Peter






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

Re: [Development] Qt 5 beta

[Peter Kümmel]

On 30.08.2012 13:23, lars.kn...@nokia.com wrote:
> Hi everybody,
>
> the Qt 5 beta has now been released. Please find all the details at
>
> http://www.qt-project.org/wiki/Qt-5-Beta
>
> and my blog post at
>
> http://labs.qt.nokia.com/2012/08/30/qt-5-beta-is-here/
>
> Enjoy!
>
> Lars
>

Where should bugs be reported?
Only in Jira? Or also(only?) a post to this list?

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

Re: [Development] Qt 5 beta

[Peter Kümmel]

On 31.08.2012 13:54, Thiago Macieira wrote:
> On sexta-feira, 31 de agosto de 2012 13.40.38, Peter Kümmel wrote:
>>> On the #qt-release channel, then reviewed through Gerrit.
>>> https://codereview.qt-project.org/33837
>>
>> This is a little bit "behind closed doors".
>> Similar to the decision releasing beta without any note on the list.
>
> It wasn't closed-doors. The commit was public. If you wanted to find out about
> it, you could have set up a Gerrit notification on the qtrepotools repository.
> The #qt-labs channel had a link to #qt-releases on its topic, inviting
> everyone to participate in the process.
>
> We can't very well announce every single change we're making on the mailing
> list. I only post when it's large, relevant for others, or when I really need
> input from others.
>
> Finally, this *was* a subjective choice: mine. I want to drive adoption of
> newer, better technology. LZMA is a great improvement over the compression
> technologies used so far and the xz format is getting interesting adoption.
> Many thanks to Julian Seward for bzip2 (among other projects he's contributed
> to), but xz is producing smaller packages nowadays.
>
> So, I'd say that our position is: stop complaining and upgrade. If you can't
> upgrade, there's .gz and you'll pay the penalty by increased disk space in
> your system.
>

I also prefer LZMA, this was just a comment about the process.

>
>
> ___
> 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] Qt 5 beta

[Peter Kümmel]

On 31.08.2012 13:31, Thiago Macieira wrote:
> On sexta-feira, 31 de agosto de 2012 12.05.00, Laszlo Papp wrote:
>>> On my suggestion, we dropped .tar.bz2. We're keeping .tar.gz to ensure
>>> maximum
>>> compatibility and .tar.xz because it's the smaller of the three.
>>
>> Was this decision publicly discussed on the mailing list (development,
>> release, or both)? Perhaps, it is just me, but I have just skimmed through
>> the release mailing list, but I have not caught this discussion.
>
> On the #qt-release channel, then reviewed through Gerrit.
> https://codereview.qt-project.org/33837

This is a little bit "behind closed doors".
Similar to the decision releasing beta without any note on the list.

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

Re: [Development] Qt 5 beta

[Peter Kümmel]

On 31.08.2012 09:00, Yves Bailly wrote:
> Hello all,
>
> Le 30/08/2012 14:33, Yves Bailly a écrit :
>> Le 30/08/2012 13:23, lars.kn...@nokia.com a écrit :
>>> the Qt 5 beta has now been released. Please find all the details at
>>> http://www.qt-project.org/wiki/Qt-5-Beta
>>>
>>
>> Trying to compile on Windows 7 64bits using MSVC 2010 (32bits compiler). 
>> After having
>> read the provided README.
>>
>> NMAKE : fatal error U1077: 'C:\vs10\VC\BIN\cl.EXE' : return code '0x2'
>> Stop.
>> *** qtbase/configure exited with non-zero status.
>
> No more idea about this compiling issue? it's quite frustrating...
>

Start from scratch. Be sure your source directory is not polluted with
a previous build, therefore build out of source so you could simply throw
away a failed build deleting the complete build folder.

When it fails post the complete output, also the content of your PATH
variable: 'set' prints all environment variables.

Peter

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

Re: [Development] tools/configure with mingw build error

[Peter Kümmel]

On 29.08.2012 02:02, Rohan McGovern wrote:
>>
>> Is there a list which configurations are checked by the CI?
>>
>
> Yes, you can check the list from testresults.qt-project.org, e.g.
> http://testresults.qt-project.org/ci/QtBase_master_Integration/latest-success/

For the quality gate checks such a short list is OK.

>
> MinGW used to be tested by CI, but the compiler frequently crashed
> (internal compiler error), so it was removed - there are some links from
> this task: https://bugreports.qt-project.org/browse/QTQAINFRA-549
>
>> For instance CMake checks >30 Windows and >60 Linux/Unix configuration on a 
>> daily basis (even jom)
>> http://open.cdash.org/index.php?project=CMake
>>
>
> Impressive for sure, but note it is not really fair to compare that with
> Qt's CI, since Qt's needs to pass before code is allowed in (quality gate)
> while most of the configurations in the above link apparently don't
> (not a quality gate).

Maybe it is possible to test on a daily/weekly basis much more configurations,
and to only send an email when something breaks.

Peter




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

Re: [Development] tools/configure with mingw build error

[Peter Kümmel]

On 28.08.2012 21:14, Peter Kümmel wrote:
> On 28.08.2012 20:46, Peter Kümmel wrote:
>>>>
>>>> But also jom fails, I thought jom could also handle mingw makefiles?
>>>
>>> No, Jom only handles NMake makefiles, afaik.
>>>
>>
>> Checked it again: I could build qt/4.8 with jom.
>>
>> So I would say the Makefiles in Qt5 are broken (at least for configure).
>>
>
> Also the makefile for qmake doesn't work.
>
> In Qt 4.8 for qmake there are two makefiles for g++:
> Makefile.win32-g++ and Makefile.win32-g++-sh
>
> In qtbase/qmake there is only Makefile.win32-g++.
> The two files were merged:
>   
> https://qt.gitorious.org/qt/qtbase/commit/d9bf972e2b5f6bace5b7be350a70b4207e320692
>
> Seems nobody have used mingw/jom since 6 months.
>

This could be all checked by CI, but it isn't.

Is there a list which configurations are checked by the CI?

For instance CMake checks >30 Windows and >60 Linux/Unix configuration on a 
daily basis (even jom)
http://open.cdash.org/index.php?project=CMake

> Peter
>
>
>> Peter
>> ___
>> 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] tools/configure with mingw build error

[Peter Kümmel]

On 28.08.2012 21:12, marius.storm-ol...@nokia.com wrote:
> On 28/08/2012 13:46, ext Peter Kümmel wrote:
>> On 28.08.2012 19:59, marius.storm-ol...@nokia.com wrote:
>>> On 28/08/2012 12:48, ext Peter Kümmel wrote:
>>>> But also jom fails, I thought jom could also handle mingw
>>>> makefiles?
>>>
>>> No, Jom only handles NMake makefiles, afaik.
>>
>> Checked it again: I could build qt/4.8 with jom.
>>
>> So I would say the Makefiles in Qt5 are broken (at least for
>> configure).
>
> What was the mkspec for Qt 4.8 when you built it with Jom?

mkspecs/win32-g++-4.6

>
> (Look at the contents of /.qmake.cache and look at the QMAKESPEC
> variable)
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] tools/configure with mingw build error

[Peter Kümmel]

On 28.08.2012 20:46, Peter Kümmel wrote:
>>>
>>> But also jom fails, I thought jom could also handle mingw makefiles?
>>
>> No, Jom only handles NMake makefiles, afaik.
>>
>
> Checked it again: I could build qt/4.8 with jom.
>
> So I would say the Makefiles in Qt5 are broken (at least for configure).
>

Also the makefile for qmake doesn't work.

In Qt 4.8 for qmake there are two makefiles for g++:
Makefile.win32-g++ and Makefile.win32-g++-sh

In qtbase/qmake there is only Makefile.win32-g++.
The two files were merged:
 
https://qt.gitorious.org/qt/qtbase/commit/d9bf972e2b5f6bace5b7be350a70b4207e320692

Seems nobody have used mingw/jom since 6 months.

Peter


> Peter
> ___
> 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] tools/configure with mingw build error

[Peter Kümmel]

On 28.08.2012 19:59, marius.storm-ol...@nokia.com wrote:
> On 28/08/2012 12:48, ext Peter Kümmel wrote:
>> On 28.08.2012 19:27, marius.storm-ol...@nokia.com wrote:
>>> On 28/08/2012 12:16, ext Peter Kümmel wrote:
>>>> Have I missed something or is building with mingw in cmd.exe not supported?
>>>
>>> This is not your fault, it's the rubenvb release which is broken, as the
>>> GNU Make tool provided is not properly splitting the file paths. Thus,
>>> mingw32-make is trying to stat the wrong files and cannot find all the
>>> files required.
>>>
>>> If you're feeling adventurous, I've found that you can do a binary patch
>>> by simply replacing the pattern 0x003a3b00 with 0x003b3b00 in
>>> mingw32-make.exe, and it should do the path splitting correctly and find
>>> the required files.
>>>
>>> Note that this is just a work-around, and Ruben will have to correct the
>>> way he cross-compiles the MinGW tools.
>>>
>>> See
>>> http://sourceforge.net/tracker/?func=detail&aid=3545000&group_id=202880&atid=983354
>>> for details.
>>
>> Ahh thanks.
>>
>> But also jom fails, I thought jom could also handle mingw makefiles?
>
> No, Jom only handles NMake makefiles, afaik.
>

Checked it again: I could build qt/4.8 with jom.

So I would say the Makefiles in Qt5 are broken (at least for configure).

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

Re: [Development] tools/configure with mingw build error

[Peter Kümmel]

On 28.08.2012 19:27, marius.storm-ol...@nokia.com wrote:
> On 28/08/2012 12:16, ext Peter Kümmel wrote:
>> I've tried to build qtbase
>> 1. on Windows 7
>> 2. rubenvb's mingw-w64:
>> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-4.7-release/
>> 3. in Windows shell cmd.exe
>> 4. as shadow build with ..\qtbase\configure.bat -fast -nomake demos -nomake 
>> examples -release
>>
>> It copies the headers and starts to build configure.exe but after compiling 
>> three files
>> it starts to links and complains about missing .o files.
>>
>> Have I missed something or is building with mingw in cmd.exe not supported?
>
> This is not your fault, it's the rubenvb release which is broken, as the
> GNU Make tool provided is not properly splitting the file paths. Thus,
> mingw32-make is trying to stat the wrong files and cannot find all the
> files required.
>
> If you're feeling adventurous, I've found that you can do a binary patch
> by simply replacing the pattern 0x003a3b00 with 0x003b3b00 in
> mingw32-make.exe, and it should do the path splitting correctly and find
> the required files.
>
> Note that this is just a work-around, and Ruben will have to correct the
> way he cross-compiles the MinGW tools.
>
> See
> http://sourceforge.net/tracker/?func=detail&aid=3545000&group_id=202880&atid=983354
> for details.

Ahh thanks.

But also jom fails, I thought jom could also handle mingw makefiles?

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

[Development] tools/configure with mingw build error

[Peter Kümmel]

I've tried to build qtbase
1. on Windows 7
2. rubenvb's mingw-w64: 
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-4.7-release/
3. in Windows shell cmd.exe
4. as shadow build with ..\qtbase\configure.bat -fast -nomake demos -nomake 
examples -release

It copies the headers and starts to build configure.exe but after compiling 
three files
it starts to links and complains about missing .o files.

Have I missed something or is building with mingw in cmd.exe not supported?
(looks like tools/configure/Makefile.mingw is for sh)

Peter

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

Re: [Development] Cross-compling & installing cmake files

[Peter Kümmel]

Many thanks! That solves the problem.

AFAIK mingw still uses the runtime from Studio 6.0.

libstdc++-6.dll links against msvcrt.dll which is here version 7.0

On 28.08.2012 13:55, Andreas Holzammer wrote:
> You are also missing the platform plugin und
> plugin/platforms/windows.dll, needs to be copied to
> win32-mainwindow/platforms. I cannot imagine that the msvc runtime is
> missing, because you are using the mingw compiler and the compiler does
> not use the msvc runtine...
>
> Am 28.08.2012 13:37, schrieb Peter Kümmel:
>> On 28.08.2012 12:18, Peter Kümmel wrote:
>>> On 28.08.2012 12:04, Stephen Kelly wrote:
>>>> On Tuesday, August 28, 2012 11:49:28 Peter Kümmel wrote:
>>>>> I tried it again from scratch, and I was wrong, it also doesn't work
>>>>> on 12.04, only one file is copied: lib/cmake/Qt5Core/Qt5CTestMacros.cmake
>>>>
>>>> Ok. Please tell me how to try it out.
>>>>
>>>> 'aptitude search mingw' gives many result. I have not used mingw on linux
>>>> before.
>>>>
>>>
>>> sudo apt-get install mingw-w64
>>>
>>> and attched script to build Qt.
>>>
>>
>> When you build Qt5 this way the generated executables are not usable.
>> You could try with the mainwindow example:
>>
>> On Windows you need some dlls:
>>
>> $ mkdir win32-mainwindow
>> $ cp release/mainwindow.exe win32-mainwindow/
>> $ cp /opt/Qt-5.0.0-win32-g++-i686-w64-mingw32/bin/*.dll win32-mainwindow/
>> $ cp /usr/lib/gcc/i686-w64-mingw32/4.6/*.dll win32-mainwindow/
>>
>> Running mainwindow.exe gives the error:
>> "This application has requested the Runtime to terminate it in an unusual 
>> way"
>>
>> Seems the msvc runtime is misused:
>> http://goo.gl/e41XF
>>
>> Peter
>>
>>
>> ___
>> 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] Cross-compling & installing cmake files

[Peter Kümmel]

On 28.08.2012 12:18, Peter Kümmel wrote:
> On 28.08.2012 12:04, Stephen Kelly wrote:
>> On Tuesday, August 28, 2012 11:49:28 Peter Kümmel wrote:
>>> I tried it again from scratch, and I was wrong, it also doesn't work
>>> on 12.04, only one file is copied: lib/cmake/Qt5Core/Qt5CTestMacros.cmake
>>
>> Ok. Please tell me how to try it out.
>>
>> 'aptitude search mingw' gives many result. I have not used mingw on linux
>> before.
>>
>
> sudo apt-get install mingw-w64
>
> and attched script to build Qt.
>

When you build Qt5 this way the generated executables are not usable.
You could try with the mainwindow example:

On Windows you need some dlls:

$ mkdir win32-mainwindow
$ cp release/mainwindow.exe win32-mainwindow/
$ cp /opt/Qt-5.0.0-win32-g++-i686-w64-mingw32/bin/*.dll win32-mainwindow/
$ cp /usr/lib/gcc/i686-w64-mingw32/4.6/*.dll win32-mainwindow/

Running mainwindow.exe gives the error:
"This application has requested the Runtime to terminate it in an unusual way"

Seems the msvc runtime is misused:
http://goo.gl/e41XF

Peter


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

Re: [Development] Cross-compling & installing cmake files

[Peter Kümmel]

On 28.08.2012 12:04, Stephen Kelly wrote:

On Tuesday, August 28, 2012 11:49:28 Peter Kümmel wrote:

I tried it again from scratch, and I was wrong, it also doesn't work
on 12.04, only one file is copied: lib/cmake/Qt5Core/Qt5CTestMacros.cmake


Ok. Please tell me how to try it out.

'aptitude search mingw' gives many result. I have not used mingw on linux
before.



sudo apt-get install mingw-w64

and attched script to build Qt.

Peter

#!/bin/sh

../qtbase/configure -xplatform win32-g++ -device-option 
CROSS_COMPILE=i686-w64-mingw32- -nomake examples -nomake demos -fast -release 
-prefix /opt/Qt-5.0.0-win32-g++-i686-w64-mingw32 -opensource -confirm-license 
&& make -j5 && sudo make install

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

Re: [Development] Cross-compling & installing cmake files

[Peter Kümmel]

On 28.08.2012 11:03, Stephen Kelly wrote:
> On Tuesday, August 28, 2012 10:44:58 Peter Kümmel wrote:
>>>> In the build dir the files are in lib/cmake, but
>>>> they are not copied to the install dir.
>>>
>>> Does the install step complete without warnings or errors?
>>
>> No, there are no cmake rule in the Makefiles which could fail.
>>
>>> I can only confirm that when I cross compile for QNX on a linux host, the
>>> cmake files are created and work fine.
>>
>> The wonders of updates:
>> The error happens on Ubuntu 11.10. On 12.04 it works.
>
> Interesting.

I tried it again from scratch, and I was wrong, it also doesn't work
on 12.04, only one file is copied: lib/cmake/Qt5Core/Qt5CTestMacros.cmake

>
> I can't explain it, and I don't have a 11.10 system to try it with anymore. I
> do know that in non-cross builds, it works just fine on 11.10 (that's unit
> tested).
>
> Thanks,
>
>
>
>
> ___
> 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] Cross-compling & installing cmake files

[Peter Kümmel]

On 28.08.2012 10:34, Stephen Kelly wrote:
> On Monday, August 27, 2012 19:23:19 Peter Kümmel wrote:
>> On 27.08.2012 19:14, Peter Kümmel wrote:
>>> Cross-compiling with mkspec/win win32-g++ doesn't
>
> This doesn't mean anything to me. What is the host and what is the target?

On Linux with mingw to win32.

>
>>> install the cmake files into lib/cmake.
>>>
>>> The line in mkspecs/features/create_cmake.prf
>>>
>>>INSTALLS += cmake_qt5_module_files
>>>
>>> is called but ignored, there are no install rules
>>> in the Makefiles for cmake files.
>>>
>>> Any ideas how to fix this?
>>
>> In the build dir the files are in lib/cmake, but
>> they are not copied to the install dir.
>
> Does the install step complete without warnings or errors?

No, there are no cmake rule in the Makefiles which could fail.

>
> I can only confirm that when I cross compile for QNX on a linux host, the
> cmake files are created and work fine.

The wonders of updates:
The error happens on Ubuntu 11.10. On 12.04 it works.

>
> Thanks,
>
>
>
>
> ___
> 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] Cross-compling & installing cmake files

[Peter Kümmel]

On 27.08.2012 19:14, Peter Kümmel wrote:
> Cross-compiling with mkspec/win win32-g++ doesn't
> install the cmake files into lib/cmake.
>
> The line in mkspecs/features/create_cmake.prf
>
>   INSTALLS += cmake_qt5_module_files
>
> is called but ignored, there are no install rules
> in the Makefiles for cmake files.
>
> Any ideas how to fix this?

In the build dir the files are in lib/cmake, but
they are not copied to the install dir.

>
> Peter

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

[Development] Cross-compling & installing cmake files

[Peter Kümmel]

Cross-compiling with mkspec/win win32-g++ doesn't
install the cmake files into lib/cmake.

The line in mkspecs/features/create_cmake.prf

 INSTALLS += cmake_qt5_module_files

is called but ignored, there are no install rules
in the Makefiles for cmake files.

Any ideas how to fix this?

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

Re: [Development] Qt5 crash in glXGetFBConfigs via qglxconvenience.cpp

[Peter Kümmel]

On 27.08.2012 13:30, Thiago Macieira wrote:
> On segunda-feira, 27 de agosto de 2012 13.23.47, Peter Kümmel wrote:
>> On 27.08.2012 13:12, Peter Kümmel wrote:
>>> qtbase/examples/widgets/mainwindows/mainwindow
>>> crashes here immediately on startup. Attached the backtrace.
>>>
>>> It's a fresh Qt5 build on a virtual machine.
>>> Ubuntu 12.04 based distro
>>> gcc 4.6.3
>>>
>>> All is fine with Qt4.
>>> I have a debug setup here so I could provide more information.
>>
>> When I remove fglrx it crashes in libxcb-glx, see attachment.
>>
>> Is this maybe a bug in the distro/driver and not in Qt?
>>
>> Peter
>
> Works here, using Mesa.
>

When I disable OpenGL it works here too.
I assume OpenGL support in VirtualBox is simply too bad.

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

Re: [Development] Qt5 crash in glXGetFBConfigs via qglxconvenience.cpp

[Peter Kümmel]

On 27.08.2012 13:12, Peter Kümmel wrote:

qtbase/examples/widgets/mainwindows/mainwindow
crashes here immediately on startup. Attached the backtrace.

It's a fresh Qt5 build on a virtual machine.
Ubuntu 12.04 based distro
gcc 4.6.3

All is fine with Qt4.
I have a debug setup here so I could provide more information.



When I remove fglrx it crashes in libxcb-glx, see attachment.

Is this maybe a bug in the distro/driver and not in Qt?

Peter
(gdb) bt
#0  0x72af5100 in xcb_glx_query_server_string_string_length () from 
/usr/lib/x86_64-linux-gnu/libxcb-glx.so.0
#1  0x74923444 in ?? () from /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
#2  0x74903348 in ?? () from /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
#3  0x748ff1e7 in glXGetFBConfigs () from 
/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
#4  0x74900178 in glXChooseFBConfigSGIX () from 
/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
#5  0x704da142 in qglx_findConfig (display=0x63adc0, screen=0, 
format=..., drawableBit=1) at 
/home/synth/sandbox/qt5/qtbase/src/platformsupport/glxconvenience/qglxconvenience.cpp:124
#6  0x704da33e in qglx_findVisualInfo (display=0x63adc0, screen=0, 
format=0x75cfe8) at 
/home/synth/sandbox/qt5/qtbase/src/platformsupport/glxconvenience/qglxconvenience.cpp:169
#7  0x704b2f50 in QXcbWindow::create (this=0x75cf90) at 
/home/synth/sandbox/qt5/qtbase/src/plugins/platforms/xcb/qxcbwindow.cpp:240
#8  0x704b2b35 in QXcbWindow::QXcbWindow (this=0x75cf90, 
window=0x6584f0) at 
/home/synth/sandbox/qt5/qtbase/src/plugins/platforms/xcb/qxcbwindow.cpp:171
#9  0x704a56e3 in QXcbIntegration::createPlatformWindow (this=0x632830, 
window=0x6584f0) at 
/home/synth/sandbox/qt5/qtbase/src/plugins/platforms/xcb/qxcbintegration.cpp:132
#10 0x76dc80b5 in QWindow::create (this=0x6584f0) at 
/home/synth/sandbox/qt5/qtbase/src/gui/kernel/qwindow.cpp:312
#11 0x775b5b52 in QWidgetPrivate::create_sys (this=0x65ff20, window=0, 
initializeWindow=true, destroyOldWindow=true) at 
/home/synth/sandbox/qt5/qtbase/src/widgets/kernel/qwidget_qpa.cpp:135
#12 0x7757ddbd in QWidget::create (this=0x7fffe5d0, window=0, 
initializeWindow=true, destroyOldWindow=true) at 
/home/synth/sandbox/qt5/qtbase/src/widgets/kernel/qwidget.cpp:1320
#13 0x7758d75f in QWidget::setVisible (this=0x7fffe5d0, 
visible=true) at 
/home/synth/sandbox/qt5/qtbase/src/widgets/kernel/qwidget.cpp:7219
#14 0x7758cbbc in QWidget::show (this=0x7fffe5d0) at 
/home/synth/sandbox/qt5/qtbase/src/widgets/kernel/qwidget.cpp:6925
#15 0x0041be36 in main (argc=1, argv=0x7fffe768) at 
/home/synth/sandbox/qt5/qtbase/examples/widgets/mainwindows/mainwindow/main.cpp:162
(gdb) 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt5 crash in glXGetFBConfigs via qglxconvenience.cpp

[Peter Kümmel]

qtbase/examples/widgets/mainwindows/mainwindow
crashes here immediately on startup. Attached the backtrace.

It's a fresh Qt5 build on a virtual machine.
Ubuntu 12.04 based distro
gcc 4.6.3

All is fine with Qt4.
I have a debug setup here so I could provide more information.

Peter


(gdb) bt
#0  0x749715ae in glXGetFBConfigs () from /usr/lib/fglrx/libGL.so.1
#1  0x7497221a in ?? () from /usr/lib/fglrx/libGL.so.1
#2  0x74972479 in glXChooseFBConfigSGIX () from 
/usr/lib/fglrx/libGL.so.1
#3  0x71388142 in qglx_findConfig (display=0x63b620, screen=0, 
format=..., drawableBit=1) at 
/home/synth/sandbox/qt5/qtbase/src/platformsupport/glxconvenience/qglxconvenience.cpp:124
#4  0x7138833e in qglx_findVisualInfo (display=0x63b620, screen=0, 
format=0x75dc48) at 
/home/synth/sandbox/qt5/qtbase/src/platformsupport/glxconvenience/qglxconvenience.cpp:169
#5  0x71360f50 in QXcbWindow::create (this=0x75dbf0) at 
/home/synth/sandbox/qt5/qtbase/src/plugins/platforms/xcb/qxcbwindow.cpp:240
#6  0x71360b35 in QXcbWindow::QXcbWindow (this=0x75dbf0, 
window=0x6591e0) at 
/home/synth/sandbox/qt5/qtbase/src/plugins/platforms/xcb/qxcbwindow.cpp:171
#7  0x713536e3 in QXcbIntegration::createPlatformWindow (this=0x632b60, 
window=0x6591e0) at 
/home/synth/sandbox/qt5/qtbase/src/plugins/platforms/xcb/qxcbintegration.cpp:132
#8  0x76dc80b5 in QWindow::create (this=0x6591e0) at 
/home/synth/sandbox/qt5/qtbase/src/gui/kernel/qwindow.cpp:312
#9  0x775b5b52 in QWidgetPrivate::create_sys (this=0x660ba0, window=0, 
initializeWindow=true, destroyOldWindow=true) at 
/home/synth/sandbox/qt5/qtbase/src/widgets/kernel/qwidget_qpa.cpp:135
#10 0x7757ddbd in QWidget::create (this=0x7fffe5d0, window=0, 
initializeWindow=true, destroyOldWindow=true) at 
/home/synth/sandbox/qt5/qtbase/src/widgets/kernel/qwidget.cpp:1320
#11 0x7758d75f in QWidget::setVisible (this=0x7fffe5d0, 
visible=true) at 
/home/synth/sandbox/qt5/qtbase/src/widgets/kernel/qwidget.cpp:7219
#12 0x7758cbbc in QWidget::show (this=0x7fffe5d0) at 
/home/synth/sandbox/qt5/qtbase/src/widgets/kernel/qwidget.cpp:6925
#13 0x0041be36 in main (argc=1, argv=0x7fffe768) at 
/home/synth/sandbox/qt5/qtbase/examples/widgets/mainwindows/mainwindow/main.cpp:162
(gdb) 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Q_PLUGIN_METADATA without FILE

[Peter Kümmel]

On 26.08.2012 20:14, Peter Kümmel wrote:
> http://doc-snapshot.qt-project.org/5.0/qtplugin.html#Q_PLUGIN_METADATA
>
> When Q_PLUGIN_METADATA() is used with a FILE name which doesn't
> exist, moc throws an error, but when FILE isn't present at all
> moc silently doesn't generate the pluginMetaData[]s.
> Isn't this a bug?
>

False alarm. But the docu doesn't mention that FILE is optional.

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

[Development] Q_PLUGIN_METADATA without FILE

[Peter Kümmel]

http://doc-snapshot.qt-project.org/5.0/qtplugin.html#Q_PLUGIN_METADATA

When Q_PLUGIN_METADATA() is used with a FILE name which doesn't
exist, moc throws an error, but when FILE isn't present at all
moc silently doesn't generate the pluginMetaData[]s.
Isn't this a bug?

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

Re: [Development] No QT_NO_DEBUG in Qt5 cmake files

[Peter Kümmel]

On 26.08.2012 18:16, Thiago Macieira wrote:
> On domingo, 26 de agosto de 2012 17.31.07, Peter Kümmel wrote:
>> When building plugins, moc generates files with '#ifdef QT_NO_DEBUG'
>> but the lib/cmake modules doesn't add QT_NO_DEBUG for release builds.
>> A bug?
>
> What are you talking about?

A bug in Qt5CoreMacros.cmake:
http://qt.gitorious.org/qt/qtbase/blobs/master/src/corelib/Qt5CoreMacros.cmake#line216


moc generates this plugin code:

#ifdef QT_NO_DEBUG

QT_PLUGIN_METADATA_SECTION
static const unsigned char qt_pluginMetaData[] = { ... };
#else // QT_NO_DEBUG

QT_PLUGIN_METADATA_SECTION
static const unsigned char qt_pluginMetaData[] = { ... };
#endif // QT_NO_DEBUG


Therefore also QT_NO_DEBUG must be defined for a release build, if not then
the plugin could not be loaded (at least on Windows) because the plugin
meta info says the the plugin is a debug build.

When 'qt5_use_modules _target' is used, QT_NO_DEBUG is not set even if
'qt5_use_modules _target' adds other defines:
 set_property(TARGET ${_target} APPEND PROPERTY COMPILE_DEFINITIONS 
${Qt5${_module}_COMPILE_DEFINITIONS})

A workaround is to define QT_NO_DEBUG in the project which uses Qt5

 set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -DQT_NO_DEBUG")

but I think QT_NO_DEBUG should be already set by the cmake code shipped with Qt.

Peter





>
> The moc program is the same, regardless of your buildsystem. CMake runs it to
> generate code, even if the automoc functionality is enabled. So the code
> generation is the same.
>
>
>
>
> ___
> 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] No QT_NO_DEBUG in Qt5 cmake files

[Peter Kümmel]

When building plugins, moc generates files with '#ifdef QT_NO_DEBUG'
but the lib/cmake modules doesn't add QT_NO_DEBUG for release builds.
A bug?

Peter



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

Re: [Development] Cross compiling Qt 5

[Peter Kümmel]

On Sun, 19 Aug 2012 12:00:25 +0200
Thiago Macieira  wrote:
> 
> I'd actually prefer that you clean this up *after* we switch buildsystems, 

Ahhh! :)

> whenever that happens. Cleaning up configure is an unnecessary task if we're 
> going to throw it away soon after.
> 
> Please keep changes to the qmake & configure buildsystem to a minimum 
> required 
> to support the 5.0 release.

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

[Development] Cross compiling Qt 5

[Peter Kümmel]

Qt could be compiled native or cross for a system 
different to the system on which Qt is build.

But this is not how mkspecs/ is organized:

linux-*native
win32-*native
wince* cross
unsupported/*  cross and native
device/*   cross

also configure supports different options:
  -xplatform
  -device
  -device-options
  -sysroot

In short, it is a mess.


Couldn't we cleanup this by only having native specs
in 'mkspecs' and cross specs in 'mkspecs/target'.

A more configure like option would be 'target',
not 'xplatform' or 'device':

http://airs.com/ian/configure/configure_5.html
   When building cross compilation tools, 
   there are two different systems involved: 
   the system on which the tools will run, 
   and the system for which the tools generate code.
   - The system on which the tools will run is called the host system.
   - The system for which the tools generate code is called the target system.

Therefore I propose to cleanup this before the 5.0 release.


AFAIK host != "system on which configure runs" is not supported by Qt, 
so we only need 'target' based options.

We need at least these two options:
  1. specify mkspec name
  2. specify toolchain prefix

maybe also ( 
http://labs.qt.nokia.com/2012/04/13/cross-compiling-qt-for-the-masses/ )
  3. sysroot
  4. additional options


Here a proposal:
  1. -target-mkspec  : specify mkspec name
  2. -target : specify toolchain prefix
  3. isn't sysroot specified by the toolchain compiler? 
  4. not needed


Or are we already in the "wait for 5 + N mode"?

Peter





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

Re: [Development] The BuildFlags test you attempted last week...

[Peter Kümmel]

sorry, wrong list.

On 10.07.2012 11:21, Peter Kümmel wrote:
> On 09.07.2012 17:35, David Cole wrote:
>> Not sure what your main goal was for that test, but a similar test already 
>> exists to ensure proper definition of
>
> http://www.cmake.org/Bug/view.php?id=13069
>
> Seems there is no test which checks if -DCMAKE_BUILD_TYPE=XXX triggers the 
> selection of the matching CMAKE_C_FLAGS_XXX:
>
> CMakeLists: set(CMAKE_C_FLAGS_DEBUG -DTEST_STRING="${CMAKE_BUILD_TYPE}"
> main.c: printf("%s\n", TEST_STRING)
> test  : output == ${CMAKE_BUILD_TYPE}
>
>
>> CMAKE_BUILD_TYPE or proper selection of build configuration in a 
>> multi-config generator. But only in the context of
>> running a ctest -D dashboard or a ctest -S dashboard script.
>>
>> See the files Tests/CTestConfig/CMakeLists.txt and 
>> Tests/CTestConfig/CTestConfig.cxx for details.
>>
>> You would need a block for "if(CMAKE_CONFIGURATION_TYPES)" in order to get 
>> the logic just right w.r.t. CMAKE_BUILD_TYPE
>> in your test.
>>
>> The Visual Studio and/or Xcode dashboards that did pass your test, passed it 
>> by luck because the built configuration
>> happened to match the CMAKE_BUILD_TYPE that you were trying to "expect".
>>
>> The important piece of knowledge to have here is that CMAKE_BUILD_TYPE is 
>> not defined for multi-config generators, and
>> in fact, it should be considered bad practice, although it's not strictly an 
>> error, to define it in such a build tree.
>> Because in a multi-config generator you can actually have multiple builds 
>> (Debug+Release+...) existing side-by-side in
>> the same build tree.
>>
>>
>> Hope this helps,
>> David
>>
> ___
> 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] The BuildFlags test you attempted last week...

[Peter Kümmel]

On 09.07.2012 17:35, David Cole wrote:
> Not sure what your main goal was for that test, but a similar test already 
> exists to ensure proper definition of

http://www.cmake.org/Bug/view.php?id=13069

Seems there is no test which checks if -DCMAKE_BUILD_TYPE=XXX triggers the 
selection of the matching CMAKE_C_FLAGS_XXX:

CMakeLists: set(CMAKE_C_FLAGS_DEBUG -DTEST_STRING="${CMAKE_BUILD_TYPE}"
main.c: printf("%s\n", TEST_STRING)
test  : output == ${CMAKE_BUILD_TYPE}


> CMAKE_BUILD_TYPE or proper selection of build configuration in a multi-config 
> generator. But only in the context of
> running a ctest -D dashboard or a ctest -S dashboard script.
>
> See the files Tests/CTestConfig/CMakeLists.txt and 
> Tests/CTestConfig/CTestConfig.cxx for details.
>
> You would need a block for "if(CMAKE_CONFIGURATION_TYPES)" in order to get 
> the logic just right w.r.t. CMAKE_BUILD_TYPE
> in your test.
>
> The Visual Studio and/or Xcode dashboards that did pass your test, passed it 
> by luck because the built configuration
> happened to match the CMAKE_BUILD_TYPE that you were trying to "expect".
>
> The important piece of knowledge to have here is that CMAKE_BUILD_TYPE is not 
> defined for multi-config generators, and
> in fact, it should be considered bad practice, although it's not strictly an 
> error, to define it in such a build tree.
> Because in a multi-config generator you can actually have multiple builds 
> (Debug+Release+...) existing side-by-side in
> the same build tree.
>
>
> Hope this helps,
> David
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templates as QObjects

[Peter Kümmel]

On 26.06.2012 23:17, Olivier Goffart wrote:
>
> I'm not sure the class name is that important.
> I mean, if  Foo().metaObject()->className() is just "Foo" it is still ok.
> Because it is hard to support, and hardly usefull.

OK, I thought className() is used by qobject_cast, but it isn't,
so it's maybe really not that important.

But I could imagine when you do alot gui stuff dynamically the
class name would be usefully. A simple grep and wc in qtbase/src
gives 158 hits, so it is used.

>
> Also remember that template parametter can be more complex than just a type.
> It probably should support stuff as complicated as this
>
> template  class T,
>typename T<>::size_type = sizeof(T<>)>  class Bar;
> (I think i made that quite complicated already)

Yes, currently removing 'class' and 'typename' within <...> must
give valid signature, anything else is not supported. But this is
an isolated piece of code, and could be replaced by a more
sophisticated code later.

>
> The fact that you have that macro Q_QOBJECT_TEMPLATE_USED limit you to only
> one parametter (because you cannot have coma in macro)
> (But we could say it is ok to only support multple parametter with compiler
> that support variadic macros)

Or we introduce
Q_QOBJECT_TEMPLATE_USED_1(x)
Q_QOBJECT_TEMPLATE_USED_2(x,y) ...

>
>
> But to answer your question, the extraData is not being used currently and is
> reserved for future use, so yes, it can be used.
>

What is missing atm, are some tests for linking. I assume there will
be linker errors because of the statics when the header is included
in multiple files. And for Dlls it would be even more complicated.

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

Re: [Development] templates as QObjects

[Peter Kümmel]

On 22.06.2012 09:26, Olivier Goffart wrote:
>
> Nice stuff. Now you just need to make it for Qt5, and handle all the special
> cases :-)
>
> There is a room for tests in tets/auto/tools/moc (I'm saying that because you
> made your test somewhere else)
>

OK, ported to Qt5 now:
https://qt.gitorious.org/~syntheticpp/qt/qt5base/commit/3f37d08b81e63db6a8444eff3c08afb044d72d67

Currently it uses "extradata" in QMetaObject where each concrete template 
instantiation
stores its name (e.g. Foo instead of Foo).
Is this pointer already used by someone else?
Could we add another pointer to the private structure of QMetaObject even when 
this patch
comes after 5.0, because when extradata is already used we later have no place 
for other new stuff.

I would like to use this patch as starting point for a merge request,
so comments are welcome.

Peter


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

Re: [Development] buildsystem branches (about to be) integrated

[Peter Kümmel]

On 26.06.2012 12:28, Oswald Buddenhagen wrote:
> On Mon, Jun 25, 2012 at 12:56:15PM +0200, ext Peter Kümmel wrote:
>> Shadow builds [...] are broken:
>>
> fix integrated

Yes it works now. Thanks!

Wouldn't this be a test case for the build server?

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

Re: [Development] buildsystem branches (about to be) integrated

[Peter Kümmel]

On 25.06.2012 16:03, Иван Комиссаров wrote:
> Same for OpenSuse
>

And Ubuntu:
features/qt_module_config.prf:87: ERROR creating directory /mkspecs/modules-inst

Also here the the outdir path is lost.

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

Re: [Development] buildsystem branches (about to be) integrated

[Peter Kümmel]

On 19.06.2012 14:31, Oswald Buddenhagen wrote:
> moin,
>
> the buildsystem branch of qtbase is currently being integrated. this is
> ~120 commits worth of qmake&  project file fixes and cleanups. there are
> some changes to how modularization (in particular configure tests) is
> handled, and cross-building should be supported without hacks finally.
>
> the immediate impact:
> - lots of build scripts which employ various hacks will instantly
>break. don't panic and (mostly) just delete some code from them.
>use
>configure -xplatform  -sysroot
>make
>as you would intuitively expect. don't play tricks with funny qmake
>and make invocations.
> - the other modules will spit out lots of warnings now.
>*DON'T* do anything about them for now. i have patches prepared for
>all modules already. i will explicitly add the module owners to the
>reviews. *don't* stage anything yourself.
>once my patches are through, there will be still some warnings left.
>you'll be invited to fix them at this point.
> - some build configurations will work even worse than before until
>everything is integrated. the only variants which are expected to be
>safe are developer builds without -prefix and module-by-module builds
>with -prefix.
>
> catch me on IRC if something breaks for you and no obvious solution
> seems to help. but remember that not every breakage is due to this
> branch being integrated. ;)


Shadow builds on windows are broken:

 = D:/qt5/qtbase
 = D:/qt5/build

The include pathes to  are broken, they all miss "\qt5\build":


cl ...
-I"d:\include"
-I"d:\include\QtCore"
-I"\include\QtCore\5.0.0"
-I"\include\QtCore\5.0.0\QtCore"
-I"d:\qt5\qtbase\src\corelib\tmp"
-I"global"
-I"d:\qt5\qtbase\src\3rdparty\zlib"
-I"d:\qt5\qtbase\src\3rdparty\pcre"
-I"d:\qt5\qtbase\src\3rdparty\harfbuzz\src"
-I"d:\qt5\qtbase\src\3rdparty\md5"
-I"d:\qt5\qtbase\src\3rdparty\md4"
-I"tmp\moc\debug_shared"
-I"."
-I"d:\qt5\qtbase\mkspecs\win32-msvc2010"
...

d:\qt5\qtbase\src\corelib\global\qt_pch.h(58) :
   fatal error C1083: Datei (Include) kann nicht
   geöffnet werden: "qglobal.h": No such file or directory


Peter

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

[Development] templates as QObjects

[Peter Kümmel]

After the "noise" here "real" code:

https://qt.gitorious.org/~syntheticpp/qt/qt4/commit/c1b839494d90e8c1a93b0dd2e08a2a365095d89f

Based on Qt 4.8.2.
moc creates a header when it finds a template, if not then nothing changes.
(It builds Qt with the patch, but it's a hack in the parser)


In summary

   Foo foo1;
   Foo foo2;
   Foo foo3;

   // works
   QObject::connect(&foo1, SIGNAL(asignal(T)), &foo2, SLOT(aslot(T)));


   // this should be possible, but string matching fails
   // no problem in Qt5
   QObject::connect(&a, SIGNAL(asignal(int)), &foo1, SLOT(aslot(T)));


   // this should not be possible, but it runs because of the (void*) casts in 
the background
   // maybe catched in Qt5
   QObject::connect(&foo1, SIGNAL(asignal(T)), &foo3, SLOT(aslot(T)));


It's only an experiment, to see what could be done without using clang.

Maybe I bring it up at the QtCS.

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

Re: [Development] Container refactor update

[Peter Kümmel]

On 20.06.2012 13:38, Thiago Macieira wrote:
> On quarta-feira, 20 de junho de 2012 13.09.40, Peter Kümmel wrote:
>> On 20.06.2012 12:31, Thiago Macieira wrote:
>>> On quarta-feira, 20 de junho de 2012 10.47.01, Peter Kümmel wrote:
>>>> When Foo   is used, we would need the meta type information
>>>> with 'int' not with T:
>>>>
>>>> static const char qt_meta_stringdata_Foo[] = {
>>>>
>>>>"Foo\0\0t\0asignal(int)\0"
>>>>
>>>> };
>>>
>>> Who generates this?
>>
>> moc, we simply tell it for which types it should generate it.
>> This was the idea for "Q_QOBJECT_SPECIALISATION(int)"
>
> Please tell me what it should generate for these classes then:

I see, string based matching signal/slots will not work,
only simple replacements would make sense,
asignal(T t) -> asignal(int t).


But to get different meta types we still can use a specialization:

>
> template  class Foo
> {
>  Q_OBJECT
> signals:
>  void asignal(typename std::make_unsigned::type)
>  void othersignal(typename std::remove_reference::type&)
> };

With a typedef c&p is maybe enough:

template<>
class Foo
{
  Q_OBJECT

public:
  typedef int T;

signals:
  void asignal(typename std::make_unsigned::type)
  void othersignal(typename std::remove_reference::type&)
};


static const char qt_meta_stringdata_Foo[] = {
"Foo\0\0t\0asignal(...)\0"

The signal signature as string isn't relevant than any more.


And not all template "tricks" have to be supported.
Currently Qt says
   "Template classes not supported by Q_OBJECT"
we could switch to something like
   "Template class is too complex to be a QObject"

Peter


>
> template  class Foo
> {
>  Q_OBJECT
> signals:
>  void ptrsignal(T);
> };
>
> template  class Bar
> {
>  Q_OBJECT
> signals:
>  void asignal(typename QIntegerForSize::Unsigned);
> };
>
> Note that I can make this as complex as you can ask.
>
>
>
>
> ___
> 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] Container refactor update

[Peter Kümmel]

On 20.06.2012 13:44, Giuseppe D'Angelo wrote:
> Is it me or this thread was badly derailed?
>
> Cheers,

Don't worry I will be bashed down soon.

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