from:"marius.storm\-olsen"

On 23/07/2012 08:34, ext song.7@nokia.com wrote:
 Hi,

 Can somebody point out how to get the latest stale Qt5 code ?

The latest stale ;) Qt5 code should be what you get when you check out 
the master branch of qt5.git, as it and its submodules are only updated 
when the all the autotests pass (which in _theory_ should mean stable).

 Is there some any tag for that ?

No, not until we have a Beta release. There's an alpha tag, but that's 
per definition not a stable release, and it's really old by now.

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

Re: [Development] Latest stable Qt5 code

We are pushing as hard as we can to make it happen asap, but with all 
the vacations happening in Europe right now I think it will happen in 
early August.

-- 
.marius


On 23/07/2012 08:41, Liu Song.7 (Nokia-MP/Beijing) wrote:
 Thanks, but about when will we have a beta release ?

 -Original Message-
 From: Storm-Olsen Marius (Nokia-MP/Austin)
 Sent: Monday, July 23, 2012 9:40 PM
 To: Liu Song.7 (Nokia-MP/Beijing)
 Cc: development@qt-project.org
 Subject: Re: [Development] Latest stable Qt5 code
 Importance: High

 On 23/07/2012 08:34, ext song.7@nokia.com wrote:
 Hi,

 Can somebody point out how to get the latest stale Qt5 code ?

 The latest stale ;) Qt5 code should be what you get when you check out the 
 master branch of qt5.git, as it and its submodules are only updated when the 
 all the autotests pass (which in _theory_ should mean stable).

 Is there some any tag for that ?

 No, not until we have a Beta release. There's an alpha tag, but that's per 
 definition not a stable release, and it's really old by now.

 --
 .marius

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

Re: [Development] Use static qt libraries

On 23/07/2012 08:56, ext song.7@nokia.com wrote:
 Hi,

 To use the static qt libraries, now I can build out all the libQtCore.a
 , libQtGui.a , libQtWidgets.a etc with option -static.

 Also I can create a new shared object libQtMaster.so which is composed
 of all of above static objects (libQtXXX.a),

This would be all wrong.

The only reason for compiling several modules into one would be (of the 
top of my head) to
 1) Get cross-module optimizations (which indicate also 
cross-compile-unit optimizations, so you'll need a bin tools chain which 
can do that) to a) reduce code size, and b) improve performance.
 2) Reduce number of exported symbols.
 3) Faster shared library load time.

To do this you would have to compile each of the modules as normal 
(shared library), and then have a step which links all of the object 
files into one shared library, maybe called just qt5.so

Configuring as static only to gather them into a shared lib is wrong.


 then I want my Qt application be dynamic linked with this libQtMain.so by:

 QT += master

 so how to create this new QT module “master” that can be used from the
 .pro files ?

This is also wrong, since this would require everyone to change the way 
they create Qt projects. In this case you would want
 QT += core gui network
to do the same thing, simply to add linking to this new qt5.so library.

That way you can keep projects working both with and without this 
magical single library without further adjustments.


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

Re: [Development] Use static qt libraries

No, you will need to link it all at once, since an .so is considered a final 
product.

You might be able to mess around with a qt5-massive-library.pro, which 
include()s all the module .pro files you want in the final library.
It's unknown how much tweaking you will need to achieve this final all-in-one 
module though. This is uncharted territory.

(Btw, with GCC you _can_ do
gcc -shared qt5.so -Wl,--whole-archive lib1.a lib2.a lib3.a 
-Wl,--no-whole-archive
but I have no idea if the end result would be usable in Qt's case. I doubt it.)

-- 
.marius


 -Original Message-
 From: Liu Song.7 (Nokia-MP/Beijing)
 Sent: Monday, July 23, 2012 9:16 AM
 To: Storm-Olsen Marius (Nokia-MP/Austin)
 Cc: development@qt-project.org
 Subject: RE: [Development] Use static qt libraries
 
 Thanks for help. Is there any tool to link all of the separate shared 
 libraries
 into one single shared library (libqt5.so) ?
 
 Thanks,
 Song
 
 -Original Message-
 From: Storm-Olsen Marius (Nokia-MP/Austin)
 Sent: Monday, July 23, 2012 10:12 PM
 To: Liu Song.7 (Nokia-MP/Beijing)
 Cc: development@qt-project.org
 Subject: Re: [Development] Use static qt libraries
 Importance: High
 
 On 23/07/2012 08:56, ext song.7@nokia.com wrote:
  Hi,
 
  To use the static qt libraries, now I can build out all the
  libQtCore.a , libQtGui.a , libQtWidgets.a etc with option -static.
 
  Also I can create a new shared object libQtMaster.so which is composed
  of all of above static objects (libQtXXX.a),
 
 This would be all wrong.
 
 The only reason for compiling several modules into one would be (of the top
 of my head) to
  1) Get cross-module optimizations (which indicate also cross-compile-unit
 optimizations, so you'll need a bin tools chain which can do that) to a) 
 reduce
 code size, and b) improve performance.
  2) Reduce number of exported symbols.
  3) Faster shared library load time.
 
 To do this you would have to compile each of the modules as normal (shared
 library), and then have a step which links all of the object files into one
 shared library, maybe called just qt5.so
 
 Configuring as static only to gather them into a shared lib is wrong.
 
 
  then I want my Qt application be dynamic linked with this libQtMain.so by:
 
  QT += master
 
  so how to create this new QT module master that can be used from the
  .pro files ?
 
 This is also wrong, since this would require everyone to change the way they
 create Qt projects. In this case you would want
  QT += core gui network
 to do the same thing, simply to add linking to this new qt5.so library.
 
 That way you can keep projects working both with and without this magical
 single library without further adjustments.
 
 
 --
 .marius
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Use static qt libraries

No, I mean you should create a new .pro file which includes all the module libs 
you want to include, and then later in that file do the tweaks needed to 
generate the required result. Just compiling this new project will be enough to 
produce the end result.

So, a new qt5-massive-library.pro which does something like:
include(../corelib/corelib.pro)
include(../gui/gui.pro)
include(../network/network.pro)
include(../opengl/opengl.pro)

TARGET = Qt5
MODULE = qt5-massive-library
...etc...

-- 
.marius


 -Original Message-
 From: Liu Song.7 (Nokia-MP/Beijing)
 Sent: Monday, July 23, 2012 9:39 AM
 To: Storm-Olsen Marius (Nokia-MP/Austin)
 Cc: development@qt-project.org
 Subject: RE: [Development] Use static qt libraries
 
 OK, based on my current understanding, do you mean that:
 I still need to build all of the current qt modules as static objects, which 
 can
 be done by OPTS += -static or by other way ?
 
 Thanks,
 Song
 
 -Original Message-
 From: Storm-Olsen Marius (Nokia-MP/Austin)
 Sent: Monday, July 23, 2012 10:35 PM
 To: Liu Song.7 (Nokia-MP/Beijing)
 Cc: development@qt-project.org
 Subject: RE: [Development] Use static qt libraries
 Importance: High
 
 No, you will need to link it all at once, since an .so is considered a final
 product.
 
 You might be able to mess around with a qt5-massive-library.pro, which
 include()s all the module .pro files you want in the final library.
 It's unknown how much tweaking you will need to achieve this final all-in-one
 module though. This is uncharted territory.
 
 (Btw, with GCC you _can_ do
 gcc -shared qt5.so -Wl,--whole-archive lib1.a lib2.a lib3.a 
 -Wl,--no-whole-
 archive but I have no idea if the end result would be usable in Qt's case. I
 doubt it.)
 
 --
 .marius
 
 
  -Original Message-
  From: Liu Song.7 (Nokia-MP/Beijing)
  Sent: Monday, July 23, 2012 9:16 AM
  To: Storm-Olsen Marius (Nokia-MP/Austin)
  Cc: development@qt-project.org
  Subject: RE: [Development] Use static qt libraries
 
  Thanks for help. Is there any tool to link all of the separate shared 
  libraries
  into one single shared library (libqt5.so) ?
 
  Thanks,
  Song
 
  -Original Message-
  From: Storm-Olsen Marius (Nokia-MP/Austin)
  Sent: Monday, July 23, 2012 10:12 PM
  To: Liu Song.7 (Nokia-MP/Beijing)
  Cc: development@qt-project.org
  Subject: Re: [Development] Use static qt libraries
  Importance: High
 
  On 23/07/2012 08:56, ext song.7@nokia.com wrote:
   Hi,
  
   To use the static qt libraries, now I can build out all the
   libQtCore.a , libQtGui.a , libQtWidgets.a etc with option -static.
  
   Also I can create a new shared object libQtMaster.so which is composed
   of all of above static objects (libQtXXX.a),
 
  This would be all wrong.
 
  The only reason for compiling several modules into one would be (of the
 top
  of my head) to
   1) Get cross-module optimizations (which indicate also cross-compile-
 unit
  optimizations, so you'll need a bin tools chain which can do that) to a)
 reduce
  code size, and b) improve performance.
   2) Reduce number of exported symbols.
   3) Faster shared library load time.
 
  To do this you would have to compile each of the modules as normal
 (shared
  library), and then have a step which links all of the object files into one
  shared library, maybe called just qt5.so
 
  Configuring as static only to gather them into a shared lib is wrong.
 
 
   then I want my Qt application be dynamic linked with this libQtMain.so
 by:
  
   QT += master
  
   so how to create this new QT module master that can be used from the
   .pro files ?
 
  This is also wrong, since this would require everyone to change the way
 they
  create Qt projects. In this case you would want
   QT += core gui network
  to do the same thing, simply to add linking to this new qt5.so library.
 
  That way you can keep projects working both with and without this magical
  single library without further adjustments.
 
 
  --
  .marius
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] 回复： Re: Use static qt libraries

I have my doubts about how much you'll really gain from that.

This would only give you a large benefit if most applications requires all the 
libs you bundle together, and that you significantly reduce the total amount of 
symbols exported by the final shared library. I guess worth a quick try, but I 
wouldn't spend too much time on it. Most OSes will have pretty good caching of 
these libs anyways, and time is probably better spent optimizing the 
initialization of the applications rather than focusing on the time it takes to 
resolve library symbols.
 
M2c.

-- 
.marius


 -Original Message-
 From: development-bounces+marius.storm-olsen=nokia.com@qt-
 project.org [mailto:development-bounces+marius.storm-
 olsen=nokia@qt-project.org] On Behalf Of Liu Song.7 (Nokia-
 MP/Beijing)
 Sent: Monday, July 23, 2012 6:06 PM
 To: development@qt-project.org; thiago.macie...@intel.com
 Subject: [Development] 回复： Re: Use static qt libraries
 
 To reduce the loading time.
 -原信息-
 发件人: ext Thiago Macieira
 发送：  2012/07/24, 02:09
 收件人: development@qt-project.org
 主题： Re: [Development] Use static qt libraries
 
 
 On segunda-feira, 23 de julho de 2012 14.39.16, song.7@nokia.com wrote:
  OK, based on my current understanding, do you mean that:
  I still need to build all of the current qt modules as static objects, which
  can be done by OPTS += -static or by other way ?
 
 No.
 
 What you need to do is figure out what you want to do in the first place.
 What
 is your objective? What are you trying to accomplish? And why is the current
 solution not enough?
 
 Don't tell us how you planned on implementing it. Forget libqt5.so.
 --
 Thiago Macieira - thiago.macieira (AT) intel.com
   Software Architect - Intel Open Source Technology Center
  Intel Sweden AB - Registration Number: 556189-6027
  Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Abandoning the container changes

2012-07-18 Thread marius.storm-olsen

On 18/07/2012 02:06, ext joao.abeca...@nokia.com wrote:
 Hey,

 I would rather we don't *rush* the container changes in, but get them
 up to snuff in a separate branch, instead. I would also like to
 challenge the assumptions I've seen repeated that probability for
 breakage is low and autotest coverage is high. It isn't and it isn't.
 It is very easy to break less-often used features and corner cases
 that will not get caught by autotests. I don't think this is
 acceptable for fundamentals like QVector and friends.

 I think it would be feasible to do a binary-only break somewhere
 around the 5.2 timeframe (say, ~12 months) where we address this.
 Technically, this would be Qt 6, but user porting effort would be
 reduced to a recompile. The value of having a long lived (5 years?)
 binary compatible 5.x series is (IMO) low as there are quite often
 other reasons to recompile the stack.

If there's reasons to break BC, there's reasons for a new Major version. 
We don't circumvent the policies because is looks silly to have a new 
major version in such a short time after 5.0.

However, I can imagine there's other significant changes we'll notice 
after 5.0 which will warrant other BC-incompatible changes, and maybe 
we'd want to refactor out more of the modules from QtBase into their own 
repos? As such, we might have several valid reason for having another 
major, to quickly correct learned lessons from Qt 5, and to ensure Qt 
6 can live on for a very long time.

Still, if Qt 6 would be on the road-map then, we should aim for making 
transitioning as simple as a pure recompile. We don't _have_ to do 
significant restructuring just because we're going a new major. Simply 
saying that we need to do it because of BC issues is fine. If major 
speed improvements is a result of that, I'm sure many people would 
understand.

Anyways, several people and Thiago himself has said that now is not the 
time for such a change to our tools classes, and we should listen to 
that. I don't think you want to add them both and let the end user 
decide, as it will create a maintenance nightmare, and you will have 
applications which both use Qt 5 but are incompatible with each others 
run-time. (Some apps will demand that you use the optimized Qt5 for 
plug-ins etc.)

-- 
.marius

 Cheers,
 João

 
 From: development-bounces+joao.abecasis=nokia@qt-project.org 
 [development-bounces+joao.abecasis=nokia@qt-project.org] on behalf of ext 
 André Pönitz [andre.poen...@mathematik.tu-chemnitz.de]
 Sent: 17 July 2012 23:59
 To: development@qt-project.org
 Subject: Re: [Development] Abandoning the container changes

 On Tue, Jul 17, 2012 at 05:19:23PM +0200, Oswald Buddenhagen wrote:
 On Mon, Jul 16, 2012 at 02:52:32PM -0700, ext Thiago Macieira wrote:
 On segunda-feira, 16 de julho de 2012 21.34.10, André Pönitz
 wrote:
 On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira
 wrote:
 I think that, despite the potential benefits of the changes,
 we should not apply them at this time. There are far too many
 chances for breakage and it's a blatant disrespect for the
 feature freeze.

 I assume this is meant as a verdict, not as (possibly
 temporary) state of thinking.

 Correct. The changes are the right thing to do, just not now.
 We'll have to live with the current containers and their overhead
 until Qt 6.

 That includes the fact that QListQVariant is extremely
 inefficient.

 this is absurd.

 Incidentally, I agree. [Even if I lack the skill to express myself
 so clearly at times ;-}]

 we said A, now we need to say B. or unsay A, which i don't think
 anyone wants.

 i for one don't believe in qt6 anytime soon. it's the do-never release
 qt5 was for years.

 The suggested 4 years are 3 1/2 years too much anyway.

 That's 3 1/2 years more of forcing people to re-invent the wheel when
 it comes to performance-sensitive components in a Qt environment, and
 it's 3 1/2 years on top of the past half decade or so where Qt containers
 fail to deliver on one of the original reasons to have them at all
 (portability, convenience of use, _and_ performance).

 We do have the chance to fix it _now_, and we have a fairly decent
 idea of how the fix looks like. The whole change is essentially
 source compatible, i.e. has a low probability of breaking other
 components, and it is very well covered by autotests. The chances
 to be ready before the rest (Webkit Windows? Mac?) is ready for
 a 5.0 release are good.

 To get back on the constructive side I propose to do any of the
 following, in decreasing order of desirability:

 (A) Have the QString/QByteArray related bits in 5.0.

 (B) Have everything in 5.0.

 (C) Don't do anything for 5.0, but aim for a 6.0 instead for a 5.1
 next.

 (D) Don't do anything for 5.0, but allow 5.1 to be source compatiple
 but binary incompatible.

 (E) Don't do anything for 5.0, and provide a compile-time switch
 for 5.1 to select between current and patched

Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server

2012-07-16 Thread marius.storm-olsen

On 13/07/2012 10:04, ext marius.storm-ol...@nokia.com wrote:
 So, I think we'll go ahead and get a port forward setup.

It has been done.

You can now point your git to
 git clone ssh://username@ssh.qt-project.org:443/qt/qt5
instead, if needed.

-- 
.marius

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

Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server

2012-07-13 Thread marius.storm-olsen

On 13/07/2012 06:42, ext Laszlo Papp wrote:
 There are certain situations out there, when it is currently not so
 simple to contribute to the Qt Project. One typical use case, if
 there is a proxy server without using socks, just plain http. In
 those cases, ssh tunneling does not work either properly. Imagine
 that, the ports 80 and 443 are allowed only.

 What one can do for instance in the KDE project is simpler since
 git.kde.org does listen via ssh on the port 443, so that
 establishment can be used for cloning and pushing to the KDE
 repositories. Unfortunately, this is not the case with the Qt Project
 currently. As far as I have been told, the port 443 is used for the
 Gerrit webinterface. What one could do is to use a gateway server
 listetning on port 443 via ssh. Unfortunately, many people do not
 have such an ability. Furthermore, I do think it is suboptimal, if
 each contributor in this situation should solve the issue in question
 on their own.

 Many people cannot just unfortunately use the port 29418
 recommended. Hence, I am now asking, if it is possible to find a
 solution for people willing to contribute to the Qt Project with
 these conditions. One option is an outside proxy on the port 443, but
 any solution is welcome.

I think we could do the same setup as GitHub, and simply have port 
forwarding from ssh.qt-project.org:443 to 
codereview.qt-project.org:29418. That should enable most people to work 
behind corporate firewalls.

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

Re: [Development] Migrating widgets out of qtbase into their own repo

2012-07-03 Thread marius.storm-olsen

No, there are no plans for that. At least not any immediate plans to my 
knowledge.

-- 
.marius


 -Original Message-
 From: development-bounces+marius.storm-olsen=nokia.com@qt-
 project.org [mailto:development-bounces+marius.storm-
 olsen=nokia@qt-project.org] On Behalf Of ext Donald Carr
 Sent: Tuesday, July 03, 2012 5:32 PM
 To: development@qt-project.org
 Subject: [Development] Migrating widgets out of qtbase into their own repo
 
 Good morning,
 
 I was under the impression that QWidget was due to migrate out of
 qtbase into their own git submodule prior to the Qt 5 launch. Is this
 the case, and if so who, if anyone, is working on it right now?
 
 Yours sincerely,
 Donald
 
 --
 ---
  °v°  Donald Carr
 /(_)\ Vaguely Professional Penguin lover
  ^ ^
 
 Cave canem, te necet lingendo
 Chasing my own tail; hate to see me leave, love to watch me go
 Feeding the trolls is only marginally more rewarding than feeding the
 pigeons, and carries the same consequences
 ___
 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] Policy for creating new mailing lists

2012-07-02 Thread marius.storm-olsen

On 30/06/2012 09:53, ext Laszlo Papp wrote:
 What is the policy for creating mailing lists? I have just realized
 this mailing list after a little bit of talk over here at aKademy:
 http://lists.qt-project.org/mailman/listinfo/qt-components

 I had the impression previously, those requests should be going
 through the approval on this mailing list, like it happened back
 then with the raspberry mailing list. I would really appreciate
 either that way or an announcement. Not because of making those
 people's life more difficult, but getting informed to not lose
 important things ongoing. Essentially similarly like with other new
 introduces, like playground project and so forth.

I was actually unaware that this mailing list had popped up. It was 
probably decided at one of the sessions at the QtCS that this list 
should be created, and then it was created silently. That's not good, it 
should have been discussed and presented at the development mailing 
list, like you suggested, as not everybody could be present at the QtCS, 
or even at that particular session.

So yes, I agree with you, new mailing lists needs to be announced.

Can the one responsible for this list please provide the development 
list a short description of the new ML and why it was needed?

Thanks!

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

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

2012-07-02 Thread marius.storm-olsen

On 01/07/2012 13:26, ext k blammo wrote:
 On 01/07/2012 15:44, Thiago Macieira wrote:

 The perl that comes with msysgit doesn't work with our syncqt script.

 Is this a regression with respect to
 https://codereview.qt-project.org/#change,27136
 or is it a different issue?

Seems likely.
Most of us don't detect this issue, since we use ActiveState Perl 
instead of the MSysGit perl.

The MSysGit perl is not intended to be a complete perl installation, but 
just enough to drive the scripts that are part of the Git package. So, 
one should not rely on it in a production system.

Just install ActiveState (or any other of your favorite), and ensure 
it's first in the path. Or just make sure you use the git's cmd/ path 
instead of bin/ path in your environment, and they won't conflict.

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

Re: [Development] Nominating Ritt Konstantin as approver

2012-07-02 Thread marius.storm-olsen

On 02/07/2012 16:45, ext Girish Ramakrishnan wrote:
 On Tue, Jun 26, 2012 at 10:54 PM, Giuseppe D'Angelo
 dange...@gmail.com wrote:
 On 26 June 2012 18:21, Konstantin Ritt ritt...@gmail.com wrote:
 Any progress?)

 Konstantin

 Only another couple of days :-)

 You have been nominated on 7 of June, so you must wait for the 28
 :)

 The wait is over :) Can someone give him the staging button?

 Congrats Ritt!

It has been done.
Congratulations Ritt!

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

Re: [Development] QtCS: OpenGL session notes

2012-06-27 Thread marius.storm-olsen

On 25/06/2012 13:44, ext Girish Ramakrishnan wrote:
 Future plans
 - Desktop OpenGL 3+ support, ES 3 support

We've just added ANGLE support in Qt (-angle dir), to enable DirectX 
usage instead of OpenGL ES 2 on Windows, due to many buggy drivers.

How will this effort affect this usage?

Will we actively contribute to the ANGLE project, to ensure it's usable 
when we extend our use of OpenGL?

It would be bad for end users if they rely on ANGLE and we change the 
OpenGL backend to use functionality not covered by ANGLE in the next 
version, making migration to the next version of Qt impossible.

What is the timeline for OpenGL 3+ support, and when is OpenGL ES 3 
scheduled for release?

-- 
.marius


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

Re: [Development] QtCS: OpenGL session notes

2012-06-27 Thread marius.storm-olsen

On 27/06/2012 12:14, ext Sean Harmer wrote:
 On Wednesday 27 June 2012 16:30:50 marius.storm-ol...@nokia.com
 wrote:
 On 25/06/2012 13:44, ext Girish Ramakrishnan wrote:
 Future plans - Desktop OpenGL 3+ support, ES 3 support

 We've just added ANGLE support in Qt (-angle dir), to enable
 DirectX usage instead of OpenGL ES 2 on Windows, due to many buggy
 drivers.

 You mean for embedded flavours of Windows right? OpenGL 3+ works fine
 on desktop windows - although getting hold of a Core Profile context
 on Windows via Qt was broken last time I tried it (but that was some
 months ago).

No, I don't mean for embedded alone. Desktop OpenGL drivers are also of 
quite varying quality, and the DirectX drivers are usually better.

Not to mention that with Windows 8 you might have a hard time getting 
access to the OpenGL APIs, depending on which system you are on and how 
integrated you want to be.

No WGL/EGL support for Metro applications afaik, see 
http://msdn.microsoft.com/en-us/library/windows/apps/br205756.aspx and
http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/c77de65a-1fbb-491f-9f6b-0c4a7b452ec2
 
and
http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/a861db02-dce8-4f61-9969-b8a7a7cd55c7

(Yes, non-Metro apps can use OpenGL just fine, although reports have 
come back that currently the OpenGL drivers are lagging behind the 
DirectX ones.)

No OpenGL for Windows 8 RT (ARM) version either, which should also be a 
target.


 How will this effort affect this usage?

 The same way it will affect those platforms that only support OpenGL
 ES2 I guess - they just won't use the new features/capabilities.

Ok, so ifdef out the extensions completely when we compile with the 
ANGLE library?


 Will we actively contribute to the ANGLE project, to ensure it's
 usable when we extend our use of OpenGL?

 It would be bad for end users if they rely on ANGLE and we change
 the OpenGL backend to use functionality not covered by ANGLE in the
 next version, making migration to the next version of Qt
 impossible.

 What is the timeline for OpenGL 3+ support, and when is OpenGL ES
 3 scheduled for release?

 It is possible to use OpenGL 3 (or even 4) on the desktop right now
 just that Qt does not yet wrap the new features.

 OpenGL ES 3 is scheduled for release soon which translates to
 probably sometime this year. It is supposed to reduce the delta
 between desktop OpenGL and OpenGL ES.

Good to know, thanks.


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

Re: [Development] Notes from the QWidget session

2012-06-27 Thread marius.storm-olsen

On 27/06/2012 12:55, ext Thorbjørn Martsum wrote:
 Btw. Is somebody looking into the regressions in QGraphicsView?

Nope, QGV is currently lacking a maintainer.
Anyone with qualifications and feeling the urge? :)

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

Re: [Development] Code of conduct.

2012-06-22 Thread marius.storm-olsen

Right. I must admit i can't see which specific incident which triggered this 
thread now, i believe the community has behaved good lately. But i agree that a 
general code of conduct for all our forums (mails, IRC, reviews, bugreports, 
etc)

So, let's grab one of the existing CoC for KDE, Linux.Conf and/or others, take 
the best of them and make it our own.

Anyone feel like taking the lead on that, and drive the discussions until a 
conclusion?

--
Sent from my Nokia N9

On 6/22/12 1:16 ext Thiago Macieira wrote:
On sexta-feira, 22 de junho de 2012 08.47.34, Rohan McGovern wrote:
 Having a code of conduct may anyway be a good thing, but I
 don't think it would have made a difference to the behavior from
 non-contributors I think you're referring to in your mail.
 No matter what you do, jerks will be jerks

That is true, but like you said it's a good thing. It's something we can point 
to when things start to get heated, even to non-contributors. And if we do 
need to take action, like moderating or banning someone from a mailing list, 
we can point to it and say it was not an arbitrary decision.

I'd like to think that common sense should be enough to guide our conduct, but 
experience shows that common sense is not that common. And as the community 
grows, we might get more and more people with different cultures, different 
viewpoints and who might inadvertently step on other people's toes.

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

[Development] Release Testing Form: http://testresults.qt-project.org/forms/release-testing/

2012-06-06 Thread marius.storm-olsen

Hi,

I have created an online form
(http://testresults.qt-project.org/forms/release-testing/) based on the
list I sent previously
(http://lists.qt-project.org/pipermail/releasing/2012-May/000275.html).

The form will send an email with the form data directly to the
releas...@qt-project.org mailing list, making reporting unified, and
ensuring that everyone looks at the same things on all platforms and
consistently from package to package.

Of course, you are allowed to look for more issues than those noted, just
fill in issues in the comment fields!

From now on, when testing packages, please use this form since it makes it
easier for everyone to read the reports, and quickly spot problem areas.

The form is completely open, and in Gerrit (git clone
ssh://codereview.qt-project.org:29418/qtqa/release-testing.git).
Feel free to improve, fix and add suggestions to other items to look for.

Thanks!

-- 
.marius

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

Re: [Development] FW: Alpha 2 this week or skip it

2012-06-02 Thread marius.storm-olsen

It's not wrong and it doesn't really matter. Once MSVC starts to differ from 
the VC version, in the sense that they are not connected, then we can discuss 
changing them.

For now, let's not make Qt 5 more incompatible with Qt 4. It's not worth it, 
just to be pedantic. :-)

--
Sent from my Nokia N9

On 6/2/12 2:14 ext Loaden wrote:
If it realy wrong, we should rename win32-msvc2010 - win32-msvc10, msvc2008 - 
win32-msvc9 ...


2012/6/1 Thiago Macieira thiago.macie...@intel.com

Right. We've been doing it wrong all along, then: our mkspecs say msvc which
is the compiler, but give the year as the complement.

Maybe we should then start correcting this by keeping msvc11.




-- 

Please don't ask where I come from, It's a shame!
Best Regards
Yuchen
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] On QML, ownership, QObject-trees and QSharedPointer

2012-05-23 Thread marius.storm-olsen

W00t should have a backlog which covers the conversation, if it was done on our 
public channels :-)

--
Sent from my Nokia N9On 5/23/12 13:44 ext Thiago Macieira wrote:
On quarta-feira, 23 de maio de 2012 14.16.12, Alberto Mardegan wrote:
 On 05/23/2012 01:25 PM, Rene Jensen wrote:
  Question: How can we expose objects governed by QSharedPointer to QML
  safely? I can guarantee the lifecycle beyond the life of my
  QDeclarativeEngine.
 
 As neither of us knows exactly how QML handles QSharedPointer (my guess
 is that it simply doesn't; QSharedPointer is a template class which can
 be used with many other types than QObject, so I don't think that
 exposing it in QML is trivial), I would simply recommend you not to use it.
 I actually mentioned QSharedPointer in a recent blog post of mine [0],
 which you might find interesting especially if your use of
 QSharedPointer is suggested by your previous experience with other toolkits.
 If you really think that QSharedPointer is absolutely necessary in your
 case (I still doubt), then just expose its QObject data to QML, since you
 also claim that you can make sure its lifetime will survive the engine.

Just a tidbit...

I've long wanted to make QSharedPointer on QObject-derivatives participate in 
the whole-tree ownership, somehow. I introduced QSharedPointer in 4.4 and I 
did some work in 4.5 to make that work.

My original solution was to have a parent only deref its children's shared 
pointer counter, deleting it only if it became zero. That means that if you 
had a QSharedPointer to an object in the middle of the hierarchy, that object 
would be orphaned instead of deleted when the parent died. The converse was 
that when the last QSharedPointer reference to a QObject went away, the object 
might survive if it still had a parent.

There were a few problems with that solution. I can remember now:

1) it didn't play very well with QWidgets after the Alien project. QWidgets 
often reference the top-level window, which is the ultimate parent widget (the 
one with no parents). Orphaning a QWidget from QWidget's destructor was a 
recipe for disaster, since the original TLW data might have been gone already.

2) it didn't play very well with QObject siblings talking to each other during 
destruction or, worse, deleting each other. This is a huge pain and source of 
complexity during QObject infanticide.

3) what happens if you had a QSharedPointerQObject with a parent, dropped 
the last QSharedPointer reference (it survives because of the parent) and 
later orphaned that object via setParent(0)? Should it be deleted?

The worst of it all is that I remember having a discussion during 4.6 times 
with someone on IRC and coming up with a brilliant and simple solution. 
Something like don't orphan, but keep a refcount on the entire tree. The 
problem is that I didn't write it down, because I thought it was so simple and 
evident that I'd be able to remember or work it out again.

I haven't been able to. Fermat would be proud.

Anyway, that reminds me I have some pending QSharedPointer work to do. I'll 
get on with it.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build failed use MinGW-TDM or MinGW-w64 on Windows

Based on the output below, I think there might be a path invariance between 
prefix and QTDIR, if you have that set.

So, make sure that $$QTDIR is the same as $$[QT_HOST_PREFIX]. If you have QTDIR 
set, then qmake will pass '-qtdir path' to syncqt on invocation. Check that 
against what 'qmake –query | grep HOST_PREFIX' reports. They have to match for 
-developer–build, where installation path == build path, if they don't that's 
likely your problem. (yes, this is all fixed in Ossi's build system branch)

--
.marius

On 5/15/12 10:21 AM, ext Loaden loa...@gmail.commailto:loa...@gmail.com 
wrote:

Full configure/build log, please see attachments.

2012/5/15 Loaden loa...@gmail.commailto:loa...@gmail.com
Hi, All!
I am just try to build Qt5 under Windows, use MinGW-TDM or MinGW-w64 (32bit), 
but both failed with the same log.
I don't know how to fix the problem.
Any comments?
cd svg\  mingw32-make -f Makefile
mingw32-make[3]: Entering directory 
`D:/qpSOFT/Projects/BuildQt5-TDM/qtsvg/src/svg'
mingw32-make -f Makefile.Debug all
mingw32-make[4]: Entering directory 
`D:/qpSOFT/Projects/BuildQt5-TDM/qtsvg/src/svg'
g++ -c -fno-keep-inline-dllexport -g -Wall -frtti -fexceptions -mthreads 
-DQT_SHARED -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_BUILD_SVG_LIB 
-DQT_NO_USING_NAMESPACE -DQT_MAKEDLL -DQT_NO_CAST_TO_ASCII 
-DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER 
-DQT_DEPRECATED_WARNINGS -D_USE_MATH_DEFINES -DQT_DLL -DQT_HAVE_SSE2 
-Id:\qpSOFT\Projects\BuildQt5-TDM\qtbase\include 
-I..\..\include\QtSvg\5.0.0 -I..\..\include\QtSvg\5.0.0\QtSvg 
-I..\..\include -I..\..\include\QtSvg -I..\..\include -Itmp 
-Id:\qpSOFT\Projects\Qt5\qtbase\src\3rdparty\harfbuzz\src 
-Id:\qpSOFT\Projects\Qt5\qtsvg\src\3rdparty\zlib 
-Id:\qpSOFT\Projects\Qt5\qtbase\mkspecs\win32-g++ -Idebug 
-Id:\qpSOFT\Projects\Qt5\qtsvg\src\svg -I. 
-Id:\qpSOFT\Projects\BuildQt5-TDM\qtbase\mkspecs\default -o 
debug\qsvggraphics.o d:\qpSOFT\Projects\Qt5\qtsvg\src\svg\qsvggraphics.cpp
In file included from d:\qpSOFT\Projects\Qt5\qtsvg\src\svg\qsvgnode_p.h:56:0,
 from d:\qpSOFT\Projects\Qt5\qtsvg\src\svg\qsvggraphics_p.h:56,
 from d:\qpSOFT\Projects\Qt5\qtsvg\src\svg\qsvggraphics.cpp:42:
d:\qpSOFT\Projects\Qt5\qtsvg\src\svg\qsvgstyle_p.h:65:20: fatal error: 
qdebug.h: No such file or directory
compilation terminated.
mingw32-make[4]: *** [debug/qsvggraphics.o] Error 1
mingw32-make[4]: Leaving directory 
`D:/qpSOFT/Projects/BuildQt5-TDM/qtsvg/src/svg'
mingw32-make[3]: *** [debug-all] Error 2
mingw32-make[3]: Leaving directory 
`D:/qpSOFT/Projects/BuildQt5-TDM/qtsvg/src/svg'
mingw32-make[2]: *** [sub-svg-make_default-ordered] Error 2
mingw32-make[2]: Leaving directory `D:/qpSOFT/Projects/BuildQt5-TDM/qtsvg/src'
mingw32-make[1]: *** [module-qtsvg-src-make_default] Error 2
mingw32-make[1]: Leaving directory `D:/qpSOFT/Projects/BuildQt5-TDM/qtsvg'
mingw32-make: *** [module-qtsvg-make_default] Error 2
mingw32-make: *** Waiting for unfinished jobs
Project MESSAGE: Warning: unknown QT module: network
Project MESSAGE: Warning: unknown QT module: core
Project MESSAGE: This project is using private headers and will therefore be 
tied to this specific Qt module build version.
Project MESSAGE: Running this project against other versions of the Qt modules 
may crash at any arbitrary point.
Project MESSAGE: This is not a bug, but a result of using Qt internals. You 
have been warned!
Project MESSAGE: Warning: unknown QT module: network
Project MESSAGE: Warning: unknown QT module: core
Project MESSAGE: Warning: unknown QT module: network
Project MESSAGE: Warning: unknown QT module: core
cd xmlpatterns\  mingw32-make -f Makefile
mingw32-make[3]: Entering directory 
`D:/qpSOFT/Projects/BuildQt5-TDM/qtxmlpatterns/src/xmlpatterns'
mingw32-make -f Makefile.Debug all
mingw32-make[4]: Entering directory 
`D:/qpSOFT/Projects/BuildQt5-TDM/qtxmlpatterns/src/xmlpatterns'
g++ -c -fno-keep-inline-dllexport -g -Wall -fexceptions -mthreads -frtti 
-DQT_SHARED -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_BUILD_XMLPATTERNS_LIB 
-DQT_NO_USING_NAMESPACE -DQT_MAKEDLL -DQT_NO_CAST_TO_ASCII 
-DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER 
-DQT_DEPRECATED_WARNINGS -D_USE_MATH_DEFINES -DQT_DLL -DQT_HAVE_SSE2 
-Id:\qpSOFT\Projects\BuildQt5-TDM\qtbase\include 
-I..\..\include\QtXmlPatterns\5.0.0 
-I..\..\include\QtXmlPatterns\5.0.0\QtXmlPatterns -I..\..\include 
-I..\..\include\QtXmlPatterns -I..\..\include -Itmp 
-Id:\qpSOFT\Projects\Qt5\qtxmlpatterns\src\xmlpatterns\acceltree 
-Id:\qpSOFT\Projects\Qt5\qtxmlpatterns\src\xmlpatterns\data 
-Id:\qpSOFT\Projects\Qt5\qtxmlpatterns\src\xmlpatterns\api 
-Id:\qpSOFT\Projects\Qt5\qtxmlpatterns\src\xmlpatterns\environment 
-Id:\qpSOFT\Projects\Qt5\qtxmlpatterns\src\xmlpatterns\expr 
-Id:\qpSOFT\Projects\Qt5\qtxmlpatterns\src\xmlpatterns\functions 
-Id:\qpSOFT\Projects\Qt5\qtxmlpatterns\src\xmlpatterns\iterators 
-Id:\qpSOFT\Projects\Qt5\qtxmlpatterns\src\xmlpatterns\janitors

Re: [Development] The place of QML

Sounds like marketing?

It might be a 'constant' in the grand scheme of big-O notations. However,
if the result is that you can only get 24 fps on low-end HW with large
power footprint vs. 60 fps with HW acceleration, lower power footprint and
leaving the main CPU to do more important tasks, what would you call the
former? That's right, outdated technology. Scene graph is very much based
on what todays graphics cards are optimized for, while QPainter.. well,
it's not. We have gone as far as we could with QPainter, and needed
something new to survive the next 5-10 years. It's not about marketing, I
assure you.

-- 
.marius


On 5/18/12 7:36 AM, ext Иван Комиссаров abba...@gmail.com wrote:

Btw, you're saying that painter technology is outdated? What speedup
provides QML scene graph? According to this
http://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/ article,
speedup is 2.5 times. As for me, it's just a constant optimization, it is
not reduces complexity very much, as for me.
If you say you reduced speed 10 times or 100 - it's the other issue. But
saying that painter is outdated just because it 3 times slower than new
qml... sounds like a marketing.
___
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 place of QML

On 5/18/12 8:22 AM, ext Uwe Rathmann uwe.rathm...@tigertal.de wrote:
I would be careful with terms like outdated. In the end the desktop is
the concept of the 90s ( widget are much older ) and the current
desktops are the part that doesn't work on smartphones alike devices.
But are keyboard and mouse outdated - only because smartphones and
tablet devices don't have one - or why should a scene graph based
application be more modern, when it runs inside of a Xfce/X11 desktop ?

Most desktops (Windows w/DWM, OSX w/Quartz Compositor, Linux
w/Compiz,Kwin) use compositing window managers these days, so running on
HW accelerated graphics cards using things like OpenGL and the like to
off-load as much as possible to the GPU, and enable very advanced effects,
while at the same time freeing up the main CPU to do other things than
creating a drop-shadow for a window pane etc.


 What speedup provides QML scene graph? According to this
http://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/ article,
speedup is 2.5 times. As for me, it's just a constant optimization, it
is not reduces complexity very much, as for me.

With raster QPainter::drawPolygon is significantly faster than
QPolygonF::drawPolygonF. QPolygon::drawPolygon on Qt3/X11 is only a thin
wrapper around X11 methods - something you can't beat performancewise.

Often it's hard to beat the performance of the main CPU(s for most people
these days) filling in a polygon directly, rather than handing it off to a
GPU. However, that's just a very very very tiny piece of the whole
picture. There are so many more collaborating parts of a whole application
which you are simply ignoring here.

But by far the best performance you will have when you can reduce the
number of points before drawPolygon on is called.

Even more performance you'd get by instead of flooding your main CPU with
polygon fills etc, you leave that up to the GPU and let the main CPU
update your business logic, think about the next frame in the animation,
etc; especially if that polygon you just filled is not even going to be
displayed in the scene because you paint something over it with the next
item needed in the same frame. Scene graph is designed to avoid all this
and give you the full HW accelerated benefits.

Just look at what can be done on the Raspberry Pi with scene graph +
wayland, and tell me you can do the same with QPainter + X11 through the
Pi's main CPU!
http://www.youtube.com/watch?v=HItv4HX5r3k - Qt 5 and Wayland on the
Raspberry Pi

-- 
.marius


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

Re: [Development] qtphonon's status.

On 5/18/12 10:14 AM, ext Thiago Macieira thi...@kde.org wrote:

On sexta-feira, 18 de maio de 2012 05.54.10, marius.storm-ol...@nokia.com
wrote:
 This probably means we should keep the old repo there for backwards
 compatibility, and with documentation stating that the module is old and
 out-of-date, and where and how they can get a more recent version.

I disagree. At this point, we don't know what the Phonon developers want
to do 
with their API in Qt5, whether they want to keep API compatibility or
not. The 
decision to do that for Qt was our own and does not necessarily imply the
same 
for Phonon.

I'd love them to, but if they have different plans and little manpower,
we 
can't force them to keep the API.

Until the Phonon maintainers speak up and let us know what their plans
for Qt 
5 are, we should consider our qtphonon.git module a disservice to
everyone. If 
none of them speak up, I recommend removing the module from the build
process.

We did promise a minimal migration path from Qt 4 to Qt 5, and removing
the phonon module from qt5.git, with no easy way of compiling up the
current upstream phonon with Qt 5 goes against this promise. That's why I
think we should keep it, until upstream has given a clear message of how
to proceed for Qt 5 users of phonon. (1. What their direction is, 2.
Migration path for Qt 4 users, 3. Build instructions for Qt 5 users on all
T1 platforms, etc)

Until then, at least Qt users can use phonon as is, just like they do in
Qt 4.

-- 
.marius

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

Re: [Development] Build failed use MinGW-TDM or MinGW-w64 on Windows

Just try to do
%QTSOURCE%\configure -opensource -prefix 
D:/qpSOFT/Projects/BuildQt5-x86-tdm/qtbase -confirm-license -platform win32-g++ 
-debug-and-release -fast -nomake examples config.log 21
Instead, and see if that helps.

--
.marius


On 5/18/12 11:37 AM, ext Loaden loa...@gmail.commailto:loa...@gmail.com 
wrote:

The configure command on Windows:
%QTSOURCE%\configure -opensource -prefix %CD%\qtbase -confirm-license -platform 
win32-g++ -debug-and-release -fast -nomake examples config.log 21

Here is the 'qmake -query' print log:
 D:\qpSOFT\Projects\BuildQt5-x86-tdmqmake -query
QT_INSTALL_PREFIX:D:\qpSOFT\Projects\BuildQt5-x86-tdm\qtbase
QT_HOST_PREFIX:D:\qpSOFT\Projects\BuildQt5-x86-tdm\qtbase
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qtphonon's status.

On 5/18/12 12:02 PM, ext Stephen Kelly 
stephen.ke...@kdab.commailto:stephen.ke...@kdab.com wrote:


On Friday, May 18, 2012 08:41:13 
marius.storm-ol...@nokia.commailto:marius.storm-ol...@nokia.com wrote:

 We did promise a minimal migration path from Qt 4 to Qt 5, and removing

 the phonon module from qt5.git, with no easy way of compiling up the

 current upstream phonon with Qt 5 goes against this promise.



It hasn't received any attention so far though, has it? Maybe phonon can be 
part of that promise in Qt 5.1.

Right, no attention from us and no attention from the phonon developers, at 
least with respect for Qt 5 end-users. So, by it receiving 'attention' from us 
now by simply removing the old fork  from the repo, it would only hurt the 
end-user, making it harder for them to migrate over to Qt 5.


 That's why I

 think we should keep it, until upstream has given a clear message of how

 to proceed for Qt 5 users of phonon. (1. What their direction is, 2.

 Migration path for Qt 4 users, 3. Build instructions for Qt 5 users on all

 T1 platforms, etc)



The only problematic part in your list is (1). In the absence of any other 
plans, I'm sure we'll just end up with a simple port to Qt 5 with no API change.

Which is fine really. What I care about is the end-user, and that they can 
continue as before, with minimal migration needed.




 Until then, at least Qt users can use phonon as is, just like they do in

 Qt 4.



I don't think having two phonons (the old and obsolete copy in Qt and the 
upstream) is a good idea.

No, two phonons is a terrible idea :) However, it's the better of two evils, 
were we currently have no migration path from Qt 4 phonon users to the current 
upstream. Thus, keeping 'compatibility' by keeping the old phonon around is 
better for the end-user IMO. Expert users can still nuke the qt5.git one, and 
compile the upstream.

--

On a different matter, Stephen, can you please adjust your MUA to not force a 
font-family:'Monospace'; font-size:11pt; font-weight:400; font-style:normal; 
style in the body of your emails? Since most MUAs render the HTML part of 
emails (my N9 included), the emails look quite terrible, with large fonts, and 
whitespace on smaller devices. Let my MUA decide on the best fonts to display 
your emails unless you are sending me a colorful email invite :)

Thanks!

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

Re: [Development] qtphonon's status.

2012-05-17 Thread marius.storm-olsen

This probably means we should keep the old repo there for backwards
compatibility, and with documentation stating that the module is old and
out-of-date, and where and how they can get a more recent version.

We shouldn't mix build systems in qt5.git itself. If other add-ons decide
to use cmake as their build system, that's fine; but any module aiming to
be part of qt5.git will need to use the same build system as the rest of
the modules of qt5.git. (This will also be true for whatever build system
we move to at some later point.)

Distros of course should bundle Qt with the latest version from upstream.

-- 
.marius

On 5/17/12 11:50 PM, ext Olivier Goffart oliv...@woboq.com wrote:

On Thursday 17 May 2012 21:42:03 Thiago Macieira wrote:
 On quinta-feira, 17 de maio de 2012 19.03.30, lars.kn...@nokia.com
wrote:
  What's the difference between webkit and phonon in this regard?
  
  Webkit isn't hosted on qt-project neither, so removing it from
qt-project
  is the right choice if it's being developed somewhere else.
 
 The qt5-module.git repository of Qt WebKit is a branch of the webkit
SVN
 that contains the latest version supposed to work with Qt. It's not
exactly
 the same thing.
 
 If the Phonon devs do the same for qtphonon.git, I don't see a problem
in
 keeping the repository around. That's not the current situation.


The phonon upstream repository is itself modularized into several sub-
repositories (core + one per backend)

Also, as I pointed out, the upstream phonon requires cmake for building.
It could theoretically be possible to create the qmake .pro files, but
then 
someone will need to maintain them.
(I personaly think it is fine to have add-ons requiring cmake. But I
don't 
know about qt5.git)

-- 
Olivier

Woboq - Qt services and support - http://woboq.com
___
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] important: upcoming rename of _qpa.h to _p.h

2012-05-10 Thread marius.storm-olsen

It has always supported it. It's just not used that much.

--
Sent from my Nokia N9
On 5/11/12 3:50 ext Girish Ramakrishnan wrote:
AFAIK, Installing with INSTALL_ROOT is known not to work with Qt5's
modular projects.

BTW, does windows even support make install? Has it started supported
it these days?

Girish

On Thu, May 10, 2012 at 5:02 PM, Loaden loa...@gmail.com wrote:
 Not work for nmake install INSTALL_ROOT=..., missed 'qba' headers in
 QtGui.

 progressmanager_win.cpp
 Header QtGui/QPlatformNativeInterface is deprecated. Please include
 qpa/qplatformnativeinterface.h instead.
 ..\..\..\..\Qt5\qtbase\include\QtGui\QPlatformNativeInterface(8) : fatal
 error C1083: Cannot open include file: 'qpa/qplatformnativeinterface.h': No
 such file or directory
 NMAKE : fatal error U1077: 'D:\qpSOFT\DEVx86\bin\cl.EXE' : return code
 '0x2'
 Stop.
 NMAKE : fatal error U1077: 'D:\qpSOFT\DEVx86\bin\nmake.exe' : return code
 '0x2'


 2012/5/9 Girish Ramakrishnan gir...@forwardbias.in

 On Tue, May 8, 2012 at 5:31 PM, Girish Ramakrishnan
 gir...@forwardbias.in wrote:
  On Tuesday, May 8, 2012, Girish Ramakrishnan gir...@forwardbias.in
  wrote:
  Hi,
 
  On Tue, May 8, 2012 at 3:07 AM, Girish Ramakrishnan
  gir...@forwardbias.in wrote:
  The change landed. For some reason, the ci is failing compile in all
  other modules. Works locally with shadow builds but not on CI. I am on
  it.
 
 
  Fix is integrating: https://codereview.qt-project.org/#change,25570.
  Sorry for blocking the CI.
  Girish
 
 
  Ci is unblocked. fixes for wayland, qtmm and declarative have landed.
  https://codereview.qt-project.org/#change,23444 is needed for complete
  source compat.
 

 That's the wrong change :) I meant
 https://codereview.qt-project.org/#change,25654

 Girish

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




 --
 Please don't ask where I come from, It's a shame!
 Best Regards
 Yuchen

___
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] [CI] reverse dependency testing

2012-05-01 Thread marius.storm-olsen

Looks good, but please move the details over to the other wiki.
The Mediawiki installation at wiki.qt-project.org has been deprecated since 
DevNet was moved over and we got www.qt-project.org/wiki.

The content from wiki.qt-project.org is planned to be moved, but we are not 
sure yet when this will happen.

-- 
.marius

 -Original Message-
 From: development-bounces+marius.storm-olsen=nokia.com@qt-
 project.org [mailto:development-bounces+marius.storm-
 olsen=nokia@qt-project.org] On Behalf Of Mcgovern Rohan (Nokia-
 MP/Brisbane)
 Sent: Tuesday, May 01, 2012 1:35 AM
 To: development
 Subject: [Development] [CI] reverse dependency testing
 
 A while back, it was requested that the Qt Project CI should reject
 incoming changes to QtBase if they would cause compile or autotest
 failures in QtDeclarative.
 
 That is now implemented, which should reduce the risk of accidental
 source or behavior incompatible changes in qtbase.
 
 However, if you need to _deliberately_ do some changes in qtbase which
 would break qtdeclarative, it's necessary to do some additional steps.
 These are documented, along with a few other bits of information, on the
 wiki at http://wiki.qt-project.org/CI:_Revdep .
 
 The reverse dependency testing is not yet set to enforcing, so it won't
 block changes.  Assuming no objections, we'll probably set it enforcing
 on this Thursday, 3rd May (if it is passing at that time).
 
 Similar reverse dependency testing can be added for other modules on
 request.
 ___
 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] RFC: Test Reports for source/binary packages

2012-05-01 Thread marius.storm-olsen

Hi,

Back in the days, when we were approaching a new release of Qt, we would use a 
black team http://www.t3y.com/tangledwebs/07/tw0706.html which would be 
responsible for driving the testing of a new package. Their main focus would be 
to test every new package generated, both source and binary packages, and try 
to break them with the most used configuration (every configuration is not 
possible due to the vast number of configurable options, and system 
configurations).

When doing this they would have a common list of issues to look out for, to 
make sure that the reporting had some structure (same report fields for each 
reporter/platform/package) and that they wouldn't skip something for one 
package, etc. The list contained things like:

  *   General:
 *   Report date
 *   Testers name
 *   Package name
 *   Package type
 *   Build date
 *   Makespec used
  *   Source packages:
 *   Configuration line for main testing
*   Configure asks about license when run with no license options
 *   Compiling the package
*   Compiles with minimal options (e.g. -opensource -confirm-license)
*   Compiles as a static build, where supported
*   Compiles in namespace, where supported
*   Compiles with shadow build
*   Cross-compiles, where supported
 *   Installing the package works
*   make install to system directory as root works
*   make install to local prefix as regular user works
*   make install distributes files correctly on Mac
*   make clean and make distclean works
 *   Text files have the correct EOL for the type of package?
 *   Files/directories in the package have sane file permissions and 
timestamps?
 *   Tags (%VERSION%, %SHORTVERSION%) have been replaced properly
 *   README has valid information about how to compile the package on the 
platform tested
  *   Binary packages:
 *   Fresh install
*   Installer is correctly signed, e.g. Windows shows correct 
vendor/certificate data and no warnings about untrusted vendor.
*   Installer displays appropriate graphics, strings, version numbers
*   Installer offers the correct license(s)
*   Installer offers sane default install directory (including version 
number)
*   Installer correctly installs to default directory
*   installer correctly installs to non-default drive/directory
*   Installer sanely reports progress and completion
*   Installer installs only selected components
*   Component selection works sanely
*   Shortcuts from last page of installer work (e.g. shortcuts to 
README, demos, etc)
*   Installer correctly creates desktop shortcuts and they all work
*   Installer correctly creates Start Menu shortcuts and they all work
*   Environment settings are correct in Qt MSVC Command Prompt
*   Package shows up in Control Panel/Package Manager with correct 
description/version
*   Any patching of files has been done correctly, e.g. patching of 
library paths into .exe files and the paths hard-coded in the QtCore library.
 *   Upgrade install, if supported
  - As above
 *   Parallel install, if supported
  - As above
  - Can't install over the top of an existing package without being warned
  - Shortcuts point to the right package
  - Previously installed packages still work
 *   Uninstall
  - Removes all installed files,
  - Removes all empty dirs,
  - Removes registry keys,
  - Reverses any other changes made by installer
  - What to do with data files created by installed files, e.g. saved settings 
and files created by demo apps?
  - What to do with data shared between more than one package instance?
 *   Aborting installation, if supported
  - Cancel button is available
  - Installer cleans up, as for full uninstallation
 *   Failed installation
  - insufficient disk space (can be faked by installing onto a small USB key/SD 
card)
  - network problems while using online installer
  *   Both package types:
 *   Verify the license
 *   Assistant works
 *   Designer works
 *   Showcase demo/example apps launch without crashing
 *   Showcase demo/example apps function acceptably.
 *   Demo/example apps can be rebuilt
 *   External Qt apps can be built against the package (e.g. Qt Creator)
 *   Did DLL Swapping on a Qt app (e.g. KDE, Google Earth, Qt Creator) 
work?
 *   Click around various examples/demos for a while (GUI stress-testing)
 *   Audio/Video w/phonon
 *   Audio/Video w/QtMultimedia
 *   Raster paint engine works
 *   Image formats work
 *   Graphicsview
 *   OpenGL
 *   OpenVG
 *   Printing
 *   QML
 *   QtNetworking
 *   QtScript
 *   QtSql
 *   QtSvg
 *   WebKit works?
*   Logging into a popular site (facebook, hotmail, gmail etc) using 
the demo-browser

Re: [Development] [Poll] Which direction should Qt Quick 2.x development take?

2012-04-30 Thread marius.storm-olsen

I also want to highlight the upcoming Qt Contributor Summit (June 21-23, 
Kalkscheune, Berlin, Germany), which is the perfect environment for Qt 5.1 
discussion. (It's why we have the event in the first place.)

More details here http://qt-project.org/groups/qt-contributors-summit-2012/wiki

-- 
.marius


 -Original Message-
 From: development-bounces+marius.storm-olsen=nokia.com@qt-
 project.org [mailto:development-bounces+marius.storm-
 olsen=nokia@qt-project.org] On Behalf Of Alpert Alan (Nokia-
 MP/Brisbane)
 Sent: Monday, April 30, 2012 9:02 PM
 To: development@qt-project.org
 Subject: Re: [Development] [Poll] Which direction should Qt Quick 2.x
 development take?
 
 On Tue, 1 May 2012 06:50:55 ext Davet Jacques wrote:
  Hi fellow Qt users,
 
  spread across various comment threads at the Qt developer forum, Qt Labs
  blogs, and Qt mailing lists, there has recently been quite a bit of
  discussion over the scope and priorities of Qt Quick, and whether or not
  Nokia's (and the other Qt contributor's) roadmap, focus and design choices
  align with the needs and preferences of the majority of Qt users.
 
  So I thought it might be interesting for everyone to get an overview over
  where exactly Qt users as a whole  (or at least those who are active in
  Qt's online communities) would prefer  Qt Quick 2.x to go (or not go) in
  the near- or mid-term future.
 
  So there is now a corresponding poll (link at the bottom of this mail)
  hosted at the Qt Developer forum. Completely unofficial, but still
  worthwhile I think.
 
 
 For those interested in the path forward for actively prioritizing or
 developing these features, I've replied in devnet with some notes on each.
 
 
  Link to the poll:
  http://qt-project.org/forums/viewthread/16693/
 
 --
 Alan Alpert
 Senior Engineer
 Nokia, Qt Development Frameworks
 ___
 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/Qt Creator/Qt SDK

2012-04-20 Thread marius.storm-olsen

Now wait a minute, I never said such a thing.

I said that the MinGW-w64 binaries are Cygwin-based now. Meaning, the
MinGW they release needs Cygwin DLLs to run.

The output they generate is still native Win32 binaries, which does
_not_ require Cygwin. (Anything else would be silly, since you could
then just use the normal Cygwin-provided gcc, and not MinGW.)

Now, I do see that the latest official release actually comes from the
personal(!) build directory of a Ray Linn, and does not require Cygwin.
(I only noticed it when looking at the files page, and it says Looking
for the latest version? Download
mingw-w64-gcc-4.6.3-runtime-2.0.1-static-ada-20120321.7z (28.2 MB),
which happens to point to
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/ray_linn/)

But personally I much better like the structure, consistency, and
variety of the mingwbuilds project. You have to admit looking at
http://sourceforge.net/projects/mingwbuilds/files/windows-host/ it feels
much cleaner and professional. The MinGW-w64 project _feels_ as if it
doesn't have a clear mission. (I'm not saying they don't have one.)

--
.marius

On 20/04/2012 06:09, ext Pau Garcia i Quiles wrote:
Hi,

I'd say you are confusing mingw-w64 is available in Cygwin (like
mingw.org is) with mingw-w64-produced binaries need Cygwin DLLs.

I've been using mingw-w64 for zsync on Windows (
https://www.assembla.com/spaces/zsync-windows ) for quite some time
and the zsync.exe and zysncmake.exe binaries work without Cygwin DLLs.

On Fri, Apr 20, 2012 at 12:46 PM,marius.storm-ol...@nokia.com wrote:
Take another look. They haven't produced pure MinGW binary releases
since the end of 2011. The front page says The mingw-w64 toolchain has
been officially added to Cygwin mirrors, and when you look under the
Releases (and then under Automated Builds) section to the left on
the front page, you will see that only Cygwin-based binaries (and
linux-based cross-compilers) are now being produced. And yes, if you run
'depends' on those binaries, they do require the Cygwin DLLs.

I'm sure you can download the sources and built it yourself without the
need to be Cygwin-based, but Daniel didn't want to do that, he wanted
binaries he could just include.

The MinGWbuilds project produces much cleaner downloads, and also a nice
set of GCC versions you can choose from. And yes, the MinGWbuilds ones
are also dual target (x86/x64), just provide the -m32/-m64 flags as
normal. The binaries for x86 and x64 are just describing the host, and
what they target by default. (More details on that on the previous site:
http://code.google.com/p/mingw-builds/)

--
.marius

On 19/04/2012 22:16, ext 1+1=2 wrote:
No, MinGW-w64 doesn't depend on Cygwin.

http://openfoamwiki.net/index.php/Tip_Cross_Compiling_OpenFOAM_in_Linux_For_Windows_with_MinGW#Differences_between_mingw32_and_mingw-w32_versions

Mingw-w64 began as a spin-off from the mingw.org project, with the
original intent of building for 64-bit targets. Nonetheless, mingw-w64
has retro-compatibility with the 32bit MinGW version, thus enabling a
2-in-1 build package for 32 and 64bit Windows systems.

On Thu, Apr 19, 2012 at 7:59 PM,marius.storm-ol...@nokia.comwrote:
On 19/04/2012 17:06, ext 1+1=2 wrote:
From the homepage of project, http://mingwbuilds.sourceforge.net/

This is the MinGW-builds project (mingwbuilds)
This project was registered on SourceForge.net on Mar 30, 2012, and
is described by the project team as follows:
Snapshots and releases builds of the MinGW compiler that use CRT
amp; WinAPI from the mingw-w64 project. Builds support the following
technologies: - OpenMP - LTO - Graphite - std Concurrency

So, the official homepage should be: http://mingw-w64.sourceforge.net/

No, the first project is not related to the other. MinGW-builds was just
recently moved from http://code.google.com/p/mingw-builds/ to
http://sourceforge.net/projects/mingwbuilds, hence the new date on the
Sourceforge project page.

MinGW-builds only snags the *CRT* and *WinAPI* parts from the MinGW-w64
project, but is otherwise unrelated.

MinGW-w64 distributes MinGW binaries which require Cygwin to run, while
the MinGW-builds project distributes native Win32 versions of MinGW.
Only the latter is acceptable to the Qt Project.

--
.marius

Regards,

Debao

On Thu, Apr 19, 2012 at 2:32 PM,marius.storm-ol...@nokia.com wrote:
If you click the link in Daniels initial email, and onto the windows
host directory, you would see that the have both the 4.7.0 release and
the 4.7.1 prerelease as binaries already.

--
Sent from my Nokia N9

On 4/19/12 16:14 ext Mark wrote:
2012/4/19daniel.molken...@nokia.com

Hi Everyone,

After several complains from the community that GCC 4.4 shipped with
both Creator and the Qt SDK is fairly outdated (and not C++11
compliant), we are going to ship a mingw.org-based GCC 4.6.2 with

Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK

2012-04-19 Thread marius.storm-olsen

If you click the link in Daniels initial email, and onto the windows host 
directory, you would see that the have both the 4.7.0 release and the 4.7.1 
prerelease as binaries already.

--
Sent from my Nokia N9

On 4/19/12 16:14 ext Mark wrote:
2012/4/19 daniel.molken...@nokia.com

Hi Everyone,
 
After several complains from the community that GCC 4.4 shipped with both 
Creator and the Qt SDK is fairly outdated (and not C++11 compliant), we are 
going to ship a mingw.org-based GCC 4.6.2 with the next Qt Creator release. 
Even though we verified that this works with the MinGW 4.4 compiled Qt releases 
from the Qt SDK, I think we should agree on a common version. Thus, I want to 
come to an agreement with all relevant stakeholders in the Qt  Project on which 
MinGW to ship.
 
From my POV, the following things are important when choosing a “proper” 
MinGW-based compiler:
 
-  Prefer existing MinGW distros* over compiling  maintaining MinGW 
ourselves (although others may disagree here)
-  Make sure they are minimal and centered around C/C++ development 
(i.e. no elaborate gjc cruft like we still have in our current MinGW 4.4 
packages)
-  Make sure we pick a distro that provides regular updates and 
provides new GCC versions in a timely manner
-  Let’s ship both a 64 and a 32 bit version, and ideally ones that 
provide a cross-compiler respectively
-  Let’s make sure we start providing them at the same time, and we 
start building our products with them
 
Marius found http://sourceforge.net/projects/mingwbuilds/files/, which seems to 
satisfy all of the above. Other suggestions/preferences are welcome.
 
If deemed necessary, we can also build our own MinGW distro via Qt Project’s 
public build infrastructure (http://builds.qt-project.org). We need good build 
recipes for that, though, and someone who is willing to maintain them.
 
Cheers,
  Daniel
 
*) by “Distro” I mean different entities compiling  providing MinGW releases 
such as MinGW.org, TDM, etc




Why not wait till there is a MingW with GCC 4.7.0 release? I'm asking that 
since GCC 4.7 adds support for AVX and AMD bulldozer (bdver1) specific compiler 
optimization which seem to be greatly beneficial for AMD cpu's. So it might be 
worth the consideration to postpone the next Qt Creator release till there is a 
MingW with GCC 4.7.0.


Just my opinion.


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

Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK

2012-04-19 Thread marius.storm-olsen

On 19/04/2012 17:06, ext 1+1=2 wrote:
 From the homepage of project, http://mingwbuilds.sourceforge.net/

This is the MinGW-builds project (mingwbuilds)
This project was registered on SourceForge.net on Mar 30, 2012, and
 is described by the project team as follows:
Snapshots and releases builds of the MinGW compiler that use CRT
 amp; WinAPI from the mingw-w64 project. Builds support the following
 technologies: - OpenMP - LTO - Graphite - std Concurrency

 So, the official homepage should be: http://mingw-w64.sourceforge.net/

No, the first project is not related to the other. MinGW-builds was just 
recently moved from http://code.google.com/p/mingw-builds/ to 
http://sourceforge.net/projects/mingwbuilds, hence the new date on the 
Sourceforge project page.

MinGW-builds only snags the *CRT* and *WinAPI* parts from the MinGW-w64 
project, but is otherwise unrelated.

MinGW-w64 distributes MinGW binaries which require Cygwin to run, while 
the MinGW-builds project distributes native Win32 versions of MinGW. 
Only the latter is acceptable to the Qt Project.

-- 
.marius


 Regards,

 Debao


 On Thu, Apr 19, 2012 at 2:32 PM,marius.storm-ol...@nokia.com  wrote:
 If you click the link in Daniels initial email, and onto the windows host 
 directory, you would see that the have both the 4.7.0 release and the 4.7.1 
 prerelease as binaries already.

 --
 Sent from my Nokia N9

 On 4/19/12 16:14 ext Mark wrote:
 2012/4/19daniel.molken...@nokia.com

 Hi Everyone,

 After several complains from the community that GCC 4.4 shipped with both 
 Creator and the Qt SDK is fairly outdated (and not C++11 compliant), we are 
 going to ship a mingw.org-based GCC 4.6.2 with the next Qt Creator release. 
 Even though we verified that this works with the MinGW 4.4 compiled Qt 
 releases from the Qt SDK, I think we should agree on a common version. Thus, 
 I want to come to an agreement with all relevant stakeholders in the Qt  
 Project on which MinGW to ship.

  From my POV, the following things are important when choosing a “proper” 
 MinGW-based compiler:

 -  Prefer existing MinGW distros* over compiling  maintaining MinGW 
 ourselves (although others may disagree here)
 -  Make sure they are minimal and centered around C/C++ development 
 (i.e. no elaborate gjc cruft like we still have in our current MinGW 4.4 
 packages)
 -  Make sure we pick a distro that provides regular updates and 
 provides new GCC versions in a timely manner
 -  Let’s ship both a 64 and a 32 bit version, and ideally ones that 
 provide a cross-compiler respectively
 -  Let’s make sure we start providing them at the same time, and we 
 start building our products with them

 Marius found http://sourceforge.net/projects/mingwbuilds/files/, which seems 
 to satisfy all of the above. Other suggestions/preferences are welcome.

 If deemed necessary, we can also build our own MinGW distro via Qt Project’s 
 public build infrastructure (http://builds.qt-project.org). We need good 
 build recipes for that, though, and someone who is willing to maintain them.

 Cheers,
   Daniel

 *) by “Distro” I mean different entities compiling  providing MinGW 
 releases such as MinGW.org, TDM, etc




 Why not wait till there is a MingW with GCC 4.7.0 release? I'm asking that 
 since GCC 4.7 adds support for AVX and AMD bulldozer (bdver1) specific 
 compiler optimization which seem to be greatly beneficial for AMD cpu's. So 
 it might be worth the consideration to postpone the next Qt Creator release 
 till there is a MingW with GCC 4.7.0.


 Just my opinion.


 Cheers,
 Mark
 ___
 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] important: upcoming rename of _qpa.h to _p.h

2012-04-17 Thread marius.storm-olsen

 -Original Message-
 From: ext Girish Ramakrishnan [mailto:gir...@forwardbias.in]
 On Tue, Apr 17, 2012 at 4:03 AM,  marius.storm-ol...@nokia.com wrote:
  On 17/04/2012 03:34, ext Paul Olav Tvete wrote:
  On Tuesday 17 April 2012 03:57:16 ext Girish Ramakrishnan wrote:
  As per the previous discuss, I renamed all the _qpa.h to _p.h with
  a couple of helper scripts
 
  I just added the following -1 comment on gerrit:
 
  I do not agree with this change. We have made a difference between
  public API and plugin API, and this is different from private
  implementation detail.
 
  The rest of the Lighthouse team are also skeptical. The main issue,
  as far as I can see, is documentation. This can be solved much in a
  much simpler way by using the \internal tag, as discussed earlier.
  There should also be a warning in the _qpa.h files, but it shouldn't
  be the don't even think of using this file warning from the _p.h
  file; these files are there for platform plugin authors to use.
 
  Also remember that yes, we don't promise BC from 5.0.0, but at some
  point we would want the QPA api to stabilize at let it keep the same
  promise as the rest of Qt, don't we?
 
  At which point, we would have to rename the files again?
 
 This is how we have always done development in Qt. It starts out with
 _p.h and then becomes .h :)

Well, that breaks SC for existing projects, which have been ok with the missing 
BC. So you want to improve by promising BC by breaking SC?

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

Re: [Development] important: upcoming rename of _qpa.h to _p.h

2012-04-17 Thread marius.storm-olsen

Yes, it does.
And for the case of QPA, we have said that we don't want to promise BC, but we 
haven't said that we will go around breaking SC for every patch release. (And 
we shouldn't, since SC breakage uses quite a bit of resources on all parties, 
so avoid them if you can.)

Like some others, I would prefer it to remain in non-private headers, while 
mark the QPA API with non-BC promise.
IMO, in Qt 5.1 we should be able to promise BC on the QPA APIs too.

--
.marius

From: development-bounces+marius.storm-olsen=nokia@qt-project.org 
[mailto:development-bounces+marius.storm-olsen=nokia@qt-project.org] On 
Behalf Of ext Stephen Kelly
Sent: Tuesday, April 17, 2012 10:27 AM
To: development@qt-project.org
Subject: Re: [Development] important: upcoming rename of _qpa.h to _p.h


On Tuesday, April 17, 2012 15:05:49 
marius.storm-ol...@nokia.commailto:marius.storm-ol...@nokia.com wrote:

 Well, that breaks SC for existing projects, which have been ok with the

 missing BC. So you want to improve by promising BC by breaking SC?



_p also means SC is not maintained.



Thanks,



--

Stephen Kelly stephen.ke...@kdab.commailto:stephen.ke...@kdab.com | 
Software Engineer

KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company

www.kdab.comhttp://www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) 
+46-563-540090

KDAB - Qt Experts - Platform-Independent Software Solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Resolving the wiki situtation

2012-04-13 Thread marius.storm-olsen

On 13/04/2012 11:03, ext Girish Ramakrishnan wrote:
 On Fri, Apr 13, 2012 at 8:57 AM,marius.storm-ol...@nokia.com
 wrote:
 On 13/04/2012 08:50, ext Girish Ramakrishnan wrote:
 On Fri, Apr 13, 2012 at 1:56 AM,alexandra.lei...@nokia.com
 wrote: Will the old pages redirect to the new one or will the
 domain wiki.qt-project.org completely die after thursday? Ideally
 former since we have lots of pages in wiki.qt-project.org but I
 can live with the fact that it will completely die.

 I had also suggested that we make wiki.qt-project.org read-only
 to Quim. Do you think we can just lock it starting this weekend?

 Ideally I would want wiki.qt-project.org to point to the valid
 wiki (which is now at qt-project.org/wiki). I really don't think we
 should spend time and effort keeping backwards compatibility with
 the old wiki entries.

 I was hoping we could have a simple url rewrite, but I agree no more
 effort.

 Some of our pages (like devices - http://wiki.qt-project.org/Devices
 which went out in yesterday's blog post) will all be broken. But as
 I said, I can live with that :)

Ok, the messaging since we got both wikis is that the old wiki will die 
and to use the new wiki from that day on. :)

Just copy the content over to the new wiki, and update the blog post.

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

Re: [Development] Qt 5.0 alpha released

2012-04-12 Thread marius.storm-olsen

Hi, just wanted to share some download stats with you guys:

  10668 /qt5.0/alpha/qt-everywhere-opensource-src-5.0.0-alpha.7z
  1 
/qt5.0/alpha/qt-everywhere-opensource-src-5.0.0-alpha.7z?51580699043405175974186249732156
 93 /qt5.0/alpha/qt-everywhere-opensource-src-5.0.0-alpha.tar.7z
   2436 /qt5.0/alpha/qt-everywhere-opensource-src-5.0.0-alpha.tar.bz2
   1616 /qt5.0/alpha/qt-everywhere-opensource-src-5.0.0-alpha.tar.gz
796 /qt5.0/alpha/qt-everywhere-opensource-src-5.0.0-alpha.tar.xz
   6084 /qt5.0/alpha/qt-everywhere-opensource-src-5.0.0-alpha.zip

Since the first two and the last in this list indicate Windows downloads (due 
to the CRLF EOL, unless people use 'unzip -a'), we get a guesstimate of
  16753 Windows downloads
   4941 Linux/OSX downloads

~3.4x more Windows downloads than Linux and Mac OSX combined. Not hard facts, 
but still interesting.

--
.marius

From: development-bounces+marius.storm-olsen=nokia@qt-project.org 
[mailto:development-bounces+marius.storm-olsen=nokia@qt-project.org] On 
Behalf Of Storm-Olsen Marius (Nokia-MP/Austin)
Sent: Tuesday, April 03, 2012 10:01 AM
To: annou...@qt-project.org
Cc: development@qt-project.org; releas...@qt-project.org; 
inter...@qt-project.org
Subject: [Development] Qt 5.0 alpha released


Hi,



We are happy to announce the Qt 5.0 alpha release. This is the first major Qt 
release since the Qt Project went live, and a large amount of work and features 
have gone into this release.



Blog post: http://labs.qt.nokia.com/2012/04/03/qt-5-alpha/

Download page: http://qt-project.org/wiki/Qt-5-Alpha



Thanks a lot for all the contributions and feedback, and thanks to all the 
people who made this happen!



The Qt Project



--

Marius Storm-Olsen

Head of Qt OSS



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

Re: [Development] Qt Summit 2012 Registration is now open!

2012-04-12 Thread marius.storm-olsen

Quim,



I agree with André on this one. Google's terms and policies are quite 
complicated, and it's not right for the Qt Project to force anyone to abide by 
their terms. We need to stop using their spreadsheet and find other ways to 
organize the information you need to keep tabs on the Contributor Summit.



A simple highlight of one of the terms for Google Docs (underline, bolding and 
eliding by me) from http://www.google.com/intl/en/policies/terms/ @ 2012-04-12 
20:30:

When you upload or otherwise submit content to our Services, you give Google 
(and those we work with) a worldwide license to use, host, store, reproduce, 
modify, create derivative works (...), communicate, publish, publicly perform, 
publicly display and distribute such content.



--

.marius





 -Original Message-

 From: development-bounces+marius.storm-olsen=nokia.com@qt-

 project.org [mailto:development-bounces+marius.storm-

 olsen=nokia@qt-project.org] On Behalf Of ext André Pönitz

 Sent: Thursday, April 12, 2012 7:34 PM

 To: Gil Quim (Nokia-DXM/SiliconValley)

 Cc: development@qt-project.org

 Subject: Re: [Development] Qt Summit 2012 Registration is now open!



 On Thu, Apr 12, 2012 at 02:44:36PM -0700, Quim Gil wrote:

  On 04/11/2012 02:23 PM, ext André Pönitz wrote:

  On Wed, Apr 11, 2012 at 10:01:13AM -0700, Quim Gil wrote:

  Just to be clear: Nokia employees follow the same registration process,

  like anybody else. Organizers too. Lars too. Me too. Everybody.

  

  If you say so...

  

  http://qt-project.org/groups/qt-contributors-summit-2012/wiki

  

  There will be at least one person who is not even remotely amused

  about the prospect to have to enter personal data into some random

  document hosted at some third party site.

 

  Interesting. Can I ask what is your concern?

 

  Every time someone registers to some third party event s/he uses

  some third party site.



 There seems to be a misunderstanding concerning the term third

 party here.



 In that what I consider a usual registration process _two_ parties

 are involved: A person who wants to attend an event, and the host of the

 event. The host typically promises to use the attendee's personal data

 only for the purpose of the event, to not pass it on to third parties

 etc, and the attendee typically trusts the host of the event to stick

 to the promise.



 The registration setup you choose for the summit involves a third

 party as man in the middle which neither the host nor the attendee

 has any business with, let alone controls in any way. On the

 contrary, by using the services of said third party one agrees to

 their terms and conditions, put into writing in several pages of

 legalese, not all of it harmless to the uninitiated on first sight.



  This is no exception. Last year a 3rd party service was used as well afair.



 I don't really remember filling in a form hosted at google.

 But I admit that doesn't mean much.



  The alternative would have been to use something within

  http://qt-project.org - but what? We didn't want to bring more work

  to Marius  co installing services and we actually are reusing as

  much as Qt DevNet as possible,



 The alternatives range from a hand crafted web page on qt-project.org

 to using plain email and manual transfer into a database. Total effort

 for a 200 person event in both cases less than a day. And I'd rather

 volunteer to key in the data personally instead of spending the

 time discussing basic privacy concerns.



  The personal data requested is mostly public anyway?



 [mostly perhaps. But even if so, it would not matter in this

 particular context. Availability does not imply the right to use it

 without consent, at least not over here.]



  Also, if you send it to me via email guess what I will do:

  store it in the same online spreadsheet [...]



 I would feel more comfortable if you could at least try to pretend

 that a Qt Project community manager acknowledges the existence of

 the concept of privacy, and does not feed personal data of members of

 the community into _anything_ outside the reach of the Qt Project

 without the consent of the person concerned.



  [...] since that is the space used by the organizers and all

  badges are printed from there.



 I can take care of a badge. No worries ;-)



 Andre'





 ___

 Development mailing list

 Development@qt-project.orgmailto: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 Summit 2012 Registration is now open!

2012-04-06 Thread marius.storm-olsen

IMO that's reasonable. They are an equal part of the Qt community as 
anybody else, since it benefits Qt directly.

-- 
.marius

On 04/06/2012 08:01 AM, ext simon.hausm...@nokia.com wrote:
 I think it would be great if we could extend the invitations to WebKit 
 committers that are contributors to the Qt port.

 Quim, what do you think?

 Simon

 --
 Sendt fra min Nokia N904.04.12 19:51 skrev Gil Quim (Nokia-DXM/SiliconValley):
 Qt WebKit counts just like any other Qt module. In case of doubt get an 
 indication or invitation from the module maintainers.


 Quim


 On 4/4/12 10:41 AM ext Jesus Sanchez-Palencia wrote:

 From the registration page: Reasons for Attending. What are webkit
 people considered?! We don't fit as maintainers neither as approvers.

 =/



 Cheers,


 -jesus
 yet another QtWebKit Gerrit Outlaw



 2012/4/4 Sivan Greenbergsi...@omniqueue.com:
 We now have a human friendly URL for the registration page (Thanks
 Thiago the reminder):

 http://tinyurl.ms/50kb

 -Sivan

 On Tue, Apr 3, 2012 at 10:31 PM, Sivan Greenbergsi...@omniqueue.com  wrote:
 reserve your place.

 [0]: http://tinyurl.ms/50kb
 ___
 Development mailing list
 si...@omniqueue.com
 http://tinyurl.ms/50kb

 ___

 Development mailing list

 si...@omniqueue.com
 http://tinyurl.ms/50kb



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


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

Re: [Development] Compiling Qt5 Alpha on Windows XP not working

2012-04-04 Thread marius.storm-olsen

Oh, the build script pushes the option /MP to the CL environment variable, to 
ensure that cl will compile on all available cores on your machine. However, it 
seems like you already have options set in CL, and Perls 'unshift' will 
separate each option with a semi-colon, which cl doesn't like. Try unsetting 
your CL environment variable before executing the build script.

-- 
.marius


 -Original Message-
 From: development-bounces+marius.storm-olsen=nokia.com@qt-
 project.org [mailto:development-bounces+marius.storm-
 olsen=nokia@qt-project.org] On Behalf Of ext Daniel Kreuter
 Sent: Wednesday, April 04, 2012 3:16 AM
 To: development@qt-project.org
 Subject: Re: [Development] Compiling Qt5 Alpha on Windows XP not working
 
 Ok now while compiling with the Win SDK 7.1 I get the following error:
 
 Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
 Copyright (C) Microsoft Corporation.  All rights reserved.
 
 cd src\tools\bootstrap\  C:\Program Files\Microsoft Visual Studio 
 10.
 0\VC\Bin\nmake.exe -f Makefile
 
 Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
 Copyright (C) Microsoft Corporation.  All rights reserved.
 
 C:\Program Files\Microsoft Visual Studio 10.0\VC\Bin\nmake.exe -f
 Make
 file.Debug
 
 Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
 Copyright (C) Microsoft Corporation.  All rights reserved.
 
 cl -c -nologo -Zm200 -Zc:wchar_t -Zi -MDd -GR -EHsc -W3 -w34100 -
 w34189
 -DUNICODE -DWIN32 -DQT_LARGEFILE_SUPPORT -DQT_BOOTSTRAPPED -
 DQT_LITE_UNICODE -DQ
 T_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII -DQT_NO_CODECS -
 DQT_NO_DATASTREAM -DQ
 T_NO_GEOM_VARIANT -DQT_NO_LIBRARY -DQT_NO_QOBJECT -
 DQT_NO_STL -DQT_NO_SYSTEMLOCA
 LE -DQT_NO_THREAD -DQT_NO_UNICODETABLES -
 DQT_NO_USING_NAMESPACE -DQT_NO_DEPRECAT
 ED -DQT_NODLL -I..\..\..\include -I..\..\..\include\QtCore 
 -I..\..\..\inclu
 de\QtCore\5.0.0 -I..\..\..\include\QtCore\5.0.0\QtCore -
 I..\..\3rdparty\zlib
  -I..\..\..\mkspecs\win32-msvc2010 -Fotmp\obj\debug_shared\
 @C:\DOCUME~1\kreu
 terd\LOCALS~1\Temp\nm73.tmp
 cl : Command line error D8021 : invalid numeric argument '/MP;/AI'
 NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio
 10.0\VC\Bi
 n\cl.EXE' : return code '0x2'
 Stop.
 NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio
 10.0\VC\Bi
 n\nmake.exe' : return code '0x2'
 Stop.
 NMAKE : fatal error U1077: 'cd' : return code '0x2'
 Stop.
 cd qtbase  C:\Program Files\Microsoft Visual Studio
 10.0\VC\Bin\nmake.exe  e
 xited with status 512 at build line 64
 Qt::Build::exe('Qt::Build=HASH(0x3faaf4)', 'cd qtbase  C:\Program 
 Fil
 es\Microsoft Visual Studio 10.0\V...') called at build line 105
 Qt::Build::exeLowPriv('Qt::Build=HASH(0x3faaf4)', 'cd qtbase 
 C:\Prog
 ram Files\Microsoft Visual Studio 10.0\V...') called at build line 377
 Qt::Build::build_project('Qt::Build=HASH(0x3faaf4)', 'qtbase') called 
 at
  build line 408
 Qt::Build::build_qt('Qt::Build=HASH(0x3faaf4)') called at build line 
 437
 
 Qt::Build::run('Qt::Build=HASH(0x3faaf4)') called at build line 446
 
 Any suggestions? (No Visual Studio is not installed)
 
 On Wed, Apr 4, 2012 at 9:42 AM, Loaden loa...@gmail.com wrote:
  See: http://qt-project.org/wiki/Building_Qt_5_from_Git
 
  2012/4/4 Daniel Kreuter daniel.kreute...@googlemail.com
 
  Hello guys,
 
  I'm trying to compile Qt5 Alpha on my Windows XP machine, but I get
  the following output when calling either perl build or mingw32-make:
 
  C:\QtSDK\Qt5Alphamingw32-make
  cd qtbase\  mingw32-make -f Makefile
  mingw32-make[1]: Entering directory `C:/QtSDK/Qt5Alpha/qtbase'
  cd src\tools\bootstrap\  mingw32-make -f Makefile
  mingw32-make[2]: Entering directory
  `C:/QtSDK/Qt5Alpha/qtbase/src/tools/bootstra
  p'
  mingw32-make -f Makefile.Debug
  mingw32-make[3]: Entering directory
  `C:/QtSDK/Qt5Alpha/qtbase/src/tools/bootstra
  p'
  g++ -c -fno-keep-inline-dllexport -g -frtti -fexceptions -mthreads -Wall
  -DUNICO
  DE -DQT_LARGEFILE_SUPPORT -DQT_BOOTSTRAPPED -
 DQT_LITE_UNICODE
  -DQT_NO_CAST_FROM_
  ASCII -DQT_NO_CAST_TO_ASCII -DQT_NO_CODECS -
 DQT_NO_DATASTREAM
  -DQT_NO_GEOM_VARIA
  NT -DQT_NO_LIBRARY -DQT_NO_QOBJECT -DQT_NO_STL -
 DQT_NO_SYSTEMLOCALE
  -DQT_NO_THRE
  AD -DQT_NO_UNICODETABLES -DQT_NO_USING_NAMESPACE -
 DQT_NO_DEPRECATED
  -DQT_NODLL -
  I..\..\..\include -I..\..\..\include\QtCore
  -I..\..\..\include\QtCore\5.0.0
   -I..\..\..\include\QtCore\5.0.0\QtCore -I..\..\..\mkspecs\win32-g++
  -o tmp
  \obj\debug_shared\qlatincodec.o ..\..\corelib\codecs\qlatincodec.cpp
  cc1plus.exe: error: unrecognized command line option
  -fno-keep-inline-dllexport
  
  mingw32-make[3]: *** [tmp/obj/debug_shared/qlatincodec.o] Error 1
  mingw32-make[3]: Leaving directory
  `C:/QtSDK/Qt5Alpha/qtbase/src/tools/bootstrap
  '
  mingw32-make[2]: *** [debug] Error 2
  mingw32-make[2]: Leaving directory
  `C:/QtSDK/Qt5Alpha/qtbase/src/tools/bootstrap

Re: [Development] Compiling Qt5 Alpha on Linux fails

2012-04-04 Thread marius.storm-olsen

Try following the instructions here
http://qt-project.org/wiki/Qt-5-Alpha-building-instructions

Qt should not be configured in such a way that it needs to be installed. That's 
not a supported build configuration for the alpha.
Only in-source non-install builds for alpha.

-- 
.marius


 -Original Message-
 From: development-bounces+marius.storm-olsen=nokia.com@qt-
 project.org [mailto:development-bounces+marius.storm-
 olsen=nokia@qt-project.org] On Behalf Of ext Peter Rullmann
 Sent: Wednesday, April 04, 2012 4:29 AM
 To: Qt Development List
 Subject: [Development] Compiling Qt5 Alpha on Linux fails
 
 Hi,
 
 I'm trying to compile Qt5 Alpha on Linux, but got stuck.
 
 I am running Ubuntu 11.04, but my colleague running 11.10 has exactly the
 same issues.
 
 I built using `./configure -opensource -confirm-license -nomake tests` and
 `sudo ./build -j 2`
 
 Here are the Problems I had:
 * I had to run ./build with sudo, which is not documented in the
instructions
 * There was a problem in 'qt3d/src/quick3d', which I worked around by
running make in that directory by hand and creating the target directory
beforehand.
 * 'gperf' seems to be needed, but is not listed in the dependencies.
 * Then I got stuck in qtwebkit:
 
 g++
 -Wl,-rpath,/home/mavu/src/qt-everywhere-opensource-src-
 5.0.0/qtwebkit/WebKitBuild/Release/lib
 -fuse-ld=gold -Wl,--no-undefined -Wl,--gc-sections -Wl,--no-undefined
 -Wl,-O1
 -Wl,-rpath-link,/home/mavu/src/qt-everywhere-opensource-src-
 5.0.0/qtwebkit/WebKitBuild/Release/lib
 -Wl,-rpath,/usr/local/Qt-5.0.0/lib -shared -o libWTRInjectedBundle.so
 obj/release/home/mavu/src/qt-everywhere-opensource-src-
 5.0.0/qtwebkit/Tools/DumpRenderTree/qt/QtInitializeTestFonts.o
 obj/release/AccessibilityController.o
 obj/release/AccessibilityTextMarker.o
 obj/release/AccessibilityTextMarkerRange.o
 obj/release/AccessibilityUIElement.o obj/release/InjectedBundle.o
 obj/release/InjectedBundleMain.o obj/release/InjectedBundlePage.o
 obj/release/EventSendingController.o obj/release/GCController.o
 obj/release/LayoutTestController.o obj/release/TextInputController.o
 obj/release/Bindings/JSWrapper.o obj/release/qt/ActivateFontsQt.o
 obj/release/qt/InjectedBundleQt.o
 obj/release/qt/LayoutTestControllerQt.o
 obj/release/home/mavu/src/qt-everywhere-opensource-src-
 5.0.0/qtwebkit/WebKitBuild/Release/Tools/WebKitTestRunner/InjectedBun
 dle/generated/JSAccessibilityController.o
 obj/release/home/mavu/src/qt-everywhere-opensource-src-
 5.0.0/qtwebkit/WebKitBuild/Release/Tools/WebKitTestRunner/InjectedBun
 dle/generated/JSAccessibilityTextMarker.o
 obj/release/home/mavu/src/qt-everywhere-opensource-src-
 5.0.0/qtwebkit/WebKitBuild/Release/Tools/WebKitTestRunner/InjectedBun
 dle/generated/JSAccessibilityTextMarkerRange.o
 obj/release/home/mavu/src/qt-everywhere-opensource-src-
 5.0.0/qtwebkit/WebKitBuild/Release/Tools/WebKitTestRunner/InjectedBun
 dle/generated/JSAccessibilityUIElement.o
 obj/release/home/mavu/src/qt-everywhere-opensource-src-
 5.0.0/qtwebkit/WebKitBuild/Release/Tools/WebKitTestRunner/InjectedBun
 dle/generated/JSEventSendingController.o
 obj/release/home/mavu/src/qt-everywhere-opensource-src-
 5.0.0/qtwebkit/WebKitBuild/Release/Tools/WebKitTestRunner/InjectedBun
 dle/generated/JSGCController.o
 obj/release/home/mavu/src/qt-everywhere-opensource-src-
 5.0.0/qtwebkit/WebKitBuild/Release/Tools/WebKitTestRunner/InjectedBun
 dle/generated/JSLayoutTestController.o
 obj/release/home/mavu/src/qt-everywhere-opensource-src-
 5.0.0/qtwebkit/WebKitBuild/Release/Tools/WebKitTestRunner/InjectedBun
 dle/generated/JSTextInputController.o
 -L/usr/local/Qt-5.0.0/lib
 -L/home/mavu/src/qt-everywhere-opensource-src-
 5.0.0/qtwebkit/WebKitBuild/Release/lib
 -lfontconfig -lgio-2.0 -lgstapp-0.10 -lgstinterfaces-0.10
 -lgstpbutils-0.10 -pthread -lgstvideo-0.10 -lgstbase-0.10 -lgstreamer-0.10
 -lgobject-2.0 -lgmodule-2.0 -lxml2 -lgthread-2.0 -lrt -lglib-2.0
 -lQtWebKit -lQtQml -L/usr/local/Qt-5.0.0/lib -lQtV8 -lQtOpenGL
 -lQtXmlPatterns -lQtWidgets -lQtSql -lQtScript -lQtNetwork -lQtGui
 -lQtCore -lGL -lpthread
 mv -f libWTRInjectedBundle.so ../../../lib/
 make[5]: Leaving directory
 `/home/mavu/src/qt-everywhere-opensource-src-
 5.0.0/qtwebkit/WebKitBuild/Release/Tools/WebKitTestRunner/InjectedBun
 dle'
 make[4]: Leaving directory
 `/home/mavu/src/qt-everywhere-opensource-src-
 5.0.0/qtwebkit/WebKitBuild/Release/Tools/WebKitTestRunner/InjectedBun
 dle'
 make[3]: Leaving directory
 `/home/mavu/src/qt-everywhere-opensource-src-
 5.0.0/qtwebkit/WebKitBuild/Release/Tools/WebKitTestRunner'
 make[2]: Leaving directory
 `/home/mavu/src/qt-everywhere-opensource-src-
 5.0.0/qtwebkit/WebKitBuild/Release/Tools'
 make[1]: Leaving directory
 `/home/mavu/src/qt-everywhere-opensource-src-
 5.0.0/qtwebkit/WebKitBuild/Release'
 cd qtwebkit  perl Tools/Scripts/build-webkit --qt --makeargs=install
 exited with status 512 at ./build line 64
Qt::Build::exe('Qt::Build=HASH(0xa1586d8)', 'cd qtwebkit

Re: [Development] V8 on iOS

2012-04-02 Thread marius.storm-olsen

On 02/04/2012 08:06, ext Thiago Macieira wrote:
 On segunda-feira, 2 de abril de 2012 13.02.08,
 aaron.kenn...@nokia.com wrote:
 On 02/04/2012, at 2:21 PM, ext Ian wrote:
 Chris, Thanks for your answer. So, the low-down is that it's not
 (practically) possible to use QML without V8, and even if V8 did
 have a interpreter backend, it would be too slow to be useable?
 If so, I guess I'm going to have to find a way to get V8 working
 on iOS…

 V8 with an interpreter backend would probably be fine.  However, V8
 doesn't have such a backend and writing one would be an enormous
 effort - akin to one of their architecture ports.

 I estimated a 40k contribution to do that.

 The key to getting V8 running on iOS will be executing writable
 pages. Unless you can solve that - and in a way that keeps Apple
 happy if you ever want to deploy such apps - everything else will
 be in vein.

 I don't think Apple will ever allow that. I don't think Apple will
 allow executing any code that isn't loaded strictly from disk.

What do they use themselves for their own webkit JS engine?

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

Re: [Development] Maintainer TrustMes

2012-04-02 Thread marius.storm-olsen

On 02/04/2012 08:22, ext Thiago Macieira wrote:
 One of the duties of a maintainer is to ensure that every
 contribution to the code he/she maintains is being reviewed. That is,
 if no one else approves or rejects, the maintainer has the duty to
 make that happen. I've done this in the past and approved based on +1
 given by other people, or by reviewing stuff myself.

 What are we supposed to do when no one else approves or rejects a
 commit that we created ourselves? Or worse, when no one reviews at
 all?

 My question applies mostly to QtDBus, since I don't expect most
 people will know anything about that module. I've (ab)used Stephen's
 goodwill to review simple things, but I don't expect him to
 understand the message delivery path for example.

 What is the suggested procedure?

You don't have to have intimate knowledge about a module to review code 
constructs against policies etc. And if there's no one else with 
knowledge about a module, it's probably a good idea for someone to step 
up and learn a little about that particular module. It's not good that 
only 1 person knows a module, in case that person gets sick, get hit by 
a bus (morbid I know, but still a possibilty) etc.

In any case, try to get someone to review at least the code syntax 
parts, and see if you can persuade them to learning the technical bits 
as well.

Last resort, the Chief Maintainer has the ultimate responsibility ;)

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

Re: [Development] New QUrl reviewing

2012-03-29 Thread marius.storm-olsen

Eh, after alpha please?

-- 
.marius


 -Original Message-
 From: development-bounces+marius.storm-olsen=nokia.com@qt-
 project.org [mailto:development-bounces+marius.storm-
 olsen=nokia@qt-project.org] On Behalf Of Knoll Lars (Nokia-MP/Oslo)
 Sent: Thursday, March 29, 2012 6:56 AM
 To: thiago.macie...@intel.com; development@qt-project.org
 Subject: Re: [Development] New QUrl reviewing
 
 All is reviewed. Stage at your convenience ;-)
 
 Cheers,
 Lars
 
 On 3/28/12 11:42 PM, ext Thiago Macieira thiago.macie...@intel.com
 wrote:
 
 On quarta-feira, 28 de março de 2012 19.08.04, lars.kn...@nokia.com wrote:
  I'll try to go through them tonight.
 
 Thanks for the effort. I've gone over all the recommendations and made
 the
 modifications. We're pending further work on:
 
 1) QUrlTwoFlags - a helper class like QFlags but that takes two enums not
 just
 one. I'll simplify this into QFlags if possible and make it generic later.
 
 2) renaming the QUrlQuery methods (i.e., API review). The names were
 kept
 equal to Qt 4's for compatibility reasons, but since this is a new class
 and
 you need to touch your code anyway to use them, we could use better
 names.
 Will do after they code is in.
 
 3) decide if QUrl::errorString() should be translatable
 
 One of the changes has already been staged (the one in qtdeclarative).
 The
 rest have been updated with the fixes. All the commits have two changes
 except
 the first two below: the first is just a rebase because Gerrit required
 me to
 rebase. The second contains the modifications.
 
 To be re-approved or reviewed for the changes:
 http://codereview.qt-project.org/21045 only rebase - Gerrit shows no
 changes
 http://codereview.qt-project.org/21046 only rebase - Gerrit shows no
 changes
 http://codereview.qt-project.org/21047 updated the constants to be
 higher
 http://codereview.qt-project.org/21048 only rebase - Gerrit shows no
 changes
 http://codereview.qt-project.org/21052 renamed encodedUtf8ToUcs4 to
 *Utf16
 http://codereview.qt-project.org/21049 two changes requested by Lars
 http://codereview.qt-project.org/21057 only rebase - Gerrit shows
 unrelated
 http://codereview.qt-project.org/21056 only rebase - Gerrit shows
 unrelated
 http://codereview.qt-project.org/21058 only rebase - Gerrit shows
 unrelated
 http://codereview.qt-project.org/21060 improvements and test requested
 by
 Lars
 http://codereview.qt-project.org/21061 only rebase - Gerrit shows
 unrelated
 http://codereview.qt-project.org/21063 only rebase - Gerrit shows
 unrelated
 http://codereview.qt-project.org/21064 only rebase - Gerrit shows
 unrelated
 http://codereview.qt-project.org/21066 changes but Gerrit shows
 unrelated
 too
 http://codereview.qt-project.org/21067 only rebase - Gerrit shows
 unrelated
 http://codereview.qt-project.org/21068 only rebase - Gerrit shows
 unrelated
 http://codereview.qt-project.org/21751 new change
 
 --
 Thiago Macieira - thiago.macieira (AT) intel.com
   Software Architect - Intel Open Source Technology Center
  Intel Sweden AB - Registration Number: 556189-6027
  Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] Qt 4.8.1 release during week 11/2012

2012-03-20 Thread marius.storm-olsen

Please don't create the tags yet though. I've heard that there are a
couple of things that needs to be fixed first, though I have not received
an email on the issues yet.

-- 
.marius

On 3/20/12 9:20 AM, ext Sergio Ahumada sergio.ahum...@nokia.com wrote:

On 03/20/2012 09:08 AM, ext Turunen Tuukka wrote:

 Hi Girish,

 No, we have not yet gained these. Who can create them?

 The persons who should have the rights are:

 iikka.ekl...@digia.com
 akseli.salova...@digia.com
 janne.antt...@digia.com

 For the 4.8.1 we will just tag, as it was decided that we do 4.8.1
without
 a branch. Naturally having a branch is good, but it is possible to do
 without as well.

 The release is ready, and so are the installers. We need confirmation
from
 Nokia when they are ready to release. As the Qt Project does not have
 distribution server for installers available now, we need to use Nokia's
 servers (the same ones where all lgpl packages until 4.8.0 are). Digia's
 existing servers are used for Qt Commercial distribution, and most
likely
 can not take the load of all commercial and lgpl users rushing to get
the
 new version.

 Yours,


Hi,

I've created a Qt Release Team group in Gerrit and I've added those
people to the group. I think that's enough to create tags, not for
branches yet though.

Cheers,
-- 
Sergio Ahumada
___
Releasing mailing list
releas...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/releasing



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

Re: [Development] [Releasing] Qt 4.8.1 release during week 11/2012

2012-03-20 Thread marius.storm-olsen

On 3/20/12 11:56 AM, ext Turunen Tuukka tuukka.turu...@digia.com wrote:


On 20.3.2012 11.11, marius.storm-ol...@nokia.com
marius.storm-ol...@nokia.com wrote:

Please don't create the tags yet though. I've heard that there are a
couple of things that needs to be fixed first, though I have not received
an email on the issues yet.


If there is something critical, we can of course fix. But since 4.8.1 is
done without a branch, we can not easily pick any single items into the
source. We would by default need to take in all the contributions up until
the fix, which causes all items to be re-done and tested. As there is a
large amount of eagerly waited fixes already in 4.8.1 I would not like to
wait a couple of more weeks with it (as would be the case if we start over
with the testing).

The thing is, if there's issues that needs to be fixed coming from the
legal scan, we have no option, we need to fix them before we can
distribute the package.

The solution then _could_ be to apply changes to the normal 4.8 branch,
and then we can cherry-pick only those changes on top of the current SHA1
and tag that. (A tag can be a commit, alas, does _not_ have to be a SHA1
from any of the branches. So, it's fully possible.)

-- 
.marius

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

Re: [Development] The qtbase CI should run the qtdeclarative tests

2012-03-18 Thread marius.storm-olsen

While it's not normal to do this type of dependency lock for upwards 
dependencies, i think in this case we should indeed do the extra checking. Not 
just because QtDeclarative is such an important tech for Qt5, but also because 
it's a very good test case for QtBase.

The extra time used for checking both repos will give much greater stability as 
a whole.

Maybe the fast platforms can do the extra checking, while slow platforms still 
handle only QtBase? At least we will capture most compile issues?
(The CI rules might get very complicated though.)

Rohan/Sergio, what will be the turn-around increase if we always test 
Declarative together with QtBase?

Thanks!

--
Sent from my Nokia N9

On 3/16/12 17:15 Hansen Kent (Nokia-MP/Oslo) wrote:
Hi, Again the qtdeclarative CI has been blocked an entire day because of qtbase 
changes. 


It's great that the CI catches all these issues, but at the same time it's 
ridiculous how much time is spent suffering through failed qtdeclarative CI 
runs and fixing those failures up after the fact!


If the turn-around time will increase by one hour or whatever by also testing 
qtdeclarative as part of the qtbase CI runs, so what? The increased stability 
and confidence in the results should easily make it a net win. No longer will 
there be a need to wonder whether a failed qtdeclarative CI run was due to one 
of the actual staged changed, or a recent qtbase change, and dreading the 
aftermath that comes from that.


The current option of pinning the qtbase SHA1 used by qtdeclarative to some 
older, known good SHA1 _after_ a breaking qtbase change has gone through, is 
bad. BAD! Don't ask me to write a paper called Pinning of SHA1s considered 
harmful, because I will.


Pinning just masks the failure. C'mon, after first locating a good qtbase 
SHA1 and being able to commit your own changes again, wouldn't you ideally want 
to go on with your own work instead of spending the rest of the day chasing 
down some unknown change in qtbase, contacting the author (if possible), 
waiting for the fix/revert, and babysitting that through the CI? But someone 
certainly needs to fix it, and while that's ongoing, new changes are blissfully 
making their way into qtbase, which means new qtdeclarative failures can 
appear, and it gets progressively harder to get out of the mess. (Happened 
twice this week.)


Marking qtdeclarative tests as insignificant due to qtbase-introduced failures, 
just to get stuff through the CI again, is also a bit ho-humm. Who follows up 
that backlog of ignored tests?


Yes, there are some qtbase changes that require qtdeclarative to be adapted 
(AKA intentional breakages), and then you need to run the qtbase CI in 
isolation. But that should be the exception, not the rule. It's in those cases 
one should first pin the qtbase SHA1 in qtdeclarative before staging the qtbase 
change, and afterwards adapt qtdeclarative (with a change already prepared and 
reviewed) and unpin the qtbase SHA1 at once. Takes away all the surprise.


Hey, I know, we can just move qtdeclarative into qtbase. Bring back the 
-no-declarative configure option and we're golden.


With best wishes for the weekend,
Kent 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Playground - Command Line Parser experiment

2012-03-15 Thread marius.storm-olsen

On 15/03/2012 04:53, ext David Faure wrote:
 On Monday 12 March 2012 20:06:22 marius.storm-ol...@nokia.com wrote:
 Anyways, something to keep in mind when working on your
 implementation. It's a can of worms with a lot of bikeshedding ;)

 Yes, this has been said a few times already. However I don't think
 this is enough of an argument for not doing anything about this in Qt
 (I know for a fact that your email discouraged Laszlo of even
 trying).

 If the message, upfront, is you won't be able to get this into Qt,
 then a natural reaction is to just say OK, then I give up, we'll do
 something KDE- specific instead. But this goes against my main goal
 of removing the distinction between a KDE app and a Qt app as much as
 possible.

I'm sorry if it discouraged Laszlo from trying to embark on this 
project. Nowhere in my email did I say that it couldn't or shouldn't be 
done, nor that it wouldn't be accepted in Qt.

My arguments underlined why this task/project is _special_, and why I 
believe that it would fit better as a separate AddOn repo, than a 
feature branch to qtbase.

I think development and adoption would happen more quickly if the 
project has its own AddOn.

Also, with an AddOn it doesn't matter much what other people say. If you 
don't want it/agree with it etc, then you simply don't include it.


 I see no reason why command-line argument parsing can't be provided
 by Qt. It's not as complex as you say, all kde apps do fine with the
 features listed at http://api.kde.org/4.x-api/kdelibs-
 apidocs/kdecore/html/classKCmdLineOptions.html#ac3064e6ec33f92a4a6d17eb8ff766034

I'm not saying that it cannot be provided for Qt. I'm saying there are 
many opinions on how an argument parser should work, so do it in an 
Addon first. Then it doesn't matter so much if not everyone agrees. It 
might be harder if you don't get broad agreement when working on a 
feature branch of QtBase (say if Lars or Thiago say no), then you cannot 
merge and the work is in limbo.

And nothing says we cannot pull it from the Addon into QtBase at a later 
point in time.


 You're right, tar couldn't use this. But then again, tar is not a
 Qt application, and will probably never be. And for a new program,
 there's always the option of *choosing* a set of command-line options
 that is actually doable with the existing Qt class, rather than going
 for something as funky as tar xvf. Look at GNU getopt: same issue,
 it can't be used by tar. So what?

The applications I mentioned are bastards when it comes to 
commands/actions/options, and I mentioned them on purpose to facilitate 
discussion. They don't represent valid use-cases, but rather indicate 
the extremes. It's a balancing act though, to figure out which features 
to support, and which ones to ignore to capture the 90% without getting 
too complex.

For example:
* Do short options only accept single letter, or can they have more?
 -E for preprocessing in GCC, /E or /EP with MSVC
 -reverse for Qt apps

* Will 'single dash' long options be allowed?
 -traditional-cpp in gcc
 -style=foo for Qt apps

* Will short option clustering be allowed? What if short options support 
more than one letter?

* What if the clustering of some short options match another single 
short option, or a long option if single dash long options are allowed?

* Do you allow for turning on/off boolean values with preceeding +/-?
 MSVC uses trailing '-' to turn off options, like /GR- to
 turn off RTTI

* Do you use space, '=', ':' or nothing as a option/value separator?
 -ofilename
 -output filename
 -output:filename
 -output=filename

There's lots of nuances to evaluate. You could say lets just support 
getopt, but then you're likely falling into the unix-world-only trap. 
But I guess, so what? ;)

-- 
.marius

PS. To sum up, do it as an addon, not as a feature branch, and _not_ 
don't do it.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Playground - Command Line Parser experiment

2012-03-12 Thread marius.storm-olsen

On 08/03/2012 17:36, ext Laszlo Papp wrote:
 It is not a separate module, but class(es). The name for this
 experiment, in playground, would be something like Command Line
 Parser. According to the regulation: if nobody objects to this
 addition from the beginning, I need to get the support of one
 existing module maintainer in order to be able to experiment with
 this feature in playground.

Like Ossi said, normally this would just be a feature branch, due to 
their natural fitting into existing modules. However, this case is 
special. See below.


 Either way, please let me know your thoughts. Thank you in advance!

It has been a long tradition inside Trolltech, and later Qt Development 
Frameworks that all new employees come with a bright idea to implement a 
command-line parser. After all, the Qt framework doesn't come with any, 
so it must certainly somehow have been forgotten.

Not so. We probably have 10-12 command-line parsers developed throughout 
the years, but none of them have ever been included in the product. 
Mostly because either,

a) The parser is too trivial and doesn't handle the normal levels of 
complexity of command line arguments out there. (tar, find, zip, and 
standard Qt (built-in) arguments anyone?)

b) The parser is too complex, where it doesn't live up to the simplicity 
expected from Qt API and usage.

c) The parser only focuses on the standard for a single platform. 
(Linux users will not go for Windows style /? options, and Windows users 
won't accept --help Linux options, etc)

The problems with writing a parser like this is to make it general 
enough to support most of the Qt users, to justify it being part of the 
core set of modules. If it doesn't, it probably shouldn't be in QtBase, 
and as such should be a separate Addon, IMO.

Anyways, something to keep in mind when working on your implementation. 
It's a can of worms with *a lot* of bikeshedding ;)

Good luck!

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

Re: [Development] Demos, examples, docs etc for Alpha release

2012-03-12 Thread marius.storm-olsen

On 12/03/2012 18:10, ext Quim Gil wrote:
 Also, a basic question: where can someone find the actual list of
 Essential and Add-on modules that will be included in the Alpha? A
 Work-in-progress list is fine, now the only reference I have is a
 slide from last October-November.

The current release script generates a package (890MB tar = 251MB 
tar.gz), correlated with the categorization of modules at 
http://qt-project.org/wiki/Qt_5.0 and corrected with some recent 
discussions between Henry, Lars and Thiago, this list of modules:

Qt Essentials:
 qt3d
 qtcore
 qtdeclarative
 qtgui
 qtjsbackend
 qtlocation
 qtmultimedia
 qtnetwork
 qtsql
 qttestlib
 qtwebkit

Qt Add-ons:
 qlalr
 qtactiveqt
 qtconcurrent
 qtconnectivity
 qtdbus
 qtdoc
 qtdocgallery
 qtfeedback
 qtgraphicaleffects
 qtimageformats
 qtjsondb
 qtphonon
 qtpim
 qtplatformsupport
 qtprintsupport
 qtqa
 qtquick1
 qtrepotools
 qtscript
 qtscripttools
 qtsensors
 qtsvg
 qtsystems
 qttools
 qttranslations
 qtwayland
 qtwebkit-examples-and-demos
 qtwidgets
 qtxml
 qtxmlpatterns

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

Re: [Development] [Marketing] GSoC 2012

2012-03-09 Thread marius.storm-olsen

On 09/03/2012 10:07, ext STEFANI Mathieu wrote:
 The deadline is now in 7 hours (23:00 UTC)

 As a student perspective, I would really be enthusiast working on the Qt 
 Project, and
 I think it definitely should be sent for approval to the GSoC 2012.

 However, the project needs mentors. Nokia employees seem to have been removed
 from the mentors list, why ?

Unfortunately, after a thorough evaluation of the GSoC 2012 MOPA (Mentor 
Organization Participation Agreement), Nokia employees are not able to 
participate in this year GSoC. The details on the reasoning is 
unbeknownst to me. Sorry.

-- 
.marius


 Currently, the wiki lists two mentors, but we need more. Furthermore, if you 
 want
 the project to enter the GSoC, some paperwork needs to be done, and we have to
 hurry up.

 Com'on guys, the Qt project is a great project, and I'm sure many students 
 would
 love getting involved on it (including me) :)

 -Original Message-
 From: development-bounces+mathieu.stefani=supinfo@qt-project.org 
 [mailto:development-bounces+mathieu.stefani=supinfo@qt-project.org] On 
 Behalf Of Giuseppe D'Angelo
 Sent: jeudi 1 mars 2012 09:22
 To: daniel.molken...@nokia.com
 Cc: development@qt-project.org
 Subject: Re: [Development] [Marketing] GSoC 2012

 Hi,

 If you want to mentor a project or if you have a proposal to make, please
 sign up at http://wiki.qt-project.org/GSOC_Proposals.

 Although there hasn't been much discussion, I'm happy to see that some
 proposals are being made :-)

 Just for the records: some ancient proposals from some year ago are
 available here
 http://web.archive.org/web/20100606041700/http://groups.google.com/group/qt-gsoc/web/project-ideas

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

Re: [Development] On qbs use inside Qt

2012-02-17 Thread marius.storm-olsen

On 17/02/2012 05:41, ext Thiago Macieira wrote:
 On sexta-feira, 17 de fevereiro de 2012 09.19.20,
 eike.zil...@nokia.com wrote:
 wonderWhy would that mean to reject
 http://codereview.qt-project.org/16019 ?/wonder

 It just adds files that could be used for building Qt Creator with
 qbs, but it doesn't disrupt anybody's workflow as long as they use
 qmake. Which still is the only supported and required build system
 for Qt Creator. Any change that does not build with qmake will be
 rejected.

 You're opening the door for anyone to come in and supply their own
 buildsystem files for Qt Creator, before any decision on which one we
 want in the end is made.

 If the Creator team is fine with that, then go ahead.

 I don't want those changes in the modules I am watching for. I get
 enough emails from Gerrit as it is.

As Qt Creator is working towards integrating qbs into the product, I 
think it's only natural that the qbs files are added to the Qt Creator 
repository. Qt and Qt Creator are two separate products, and obviously 
can have separate policies.

Also, qbs is already capable of building Qt Creator, so adding the files 
make sense. It's not yet capable of compiling Qt, so adding those files 
obviously don't make sense yet.

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

Re: [Development] QML engine C++ class renaming

2012-02-17 Thread marius.storm-olsen

On 17/02/2012 07:27, ext Thiago Macieira wrote:
 On sexta-feira, 17 de fevereiro de 2012 13.20.09,
 marius.storm-ol...@nokia.com wrote:
 On 17/02/2012 05:39, ext Thiago Macieira wrote:
 On sexta-feira, 17 de fevereiro de 2012 01.47.13,

 andrew.den-ex...@nokia.com wrote:
 I'm not saying there won't be any maintenance burden, but it's
 not massively greater than a lot of other modules either.

 I'll take your word for it.

 What I'm still looking for is that someone comes out and says
 yeah, we'll handle that maintenance for the next year or two.

 Modules classified as done don't have to be rejected from the
 release. We have several modules classified as done.

 QtXml, QtScript and QtSvg have very little in terms of private API
 they use. QtDeclarative is quite different.

 I'm still looking for someone who will be responsible for that,
 however minimal it might sound to you.

I never said it sounded minimal.

What I mean is, if the QtDeclarative team wants QtQuick1 to remain in 
the release, they _can_ define it as done, which is not the same as 
maintained, or abandoned for that matter.

It means they will not maintain it, in the sense of fixing bugs etc, 
but would need to ensure that it keeps compiling for each release, so it 
can be used. If that level of commitment cannot be made, I agree, it 
shouldn't be in the release.

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

Re: [Development] On qbs use inside Qt

2012-02-16 Thread marius.storm-olsen

On 16/02/2012 05:24, ext Stephen Kelly wrote:
 On Thursday, February 16, 2012 12:19:10 Thiago Macieira wrote:
 If anyone wishes to start working on making Qt compile with their
 preferred

 buildsystem, they are welcome to do so -- in a branch.

 ... and presumably not in gerrit, but on github or any other git
 host?

If you want them merged back into master at a later point, the branches 
would need to be in codereview.qt-project.org, due to the CLA.

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

Re: [Development] On qbs use inside Qt

2012-02-16 Thread marius.storm-olsen

On 16/02/2012 06:35, ext Thiago Macieira wrote:
 What I mean is that the people developing qbs are free to do so and
 even try to compile qtbase or Qt Creator with it. I'd love to see
 them get qtbase up and running, including solving the bootstrapping
 problem.

We're not solving a bootstrapping issue. We're not shipping qbs with Qt. 
We expect you to have qbs, and just use it, just like make/jom (also 
based on Qt btw)/nmake/cmake/scons/waf/whatever.

Yes, I keep hearing about what about bootstrapping!, You can't have a 
build system based on Qt; 'cause then you can't build the build system 
before you have Qt, which again needs the build system! Aaaargh! *head 
explodes due to cyclic dependencies* etc.

We have working systems already, lets just use them :)

qbs can build qbs
qbs can build with cross-compilers
..I expect you can take it from there?

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

Re: [Development] Changing qreal to a float

2012-02-15 Thread marius.storm-olsen

On 15/02/2012 07:45, ext Thiago Macieira wrote:
 On quarta-feira, 15 de fevereiro de 2012 12.33.18, lars.kn...@nokia.com wrote:
 Just a small nitpick: You won't end up on the wrong side of the river. The
 earth has a diameter of around 4km. With 24 bits precision, you end up
 with a jitter of just above 2m. You might get wet feet though ;-)

 #define __FLT_EPSILON__ 1.1920928955078125e-7F

 Multiply that by 360 (degrees in a latitude) and we've got and error of 0.15.
 Multiply it by the circumference (not the diameter) at the equator of
 40,075,017 m and we have 4.77m.

 That's just one coordinate. The error accumulates with successive operations.

If it makes a difference:

- MySQL's spatial extension represents coordinates in double-percision 
(8 bytes).
 http://dev.mysql.com/doc/refman/5.0/en/gis-class-geometry.html

- SQLServer used to use 27bits in their calculations, giving less than 
10cm on a line between the equator and the North Pole (10,000km)., but 
they are now increasing that to 48bits, giving sub-millimeteric precision.
 
http://connect.microsoft.com/SQLServer/feedback/details/580254/spatial-operations-are-done-with-a-low-precision-causing-troubles-in-the-returned-data

- Who knows what Oracle does. Their documentation is confusing at best. 
Probably because they support a multitude of coordinate systems. Their 
recommendation is not to use tolerances lower than 5 cm though.
 
http://docs.oracle.com/cd/B28359_01/appdev.111/b28400/sdo_intro.htm#autoId9

:-)

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

Re: [Development] JIRA bug management: users can't close their 'assigned' bugs.

2012-02-14 Thread marius.storm-olsen

On 14/02/2012 04:13, ext Frederik Gladhorn wrote:
 I think this mail raises a good point.

 We are very protective of our bugs, maybe it's the time to reconsier jira
 rights now that we have the Qt Project in full swing :)

 I think it would be great if we could get a group of bug triagers started, for
 KDE for example that leads to fewer stale bugs and new contributors that
 discover they can fix bugs while triaging them.

 In order to enable that we would actually have to start giving jira rights to
 people. I don't think there is much reason to expect people would be mis-using
 these.

Please have a look at the
 Changes to the Jira roles and workflow
thread, which was started on 08.02.2012.

I guess many have missed that email, because discussions are much slower 
than I expected. But that mail discusses recommended changes to Jira. If 
you have opinions on that matter, please discuss it on that thread.

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

Re: [Development] Default enabling inbound flow control on sockets

On 02/13/2012 08:10 AM, ext shane.kea...@accenture.com wrote:
 Not sure. Is it a big problem? Or is it better to just continue as
 is, and let the applications that do have a problem set it to
 something reasonable to them instead?

 I'd probably suggest that we instead improve the output on that
 worst case failure to help devs fix the problems in their
 programs.

 $0.02

 Ben

 qWarning allocates memory, so once the worst case happens, we can't
 give any output (unless we first handle the exceptions inside
 Q*Socket) It would be possible to print a warning when buffering
 exceeds some threshold we consider to be unreasonably large. We can
 also improve the documentation (it's not bad, but doesn't mention
 flow control explicitly)

 https://bugreports.qt-project.org/browse/QTBUG-14464 seems to be
 explained by missing flow control causing out of memory errors under
 load.

Qt is not known for handling OOM cases, and we actually argue for the OS 
to handle it, and that the application (and its libraries) shouldn't 
have to think about memory not being available.
(Too many error conditions and OOM handling all over the place to bring 
any real benefit for it anyways.)

Here you are suggesting a behavior change to handle an OOM case, where 
the behavior will most likely cause valid applications to stop working, 
since they don't handle a (new and artificial) 64k in-buffer limit?

Maybe we should rather allocate a buffer for qWarning output, allowing 
us to properly report an error condition before the application aborts?

^shrug^ but I rather not have applications start failing at random due 
to a failure to have a new limit.

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

Re: [Development] Default enabling inbound flow control on sockets

On 02/13/2012 12:33 PM, ext marius.storm-ol...@nokia.com wrote:
 ^shrug^ but I rather not have applications start failing at random due
 to a failure to have a new limit.

..handle a new limit.

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

Re: [Development] Changes to the Jira roles and workflow

On 02/13/2012 01:27 PM, ext 
shane.kea...@accenture.commailto:shane.kea...@accenture.com wrote:

Maybe you're looking at a triage role, if the role is prioritizing and 
assigning of tasks among a team that is mostly funded by one company.

Another role we need in JIRA is contributor.
This is somebody who is not a reviewer, but can still be assigned tasks  
transition their assigned tasks through the normal workflow.
Ideally, anyone who has had a patch accepted should be given this level of 
access if they want it.*
For example, to work on bugs related to code they previously submitted.
Also, this covers most Nokia (or other organization) engineers who are not 
approvers.

The contributor role in Jira was part of the original recommendation:

Map old roles over to OG roles

The current suggestion is:

Reports - User
Developer - Contributor
Assignee - Contributor
QA - Approvers
RM - Maintainers - note, discussion over this

Note the Developer + Assignee - Contributor transition in the roles, 
meaning that the Contributor role can be assigned tasks.

--
.marius


I'm hoping abuse of JIRA privileges is rare, but it should also be easy to 
revoke them if needed.

*Some people will contribute a patch for a bug they found in their project that 
uses Qt, and we don't want to discourage this by giving unwanted responsibility.



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

Re: [Development] Importing sahumada: Can you import http://gitorious.org/qserialdevice/qserialdevice (the 2.0 branch) into playground/QtSerialPort

Given that the QSerialDevice developers have accepted the CLA for the project 
effective from start of the project, the project is now open for licencing both 
under LGPL and commercial license; just like any other module in Qt. AFAIK, 
though IANAL.

-- 
Sent from my Nokia N9

On 2/13/12 16:56 ext Angel Perles wrote:
Hi Denis,

I have a question about the license for QSerialDevice. In gitorious it 
appears as GPLv3.

I think it could be interesting to have a more permisive licensing 
option such as LGPL or BSD. This will allow to push forward this library 
compared with others such as QextSerialPort with not established license.

Others guys and me (users of QextSerialPort) are seeking for an 
appropiate library for collaborating.

Best regards,
Àngel


El 11/02/12 18:28, Denis Shienkov escribió:
 Hi all.

 I prepared for the first QtSerialPort review.
 But then I do not know what to do:
 Who will review my changes? Who will do the audit?
 Someone, please check the code, because I still have not figured much in the 
 features by:
 http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt

 Best regards,
 Denis

 09.02.2012, 23:46, marius.storm-ol...@nokia.com:
 On 09/02/2012 13:26, ext Denis Shienkov wrote:

   Hi Marius.

   I have a few more questions (or offers):

   1) Perhaps, instead of:
   ...
   and start pushing to refs/for/2.0 to the Gerrit repo.
   ...
   done refs/for/master? Because for the main branch is gerrit master,
   and not 2.0 (or am I misunderstanding something?).

 Sure, whatever you prefer. Gitorious' 2.0 branch was pushed to both 2.0
 and master, since Gerrit requires a 'master' branch. We didn't import
 the Gitorious master branch, since I think you only rebased the 2.0
 branch to avoid the commits without CLA signoff.

 How you proceed, with commits in the master or 2.0 branch is up to you
 as the maintainer.

   2) It may be worth in the current repository QSerialDevice Gitorious
   marked as deprecated (well, or something like that), and instead it
   create a new one with a new name (ex. QtSerialPort), etc. The reason
   is that QSerialDevice will not reflect the inner essence, after
   integration, and will mislead the majority of public users.

 Sure, I agree it's probably cleaner to do that. (Our internal sync
 script also infact requires the repositories to be named the same in
 Gerrit and in Gitorious.)

   3) Let us define - what the class name give, with prefix Qt, Q or no
   prefix? I looked at some of the projects Gerrit without CI (eg
   qtprocessmanager, qtjsonstream) and found that a all class names
   without the prefix. I also stick to this style?

 See
 http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#Using_the_module_name_in_application_code_and_documentation

   For Qt Add-On Modules, a C++ namespace is required to avoid class
   naming clashes with other modules in the public API. For the Qt
   Foo module the namespace would be QtFoo. Exception: in order to
   keep source compatibility with Qt 4, no namespace is required for
   former Qt 4 modules. When naming classes, the best practice is use
   simple non-prefixed class names within the C++ name space. Naming
   classes of add-ons like QMyClass is also OK.

   4) In the header of each source file, keep a reference to the
   original authors, like me, or mention only Nokia?

 Nokia did not develop the code, and must not be referenced as the
 author. Copyright remains with the author.

   5) How to make an example of the structure of the project is the
   addon for QtSerialPort (in order to make the image and likeness),
   from any Addon-project? Or maybe there is a specific example of a
   good where to get the project structure for addon?

 http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#The_structure_of_a_new_module_repository

 --
 .marius

 08.02.2012, 22:08, marius.storm-ol...@nokia.com:
 On 2/8/12 11:59 AM, ext Denis Shienkovscap...@yandex.ruwrote:

 Hi Marius.

 I do not understand this bit:
 --
 --
 For the other Qt repos we treat the Gitorious repo as public repo, so
 most people will clone from there. Then we regularly push from Gerrit to
 Gitorious to keep them in sync. However, we disable Merge Requests in
 Gitorious, since we want to force all contributions through the Gerrit
 system.
 --
 --

 ie I and other special/selected developers will commits/push to Gerrit,
 and then tested and approved by the pieces of code will be sent to
 Gitorious?

 Well, not more special than having a Jira/Gerrit account with an
 accepted CLA agreement :)

 For the Qt Essential modules we have a script which automatically pushes
 the latest changes to the Gitorious location. And we prefer most people to
 use those as the primary clone location, since it

Re: [Development] RFC: The Future of QDoc

2012-02-10 Thread marius.storm-olsen

On 10/02/2012 07:46, ext Oswald Buddenhagen wrote:
 On Fri, Feb 10, 2012 at 01:15:19PM +, ext
 casper.vandonde...@nokia.com wrote:
 does adding the documentation to the headers not make compilation
 slower?

 pretty much negligible. but: putting docs into headers causes many
 unnecessary recompiles due to the headers being included into many
 .cpp files.

Now *that's* a fair and important point, IMO.

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

Re: [Development] Changes to the Jira roles and workflow

On 09/02/2012 04:33, ext Thiago Macieira wrote:
 On Thursday, 9 de February de 2012 10.20.47, bradley.hug...@nokia.com
 wrote:
 There is call for discussion around default assignee – is it the
 module maintainer? Which tasks are up for grabs if everything new
 goes to the maintainer?
 Unassigned should be the default. When someone picks up the task,
 they should assign it to themselves. Anything else is misleading.

 Agreed. As a Maintainer, I really don't want tons of tasks assigned
 to me and in idle state. It would make my life difficult because I
 can't find the tasks I want to work on. And it would get people
 screaming at me for not looking at their tasks.

I think the argument against that is that Maintainers should know what 
goes on in their modules.

Assigning new tasks unassigned will not notify the maintainer about 
issues in the modules that have come up, and the maintainer will not by 
notified when someone takes a task and starts working on it.

(/me has no strong feelings either way, just highlighting the different 
view points)

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

Re: [Development] JIRA bug management: users can't close their 'assigned' bugs.

On 06/02/2012 03:04, ext Rick Stockton wrote:
 Hi everyone, I have a number of stale bugs which need to be closed.

 When bugs are Assigned, even to Earth Domain, the original reporter
 is unable to close them. SO, for the purpose of removing bad data from
 our DB, I'm requesting help with the following bugs. I'm the
 reporter/creator of in all cases:

 https://bugreports.qt-project.org/browse/QTBUG-19793 (some work on mouse
 buttons in 4.x, which we put into 5.0 instead. Change to CLOSED/REJECTED)

Done by Shane on 06.

 https://bugreports.qt-project.org/browse/QTBUG-22642 (Qt5 mouse buttons
 in XLIB and XCB, Resolved. Fixed in Qt 5.0.0)

This is currently in Verified state, which will changed to Closed 
once released.
(See 
https://bugreports.qt-project.org/plugins/servlet/workflow/thumbnail/getThumbnail?workflowName=Qt%20Bug%20TrackingstepId=7width=fullheight=full
 
for workflow visualization)

 https://bugreports.qt-project.org/browse/QTBUG-22642 (bad idea, should
 be CLOSED/REJECTED. Note: Current assignee is Oliver Goffart, but the
 bad idea was mine ;)

The QTBUG number on this one is the same as above.


 https://bugreports.qt-project.org/browse/QTBUG-22338 (change to
 CLOSED/REJECTED).

Done by Shane on 06.

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

Re: [Development] Changes to the Jira roles and workflow

On 09/02/2012 05:41, Goddard Michael (Nokia-MP/Brisbane) wrote:
 Assigning new tasks unassigned will not notify the maintainer
 about issues in the modules that have come up, and the maintainer
 will not by notified when someone takes a task and starts working
 on it.

 Surely this is something that JIRA could support?  Watching a
 component or similar?  (also can Gerrit do this too?)

Not by default. But there is a 3rdparty pluging to allow adding Watcher 
on components:
 
https://studio.plugins.atlassian.com/wiki/display/JCWP/JIRA+Component+Watcher+Plugin

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

Re: [Development] RFC: The Future of QDoc

On 09/02/2012 10:16, ext Hugo Parente Lima wrote:
 On Thursday 09 February 2012 14:30:20 Matt Williams wrote:
 On 9 February 2012 14:15, Keno Fischerke...@stanford.edu  wrote:
 Implement a new C++ parser

 Any plans on using Clang a parser? The wiki page mentioned Qt
 Creator's AST, but it seems like Qt Creator will be moving away
 from its own implementation in the future, so I think that might
 be something to consider. Also, since the necessary work on Clang
 is being done for Qt Creator anyway (I'm thinking of things like
 signals/slots) it might be worth to keep qdoc in mind when
 working on Clang for Qt Creator. Any thoughts?

 There's also the KDevelop C++ parser. It already supports many
 C++11 features and run very fast. As far as I'm aware it doesn't
 depends on any KDE libraries (Qt only) and already has the ability
 to extract Doxygen-style comments. I don't know if there are any
 KDevelop people on this list who can comment further?

 The KDevelop parser is based on a version of Roberto's parser, last
 time I checked the sources it used few KDE utility classes like some
 smart pointers, but I see no difference in using the KDevelop or
 QtCreator parser as both are more or less the same.

QtCreators parser is a much later version of Roberto's parser, and I 
expect that it parses much faster than the KDevelop one. I'm sure 
QtCreators parser can be upgraded to also handle those new C++11 
features, and since we need to maintain it in Creator anyways, I don't 
see why it should use another parser than a one we already have intimate 
knowledge about?


 I nice ability QDoc would have is to support other output formats
 like XML or JSON, the old QDoc had this feature but it was deprecated
 and not documented at all.

 The PySide documentation is generated using the XML output of qdoc3,
 but the current version of qdoc3 doesn't support XML output anymore.

Oops. Casper, Martin any details about this, and why XML output was 
dropped? Hugo, any reason why PySide cannot use the normal output? 
Integration with other help tools?

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

Re: [Development] RFC: The Future of QDoc

On 09/02/2012 10:33, ext Manuel Nickschas wrote:
 On Thursday 09 February 2012 15:36:09 ext Olivier Goffart wrote:
 I am working on QDoc part-time and we have been discussing some
 changes that we would like to implement to make qdoc more future
 proof. I have created a short list of the things we would like to
 do: http://developer.qt.nokia.com/wiki/Category:Tools::QDoc

 It comes down to: Implement a new C++ parser, make qdoc more
 modular and be able to handle the Qt modules better with qdoc.

 I am wondering if anybody has any ideas about what he/she would
 like qdoc to do, or how qdoc should evolve?

 Have you thought about using doxygen or any similar tool?

 Or at least make QDoc be able to parse doxygen-style comments (which
 also means it should not ignore headers, as documenting public API
 in a header file is much more common at least outside Qt than doing
 that in the implementation file...)

Qt puts the documentation in the sources since it's closer to the actual 
code, and thus more likely to be maintained at the same time as the code 
is changed. If the documentation is in another location, it's far more 
likely to be forgotten when updates/changes to behavior is done in the 
source code.


 I'd be happy to see Qt use or at least support more standard
 solutions over homegrown ones. Since that failed for localization,
 maybe we can at least get it for documentation :)

I think there are a few issues here:

1) Only Dimitri touches Doxygen code, and it doesn't look like 
contributions go in (at least not under the authors name). This means 
that the functionality to support Qt's extensive documentation needs to 
be implemented by Dimitri alone. Thus, Nokia's team cannot be working on 
enhancing Doxygen to get it up to par with the current output from qdoc.

2) From what I've seen of attempts to set up Doxygen, none of them have 
proven to create output quality on par with what qdoc produces. This is 
obviously due to qdoc only having 1 mission, to produce the 
documentation output that the Qt documentation team think is optimal, 
while Doxygen is a tool for a multitude of outputs. However, is does 
leave a quality gap between the documentation we want verses the 
documentation we can get out of the tool. A gap the documentation team 
would want to close, which again points to 1).

3) Transforming the documentation in Qt sources to only use current 
Doxygen syntax is VERY unlikely, at least in the Qt 5.0 time-frame.

All of the above is my personal opinion of course, and *NOT* 
representative of the Qt Documentation team, qdoc team or any other team 
in Nokia. I like Doxygen, and have used it on several occasions for my 
own personal projects; but I still feel that the output of qdoc looks 
better.

(And no, I *don't* use the inheritance charts. I think they are 
pointless, and not nice to look at. If you need them, something is 
obviously too complex in your design.)

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

Re: [Development] RFC: The Future of QDoc

On 09/02/2012 12:13, ext marius.storm-ol...@nokia.com wrote:
 On 09/02/2012 10:33, ext Manuel Nickschas wrote:
 I'd be happy to see Qt use or at least support more standard
 solutions over homegrown ones. Since that failed for localization,
 maybe we can at least get it for documentation :)

 I think there are a few issues here:

 1) Only Dimitri touches Doxygen code, and it doesn't look like
 contributions go in (at least not under the authors name). This means
 that the functionality to support Qt's extensive documentation needs to
 be implemented by Dimitri alone. Thus, Nokia's team cannot be working on
 enhancing Doxygen to get it up to par with the current output from qdoc.

Btw, all purely based on 
http://doxygen.svn.sourceforge.net/viewvc/doxygen/trunk/ and committers 
I can see in the revision logs. I have not been in contact with Dimitri 
on the matter, but I do see a call to action in 
http://old.nabble.com/Doxygen-support-for-QML---td32658060.html. So 
perhaps a wrong assumption on my part.

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

Re: [Development] Importing sahumada: Can you import http://gitorious.org/qserialdevice/qserialdevice (the 2.0 branch) into playground/QtSerialPort