date:20120802

QtGui should not depend on platform support. If it does it's a bug.

Cheers,
Lars

On Aug 2, 2012, at 11:47 AM, ext 
song.7@nokia.commailto:song.7@nokia.com 
song.7@nokia.commailto:song.7@nokia.com wrote:

Hi,

From the Qt build system, does any file decide the QtGui depending on the 
PlatformSupport lib ?

Any information is appreciated ;)

Thanks,
Song
___
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] Color Profile support on Qt

2012-08-02 Thread alexandros.dermenakis

I reverted the patch as requested. The change id is : 
Ic4a420d6ad0995810ed61d31edd28e7b603cca5e

I also created a clone of qtbase repository on gitorious. the link for that is 
https://qt.gitorious.org/~alexandrosdermenakis/qt/qtbase-colorprofiles

Alex

From: development-bounces+alexandros.dermenakis=nokia@qt-project.org 
[development-bounces+alexandros.dermenakis=nokia@qt-project.org] on behalf 
of Sletta Gunnar (Nokia-MP/Oslo)
Sent: Thursday, August 02, 2012 11:16 AM
To: Tvete Paul (Nokia-MP/Oslo)
Cc: development@qt-project.org
Subject: Re: [Development] Color Profile support on Qt

On Aug 2, 2012, at 10:58 AM, ext Paul Olav Tvete wrote:

 On Thursday 02 August 2012 10:31:59 ext Olivier Goffart wrote:
 If that's only a documentation problem, we can workaround that with some
 macro  magic.

 Very good point. For some reason I thought we would have to hack on qdoc 
 itself,
 but creative use of \fn and \internal should be enough.

#ifdef QDOC

can also be used to hide functions from the documentation.


 Should that even go in the constructor? Maybe QImage::setColorProfile.

 The problem with that is that it is not clear from the name whether it 
 converts
 the image data to the new profile, or just overrides the profile. Also,
 overriding the profile is really just needed for specifying the profile when
 constructing the image.

 On the other side, if we add it now, and realize this should not be pointer,
 or should not be even in QImage. Then it is too late to change.

 Those are good points. Of course we could still add new constructors, and use
 qdoc magic to hide the pointer argument in that case :)

 The only other point I can see is saving 6 extra exported symbols in Qt 5.1, 
 and
 I realize that that's not a very strong argument.

 TL;DR: I will not disagree if the consensus is to revert the change.

I say revert. We don't bind ourselves to potential future API.


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

[Development] Qt Essentials

Hi everybody,

as one of the first consequences of the situation in Brisbane, I'd like to do 
some changes to our list of essential modules. You can see the current list at 
http://qt-project.org/wiki/Qt-Essentials-Modules . 

I intend to move both Qt 3D and Qt Location out of the essentials list and make 
them add-ons for now. They are fully usable as-is today, but with the situation 
down-under I am currently unsure how well we can maintain and develop them 
going forward. If things turn out well, we can still move them into the 
Essentials list in a 5.1 or 5.x release.

In addition, I will also remove Qt JS Backend from the list of essentials. 
While the library is a requirement for the QtQml module, it doesn't provide any 
public API and as such is a pure implementation detail on which I currently 
don't want to give any long term guarantees.

Cheers,
Lars

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

Re: [Development] state of Qt's Australia office

I talked a bit with the team in Brisbane this morning. Obviously the mood there 
is somewhat grim.

Talking for me, it's really sad to see this happen. There are a lot of bright 
engineers working in that office and I have been working with many of them for 
quite some time now. I really hope that everybody will find a new job soon, and 
that most of the people will actually stay connected to the Qt ecosystem and Qt 
project in some form or another.

For Qt as a product, it is now really important to remember that we do have the 
Qt project and a live and active community around it. This might make some 
things a bit more difficult in the short term, but we will find ways to deal 
with this and to continue to move Qt forward.

I'll try to keep this list posted and informed as good as I can.

Lars

On Aug 2, 2012, at 10:38 AM, ext 
martin.jo...@nokia.commailto:martin.jo...@nokia.com 
martin.jo...@nokia.commailto:martin.jo...@nokia.com wrote:

I'm sure QML/QtQuick will live on - only Brisbane is affected.

I'm not sure if/how we, the Brisbane developers, will continue to contribute, 
however.

Br,
Martin.



From: ext qtnext [qtn...@gmail.commailto:qtn...@gmail.com]
Sent: Thursday, 2 August 2012 4:46 PM
To: Jones Martin (Nokia-MP/Brisbane)
Cc: development@qt-project.orgmailto:development@qt-project.org
Subject: Re: [Development] state of Qt's Australia office



Le jeudi 2 août 2012, martin.jo...@nokia.commailto:martin.jo...@nokia.com a 
écrit :

We just found out yesterday.  We haven’t had a chance to discuss continuation 
of QML/QtQuick, but we have passionate developers here who will continue 
contributing if possible.
Qtquick was the main point of qt5...
If your company depends on QML/QtQuick, then now is the time to discuss a 
mutually beneficial arrangement with us :)

I have invested a lot of time in qt5/qml trusting in what nokia said before... 
But i have a very small company so the only way to help that i can do is to pay 
for a commercial licence if there is a trustable company that continue qt


Martin.

From: 
development-bounces+martin.jones=nokia@qt-project.orgUrlBlockedError.aspx 
[mailto:development-bounces+martin.jonesUrlBlockedError.aspx=nokia@qt-project.orgUrlBlockedError.aspx]
 On Behalf Of ext qtnext
Sent: Wednesday, August 01, 2012 10:48 PM
To: development@qt-project.orgUrlBlockedError.aspx
Subject: Re: [Development] state of Qt's Australia office

QtDeclarative  ? Does it mean that nobody in Qt team will work on qml (Quick2) ?

2012/8/1 Atlant Schmidt aschm...@dekaresearch.comUrlBlockedError.aspx
Folks:

  (more)

  Let's hope that the remaining Trolls land in a
  more-friendly fjord!

   Atlant

-Original Message-
From: 
development-bounces+aschmidt=dekaresearch@qt-project.orgUrlBlockedError.aspx
 
[mailto:development-bounces+aschmidtUrlBlockedError.aspx=dekaresearch@qt-project.orgUrlBlockedError.aspx]
 On Behalf Of Atlant Schmidt
Sent: Wednesday, August 01, 2012 8:30 AM
To: 'C. Bergström'; development@qt-project.orgUrlBlockedError.aspx
Subject: Re: [Development] state of Qt's Australia office

Folks:

  I wasn't going to mention this but since the topic has come up...

  A source I consider reliable has whispered in my ear that
  in the aftermath of Nokia recently shooting Meltemi dead*,
  Sebastian Nyström (the Nokia Senior VP in charge of Qt) has
  been given explicit direction to sell-off the Qt asset.

  Nokia's great experiment in frameworks (mobile and otherwise)
  is over.

 Atlant


* After having previously shot Symbian and Maemo/MeeGo dead


This e-mail and the information, including any attachments, it contains are 
intended to be a confidential communication only to the person or entity to 
whom it is addressed and may contain information that is privileged. If the 
reader of this message is not the intended recipient, you are hereby notified 
that any dissemination, distribution or copying of this communication is 
strictly prohibited. If you have received this communication in error, please 
immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.
___
Development mailing list
Development@qt-project.orgUrlBlockedError.aspx
http://lists.qt-project.org/mailman/listinfo/development

 
Clickhttps://www.mailcontrol.com/sr/ufrRwuioVx3TndxI!oX7UqcUCtlg0TD8RfkI3WfseUnsO8bgDK+guU4ZxjFLV1IJtna8Ms8t0Hr1lqOECv!Swg==
  to report this email as spam.

This e-mail and the information, including any attachments, it contains are 
intended to be a confidential communication only to the person or entity to 
whom it is addressed and may contain information that is privileged. If the 
reader of this message is not the intended recipient, you are hereby notified 
that any dissemination, distribution or copying of this communication is 
strictly prohibited.

Re: [Development] state of Qt's Australia office

I talked a bit with the team in Brisbane this morning. Obviously the mood there 
is somewhat grim.

Talking for me, it's really sad to see this happen. There are a lot of bright 
engineers working in that office and I have been working with many of them for 
quite some time now. I really hope that everybody will find a new job soon, and 
that most of the people will actually stay connected to the Qt ecosystem and Qt 
project in some form or another.

For Qt as a product, it is now really important to remember that we do have the 
Qt project and a live and active community around it. This might make some 
things a bit more difficult in the short term, but we will find ways to deal 
with this and to continue to move Qt forward.

I'll try to keep this list posted and informed as good as I can.

Lars

On Aug 2, 2012, at 10:38 AM, ext 
martin.jo...@nokia.commailto:martin.jo...@nokia.com 
martin.jo...@nokia.commailto:martin.jo...@nokia.com wrote:

I'm sure QML/QtQuick will live on - only Brisbane is affected.

I'm not sure if/how we, the Brisbane developers, will continue to contribute, 
however.

Br,
Martin.



From: ext qtnext [qtn...@gmail.commailto:qtn...@gmail.com]
Sent: Thursday, 2 August 2012 4:46 PM
To: Jones Martin (Nokia-MP/Brisbane)
Cc: development@qt-project.orgmailto:development@qt-project.org
Subject: Re: [Development] state of Qt's Australia office



Le jeudi 2 août 2012, martin.jo...@nokia.commailto:martin.jo...@nokia.com a 
écrit :

We just found out yesterday.  We haven’t had a chance to discuss continuation 
of QML/QtQuick, but we have passionate developers here who will continue 
contributing if possible.
Qtquick was the main point of qt5...
If your company depends on QML/QtQuick, then now is the time to discuss a 
mutually beneficial arrangement with us :)

I have invested a lot of time in qt5/qml trusting in what nokia said before... 
But i have a very small company so the only way to help that i can do is to pay 
for a commercial licence if there is a trustable company that continue qt


Martin.

From: 
development-bounces+martin.jones=nokia@qt-project.orgUrlBlockedError.aspx 
[mailto:development-bounces+martin.jonesUrlBlockedError.aspx=nokia@qt-project.orgUrlBlockedError.aspx]
 On Behalf Of ext qtnext
Sent: Wednesday, August 01, 2012 10:48 PM
To: development@qt-project.orgUrlBlockedError.aspx
Subject: Re: [Development] state of Qt's Australia office

QtDeclarative  ? Does it mean that nobody in Qt team will work on qml (Quick2) ?

2012/8/1 Atlant Schmidt aschm...@dekaresearch.comUrlBlockedError.aspx
Folks:

  (more)

  Let's hope that the remaining Trolls land in a
  more-friendly fjord!

   Atlant

-Original Message-
From: 
development-bounces+aschmidt=dekaresearch@qt-project.orgUrlBlockedError.aspx
 
[mailto:development-bounces+aschmidtUrlBlockedError.aspx=dekaresearch@qt-project.orgUrlBlockedError.aspx]
 On Behalf Of Atlant Schmidt
Sent: Wednesday, August 01, 2012 8:30 AM
To: 'C. Bergström'; development@qt-project.orgUrlBlockedError.aspx
Subject: Re: [Development] state of Qt's Australia office

Folks:

  I wasn't going to mention this but since the topic has come up...

  A source I consider reliable has whispered in my ear that
  in the aftermath of Nokia recently shooting Meltemi dead*,
  Sebastian Nyström (the Nokia Senior VP in charge of Qt) has
  been given explicit direction to sell-off the Qt asset.

  Nokia's great experiment in frameworks (mobile and otherwise)
  is over.

 Atlant


* After having previously shot Symbian and Maemo/MeeGo dead


This e-mail and the information, including any attachments, it contains are 
intended to be a confidential communication only to the person or entity to 
whom it is addressed and may contain information that is privileged. If the 
reader of this message is not the intended recipient, you are hereby notified 
that any dissemination, distribution or copying of this communication is 
strictly prohibited. If you have received this communication in error, please 
immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.
___
Development mailing list
Development@qt-project.orgUrlBlockedError.aspx
http://lists.qt-project.org/mailman/listinfo/development

 
Clickhttps://www.mailcontrol.com/sr/ufrRwuioVx3TndxI!oX7UqcUCtlg0TD8RfkI3WfseUnsO8bgDK+guU4ZxjFLV1IJtna8Ms8t0Hr1lqOECv!Swg==
  to report this email as spam.

This e-mail and the information, including any attachments, it contains are 
intended to be a confidential communication only to the person or entity to 
whom it is addressed and may contain information that is privileged. If the 
reader of this message is not the intended recipient, you are hereby notified 
that any dissemination, distribution or copying of this communication is 
strictly prohibited.

Re: [Development] state of Qt's Australia office

Hi,

On 2 August 2012 15:02,  lars.kn...@nokia.com wrote:
 For Qt as a product, it is now really important to remember that we do have
 the Qt project and a live and active community around it. This might make
 some things a bit more difficult in the short term, but we will find ways to
 deal with this and to continue to move Qt forward.

I think that until Nokia keeps controling Qt we won't move much.

I explain better what I mean. Nobody can stop us to keep contributing
to Qt and developing Qt.
We can use in any opensource project we want. But what about companies
and commercial products?!

People still need to buy a license from Digia.

Is Digia allowed to license Qt for mobile development? I'm just asking...

-- 
Andrea Grandi - Nokia-FNDC/Tampere / Qt Ambassador
Ubuntu Member: https://launchpad.net/~andreagrandi
website: http://www.andreagrandi.it
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] state of Qt's Australia office

2012-08-02 Thread Dmytro Poplavskiy

On Thu, Aug 2, 2012 at 10:09 PM, a.gra...@gmail.com a.gra...@gmail.com wrote:
 Hi,

 On 2 August 2012 15:02,  lars.kn...@nokia.com wrote:
 For Qt as a product, it is now really important to remember that we do have
 the Qt project and a live and active community around it. This might make
 some things a bit more difficult in the short term, but we will find ways to
 deal with this and to continue to move Qt forward.

 I think that until Nokia keeps controling Qt we won't move much.

 I explain better what I mean. Nobody can stop us to keep contributing
 to Qt and developing Qt.
 We can use in any opensource project we want. But what about companies
 and commercial products?!

It's possible to use LGPL Qt in the commercial products,
it's only necessary to open changes done to the Qt itself if any.

Usually it's better to submit the changes upstream,
it reduces the maintenance burden quite a bit.

Regards
Dmytro.


 People still need to buy a license from Digia.

 Is Digia allowed to license Qt for mobile development? I'm just asking...

 --
 Andrea Grandi - Nokia-FNDC/Tampere / Qt Ambassador
 Ubuntu Member: https://launchpad.net/~andreagrandi
 website: http://www.andreagrandi.it
 ___
 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] Can we have id's in dynamically generated elements for the next QML?

2012-08-02 Thread Charley Bay

Thanks, Alan -- very rich email that helps me think about
declarative-model-instance-handling.

Alan spaketh:
snip,  What is QML declarative-best-practice for models?

 Reusable components/delegates, where data propagates in one direction, is
 the
 best-practices pattern that obviates this need. snip,


 For list delegates, this is managed through the model. Individual delegates
 should only depend on the model for state and interaction. If that's not
 enough you probably need a custom view, because views are supposed to
 handle
 the majority of the UI logic of the data.[1]


snip,

 [1] A future research topic that I'm keen on, one of these days, is to
 better
 componetize the Model/View split. QML has very simplified models, but the
 Views
 are immense and in some ways restrictive. Sometime people just use a
 Repeater/Column/Flickable for flexibility, but that's not viable for large
 data
 sets. There's clearly a better split which would allow for more of the
 View to
 be written in QML, like the UI logic, while not forcing such large
 tradeoffs.
 After the successful completion of that research project, suggesting that
 you
 create your own view would just mean another QML file in your project.


I'm very interested in that future-research-topic (we can discuss offline
in the future when you have time), IMHO some work here is needed.

For example, consider a large/rich model of a file-system where you want
rich view(s) of *all* dirs-and-files.  Example visualizers might be like:

http://lifehacker.com/219058/geek-to-live--visualize-your-hard-drive-usage

The dynamic/animated nature of QML seems like a QML implementation
(with-or-without-C++) could be gorgeous/rich/useful.

If your efforts provided specific insight and guidance to applications like
that, it would be ever-so-super-spiffy!

;-)

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

Re: [Development] state of Qt's Australia office

On 2 August 2012 15:15, Dmytro Poplavskiy dmytro.poplavs...@gmail.com wrote:
 It's possible to use LGPL Qt in the commercial products,
 it's only necessary to open changes done to the Qt itself if any.

I will try to be more specific with my question :)

What kind of license is using RIM for their Cascades UI? It's based on
Qt/QML, but as fra as I know they are submitting patches upstream
(please correct me if I'm wrong).
What kind of license is using Jolla, for example?

What I'm trying to understand is if there are any possible
restrictions or problems using Qt for a mobile products both if Nokia
is keeping Qt alive, or if they just abandon it or if they sell it or
whatever

 Usually it's better to submit the changes upstream,
 it reduces the maintenance burden quite a bit.

I totally agree with you. I would not want to adapt my code everytime
that Qt is changed upstream.

Best regards,

-- 
Andrea Grandi - Nokia-FNDC/Tampere / Qt Ambassador
Ubuntu Member: https://launchpad.net/~andreagrandi
website: http://www.andreagrandi.it
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Essentials

On quinta-feira, 2 de agosto de 2012 12.02.45, lars.kn...@nokia.com wrote:
 Hi everybody,

 as one of the first consequences of the situation in Brisbane, I'd like to
 do some changes to our list of essential modules. You can see the current
 list at http://qt-project.org/wiki/Qt-Essentials-Modules .

 I intend to move both Qt 3D and Qt Location out of the essentials list and
 make them add-ons for now. They are fully usable as-is today, but with the
 situation down-under I am currently unsure how well we can maintain and
 develop them going forward. If things turn out well, we can still move them
 into the Essentials list in a 5.1 or 5.x release.

 In addition, I will also remove Qt JS Backend from the list of essentials.
 While the library is a requirement for the QtQml module, it doesn't provide
 any public API and as such is a pure implementation detail on which I
 currently don't want to give any long term guarantees.

I agree on the JS Backend case.

For 3D and Location, I have a feeling it's a little premature, but I can't
blame you for it. Especially in Location's case, with lots of plugins to be
kept in working order, it might be tricky in the current situation.

Qt3D might be quite mature, actually, since it's been around for longer and
has no platform-specific dependencies other than OpenGL.

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


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] qsrand(31415) int qt3d

2012-08-02 Thread Mülner , Helmut

I already sent this to the qt3d mailing list, but nobody reacts on this list 
(maybe due to the Bisbane situation):

qglsection.cpp contains the following lines in the method 
QGLSectionPrivate::mapVertex:

static bool seeded = false;
if (!seeded)
qsrand(31415);

This makes the random number generator not very random!
The tank example uses the usual qsrand(time(0)) which is superseded by 
qsrand(31415).
Therefore the colors are always the same, when one starts the programs.

I think these lines can and should be removed.

I have no(t yet) access to gerrit, so could someone push this change?
Thank you
--
Helmut Mülner
DIGITAL - Institute of Information and Communication Technologies

JOANNEUM RESEARCH Forschungsgesellschaft mbH
Steyrergasse 17, 8010 Graz, AUSTRIA

phone:  +43-316-876-2612
general fax: +43-316-876-1191
web:http://www.joanneum.at/digital
e-mail: helmut.mül...@joanneum.atmailto:helmut.mül...@joanneum.at

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

Re: [Development] state of Qt's Australia office

2012-08-02 Thread Peter Rullmann

On Wed, 01 Aug 2012 17:02:14 +0200, C. Bergström  
cbergst...@pathscale.com wrote:
 For the companies reading this (RIM) - step up and post a job to get
 this thread back on track.

We do have a job open for a skilled Qt and QML platform developer.
It is in Germany though:
https://barco.taleo.net/careersection/2/jobdetail.ftl?job=72703
Send me an email if you are interested or have questions.

Regards,
Peter
-- 
Peter Rullmann | RD Manager Software | Barco Healthcare |  
+49(0)68199199152
Barco Control Rooms GmbH, Niederlassung Saarbrücken
Registered at 76229 Karlsruhe, Amtsgericht Mannheim
HRB 102241, Management: Stephen Leyland, Lutz Nehrhoff von Holderberg

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

Re: [Development] Qt Essentials

2012-08-02 Thread Yves Bailly

Greetings all,

first of all let me express a deep and warm feeling for all those writing
so nice code since so long and rewarded in such manner...

Le 02/08/2012 14:26, Thiago Macieira a écrit :
 [...]

 Qt3D might be quite mature, actually, since it's been around for longer and
 has no platform-specific dependencies other than OpenGL.

For what is worthes, here we're hardly waiting for Qt3D, delaying an internal
long-term project which would have been quite similar. That said we're not the
ones doing the job on Qt3D, so any decision you make will be seen as simply 
right.

Kindly,

-- 
  /- Yves Bailly - Software developper  -\
  \- Sescoi RD  - http://www.sescoi.fr -/
The possible is done. The impossible is being done. For miracles,
thanks to allow a little delay.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Essentials

2012-08-02 Thread Charley Bay

Agree with Thiago:

For 3D and Location, I have a feeling it's a little premature, but I can't
 blame you for it. Especially in Location's case, with lots of plugins to be
 kept in working order, it might be tricky in the current situation.

 Qt3D might be quite mature, actually, since it's been around for longer and
 has no platform-specific dependencies other than OpenGL.


I can't blame you for it, and can adapt to the changes.  IMHO they did
really good work with 3D and it provides high QML value if we can establish
a solid understanding of its support going forward.  (I really liked 3D
being in Qt essentials.)

Lars' reasoning on the JS Backend seems solid.

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

Re: [Development] state of Qt's Australia office

2012-08-02 Thread Rafael Roquetto

On Thu, Aug 02, 2012 at 03:23:06PM +0300, a.gra...@gmail.com wrote:
 On 2 August 2012 15:15, Dmytro Poplavskiy dmytro.poplavs...@gmail.com wrote:
  It's possible to use LGPL Qt in the commercial products,
  it's only necessary to open changes done to the Qt itself if any.
 
 I will try to be more specific with my question :)
 
 What kind of license is using RIM for their Cascades UI? It's based on
 Qt/QML, but as fra as I know they are submitting patches upstream
 (please correct me if I'm wrong).
RIM is using Qt open source (LGPL).

 What kind of license is using Jolla, for example?
 
 What I'm trying to understand is if there are any possible
 restrictions or problems using Qt for a mobile products both if Nokia
 is keeping Qt alive, or if they just abandon it or if they sell it or
 whatever
To be really honest, generally I wouldn't think so, as Qt is LGPL. Of course,
if Nokia pulls the plug, we are likely to have lesser contributions happening
to Qt, which I believe will certainly impact the project - but imho not to the
point of killing it.

-- 
Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions



smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] state of Qt's Australia office

Hi,

On 2 August 2012 15:40, Rafael Roquetto rafael.roque...@kdab.com wrote:
 RIM is using Qt open source (LGPL).

so happy for this :) I'm happy because:

1) RIM is able to continue using Qt without any restriction
2) RIM must patch upstream any improvement and Qt will benefit from this

 To be really honest, generally I wouldn't think so, as Qt is LGPL. Of course,
 if Nokia pulls the plug, we are likely to have lesser contributions happening
 to Qt, which I believe will certainly impact the project - but imho not to the
 point of killing it.

well, let's see what will happen.

-- 
Andrea Grandi - Nokia-FNDC/Tampere / Qt Ambassador
Ubuntu Member: https://launchpad.net/~andreagrandi
website: http://www.andreagrandi.it
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Essentials

2012-08-02 Thread qtnext

same feeling about QT3D : we can't compare QT3D Feature to for example
ogre3D, but for simple things I use Qt3D since two years and it works fine
for all my needs ... without bugs


2012/8/2 Charley Bay charleyb...@gmail.com

 Agree with Thiago:

 For 3D and Location, I have a feeling it's a little premature, but I can't
 blame you for it. Especially in Location's case, with lots of plugins to
 be
 kept in working order, it might be tricky in the current situation.

 Qt3D might be quite mature, actually, since it's been around for longer
 and
 has no platform-specific dependencies other than OpenGL.


 I can't blame you for it, and can adapt to the changes.  IMHO they did
 really good work with 3D and it provides high QML value if we can establish
 a solid understanding of its support going forward.  (I really liked 3D
 being in Qt essentials.)

 Lars' reasoning on the JS Backend seems solid.

 --charley


 ___
 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] Proposal: adding Q_DECL_NOEXCEPT to many methods

I'd like to propose we add Q_DECL_NOEXCEPT to many methods in our API.

We already took the decision to turn exception off in most modules, except 
QtCore and where exceptions were used, like QtXmlPatterns. This is the next 
step.

The Q_DECL_NOEXCEPT macro expands to noexcept, which is a new C++11 keyword. 
It is equivalent to noexcept(true), also new in C++11, and it means the method 
declares that it does not throw any exceptions.

The benefits are:
 - callers do not need to emit exception handlers around such functions
 - the compiler may assume that no exception unexpectedly happens inside that 
function body, foregoing exception handlers inside it as well.

The first behaviour is present with a C++03's empty exception specification 
(i.e., throw() in the function declaration), but the second behaviour is new 
in C++11. In the previous standard, the compiler was forced to emit exception 
code for the case when exceptions did happen even when they shouldn't. For 
that reason, the C++03 exception specification is deprecated.

The drawback is that it makes the code ugly.

The macro expands to nothing in C++98 mode. That means code using the API so 
marked and compiling in C++98 mode will simply not gain the benefits of the 
keyword, but should see no side effects.

The presence of the keyword does not affect binary compatibility. With the 
Itanium C++ ABI, it's not present in the mangling. MSVC2010 does not supoprt 
it yet, so I cannot verify what it does. However, since C++11 support cannot 
be turned on or off on it, the keyword will be enabled or it won't depending on 
the compiler version, which means that binary compatibility is irrelevant. But 
if it does encode it in the mangling, we will not be able to add the keyword 
to methods in 5.1 or later.


The question that remains is: what methods shall we add this to? We can add it 
to any method for which we can *prove* that it will never throw, which are:
 - leaf functions
 - functions calling only C functions or other noexcept functions

Outside of QtCore, I propose we add it only to methods that are called often 
and frequently. In QtCore, I propose we add it to most tool methods that are 
provably noexcept. For example, the qHash functions, QMutex, our memory 
allocation routines (the throwing is in inline code), etc.

PS: to be clear: new throws.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] state of Qt's Australia office

On quinta-feira, 2 de agosto de 2012 15.23.06, a.gra...@gmail.com wrote:
 On 2 August 2012 15:15, Dmytro Poplavskiy dmytro.poplavs...@gmail.com
wrote:
  It's possible to use LGPL Qt in the commercial products,
  it's only necessary to open changes done to the Qt itself if any.

 I will try to be more specific with my question :)

 What kind of license is using RIM for their Cascades UI? It's based on
 Qt/QML, but as fra as I know they are submitting patches upstream
 (please correct me if I'm wrong).

LGPL.

 What kind of license is using Jolla, for example?

LGPL.

 What I'm trying to understand is if there are any possible
 restrictions or problems using Qt for a mobile products both if Nokia
 is keeping Qt alive, or if they just abandon it or if they sell it or
 whatever

No, there aren't. Not from Qt's perspective, anyway.

There's only a problem if the user / customer does not accept code under the
LGPL. There are many companies that are like that, including entire industry
sectors.

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


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qsrand(31415) int qt3d

2012-08-02 Thread Mülner , Helmut

 *   Done:  Qthttps://bugreports.qt-project.org/browse/QTBUG/ 
QTBUG-26744https://bugreports.qt-project.org/browse/QTBUG-26744
Best regards
Helmut

Von: mitch.cur...@nokia.com [mailto:mitch.cur...@nokia.com]
Gesendet: Donnerstag, 02. August 2012 14:46
An: Mülner, Helmut
Betreff: RE: qsrand(31415) int qt3d

Hi Helmut.

You should create a bug report in Jira if you haven't already: 
https://bugreports.qt-project.org

Cheers.

From: 
development-bounces+mitch.curtis=nokia@qt-project.orgmailto:development-bounces+mitch.curtis=nokia@qt-project.org
 [development-bounces+mitch.curtis=nokia@qt-project.org] on behalf of ext 
Mülner, Helmut [helmut.muel...@joanneum.at]
Sent: 02 August 2012 14:33
To: development@qt-project.orgmailto:development@qt-project.org
Subject: [Development] qsrand(31415) int qt3d
I already sent this to the qt3d mailing list, but nobody reacts on this list 
(maybe due to the Bisbane situation):

qglsection.cpp contains the following lines in the method 
QGLSectionPrivate::mapVertex:

static bool seeded = false;
if (!seeded)
qsrand(31415);

This makes the random number generator not very random!
The tank example uses the usual qsrand(time(0)) which is superseded by 
qsrand(31415).
Therefore the colors are always the same, when one starts the programs.

I think these lines can and should be removed.

I have no(t yet) access to gerrit, so could someone push this change?
Thank you
--
Helmut Mülner
DIGITAL - Institute of Information and Communication Technologies

JOANNEUM RESEARCH Forschungsgesellschaft mbH
Steyrergasse 17, 8010 Graz, AUSTRIA

phone:  +43-316-876-2612
general fax: +43-316-876-1191
web:http://www.joanneum.at/digital
e-mail: helmut.mül...@joanneum.atmailto:helmut.mül...@joanneum.at

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

Re: [Development] state of Qt's Australia office

Hi,

On 2 August 2012 15:36, Peter Rullmann peter.rullm...@barco.com wrote:
 On Wed, 01 Aug 2012 17:02:14 +0200, C. Bergström
 cbergst...@pathscale.com wrote:
 For the companies reading this (RIM) - step up and post a job to get
 this thread back on track.

 We do have a job open for a skilled Qt and QML platform developer.
 It is in Germany though:
 https://barco.taleo.net/careersection/2/jobdetail.ftl?job=72703
 Send me an email if you are interested or have questions.

You have good knowledge of VoIP, A/V code and kernel drivers. ---
damn I don't have this :(

-- 
Andrea Grandi - Nokia-FNDC/Tampere / Qt Ambassador
Ubuntu Member: https://launchpad.net/~andreagrandi
website: http://www.andreagrandi.it
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] state of Qt's Australia office

On quinta-feira, 2 de agosto de 2012 15.48.19, a.gra...@gmail.com wrote:
 2) RIM must patch upstream any improvement and Qt will benefit from this

I'm not sure if you meant upstream in the way that I understand it. So let's
be clear:

Any user of LGPL must make their modifications available to anyone who received
the binary code, under the LGPL.

They do not have to make the modifications public in a website on the Internet.
There are other forms.

They do not have to make them available to someone who did not receive the
binary forms.

They do not have to upstream them. That is, they don't have to submit them to
the original project and go through the process of getting it approved.

They should, but they don't *have* to.
--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Essentials

On quinta-feira, 2 de agosto de 2012 14.39.02, Yves Bailly wrote:
 For what is worthes, here we're hardly waiting for Qt3D, delaying an
 internal long-term project which would have been quite similar. That said
 we're not the ones doing the job on Qt3D, so any decision you make will be
 seen as simply right.

This decision does not impact you then.

The Qt3D module is there and will be released either way.

The question is only whether it is part of the Essentials package.
--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

I'd say go ahead. Since adding it shouldn't change the ABI/name mangling, we 
can introduce this gradually anyway.

Cheers,
Lars

On Aug 2, 2012, at 2:50 PM, ext Thiago Macieira thi...@kde.org
 wrote:

 I'd like to propose we add Q_DECL_NOEXCEPT to many methods in our API.
 
 We already took the decision to turn exception off in most modules, except 
 QtCore and where exceptions were used, like QtXmlPatterns. This is the next 
 step.
 
 The Q_DECL_NOEXCEPT macro expands to noexcept, which is a new C++11 keyword. 
 It is equivalent to noexcept(true), also new in C++11, and it means the 
 method 
 declares that it does not throw any exceptions.
 
 The benefits are:
 - callers do not need to emit exception handlers around such functions
 - the compiler may assume that no exception unexpectedly happens inside that 
 function body, foregoing exception handlers inside it as well.
 
 The first behaviour is present with a C++03's empty exception specification 
 (i.e., throw() in the function declaration), but the second behaviour is new 
 in C++11. In the previous standard, the compiler was forced to emit exception 
 code for the case when exceptions did happen even when they shouldn't. For 
 that reason, the C++03 exception specification is deprecated.
 
 The drawback is that it makes the code ugly.
 
 The macro expands to nothing in C++98 mode. That means code using the API so 
 marked and compiling in C++98 mode will simply not gain the benefits of the 
 keyword, but should see no side effects.
 
 The presence of the keyword does not affect binary compatibility. With the 
 Itanium C++ ABI, it's not present in the mangling. MSVC2010 does not supoprt 
 it yet, so I cannot verify what it does. However, since C++11 support cannot 
 be turned on or off on it, the keyword will be enabled or it won't depending 
 on 
 the compiler version, which means that binary compatibility is irrelevant. 
 But 
 if it does encode it in the mangling, we will not be able to add the keyword 
 to methods in 5.1 or later.
 
 
 The question that remains is: what methods shall we add this to? We can add 
 it 
 to any method for which we can *prove* that it will never throw, which are:
 - leaf functions
 - functions calling only C functions or other noexcept functions
 
 Outside of QtCore, I propose we add it only to methods that are called often 
 and frequently. In QtCore, I propose we add it to most tool methods that are 
 provably noexcept. For example, the qHash functions, QMutex, our memory 
 allocation routines (the throwing is in inline code), etc.
 
 PS: to be clear: new throws.
 
 -- 
 Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
 ___
 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] state of Qt's Australia office

On 2 August 2012 15:56, Thiago Macieira thiago.macie...@intel.com wrote:
 On quinta-feira, 2 de agosto de 2012 15.48.19, a.gra...@gmail.com wrote:
 2) RIM must patch upstream any improvement and Qt will benefit from this

 I'm not sure if you meant upstream in the way that I understand it. So let's
 be clear:

 Any user of LGPL must make their modifications available to anyone who 
 received
 the binary code, under the LGPL.

 They do not have to make the modifications public in a website on the 
 Internet.
 There are other forms.

 They do not have to make them available to someone who did not receive the
 binary forms.

 They do not have to upstream them. That is, they don't have to submit them to
 the original project and go through the process of getting it approved.

 They should, but they don't *have* to.

thanks for the clarification.

Best regards,

-- 
Andrea Grandi - Nokia-FNDC/Tampere / Qt Ambassador
Ubuntu Member: https://launchpad.net/~andreagrandi
website: http://www.andreagrandi.it
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

2012-08-02 Thread Charley Bay

Thiago spaketh:

 I'd like to propose we add Q_DECL_NOEXCEPT to many methods in our API.

 We already took the decision to turn exception off in most modules, except
 QtCore and where exceptions were used, like QtXmlPatterns. This is the next
 step.

 The Q_DECL_NOEXCEPT macro expands to noexcept, which is a new C++11
 keyword.
 It is equivalent to noexcept(true), also new in C++11, and it means the
 method
 declares that it does not throw any exceptions.

 The benefits are:
  - callers do not need to emit exception handlers around such functions
  - the compiler may assume that no exception unexpectedly happens inside
 that
 function body, foregoing exception handlers inside it as well.

 The first behaviour is present with a C++03's empty exception specification
 (i.e., throw() in the function declaration), but the second behaviour is
 new
 in C++11. In the previous standard, the compiler was forced to emit
 exception
 code for the case when exceptions did happen even when they shouldn't. For
 that reason, the C++03 exception specification is deprecated.

 The drawback is that it makes the code ugly.

 The macro expands to nothing in C++98 mode. That means code using the API
 so
 marked and compiling in C++98 mode will simply not gain the benefits of the
 keyword, but should see no side effects.

 The presence of the keyword does not affect binary compatibility. With the
 Itanium C++ ABI, it's not present in the mangling. MSVC2010 does not
 supoprt
 it yet, so I cannot verify what it does. However, since C++11 support
 cannot
 be turned on or off on it, the keyword will be enabled or it won't
 depending on
 the compiler version, which means that binary compatibility is irrelevant.
 But
 if it does encode it in the mangling, we will not be able to add the
 keyword
 to methods in 5.1 or later.


Totally agree, support Q_DECL_NOEXCEPT being added to many methods in the
API.

I've seen many developers confuse exception-handling with
normal-error-handling, and think it would be best to establish clarity for
those operations that do not throw (and which logically should never throw).

This is consistent with the C++11 intent of increased type safety, and we
should use it, IMHO.  The benefits seem compelling:

(a) It better documents the design/implementation details
(b) It may lead to more efficient compiled-binary

I concede Thiago's identified drawback:

(c) It makes the code ugly

...however, it adds-the-caveat that the code ugliness is the same as
saying it better documents the design/implementation detail.  Since this is
a cross-platform reusable library and users rely upon the Qt docs anyway, I
don't think that's much of a penalty (if any).


 The question that remains is: what methods shall we add this to? We can
 add it
 to any method for which we can *prove* that it will never throw, which are:
  - leaf functions
  - functions calling only C functions or other noexcept functions

 Outside of QtCore, I propose we add it only to methods that are called
 often
 and frequently. In QtCore, I propose we add it to most tool methods that
 are
 provably noexcept. For example, the qHash functions, QMutex, our memory
 allocation routines (the throwing is in inline code), etc.

 PS: to be clear: new throws.


I'd vote to add-it-everywhere-possible, starting with those Thiago
identified.  IMHO it should be good practice for developers to
add-this-to-their-API-review-checklist to use the Q_DECL_NOEXCEPT
everywhere possible as they grow/maintain their APIs.

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

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

On quinta-feira, 2 de agosto de 2012 13.00.22, lars.kn...@nokia.com wrote:
 I'd say go ahead. Since adding it shouldn't change the ABI/name mangling, we
 can introduce this gradually anyway.

By the way, let's be conservative instead of doing it throughout.

Once added, the noexcept keyword cannot be removed. That breaks behaviour 
compatibility, even if binary compatibility is retained. That is, noexcept 
becomes part of our API.

That means adding noexcept to a method means we tie our hands in that method 
to never throw -- most often, never fail. If the method can never fail, it's 
usually a good candidate.

For example, in when I was just now adding it to qHash for QDateTime, I 
realised it does complex operations. Right now, none of those operations 
allocate memory, but it's actually very close to doing that. QDateTime has a d 
pointer and the hash function does some manipulation of the data. If I add it 
now, it means it cannot allocate memory, ever, in Qt 5. For that reason, I'm 
not sure I can do it: what if the implementation for QDateTime when timezones 
are taken into account needs to new?

The same applies to QMutex::lock: I'm not sure if I should add it. I want to. 
But what if we write a std::mutex implementation next year? That one can 
throw. I'm going to add, though, on the assumption that we'd translate 
std::mutex's exceptions to error codes.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

2012-08-02 Thread Marc Mutz

Hi Thiago,

On Thursday August 2 2012, Thiago Macieira wrote:
 I'd like to propose we add Q_DECL_NOEXCEPT to many methods in our API.

+1 from me, too.

[Though it doesn't seem to help with the problem that move constructors can't 
be inline if the class uses smart pointers. It still wants to call the dtor 
of the smart pointer. Might be just GCC not correctly implementing it, though 
(code language only - whatever that means).]

Need to be careful with templates. Can't use add the unrestricted noexcept 
there, need to use noexcept(noexcept(expr)), which is even uglier :)

Re: ugliness: I expect people will become familiar with this sooner than 
later. The C++11 std library is _full_ of noexcept tags.

Thanks,
Marc

-- 
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
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] Proposal: adding Q_DECL_NOEXCEPT to many methods

On quinta-feira, 2 de agosto de 2012 16.02.43, Marc Mutz wrote:
 Need to be careful with templates. Can't use add the unrestricted noexcept
 there, need to use noexcept(noexcept(expr)), which is even uglier

templatetypename T inline uint qHash(const T t, uint seed)
Q_DECL_NOEXCEPT_EXPR(noexcept(qHash(t)))
{ return (qHash(t) ^ seed); }

template typename T1, typename T2 inline uint qHash(const QPairT1, T2
key, uint seed = 0)
Q_DECL_NOEXCEPT_EXPR(noexcept(qHash(key.first, seed)) 
noexcept(qHash(key.second, seed)))
{
...
}

By the way, I'm running into an issue which I'm not entirely sure whether it's
a design issue. Imagine this case:

class Object
{
void f();
void g() noexcept(same noexcept status as f);
};

That is, I want to declare g to be as noexcept as its sibling function f. How?
All of these options fail:

noexcept(noexcept(f))
 - evaluates to true
noexcept(noexcept(Object::f))
 - error: invalid use of non-static member function ‘void Object::f()'
noexcept(noexcept(f()))
 - error: cannot call member function ‘void Object::f()’ without object
noexcept(noexcept(this-f()))
 - error: invalid use of ‘this’ at top level
noexcept(noexcept(Object().f()))
 - error: invalid use of incomplete type ‘struct Object’

Any suggestions?

My actual use-case is of a function declared in a base-class: I want
QMutex::lock() to be noexcept if QBasicMutex::lockInternal() is noexcept. In
that particular case, it works like this:

class QMutex : public QBasicMutex
{
static QBasicMutex *dummyBasicMutex() noexcept;
public:
void lock() noexcept(noexcept(dummyBasicMutex()-lockInternal()));
};

But it's ugly.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Can we have id's in dynamically generated elements for the next QML?

2012-08-02 Thread Mark

On Thu, Aug 2, 2012 at 4:29 AM, Alan Alpert alan.alp...@nokia.com wrote:
 On Wed, 1 Aug 2012 12:59:08 ext Charley Bay wrote:
  Mark spaketh:
  Sadly, QML 1 doesn't have id in dynamically generated id. That is a
  real big pain if you want to drag/drop something since then you
  need... an id! Right now i'm trying to fight against a lot of issues
  that wouldn't even be there if i simply had an ID. You can read more
  about that in this blog post:
 
  http://kdeblog.mageprojects.com/2012/08/01/what-will-qml-calendar-have-pro
  gress-update-qml-issue/
 
  I'm also curious to know why the decision was ever made to have
  dynamically generated elements exist without id?
 
  Is there any possibility that QML 2 (or QML 2.1 or whatever comes
  after 2) is going to have ID's for generated elements?

 This is an interesting thing that I'm still trying to grok (the
 direction-forward is not obvious to me yet, and I'm not sure what the
 Trolls have discussed on IRC).

 I know it's been discussed (a little), and that I'm not sure I'm about to
 add much.

 IMHO the issue is this declarative-approach, which IMHO is quite new as a
 paradigm.   The QML components/items themselves are independent-actors.
  They don't use layouts *explicitly* in the parent/child relationship, and
 shouldn't (but yes, layouts can be implemented to visually place
 collections of items, and that is legitimate).  While imperative
 organization is possible, it seems it should be discouraged as
 not-best-practice.

 I'm not-yet sure whether IDs are part of that topic:

 *- I *know* instance-IDs are needed for imperative.

 *- I *don't* know if instance-IDs are needed for declarative.

 I think you've almost got it. The thing you're missing is that that in QML,
 ids aren't for instances. Declarative languages do not follow such a strict
 instance mapping as imperative logic (where you need to keep track of every
 individual item - declarative languages do that for you in their own crazy
 ways ;) ).

 For example, if you have the following QML you might think you have an ID to
 an instance: Rectangle { id: rect; Rectangle{ id: rect2; width: rect.width }}.
 But if you place that inside Button.qml, you have one instance of 'rect' for
 every Button{} you use in other files. Much of the power from QML
 componentization is that you don't have to track the instances here yourself -
 write one Button which works within its own file, with the ids in that file, 
 and
 the engine takes care of multiple instances for you.

 It's almost amusing that QML is so successful in hiding the complexities of
 these multiple instances that people don't even realize it's happening :P .

I'm not laughing :p but you're right, it is very powerful yet simple.

 (This is my internal speculation/mapping, I'm just trying to
 understand/grok the new paradigm to where best-practices become obvious
 to me.)

 For example, in the design/problem you describe, the following design
 option *might* be reasonable without IDs (and I concede many other design
 options exist if we *do* have IDs):

 *- The MyCalendarEntry (QML component, no GUI real estate) has a
 DateTimeSpan property which implies where it is on a calendar.

 *- A MyCalendarItem (QML item, with GUI real estate) parents (or
 references) a SINGLE MyCalendarEntry to represent that
 MyCalendarEntry.  (Conceivably it would be 1:1, but it seems reasonable
 to have many MyCalendarItem GUI-things represent the same
 MyCalendarEntry instance if there were many views of that one entry
 in different calendar-rendering-scenarios.)

 *- Each MyCalendarItem (QML GUI item) is an independant-actor which
 finds-its-place upon a parent MyCalendarDisplay QML GUI item.  The
 parent MyCalendarDisplay has its own layout that physically arranges
 its children, which occupy their own real-estate-needs (based on their
 internal MyDateTimeSpan property).  (For example, perhaps the
 calendar-display is a MyCalendarDay or MyCalendarWeek or
 MyCalendarMonth GUI-item, and there would be different layouts for each
 of those instances.)

 *- This works without-instance-IDs because creating a MyCalendarEntry
 would *automatically* trigger creation of a MyCalendarItem, which is
 *automatically* parented by a MyCalendarDisplay, and which physically
 places the items with Z-order.  The drag/drop manipulation would directly
 manipulate the DateTimeSpan in the MyCalendarEntry, through the
 handles on the MyCalendarItem.

 Of course, another design option would be for the MyCalendarEntry QML
 component to have a C++ back-end-object with a unique ID, which could be
 used for a universal ID from within QML.

 The first design option is effectively leveraging the componentization 
 abilities
 of QML. The second one is leveraging the C++ integration that makes all things
 possible if you're having trouble doing it in QML. They are both such great
 aspects of QML that I feel I shouldn't judge either one as a better choice ;).

 I dunno.  I'm about to embark on a

Re: [Development] state of Qt's Australia office

2012-08-02 Thread Andreas Holzammer

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 02.08.2012 14:56, schrieb Thiago Macieira:
 On quinta-feira, 2 de agosto de 2012 15.48.19, a.gra...@gmail.com
 wrote:
 2) RIM must patch upstream any improvement and Qt will benefit
 from this
 
 I'm not sure if you meant upstream in the way that I understand
 it. So let's be clear:
 
 Any user of LGPL must make their modifications available to anyone
 who received the binary code, under the LGPL.
 
 They do not have to make the modifications public in a website on
 the Internet. There are other forms.
 
 They do not have to make them available to someone who did not
 receive the binary forms.
 
 They do not have to upstream them. That is, they don't have to
 submit them to the original project and go through the process of
 getting it approved.
 
 They should, but they don't *have* to.
 

As one can see at Thiago's statistics site you will see that there are
RIM commits going upstream, they are marked there as QNX. See
http://www.macieira.org/blog/qt-stats/


- -- 
Andreas Holzammer | andreas.holzam...@kdab.com | Software Engineer
KDAB (Deutschland) GmbHCo KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQGpjJAAoJEJw7+fLx1vsLHjkH/2Z9MuVIIpBt6+3AV+vIWK3t
Iouu6MDD7FbMCvPpg/8TFkAaorzNgjNdXamsOxq8+JU5YSIs+bvsV3UM0wYLzRMf
21myDyeU9+wr8+jO161pOtv8gg1y3WVjsMjZH2JlPN6axAPJ5Scw2hlgXWQqH9FY
Vvh4WZFFDHJOB3zD8UsZbTvzToIa2AewOQ7vQoht3aFjUgNTRcwsIT7Q4FZsNk9D
EHIJ/5TOKvjoQibGslAHO8b7GfIkC0+DfaP1TZ4uy5zYukSgI8mf3LB4osBH+Xve
9kpV4c+NahDJUYgzzOuhexOshLBtEhIE5SYL3jZ6Ois5gB98V5dlmZmx5ehvcUA=
=hKCj
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Kryptografische Unterschrift
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Can we have id's in dynamically generated elements for the next QML?

2012-08-02 Thread Luís Gabriel Lima


 But i still don't fully understand how to make a component draggable
 when it's being created dynamically through a Repeater.. Don't you
 just need an id for that to work?


You can use the delegate id to do the dragging.
Take a look in this [1] example, maybe it fits for your case.

[1] -
http://quickgit.kde.org/index.php?p=kde-workspace.gita=blobh=6d445510fc7b466b0d6a912b20179d296626414ehb=551e443f7b3d598971d4c29eb297a7168a10d337f=plasma%2Fdesktop%2Fapplets%2Fpager%2Fpackage%2Fcontents%2Fui%2Fmain.qml



Cheers,
-- 
Luís Gabriel
OpenBossa - INdT
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

2012-08-02 Thread Konrad Rosenbaum

Hi,

On Thursday 02 August 2012 15:27:03 Thiago Macieira wrote:
 For example, in when I was just now adding it to qHash for QDateTime, I
 realised it does complex operations. Right now, none of those operations
 allocate memory, but it's actually very close to doing that. QDateTime has
 a d pointer and the hash function does some manipulation of the data. If I
 add it now, it means it cannot allocate memory, ever, in Qt 5. For that
 reason, I'm not sure I can do it: what if the implementation for QDateTime
 when timezones are taken into account needs to new?

Where is qHash(QDateTime) defined? It doesn't seem to be where I expected it 
(qhash.* or qdatetime.*).

Anyway, Timezones can do rather complex calculations that may require memory-
allocations, but only when the QDateTime actually does calculations:
* add or subtract some time to/from the QDateTime (addSecs, addMSecs)
* convert to a different time zone (toUtc, toLocalTime, toTimeZone(x))
* convert to or from time_t

Any of those operations needs a search of the time zone for the offset valid 
at the time to be converted, if we are lucky the offset is already in memory, 
if not we need to retrieve it from a file, or worse to calculate it from a 
POSIX-style rule (and then cache it for later). When converting to another 
zone things get worse.

Depending on the implementation that will end up in Qt the actual lookup for 
which time zone is being used may have side effects too.



Konrad


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

On quinta-feira, 2 de agosto de 2012 17.55.54, Konrad Rosenbaum wrote:
 Hi,

 On Thursday 02 August 2012 15:27:03 Thiago Macieira wrote:
  For example, in when I was just now adding it to qHash for QDateTime, I
  realised it does complex operations. Right now, none of those operations
  allocate memory, but it's actually very close to doing that. QDateTime has
  a d pointer and the hash function does some manipulation of the data. If I
  add it now, it means it cannot allocate memory, ever, in Qt 5. For that
  reason, I'm not sure I can do it: what if the implementation for QDateTime
  when timezones are taken into account needs to new?

 Where is qHash(QDateTime) defined? It doesn't seem to be where I expected it
 (qhash.* or qdatetime.*).

qdatetime.{h,cpp}

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


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

2012-08-02 Thread marius.storm-olsen

On 02/08/2012 07:50, ext Thiago Macieira wrote:
 The macro expands to nothing in C++98 mode. That means code using the
 API so marked and compiling in C++98 mode will simply not gain the
 benefits of the keyword, but should see no side effects.

 The presence of the keyword does not affect binary compatibility.
 With the Itanium C++ ABI, it's not present in the mangling. MSVC2010
 does not supoprt it yet, so I cannot verify what it does. However,
 since C++11 support cannot be turned on or off on it, the keyword
 will be enabled or it won't depending on the compiler version, which
 means that binary compatibility is irrelevant. But if it does encode
 it in the mangling, we will not be able to add the keyword to methods
 in 5.1 or later.

MSVC2012 doesn't support it (yet) either. However, MSVC compilers since 
2003 support the almost equivalent throw()/throw(...)/throw(type) 
exception specification.

So, perhaps we can identify the cases where they are similar and use 
that with MSVC until proper noexcept()/noexcept(type) support is provided?

See http://msdn.microsoft.com/en-us/library/wfa0edys(v=vs.100).aspx for 
more details.

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

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

On quinta-feira, 2 de agosto de 2012 17.15.26, marius.storm-ol...@nokia.com 
wrote:
 So, perhaps we can identify the cases where they are similar and use 
 that with MSVC until proper noexcept()/noexcept(type) support is provided?

Yes. I can identify where they are similar: nowhere.

If you add it, the function with the throw() specification will *add* code to 
check all exceptions. That's why throw() is deprecated.

Don't use it.
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

2012-08-02 Thread marius.storm-olsen

On 02/08/2012 12:19, ext Thiago Macieira wrote:
 On quinta-feira, 2 de agosto de 2012 17.15.26, marius.storm-ol...@nokia.com
 wrote:
 So, perhaps we can identify the cases where they are similar and use
 that with MSVC until proper noexcept()/noexcept(type) support is provided?

 Yes. I can identify where they are similar: nowhere.

 If you add it, the function with the throw() specification will *add* code to
 check all exceptions. That's why throw() is deprecated.

Huh? The documentation explicitly says
void MyFunction(int i) throw();
tells the compiler that the function does not throw any exceptions. It 
is the equivalent to using __declspec(nothrow).

So, i.o.w. throw() == __declspec(nothrow), which in turn means

the compiler can eliminate the mechanics of tracking the lifetime of 
certain unwindable objects in such a function, and significantly reduce 
the code size.

So no, throw() will effectively remove all checking for exceptions.

Using throw(...) *will* add code to check all exceptions, but that's 
not what we were talking about.

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

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

2012-08-02 Thread marius.storm-olsen

On 02/08/2012 12:32, ext marius.storm-ol...@nokia.com wrote:
 On 02/08/2012 12:19, ext Thiago Macieira wrote:
 On quinta-feira, 2 de agosto de 2012 17.15.26, marius.storm-ol...@nokia.com
 wrote:
 So, perhaps we can identify the cases where they are similar and use
 that with MSVC until proper noexcept()/noexcept(type) support is provided?

 Yes. I can identify where they are similar: nowhere.
...
 So, i.o.w. throw() == __declspec(nothrow), which in turn means
...
 So no, throw() will effectively remove all checking for exceptions.

I see that we cannot use throw(type) though, since MSVC simply turns 
that into throw(...), which is not what you want.

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

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

On quinta-feira, 2 de agosto de 2012 17.32.36, marius.storm-ol...@nokia.com
wrote:
 the compiler can eliminate the mechanics of tracking the lifetime of
 certain unwindable objects in such a function, and significantly reduce
 the code size.

That's in the caller.

The problem is in the callee. The function that got the throw() decoration
gets more code to verify that it is not leaking any exceptions.

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


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

2012-08-02 Thread Konrad Rosenbaum

On Thursday 02 August 2012, Thiago Macieira wrote:
 On quinta-feira, 2 de agosto de 2012 17.55.54, Konrad Rosenbaum wrote:
  Where is qHash(QDateTime) defined? It doesn't seem to be where I
  expected it (qhash.* or qdatetime.*).
 
 qdatetime.{h,cpp}

Ok, found it - had the wrong branch checked out for some odd reason. This 
has a high likelyhood of causing allocations if time zones, calenders or 
anything fancy is active: it causes time zone calculations, which 
potentially cause allocations.


Konrad


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

On quinta-feira, 2 de agosto de 2012 19.25.31, marius.storm-ol...@nokia.com
wrote:
 Anyways, I see that LLVM/libc++
 (http://llvm.org/svn/llvm-project/libcxx/trunk/include/__config) defines
 it like this:
#if (__has_feature(cxx_noexcept))
#  define _NOEXCEPT noexcept
#  define _NOEXCEPT_(x) noexcept(x)
#else
#  define _NOEXCEPT throw()
#  define _NOEXCEPT_(x)
#endif
 so, they do what I suggested, except they use 'noexcept' instead of
 'noexcept(true)'. (Shouldn't really matter, just that the latter is more
 clear, IMO.)

This is GCC:

#ifndef _GLIBCXX_NOTHROW
# ifndef __cplusplus
#  define _GLIBCXX_NOTHROW __attribute__((__nothrow__))
# endif
#endif

#ifndef _GLIBCXX_NOEXCEPT
# ifdef __GXX_EXPERIMENTAL_CXX0X__
#  define _GLIBCXX_NOEXCEPT noexcept
#  define _GLIBCXX_USE_NOEXCEPT noexcept
#  define _GLIBCXX_THROW(_EXC)
# else
#  define _GLIBCXX_NOEXCEPT
#  define _GLIBCXX_USE_NOEXCEPT throw()
#  define _GLIBCXX_THROW(_EXC) throw(_EXC)
# endif
#endif

#ifndef _GLIBCXX_NOTHROW
# define _GLIBCXX_NOTHROW _GLIBCXX_USE_NOEXCEPT
#endif

There are three macros: NOEXCEPT, USE_NOEXCEPT and NOTHROW:

$ grep -r _GLIBCXX_NOTHROW *~x86_64-redhat-linux | wc -l
13
$ grep -r _GLIBCXX_NOEXCEPT *~x86_64-redhat-linux | wc -l
607
$ grep -r _GLIBCXX_USE_NOEXCEPT *~x86_64-redhat-linux | wc -l
264

Don't ask me why they need three. But two of them expand to noexcept or empty,
only USE_NOEXCEPT expands to throw() in C++98 code.

The NO_THROW ones are used only in C functions (the __cxa_foo ones). And I
think the USE_NOEXCEPT one is used only where the C++98 standard required 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


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

On quinta-feira, 2 de agosto de 2012 19.47.46, marius.storm-ol...@nokia.com
wrote:
 This tells me that MSVC's implementation of throw() == noexcept(true)
 for all intents and purposes, and we can use that in Qt.

Ah, that changes everything. But we can just use __declspec(nothrow) then, to
be on the safe side.

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


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] state of Qt's Australia office

2012-08-02 Thread Lorn Potter

On 02/08/2012, at 10:02 PM, lars.kn...@nokia.com lars.kn...@nokia.com wrote:

I talked a bit with the team in Brisbane this morning. Obviously the mood
there is somewhat grim.

Grim yes, but at least we now know what is happening with our jobs in respect
to Nokia.

Talking for me, it's really sad to see this happen. There are a lot of bright
engineers working in that office and I have been working with many of them
for quite some time now. I really hope that everybody will find a new job
soon, and that most of the people will actually stay connected to the Qt
ecosystem and Qt project in some form or another.

For Qt as a product, it is now really important to remember that we do have
the Qt project and a live and active community around it. This might make
some things a bit more difficult in the short term, but we will find ways to
deal with this and to continue to move Qt forward.

I'll try to keep this list posted and informed as good as I can.

Luckily, the majority of work for 5.0 has already been done in these effected
modules.

I cannot speak for others, but I will certainly help out when/if I can,
regardless of my employment. I want to continue working with sensors and sensor
gestures, but I can help maintain the code I helped out with in other areas -
sysinfo, bearermanagement backends.

Lars

On Aug 2, 2012, at 10:38 AM, ext martin.jo...@nokia.com
martin.jo...@nokia.com wrote:

I'm sure QML/QtQuick will live on - only Brisbane is affected.

I'm not sure if/how we, the Brisbane developers, will continue to
contribute, however.

Br,
Martin.

From: ext qtnext [qtn...@gmail.com]
Sent: Thursday, 2 August 2012 4:46 PM
To: Jones Martin (Nokia-MP/Brisbane)
Cc: development@qt-project.org
Subject: Re: [Development] state of Qt's Australia office

Le jeudi 2 août 2012, martin.jo...@nokia.com a écrit :

We just found out yesterday. We haven’t had a chance to discuss
continuation of QML/QtQuick, but we have passionate developers here who will
continue contributing if possible.

Qtquick was the main point of qt5...
If your company depends on QML/QtQuick, then now is the time to discuss a
mutually beneficial arrangement with us J

I have invested a lot of time in qt5/qml trusting in what nokia said
before... But i have a very small company so the only way to help that i can
do is to pay for a commercial licence if there is a trustable company that
continue qt

Martin.

From: development-bounces+martin.jones=nokia@qt-project.org
[mailto:development-bounces+martin.jones=nokia@qt-project.org] On Behalf
Of ext qtnext
Sent: Wednesday, August 01, 2012 10:48 PM
To: development@qt-project.org
Subject: Re: [Development] state of Qt's Australia office

QtDeclarative ? Does it mean that nobody in Qt team will work on qml
(Quick2) ?

2012/8/1 Atlant Schmidt aschm...@dekaresearch.com

Folks:

(more)

Let's hope that the remaining Trolls land in a
more-friendly fjord!

Atlant

-Original Message-
From: development-bounces+aschmidt=dekaresearch@qt-project.org
[mailto:development-bounces+aschmidt=dekaresearch@qt-project.org] On
Behalf Of Atlant Schmidt
Sent: Wednesday, August 01, 2012 8:30 AM
To: 'C. Bergström'; development@qt-project.org
Subject: Re: [Development] state of Qt's Australia office

Folks:

I wasn't going to mention this but since the topic has come up...

A source I consider reliable has whispered in my ear that
in the aftermath of Nokia recently shooting Meltemi dead*,
Sebastian Nyström (the Nokia Senior VP in charge of Qt) has
been given explicit direction to sell-off the Qt asset.

Nokia's great experiment in frameworks (mobile and otherwise)
is over.

Atlant

* After having previously shot Symbian and Maemo/MeeGo dead

This e-mail and the information, including any attachments, it contains are
intended to be a confidential communication only to the person or entity to
whom it is addressed and may contain information that is privileged. If the
reader of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please immediately notify the sender and destroy the
original message.

Thank you.

Please consider the environment before printing this email.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Clickhttps://www.mailcontrol.com/sr/ufrRwuioVx3TndxI!oX7UqcUCtlg0TD8RfkI3WfseUnsO8bgDK+guU4ZxjFLV1IJtna8Ms8t0Hr1lqOECv!Swg==
to report this email as spam.

This e-mail and the information, including any attachments, it contains are
intended to be a

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

2012-08-02 Thread Marc Mutz

On Thursday August 2 2012, Konrad Rosenbaum wrote:
 On Thursday 02 August 2012, Thiago Macieira wrote:
  On quinta-feira, 2 de agosto de 2012 17.55.54, Konrad Rosenbaum wrote:
   Where is qHash(QDateTime) defined? It doesn't seem to be where I
   expected it (qhash.* or qdatetime.*).
 
  qdatetime.{h,cpp}

 Ok, found it - had the wrong branch checked out for some odd reason. This
 has a high likelyhood of causing allocations if time zones, calenders or
 anything fancy is active: it causes time zone calculations, which
 potentially cause allocations.

That begs the question whether this is what should happen for a _hash_, which 
is supposed to be _fast_ :)

-- 
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
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] Proposal: adding Q_DECL_NOEXCEPT to many methods

2012-08-02 Thread Marc Mutz

Hi Thiago,

On Thursday August 2 2012, Thiago Macieira wrote:
 The benefits are:
  - callers do not need to emit exception handlers around such functions
  - the compiler may assume that no exception unexpectedly happens inside
 that function body, foregoing exception handlers inside it as well.

AFAIU, the compiler needs to make sure that std::terminate is called if an 
unexpected exception is thrown, which would require the equivalent of a 
function-try-catch block where the catch block calls std::terminate().

Do you have a reference?

 The first behaviour is present with a C++03's empty exception specification
 (i.e., throw() in the function declaration),

AFAIU, that's only true for MSVC, and counter to what C++03 actually mandated.

 but the second behaviour is 
 new in C++11. In the previous standard, the compiler was forced to emit
 exception code for the case when exceptions did happen even when they
 shouldn't. For that reason, the C++03 exception specification is
 deprecated.

Ok, here I'm with you again.

Btw, I've done some very rough tests:

What I set out to check was whether calling non-noexcept functions from 
noexcept ones incurs a penalty for the std::terminate call that is required 
if a noexcept function would leak an exception (it can't, it must invoke 
std::terminate() instead, and the GCC compilate works as expected in that 
respect, when I make foo() below throw) vs. if the compiler can prove that 
all operations are noexcept.

What I found was that a declaration
   int foo() noexcept;
vs.
   int foo();
doesn't influence the assembly at all (expected, the exception must be 
swallowed inside foo(), not, as with throw() by the caller of foo()).

But
   int foo();
   int bar() noexcept { const int f = foo(); return 2*f;}
seems to introduce a new entry in the gcc_except_table (that's expected, too. 
bar() needs to be prepared for foo() to throw and call std::terminate() in 
response) whereas
   int foo() noexcept;
   int bar() noexcept { const int f = foo(); return 2*f; }
does not (also expected, as the compile can now prove that the body of bar() 
can't throw; the responsibility of preventing exceptions from exiting foo() 
is now with foo()'s implementation).

The function itself is unchanged, though. I don't know enough compiler 
internals to properly interpret this result :)

In a similar test,
   int foo();
   int bar() noexcept { const int f = foo(); return 2*f; }
also adds an entry to the exception table, compared to
   int foo();
   int bar() { const int f = foo(); return 2*f; }
which doesn't. What's more interesting is that I get with -m64 -O2 and no -g 
an .o size difference of 1360 bytes for the second vs. 1576 for the first 
variant. This size difference is much bigger than I would have expected from 
the .s-file diff. For comparision, the size for both bar() and foo() noexcept 
is also 1360.

If there really is a 200 byte overhead per nonexcept function calling 
non-noexcept functions, we'd need to avoid marking functions noexcept that, 
say, Q_ASSERT(), e.g., even though we could probably live with the 
std::terminate that's called if Q_ASSERT() throws (at that point, it's clear 
that the assertion failed, if not from the resulting backtrace) :)

Even if it isn't a full 200 bytes overhead, we should make qt_assert() 
noexcept before putting it on, say, QMutex::lock() which calls it.

Thanks,
Marc

-- 
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
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] Proposal: adding Q_DECL_NOEXCEPT to many methods

On sexta-feira, 3 de agosto de 2012, às 00.25.04, you wrote:
 AFAIU, the compiler needs to make sure that std::terminate is called if an
 unexpected exception is thrown, which would require the equivalent of a
 function-try-catch block where the catch block calls std::terminate().

 Do you have a reference?

Looking at the code generated by GCC, it looks like it generates no extra
*code*, but it does generate a block of exception data. It indicates probably
that no exceptions are expected in that block and that the stack unwinder
should do what it must on its own.

 What I found was that a declaration
int foo() noexcept;
 vs.
int foo();
 doesn't influence the assembly at all (expected, the exception must be
 swallowed inside foo(), not, as with throw() by the caller of foo()).

That's the difference in behaviour, the flaw in the original standard.

 But
int foo();
int bar() noexcept { const int f = foo(); return 2*f;}
 seems to introduce a new entry in the gcc_except_table (that's expected,
 too. bar() needs to be prepared for foo() to throw and call
 std::terminate() in response) whereas

Yep.

int foo() noexcept;
int bar() noexcept { const int f = foo(); return 2*f; }
 does not (also expected, as the compile can now prove that the body of bar()
 can't throw; the responsibility of preventing exceptions from exiting foo()
 is now with foo()'s implementation).

Yep.

Which is why we should use noexcept only when we can prove that it doesn't
throw. Most of glibc does declare its functions as nothrow, even in C mode.
The keyword says no exceptions will leak. If, in addition, the compiler can
prove that none can be produced, it doesn't need to write the exception table.

 The function itself is unchanged, though. I don't know enough compiler
 internals to properly interpret this result :)

 In a similar test,
int foo();
int bar() noexcept { const int f = foo(); return 2*f; }
 also adds an entry to the exception table, compared to
int foo();
int bar() { const int f = foo(); return 2*f; }
 which doesn't.

Because no unwinding is necessary. Now try adding a type with a destructor
before the call to foo() and you'll see something quite different.

 What's more interesting is that I get with -m64 -O2 and no -g
 an .o size difference of 1360 bytes for the second vs. 1576 for the first
 variant. This size difference is much bigger than I would have expected
 from the .s-file diff. For comparision, the size for both bar() and foo()
 noexcept is also 1360.

You can't compare the size in .o since it contains relocation information that
will be removed by the linker.

 If there really is a 200 byte overhead per nonexcept function calling
 non-noexcept functions, we'd need to avoid marking functions noexcept that,
 say, Q_ASSERT(), e.g., even though we could probably live with the
 std::terminate that's called if Q_ASSERT() throws (at that point, it's clear
 that the assertion failed, if not from the resulting backtrace) :)

I don't think it's 200 bytes, but there is an overhead. An overhead, mind you,
that is read-only, sharable and clean (no relocations). The exception tables
are usually pretty far from the text, which means the pages containing them
are often not demand-paged into memory at all. It makes the library size
bigger, but shouldn't affect much at runtime.

That said, you're right: we should make our noexcept functions call only other
noexcept functions.

 Even if it isn't a full 200 bytes overhead, we should make qt_assert()
 noexcept before putting it on, say, QMutex::lock() which calls it.

Agreed. It's already noreturn on non-Windows, noexcept makes sense. Even if it
*can* throw, it makes no sense for qt_assert to throw and cause a stack
unwinding, thereby permitting code to continue executing after a double fault
(assertion and exception).

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods