Re: [Development] -Winconsistent-missing-override warning with latest Xcode and Qt 5.5
On Wed, Jul 01, 2015 at 04:36:02PM +, Edward Sutton wrote: Is there a work-around I could use in my Qt project file? Upgrade to 5.5.1. It's already fixed. The problem was not deemed important enough to affect the 5.5.0 release. My Chicago based sales rep told me that ( somewhere buried in my license fine print ) I could not release software using unreleased versions of Qt Enterprise. that makes sense for feature releases, but not for bugfixes. otherwise, qt support wouldn't be able to supply you with fixes, either, as these obviously create unreleased versions of qt, too. Lawyers frighten me much more than chief architects. :-) lawyers still put their pants on one leg at a time. IANAL, YMMV, blah blah blah -Ed On Jul 1, 2015, at 10:19 AM, Thiago Macieira thiago.macie...@intel.commailto:thiago.macie...@intel.com wrote: On Wednesday 01 July 2015 15:15:19 Edward Sutton wrote: Is there a work-around I could use in my Qt project file? Upgrade to 5.5.1. It's already fixed. The problem was not deemed important enough to affect the 5.5.0 release. -- Thiago Macieira - thiago.macieira (AT) intel.comhttp://intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.orgmailto:Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. ___ 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] [Announce] Qt 5.5 released
Hi, Qt 5.5 has just been released. For details check the blog post at http://blog.qt.io/blog/2015/07/01/qt-5-5-released/ and http://www.qt.io/qt5-5/ Big thanks to everyone involved! Br, Akseli ___ Announce mailing list annou...@qt-project.org http://lists.qt-project.org/mailman/listinfo/announce ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] CI problems
Hi, We are currently experiencing severe connectivity issues in our CI infrastructure. As a result integrations staged in Gerrit are likely to fail, hang or - in the worst case - kill kittens. Digia IT is working on it. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] -Winconsistent-missing-override warning with latest Xcode and Qt 5.5
On Wednesday 1. July 2015 16:50:09 Stephen Kelly wrote: Hello, I just tried building Qt 5.5 with Xcode 6.3.2. It built, but emitted many warnings for each translation unit about -Winconsistent-missing-override. https://codereview.qt-project.org/115201 It was just too late for Qt 5.5.0 but it will be in 5.5.1 -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] -Winconsistent-missing-override warning with latest Xcode and Qt 5.5
On Wednesday 01 July 2015 15:15:19 Edward Sutton wrote: Is there a work-around I could use in my Qt project file? Upgrade to 5.5.1. It's already fixed. The problem was not deemed important enough to affect the 5.5.0 release. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
For example, with moc removed we support template classes that inherit from QObject. Wow. I would (almost) kill for having that feature in Qt! You can work around it quite easily. What doesn’t work is adding new signals / slots inside a template class. So just add a base class declaring these signals/slots, and make your template class inherits from it. Unless you wan’t to use the template class as signal/slots arguments, this works fine. Regards, Julien +1. I do that a lot: QObject = MyClass = MyTemplate = MyClassDerived --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] -Winconsistent-missing-override warning with latest Xcode and Qt 5.5
On Wednesday 01 July 2015 18:55:24 Oswald Buddenhagen wrote: My Chicago based sales rep told me that ( somewhere buried in my license fine print ) I could not release software using unreleased versions of Qt Enterprise. that makes sense for feature releases, but not for bugfixes. otherwise, qt support wouldn't be able to supply you with fixes, either, as these obviously create unreleased versions of qt, too. Indeed. But to put your mind at ease, you can just apply this patch and it won't get you the other unreleased changes: https://codereview.qt-project.org/gitweb?p=qt/qtbase.git;a=patch;h=7d5e849e2808e9051a6d3ab19f29109b852f7bc9 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans
On 2015-06-26, Olivier Goffart oliv...@woboq.com wrote: Can we have function that takes or return std::function, std::tuple, std::unique_ptr, std::vector? While I can see the advantage of std::function, I'm not sure why we would use the remaining ones in API ? Thiago already mentioned that he didn't like std::vector. I think we mostly avoid QPair in api's (because it is generally not very documenting in API). I don't see why std::tuple is any different. /Sune ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
30.06.2015, 23:38, Bernhard priv...@bernhard-lindner.de: For example, with moc removed we support template classes that inherit from QObject. Wow. I would (almost) kill for having that feature in Qt! http://www.labri.fr/perso/guenneba/code/ppmoc.php No C++11 required (code was written in 2008 or earlier) -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] -Winconsistent-missing-override warning with latest Xcode and Qt 5.5
Is there a work-around I could use in my Qt project file? Upgrade to 5.5.1. It's already fixed. The problem was not deemed important enough to affect the 5.5.0 release. My Chicago based sales rep told me that ( somewhere buried in my license fine print ) I could not release software using unreleased versions of Qt Enterprise. Lawyers frighten me much more than chief architects. :-) -Ed On Jul 1, 2015, at 10:19 AM, Thiago Macieira thiago.macie...@intel.commailto:thiago.macie...@intel.com wrote: On Wednesday 01 July 2015 15:15:19 Edward Sutton wrote: Is there a work-around I could use in my Qt project file? Upgrade to 5.5.1. It's already fixed. The problem was not deemed important enough to affect the 5.5.0 release. -- Thiago Macieira - thiago.macieira (AT) intel.comhttp://intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.orgmailto:Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
Le mardi 30 juin 2015 à 22:37 +0200, Bernhard a écrit : For example, with moc removed we support template classes that inherit from QObject. Wow. I would (almost) kill for having that feature in Qt! You can work around it quite easily. What doesn’t work is adding new signals / slots inside a template class. So just add a base class declaring these signals/slots, and make your template class inherits from it. Unless you wan’t to use the template class as signal/slots arguments, this works fine. Regards, Julien ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] std:: in Qt ABI (was: Qt LTS C++11 plans)
-Original Message- From: development-bounces+kai.koehne=theqtcompany@qt-project.org [mailto:development-bounces+kai.koehne=theqtcompany@qt-project.org] On Behalf Of Thiago Macieira Sent: Tuesday, June 30, 2015 10:17 PM To: development@qt-project.org Subject: Re: [Development] Qt LTS C++11 plans On Tuesday 30 June 2015 18:16:34 Olivier Goffart wrote: On Friday 26. June 2015 08:41:11 Thiago Macieira wrote: On Friday 26 June 2015 11:59:11 Olivier Goffart wrote: However, it is questionable if even this works. We already rely on the standard library ABI in QException. And most users will have to recompile everything if they want to change standard library anyway. std::exception is compatible between libc++ and libstdc++, so that doesn't count. Ok. (But by luck... another version might not) s/luck/design/ Anyway, you did not answer the actual question. Are you against changing the policy or not? I am, for several reasons. For the container types, please use the Qt ones, for API consistency and familiarity. I don't want to see API using std::vector, period. Fair enough about the containers. std::string and std::list is also problematic because of https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html What I think would be very helpful is std::function though. We've a couple of places where we take function pointers with its awkward design and limitations. In others we start to have classes with just one virtual member ... This is all much more elegantly solved by just taking a std::function. Since we're talking about *ABI*, it stands to reason we're talking about mandatory features, so outside of any #ifdefs that may change between Qt's build and the user application's. That means any such feature depending on a C++11 library feature should be protected by a configure-time check and C++a #define in qconfig.h I guess this is only a limit until we require C++11 (planned for Qt 5.7)? Given our horrible configure script and configure.exe source code, writing such checks are difficult and time-consuming. More likely than not, we'll get it wrong. And finally, I am against it because libc++ and libstdc++ co-existence is still a goal, even on OS X. My understanding is that most (all?) Linux distributions focus on libc++. On OS X it's libstdc++. An ABI incompatibility in Qt would affect only apps that - don't compile Qt themselves, but use the prebuilt ones (from distribution, or from binary installers) - link against 'the other' C++ runtime library themselves, or link against libraries that do so I'm wondering how big the use case really is. In the worst case we can also provide different builds ourselves (Not that I want to pitch this, but we do the stunt on Windows already). Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] std:: in Qt ABI (was: Qt LTS C++11 plans)
-Original Message- Subject: [Development] std:: in Qt ABI (was: Qt LTS C++11 plans) Side note: Outlook decides to not show the first four characters (std:) in the Subject line/Compact View, and also drops it when Replying. WTF? [...] My understanding is that most (all?) Linux distributions focus on libc++. On OS X it's libstdc++. Obviously it's the other way round. Sorry about this. Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans
On Wednesday 01 July 2015 21:03:21 Sune Vuorela wrote: I think we mostly avoid QPair in api's (because it is generally not very documenting in API). I don't see why std::tuple is any different. I agree with Sune here. Please create your struct with the types in question and proper names. And that's only for very simple structs. Anything more complex should get a d pointer[*] and become a value-type class. Examples: QNetworkAddressEntry, QNetworkCookie, etc. [*] getting a d pointer does not mean getting rid of the private members. See the Qt 6 task for QDateTime, for example. It's also possible to have classes with no d pointer, but you need to be absolutely sure there's no chance of extension for the next 10 years. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
