Re: [Development] How long until clang memory model is ready?
That’s correct. In Qt Creator master branch (i.e. 3.1 series) you can choose the code model of different languages to use clang as a code model backend What are the pros/cons of the two options for C++ as it currently stands? Regards, Rob. On 23 January 2014 07:55, Ziller Eike eike.zil...@digia.com wrote: On Jan 22, 2014, at 8:31 PM, Cristian Adam cristian.a...@here.com wrote: On 22.01.2014 19:35, ext Olivier Goffart wrote: Regarding the use of libclang for the code model in Qt creator, there was no progress in a long time. I think the clang code model branch has been merged into master: http://lists.qt-project.org/pipermail/qt-creator/2013-December/003028.html The next version of Qt Creator should have the clang code model as a plugin. That’s correct. In Qt Creator master branch (i.e. 3.1 series) you can choose the code model of different languages to use clang as a code model backend, or Qt Creator’s built-in. (If you pointed Qt Creator to libclang (and dev headers) at Qt Creator compile time.) Br, Eike -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ 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] How long until clang memory model is ready?
Clang code model highlight feature works fine, but code completion is too slow to daily use. Some debug messages: ... Completion done in 7387 ms, with 12 items. ... Completion done in 3287 ms, with 14105 items. ... Completion done in 3236 ms, with 189 items. ... Completion done in 3325 ms, with 14106 items. ... Completion done in 3388 ms, with 0 items. ... Completion done in 3299 ms, with 200 items. ... Completion done in 3495 ms, with 14115 items. ... Completion done in 3143 ms, with 9 items. ... Completion done in 3315 ms, with 9 items. On Thu, Jan 23, 2014 at 4:37 PM, Robert Knight robertkni...@gmail.comwrote: That’s correct. In Qt Creator master branch (i.e. 3.1 series) you can choose the code model of different languages to use clang as a code model backend What are the pros/cons of the two options for C++ as it currently stands? Regards, Rob. On 23 January 2014 07:55, Ziller Eike eike.zil...@digia.com wrote: On Jan 22, 2014, at 8:31 PM, Cristian Adam cristian.a...@here.com wrote: On 22.01.2014 19:35, ext Olivier Goffart wrote: Regarding the use of libclang for the code model in Qt creator, there was no progress in a long time. I think the clang code model branch has been merged into master: http://lists.qt-project.org/pipermail/qt-creator/2013-December/003028.html The next version of Qt Creator should have the clang code model as a plugin. That’s correct. In Qt Creator master branch (i.e. 3.1 series) you can choose the code model of different languages to use clang as a code model backend, or Qt Creator’s built-in. (If you pointed Qt Creator to libclang (and dev headers) at Qt Creator compile time.) Br, Eike -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ 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 -- Regards, Fan Yang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How long until clang memory model is ready?
On Wed, Jan 22, 2014 at 7:14 PM, Chris L hackthegovernm...@hotmail.com wrote: Qt Creator could be, with a few fixed bugs the obvious #1 choice ( if it isn't already ) for general cross platform c++ Which bugs are those in your oppinion? but it seems like the devs ignore non Qt c++ development. What makes you say that? Are there specific instances where we made non-Qt C++ use-cases harder? From my point of view we do not ignore the no-Qt use-case, but Qt is definitely the focus. But then a good Qt IDE is also a good C++ IDE. I brought up the clang memory model because discussions on the irc channels and old blog entries indicate that there was a plan to use clangs memory model to support the stl's classes in Qt Creator ( unique_ptr, vector, ect... ), once clang's memory model was working correctly, and my question is about when to expect this to happen if ever? Are you talking about the code model here and not the memory model? Yes, template support is not as good as it should be. That does not require us to switch to the clang code model though (our existing one could be improved as well). The Clang plugin is part of the upcoming Qt Creator 3.1, but it is still marked as experimental there. So it will be disabled by default. It still is significantly slower than our current one though. Any help to improve it is appreciated -- especially testing and the more unusual the setup you test in the more valuable the results are. PS: Please move this thread to the Qt Creator mailing list if possible... Best Regards, Tobias ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QtSerialPort] Add some set of base auto tests
On 23.1.2014, at 9.58, Denis Shienkov denis.shien...@gmail.commailto:denis.shien...@gmail.com wrote: Hi Simo, Guys. Many thanks for your involvement. You can use this https://bugreports.qt-project.org/browse/QTQAINFRA-682 I added there some instruction for com0com installation. So, what additional info still it is necessary for you? I think we can start with this, we'll get back when necessary. If you have some test to verify that it works, it would be great. Simo Best regards, Denis 2014/1/23 Fält Simo simo.f...@digia.commailto:simo.f...@digia.com -Original Message- From: Gladhorn Frederik Sent: 22. tammikuuta 2014 22:19 To: Denis Shienkov; development@qt-project.orgmailto:development@qt-project.org Cc: Sarajärvi Tony; Fält Simo Subject: RE: [Development] [QtSerialPort] Add some set of base auto tests On Wednesday 22. January 2014 22.06.03 Denis Shienkov wrote: As mentioned on Gerrit before, I was discussing it with Simo, but the problem is really that we neither had anything integrated, nor instructions how to set it up... Those are necessary to get done before requesting any further steps on the CI side. The short instruction how to setup and configure the com0com software is here: https://codereview.qt-project.org/#change,65431 For this purpose it is enough to have a host with any Windows x32. Windows x64 doesn't suit for this purpose because com0com is delivered with unsigned drivers which won't work there. As a result, the principal thing is the configuring of the CI hosts (setup an ENV variables of QTEST_SERIALPORT_SENDER, QTEST_SERIALPORT_RECEIVER, and etc.). I don't know how to do it on CI, so an help (and some work) from the Digia is necessary, IMHO. Thiago, Oswald, Digia, Others, what do you think about it? IMHO, it is impossible to delays with this issue more (1~2 years it is too long)... If you agree with passes of names of serial ports to tests through ENV, then we can start of implementation a set of the minimal tests (even if CI is yet ready). Can you comment it? I think writing tests is a great idea in any case, so please go ahead. To get the CI to run the tests we should track this in jira, please file an issue on the Qt bug tracker under Qt Quality Assurance Infrastructure. You can use this https://bugreports.qt-project.org/browse/QTQAINFRA-682 As for how to pass the names of the serial ports, it would be best for Tony and Simo to comment. I would recommend you write a few tests (I see there is currently not much relevant stuff in tests/auto) as if you had the virtual serial ports installed. This would help so that we can verify that the setup works. Configuring the tests trough ENV variables is quite easy in CI, it is just yet another parameter in submodule's testconfig. All we need to know are the proper values to export. Simo Make sure the tests are skipped for platforms where these are not available. You can then discuss in the jira task about how to solve the installation and naming of the serial ports. I'm sure Tony and Simo will set up the needed infrastructure for you (with your help). Greetings, Frederik Best regards, Denis 16.01.2014 13:26, Laszlo Papp пишет: It had been discussed on this list about 1-2 years ago (if memory serves well), and the common consensus was to use com0com on Windows and some VT alike option on Linux. I do not think the technology changed much, so it is probably still the best option... In my opinion though, the best and easiest option would be socat on Linux. That can elegantly create pseudo terminals for this purpose. I was writing some unit tests last year targeting the replacement of socat internally, but it turned out a bit complex, so I lost motivation. In theory, it would be possible to use an internal socat functionality without requiring external dependencies, so the init and tear down would take over the responsibility for this, but it is not that urgent. It is probably not an issue on Linux to setup socat, but I will leave that the decision with the CI contributors. As mentioned on Gerrit before, I was discussing it with Simo, but the problem is really that we neither had anything integrated, nor instructions how to set it up... Those are necessary to get done before requesting any further steps on the CI side. In the long future, my opinion is to get QtMock up to the speed, preferably using the llvm C++ parser (which was not option back then when I thought abut it), and then we could remove all this workaround with a cross-platform solution which is not only useful for QtSerialPort. On Tue, Jan 14, 2014 at 8:14 AM, Denis Shienkov denis.shien...@gmail.commailto:denis.shien...@gmail.com wrote: Hi developers. I want to bring up a question of possibility of addition of some base tests for QtSerialPort. I
Re: [Development] Remove OSX 10.6 Build?
On 22/01/14 9:02 , Ziller Eike wrote: On Jan 21, 2014, at 2:56 PM, Tor Arne Vestbø tor.arne.ves...@digia.com wrote: 5.3: - Remove support from binary packages - No CI = In practice, deprecated, so let's be explicit about it for 5.3 5.4 - Bump the dev branch to 5.4 - Remove 10.6 code as see fit - Apply 10.6 fixes to 5.3.x (stable) as normal The message is Qt 5.3 deprecates 10.6 support (but is available for source builds for the lifetime of 5.3), and 5.4 will remove it.” I’d support this plan, and additionally throw in: after 5.3 / Qt Creator 3.2: - drop support for compiling running Qt Creator on 10.6 We want to start using C++11 also in Qt Creator, and 10.6 is the only thing preventing that. Since 10.6 is deployment target only for Qt, we don’t necessarily need to keep “its IDE” running there (yes, that’s a Qt-centric way of looking at Qt Creator). I think it makes perfect sense. tor arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QtSerialPort] Add some set of base auto tests
I think we can start with this, we'll get back when necessary. If you have some test to verify that it works, it would be great. No, unfortunately we have no any tests, because we planned them only after CI will be ready. Best regards, Denis 2014/1/23 Fält Simo simo.f...@digia.com On 23.1.2014, at 9.58, Denis Shienkov denis.shien...@gmail.com wrote: Hi Simo, Guys. Many thanks for your involvement. You can use this https://bugreports.qt-project.org/browse/QTQAINFRA-682 I added there some instruction for com0com installation. So, what additional info still it is necessary for you? I think we can start with this, we'll get back when necessary. If you have some test to verify that it works, it would be great. Simo Best regards, Denis 2014/1/23 Fält Simo simo.f...@digia.com -Original Message- From: Gladhorn Frederik Sent: 22. tammikuuta 2014 22:19 To: Denis Shienkov; development@qt-project.org Cc: Sarajärvi Tony; Fält Simo Subject: RE: [Development] [QtSerialPort] Add some set of base auto tests On Wednesday 22. January 2014 22.06.03 Denis Shienkov wrote: As mentioned on Gerrit before, I was discussing it with Simo, but the problem is really that we neither had anything integrated, nor instructions how to set it up... Those are necessary to get done before requesting any further steps on the CI side. The short instruction how to setup and configure the com0com software is here: https://codereview.qt-project.org/#change,65431 For this purpose it is enough to have a host with any Windows x32. Windows x64 doesn't suit for this purpose because com0com is delivered with unsigned drivers which won't work there. As a result, the principal thing is the configuring of the CI hosts (setup an ENV variables of QTEST_SERIALPORT_SENDER, QTEST_SERIALPORT_RECEIVER, and etc.). I don't know how to do it on CI, so an help (and some work) from the Digia is necessary, IMHO. Thiago, Oswald, Digia, Others, what do you think about it? IMHO, it is impossible to delays with this issue more (1~2 years it is too long)... If you agree with passes of names of serial ports to tests through ENV, then we can start of implementation a set of the minimal tests (even if CI is yet ready). Can you comment it? I think writing tests is a great idea in any case, so please go ahead. To get the CI to run the tests we should track this in jira, please file an issue on the Qt bug tracker under Qt Quality Assurance Infrastructure. You can use this https://bugreports.qt-project.org/browse/QTQAINFRA-682 As for how to pass the names of the serial ports, it would be best for Tony and Simo to comment. I would recommend you write a few tests (I see there is currently not much relevant stuff in tests/auto) as if you had the virtual serial ports installed. This would help so that we can verify that the setup works. Configuring the tests trough ENV variables is quite easy in CI, it is just yet another parameter in submodule's testconfig. All we need to know are the proper values to export. Simo Make sure the tests are skipped for platforms where these are not available. You can then discuss in the jira task about how to solve the installation and naming of the serial ports. I'm sure Tony and Simo will set up the needed infrastructure for you (with your help). Greetings, Frederik Best regards, Denis 16.01.2014 13:26, Laszlo Papp пишет: It had been discussed on this list about 1-2 years ago (if memory serves well), and the common consensus was to use com0com on Windows and some VT alike option on Linux. I do not think the technology changed much, so it is probably still the best option... In my opinion though, the best and easiest option would be socat on Linux. That can elegantly create pseudo terminals for this purpose. I was writing some unit tests last year targeting the replacement of socat internally, but it turned out a bit complex, so I lost motivation. In theory, it would be possible to use an internal socat functionality without requiring external dependencies, so the init and tear down would take over the responsibility for this, but it is not that urgent. It is probably not an issue on Linux to setup socat, but I will leave that the decision with the CI contributors. As mentioned on Gerrit before, I was discussing it with Simo, but the problem is really that we neither had anything integrated, nor instructions how to set it up... Those are necessary to get done before requesting any further steps on the CI side. In the long future, my opinion is to get QtMock up to the speed, preferably using the llvm C++ parser (which was not option back then when I thought abut it), and then we could remove all this workaround with a
Re: [Development] Remove OSX 10.6 Build?
On Jan 23, 2014, at 12:43 PM, Tor Arne Vestbø tor.arne.ves...@digia.com wrote: On 22/01/14 9:02 , Ziller Eike wrote: On Jan 21, 2014, at 2:56 PM, Tor Arne Vestbø tor.arne.ves...@digia.com wrote: 5.3: - Remove support from binary packages - No CI = In practice, deprecated, so let's be explicit about it for 5.3 5.4 - Bump the dev branch to 5.4 - Remove 10.6 code as see fit - Apply 10.6 fixes to 5.3.x (stable) as normal The message is Qt 5.3 deprecates 10.6 support (but is available for source builds for the lifetime of 5.3), and 5.4 will remove it.” I’d support this plan, and additionally throw in: after 5.3 / Qt Creator 3.2: - drop support for compiling running Qt Creator on 10.6 We want to start using C++11 also in Qt Creator, and 10.6 is the only thing preventing that. Since 10.6 is deployment target only for Qt, we don’t necessarily need to keep “its IDE” running there (yes, that’s a Qt-centric way of looking at Qt Creator). I think it makes perfect sense. tor arne I second that. Best regards, Dr. Gabriel de Dietrich Senior Software Developer qt.digia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 5.2.1 snapshots available
I have just noticed that OSX 5.2.1 offline snapshot (clang) DMG is 60MB slimmer (396 MB) than it was in 5.2.0 (455 MB). Do you know what is the reason of such difference? Regards, -- Adam ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt Creator 3.2 dropping support for Mac OS X 10.6
Hi, Let's make this: Qt Creator 3.2: - drop support for compiling running Qt Creator on 10.6 We want to start using C++11 also in Qt Creator, and 10.6 is the only thing preventing that. Since 10.6 is deployment target only for Qt, we don’t necessarily need to keep “its IDE” running there (yes, that’s a Qt-centric way of looking at Qt Creator). a actual independant proposal (since it doesn't really depend on what qt supports) and cross post it to qt-creator for some wider exposure. Actually using C++11 would also mean bumping the minimum supported compiler for *compiling* Qt Creator. That's somewhat separate, but I would assume we would require at least lamba and auto support for compiling Qt Creator 3.2. That means MSVC 2010, clang 3.1 or g++ 4.5 if I remember correctly. daniel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt5 documentation for Embedded Linux
http://qt-project.org/doc/qt-5/supported-platforms.html Embedded Linux (DirectFB, EGLFS, KMS, and Wayland) Am I right that this sentence is the complete documentation for using Qt 5 on an embedded system? Nothing about how to build, what's needed for QML, what for QWidgets, how to replace qws, a word about Wayland, hardware acceleration, OpenGL, ... Or have I just missed a link? Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 documentation for Embedded Linux
Correct. This is a bit unfortunate since platforms like eglfs and linuxfb most certainly deserve a page in the documentation. I have created http://bugreports.qt-project.org/browse/QTBUG-36412 for this. Cheers, Laszlo From: development-bounces+laszlo.agocs=digia@qt-project.org [development-bounces+laszlo.agocs=digia@qt-project.org] on behalf of Peter Kümmel [syntheti...@gmx.net] Sent: Thursday, January 23, 2014 2:46 PM To: development@qt-project.org Subject: [Development] Qt5 documentation for Embedded Linux http://qt-project.org/doc/qt-5/supported-platforms.html Embedded Linux (DirectFB, EGLFS, KMS, and Wayland) Am I right that this sentence is the complete documentation for using Qt 5 on an embedded system? Nothing about how to build, what's needed for QML, what for QWidgets, how to replace qws, a word about Wayland, hardware acceleration, OpenGL, ... Or have I just missed a link? Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of Qt3D?
Hi, On Wednesday 22 January 2014 21:42:40 Jesper Weissglas wrote: Qt3D looks appetizing for my next project, but I'm not having much luck with finding out what's going on. So I thought I'd ask. Best way to get answers ;) Following instruction on http://qt-project.org/wiki/Qt3D-Installation (for Windows/MinGW) gives you a Qt3D that builds OK but doesn't even run it's own tutorial examples. All other info from the forum relates to older versions. This list has no real mentions of Qt3D for the last months. The dedicated Qt3D list seems to have fallen off the net. (It was hosted at Nokia) The official repo at https://qt.gitorious.org/qt/qt3d has very little activity the last months. Hopefully I'm wrong, but the project looks rather dead from this point of view??? The project is far from dead. We are hacking on it right now, but given how much we want to change from Qt3D 1 we have been working on it in private. However, we are now about to begin upstreaming it to a non-CI controlled branch in the Qt3D repo. The architecture has changed quite significantly from Qt3D 1 and we have also been working hard through Qt 5.1/5.2 to get more of the OpenGL helpers in place that Qt3D will build upon. I will post more information about the new architecture and future plans shortly. Cheers, Sean ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Remove OSX 10.6 Build?
If you do the math from the data available here http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10qpcustomd=0 (that’s December 2013), 10.6 accounts for slightly less than 20% of all the OS X versions. Let’s suppose those numbers reflect the reality. For our app at least, the numbers are close to our actual OS X usage figures. Last I checked in September 2013, 20% of Mac users were on OS X 10.6. I should be able to get more up to date numbers if that is useful. As for the reason why usage of OS X 10.6 is still high - I think that is down to awareness of the need to upgrade and the effort/time vs. perceived benefits, as well as hardware compatibility issues. Once browsers (FF, Chrome) make a move towards dropping 10.6 support this might help awareness. Regards, Rob. On 23 January 2014 12:09, deDietrich Gabriel gabriel.dedietr...@digia.com wrote: On Jan 23, 2014, at 12:43 PM, Tor Arne Vestbø tor.arne.ves...@digia.com wrote: On 22/01/14 9:02 , Ziller Eike wrote: On Jan 21, 2014, at 2:56 PM, Tor Arne Vestbø tor.arne.ves...@digia.com wrote: 5.3: - Remove support from binary packages - No CI = In practice, deprecated, so let's be explicit about it for 5.3 5.4 - Bump the dev branch to 5.4 - Remove 10.6 code as see fit - Apply 10.6 fixes to 5.3.x (stable) as normal The message is Qt 5.3 deprecates 10.6 support (but is available for source builds for the lifetime of 5.3), and 5.4 will remove it.” I’d support this plan, and additionally throw in: after 5.3 / Qt Creator 3.2: - drop support for compiling running Qt Creator on 10.6 We want to start using C++11 also in Qt Creator, and 10.6 is the only thing preventing that. Since 10.6 is deployment target only for Qt, we don’t necessarily need to keep “its IDE” running there (yes, that’s a Qt-centric way of looking at Qt Creator). I think it makes perfect sense. tor arne I second that. Best regards, Dr. Gabriel de Dietrich Senior Software Developer qt.digia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Remove OSX 10.6 Build?
On quinta-feira, 23 de janeiro de 2014 15:15:16, Robert Knight wrote: As for the reason why usage of OS X 10.6 is still high - I think that is down to awareness of the need to upgrade and the effort/time vs. perceived benefits, as well as hardware compatibility issues. Once browsers (FF, Chrome) make a move towards dropping 10.6 support this might help awareness. 10.6 is the last version to support running on 32-bit x86 processors, just like 10.5 was the last with PowerPC support. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] Remove OSX 10.6 Build?
On 2014-01-23, at 11:45 AM, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 23 de janeiro de 2014 15:15:16, Robert Knight wrote: As for the reason why usage of OS X 10.6 is still high - I think that is down to awareness of the need to upgrade and the effort/time vs. perceived benefits, as well as hardware compatibility issues. Once browsers (FF, Chrome) make a move towards dropping 10.6 support this might help awareness. 10.6 is the last version to support running on 32-bit x86 processors, just like 10.5 was the last with PowerPC support. Also remember that while 10.5 is the last version to run on PowerPC processors, 10.6 is the last version to support running PowerPC applications using the Rosetta emulator, and as a development environment, it's the latest OS X which can target all versions of OS X on all architectures. -- 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 -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QtSerialPort] Add some set of base auto tests
Torsdag 23. januar 2014 15.52.12 skrev Denis Shienkov: I think we can start with this, we'll get back when necessary. If you have some test to verify that it works, it would be great. No, unfortunately we have no any tests, because we planned them only after CI will be ready. There is really no excuse not to write tests now ;) The CI team cannot really set up the CI without a single test to try running, so while they get the jenkins bits in place you should write some good tests [1] and [2]. Greetings, Frederik [1] http://qt-project.org/wiki/Writing_Unit_Tests [2] http://qt-project.org/wiki/Writing_good_tests Best regards, Denis 2014/1/23 Fält Simo simo.f...@digia.com On 23.1.2014, at 9.58, Denis Shienkov denis.shien...@gmail.com wrote: Hi Simo, Guys. Many thanks for your involvement. You can use this https://bugreports.qt-project.org/browse/QTQAINFRA-682 I added there some instruction for com0com installation. So, what additional info still it is necessary for you? I think we can start with this, we'll get back when necessary. If you have some test to verify that it works, it would be great. Simo Best regards, Denis 2014/1/23 Fält Simo simo.f...@digia.com -Original Message- From: Gladhorn Frederik Sent: 22. tammikuuta 2014 22:19 To: Denis Shienkov; development@qt-project.org Cc: Sarajärvi Tony; Fält Simo Subject: RE: [Development] [QtSerialPort] Add some set of base auto tests On Wednesday 22. January 2014 22.06.03 Denis Shienkov wrote: As mentioned on Gerrit before, I was discussing it with Simo, but the problem is really that we neither had anything integrated, nor instructions how to set it up... Those are necessary to get done before requesting any further steps on the CI side. The short instruction how to setup and configure the com0com software is here: https://codereview.qt-project.org/#change,65431 For this purpose it is enough to have a host with any Windows x32. Windows x64 doesn't suit for this purpose because com0com is delivered with unsigned drivers which won't work there. As a result, the principal thing is the configuring of the CI hosts (setup an ENV variables of QTEST_SERIALPORT_SENDER, QTEST_SERIALPORT_RECEIVER, and etc.). I don't know how to do it on CI, so an help (and some work) from the Digia is necessary, IMHO. Thiago, Oswald, Digia, Others, what do you think about it? IMHO, it is impossible to delays with this issue more (1~2 years it is too long)... If you agree with passes of names of serial ports to tests through ENV, then we can start of implementation a set of the minimal tests (even if CI is yet ready). Can you comment it? I think writing tests is a great idea in any case, so please go ahead. To get the CI to run the tests we should track this in jira, please file an issue on the Qt bug tracker under Qt Quality Assurance Infrastructure. You can use this https://bugreports.qt-project.org/browse/QTQAINFRA-682 As for how to pass the names of the serial ports, it would be best for Tony and Simo to comment. I would recommend you write a few tests (I see there is currently not much relevant stuff in tests/auto) as if you had the virtual serial ports installed. This would help so that we can verify that the setup works. Configuring the tests trough ENV variables is quite easy in CI, it is just yet another parameter in submodule's testconfig. All we need to know are the proper values to export. Simo Make sure the tests are skipped for platforms where these are not available. You can then discuss in the jira task about how to solve the installation and naming of the serial ports. I'm sure Tony and Simo will set up the needed infrastructure for you (with your help). Greetings, Frederik Best regards, Denis 16.01.2014 13:26, Laszlo Papp пишет: It had been discussed on this list about 1-2 years ago (if memory serves well), and the common consensus was to use com0com on Windows and some VT alike option on Linux. I do not think the technology changed much, so it is probably still the best option... In my opinion though, the best and easiest option would be socat on Linux. That can elegantly create pseudo terminals for this purpose. I was writing some unit tests last year targeting the replacement of socat internally, but it turned out a bit complex, so I lost motivation. In theory, it would be possible to use an internal socat functionality without requiring external dependencies, so the init and tear
[Development] First Qt 4.8.6 snapshots available ...
Hi all, We have now first snapshots available for Qt 4.8.6 on http://download.qt-project.org/snapshots/qt/4.8/2014-01-23_453/. Could you please check those and verify your fixes? Packages are built against sha1 cf179ef3e38516555ce60517aa8e085b33e75744 QWizard: Fix frame when using Vista style/MSVC2012. Changes file draft (http://download.qt-project.org/snapshots/qt/4.8/2014-01-23_453/changes-4.8.6-20140123-453) is matching to the package content (changes file inside packages will updated during RC\final). Qt 4.8.6 MinGW package is built against MinGW4.4 but there is a plan to introduce MinGW4.8(.2) based package as well. Sha1 is not yet frozen but hopefully we could freeze it during 10th of February and make Qt 4.8.6 release during February. If you have some fixes you see mandatory to get into Qt 4.8.6 release (and 10th of February schedule doesn't seem feasible) please send information about those to releas...@qt-project.org. Br, Akseli -- Akseli Salovaara Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Qt-creator] Qt Creator 3.2 dropping support for Mac OS X 10.6
All but one developer at my (smallish) company is still using OSX 10.6.8 because we need 10.6 to be able to build the current shipping version of our main product. We all use Qt Creator, so a Creator 3.2 that would not work on 10.6 would be a problem for us. Adam On Thu, Jan 23, 2014 at 4:29 AM, Daniel Teske daniel.te...@digia.comwrote: Hi, Let's make this: Qt Creator 3.2: - drop support for compiling running Qt Creator on 10.6 We want to start using C++11 also in Qt Creator, and 10.6 is the only thing preventing that. Since 10.6 is deployment target only for Qt, we don’t necessarily need to keep “its IDE” running there (yes, that’s a Qt-centric way of looking at Qt Creator). a actual independant proposal (since it doesn't really depend on what qt supports) and cross post it to qt-creator for some wider exposure. Actually using C++11 would also mean bumping the minimum supported compiler for *compiling* Qt Creator. That's somewhat separate, but I would assume we would require at least lamba and auto support for compiling Qt Creator 3.2. That means MSVC 2010, clang 3.1 or g++ 4.5 if I remember correctly. daniel ___ Qt-creator mailing list qt-crea...@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of Qt3D?
Good news. Looking forward to it... Thanks, Pawel On Thu, Jan 23, 2014 at 2:59 PM, Sean Harmer sean.har...@kdab.com wrote: Hi, On Wednesday 22 January 2014 21:42:40 Jesper Weissglas wrote: Qt3D looks appetizing for my next project, but I'm not having much luck with finding out what's going on. So I thought I'd ask. Best way to get answers ;) Following instruction on http://qt-project.org/wiki/Qt3D-Installation (for Windows/MinGW) gives you a Qt3D that builds OK but doesn't even run it's own tutorial examples. All other info from the forum relates to older versions. This list has no real mentions of Qt3D for the last months. The dedicated Qt3D list seems to have fallen off the net. (It was hosted at Nokia) The official repo at https://qt.gitorious.org/qt/qt3d has very little activity the last months. Hopefully I'm wrong, but the project looks rather dead from this point of view??? The project is far from dead. We are hacking on it right now, but given how much we want to change from Qt3D 1 we have been working on it in private. However, we are now about to begin upstreaming it to a non-CI controlled branch in the Qt3D repo. The architecture has changed quite significantly from Qt3D 1 and we have also been working hard through Qt 5.1/5.2 to get more of the OpenGL helpers in place that Qt3D will build upon. I will post more information about the new architecture and future plans shortly. Cheers, Sean ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK 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 ___ 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] [QtSerialPort] Add some set of base auto tests
Frederik, The CI team cannot really set up the CI without a single test to try running ... I added some basic tests, please look here: https://codereview.qt-project.org/#change,76396 It is enough? Best regards, Denis 23.01.2014 21:31, Frederik Gladhorn пишет: Torsdag 23. januar 2014 15.52.12 skrev Denis Shienkov: I think we can start with this, we'll get back when necessary. If you have some test to verify that it works, it would be great. No, unfortunately we have no any tests, because we planned them only after CI will be ready. There is really no excuse not to write tests now ;) The CI team cannot really set up the CI without a single test to try running, so while they get the jenkins bits in place you should write some good tests [1] and [2]. Greetings, Frederik [1] http://qt-project.org/wiki/Writing_Unit_Tests [2] http://qt-project.org/wiki/Writing_good_tests Best regards, Denis 2014/1/23 Fält Simo simo.f...@digia.com On 23.1.2014, at 9.58, Denis Shienkov denis.shien...@gmail.com wrote: Hi Simo, Guys. Many thanks for your involvement. You can use this https://bugreports.qt-project.org/browse/QTQAINFRA-682 I added there some instruction for com0com installation. So, what additional info still it is necessary for you? I think we can start with this, we'll get back when necessary. If you have some test to verify that it works, it would be great. Simo Best regards, Denis 2014/1/23 Fält Simo simo.f...@digia.com -Original Message- From: Gladhorn Frederik Sent: 22. tammikuuta 2014 22:19 To: Denis Shienkov; development@qt-project.org Cc: Sarajärvi Tony; Fält Simo Subject: RE: [Development] [QtSerialPort] Add some set of base auto tests On Wednesday 22. January 2014 22.06.03 Denis Shienkov wrote: As mentioned on Gerrit before, I was discussing it with Simo, but the problem is really that we neither had anything integrated, nor instructions how to set it up... Those are necessary to get done before requesting any further steps on the CI side. The short instruction how to setup and configure the com0com software is here: https://codereview.qt-project.org/#change,65431 For this purpose it is enough to have a host with any Windows x32. Windows x64 doesn't suit for this purpose because com0com is delivered with unsigned drivers which won't work there. As a result, the principal thing is the configuring of the CI hosts (setup an ENV variables of QTEST_SERIALPORT_SENDER, QTEST_SERIALPORT_RECEIVER, and etc.). I don't know how to do it on CI, so an help (and some work) from the Digia is necessary, IMHO. Thiago, Oswald, Digia, Others, what do you think about it? IMHO, it is impossible to delays with this issue more (1~2 years it is too long)... If you agree with passes of names of serial ports to tests through ENV, then we can start of implementation a set of the minimal tests (even if CI is yet ready). Can you comment it? I think writing tests is a great idea in any case, so please go ahead. To get the CI to run the tests we should track this in jira, please file an issue on the Qt bug tracker under Qt Quality Assurance Infrastructure. You can use this https://bugreports.qt-project.org/browse/QTQAINFRA-682 As for how to pass the names of the serial ports, it would be best for Tony and Simo to comment. I would recommend you write a few tests (I see there is currently not much relevant stuff in tests/auto) as if you had the virtual serial ports installed. This would help so that we can verify that the setup works. Configuring the tests trough ENV variables is quite easy in CI, it is just yet another parameter in submodule's testconfig. All we need to know are the proper values to export. Simo Make sure the tests are skipped for platforms where these are not available. You can then discuss in the jira task about how to solve the installation and naming of the serial ports. I'm sure Tony and Simo will set up the needed infrastructure for you (with your help). Greetings, Frederik Best regards, Denis 16.01.2014 13:26, Laszlo Papp пишет: It had been discussed on this list about 1-2 years ago (if memory serves well), and the common consensus was to use com0com on Windows and some VT alike option on Linux. I do not think the technology changed much, so it is probably still the best option... In my opinion though, the best and easiest option would be socat on Linux. That can elegantly create pseudo terminals for this purpose. I was writing some unit tests last year targeting the replacement of socat internally, but it turned out a bit complex, so I lost motivation. In theory, it would be possible to use an internal socat functionality without requiring external dependencies, so the init and tear down would take over the responsibility for this, but it is not that urgent. It is probably not an
Re: [Development] Remove OSX 10.6 Build?
On 23/01/2014, at 23.59, development-requ...@qt-project.org wrote: If you do the math from the data available here http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10qpcustomd=0 (that’s December 2013), 10.6 accounts for slightly less than 20% of all the OS X versions. Let’s suppose those numbers reflect the reality. For our app at least, the numbers are close to our actual OS X usage figures. Last I checked in September 2013, 20% of Mac users were on OS X 10.6. I should be able to get more up to date numbers if that is useful. As for the reason why usage of OS X 10.6 is still high - I think that is down to awareness of the need to upgrade and the effort/time vs. perceived benefits, as well as hardware compatibility issues. Once browsers (FF, Chrome) make a move towards dropping 10.6 support this might help awareness. Regards, Rob. I don’t think anybody has mentioned the lack of ability to upgrade hardware - mostly because of financial issues, I suppose. 10.6 is as far as I know the last Mac OS to support 32 bit systems. Previous versions of my own software supported PPC and down to Mac OS 10.4, which gave me a considerable user base from that segment. Percentages aside, there’s still a LOT of people sitting with old hardware, simply because they cannot afford to upgrade. XP was introduced in 2001. It’s still supported. Mac OS 10.6 was introduced in 2009. I understand the desire to get rid of the messiness under the hood, but I think it should be considered that it cuts out users on hardware platforms not so much up to date.___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Remove OSX 10.6 Build?
On Thu, Jan 23, 2014 at 5:16 PM, Jan Farø jan.fa...@gmail.com wrote: On 23/01/2014, at 23.59, development-requ...@qt-project.org wrote: If you do the math from the data available here http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10qpcustomd=0 (that’s December 2013), 10.6 accounts for slightly less than 20% of all the OS X versions. Let’s suppose those numbers reflect the reality. For our app at least, the numbers are close to our actual OS X usage figures. Last I checked in September 2013, 20% of Mac users were on OS X 10.6. I should be able to get more up to date numbers if that is useful. As for the reason why usage of OS X 10.6 is still high - I think that is down to awareness of the need to upgrade and the effort/time vs. perceived benefits, as well as hardware compatibility issues. Once browsers (FF, Chrome) make a move towards dropping 10.6 support this might help awareness. Regards, Rob. I don’t think anybody has mentioned the lack of ability to upgrade hardware - mostly because of financial issues, I suppose. 10.6 is as far as I know the last Mac OS to support 32 bit systems. Previous versions of my own software supported PPC and down to Mac OS 10.4, which gave me a considerable user base from that segment. Percentages aside, there’s still a LOT of people sitting with old hardware, simply because they cannot afford to upgrade. But is that a significant part of the Mac OS X users or users of Mac OS X Qt applications? I seriously doubt so. Let's be realistic, less and less software are supporting PPC nowadays, the best you can get is a 32/64 bits binary for Mac OS. Last machines from Apple with 32 bits only processor : 2006. One other point is that Qt5 is about QML and is pushing towards its usage on the desktop with better components for it with a modern GL scene graph. Running on outdated graphic cards with outdated graphic drivers is also not something people want to bother testing and fixing. Again let's balance the cost of the maintenance of the code of 10.6 vs supporting few users stuck in the past? If they must stick in the past for various reasons (financial or others) then they can just use Qt4, it works just fine for Mac OS 10.6 or even Qt5 released versions. Why such users would care of modern Qt5 applications? I would really understand people pushing for supporting an outdated OS (and not maintained anymore) on old hardware if they were no alternatives for them : in that case there are - Qt4 or Qt 5.0, 5.1, 5.2 even. People want the benefits for free, how many of the Qt developers/users with outdated 10.6 are actually contributing to fix the port? Other thing I would recommend your user base to be *very* careful with their outdated machine as for example Safari is not updated anymore on Snow Leopard letting the browser very vulnerable to security issues. XP was introduced in 2001. It’s still supported. Mac OS 10.6 was introduced in 2009. I understand the desire to get rid of the messiness under the hood, but I think it should be considered that it cuts out users on hardware platforms not so much up to date. Right but the difference is that Microsoft was not very good at making a decent successor of XP which made most of the people stick with XP. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Alexis Menard ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Remove OSX 10.6 Build?
On 24/01/2014, at 03.46, Alexis Menard men...@kde.org wrote: On Thu, Jan 23, 2014 at 5:16 PM, Jan Farø jan.fa...@gmail.com wrote: I don’t think anybody has mentioned the lack of ability to upgrade hardware - mostly because of financial issues, I suppose. 10.6 is as far as I know the last Mac OS to support 32 bit systems. Previous versions of my own software supported PPC and down to Mac OS 10.4, which gave me a considerable user base from that segment. Percentages aside, there’s still a LOT of people sitting with old hardware, simply because they cannot afford to upgrade. But is that a significant part of the Mac OS X users or users of Mac OS X Qt applications? I seriously doubt so. Let's be realistic, less and less software are supporting PPC nowadays, the best you can get is a 32/64 bits binary for Mac OS. Last machines from Apple with 32 bits only processor : 2006. One other point is that Qt5 is about QML and is pushing towards its usage on the desktop with better components for it with a modern GL scene graph. Running on outdated graphic cards with outdated graphic drivers is also not something people want to bother testing and fixing. I completely agree in regards to PPC support. In regards to users of Mac OS Qt applications: I’m am extremely confident that more Mac OS applications would be/have been written in Qt, if the priority for native looking widget support was higher. Mac OS users are notorious for their attention to detail and noticing a non-native LF. Forcing application developers to resort to Objective C/Cocoa/style sheet hacks/whatever in order to make the UI look and behave more native sort of defies the notion of a cross platform framework. Again let's balance the cost of the maintenance of the code of 10.6 vs supporting few users stuck in the past? If they must stick in the past for various reasons (financial or others) then they can just use Qt4, it works just fine for Mac OS 10.6 or even Qt5 released versions. Why such users would care of modern Qt5 applications? Qt4 looks suboptimal on Mac OS. It still has problems with some of the list widgets. Among other things. Qt5 has several showstopper issues on Mac OS, some of which seems to finally being taken seriously (5.2.1?). You can’t ship a quality application on Mac OS with Qt5.0 - Qt.5.2.0. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Remove OSX 10.6 Build?
On 24/01/2014, at 03.46, Alexis Menard men...@kde.org wrote: snip XP was introduced in 2001. It’s still supported. Mac OS 10.6 was introduced in 2009. I understand the desire to get rid of the messiness under the hood, but I think it should be considered that it cuts out users on hardware platforms not so much up to date. Right but the difference is that Microsoft was not very good at making a decent successor of XP which made most of the people stick with XP. It’s not just that. This also has to do with the cost of upgrading hardware. Charts describing OS destribution, top contributors mentioned): Worldwide: http://gs.statcounter.com/#os-ww-monthly-201212-201312-bar (Win7: 52%, XP: 22%, Mac OS: 7%) Denmark: http://gs.statcounter.com/#os-DK-monthly-201212-201312-bar (Win7: 53%, Mac OS: 16%, iOS: 8.5%) Denmark is a country with big purchasing power. Win XP is almost gone here, below Mac OS and iOS, units usually associated with higher price. China: http://gs.statcounter.com/#os-CN-monthly-201212-201312-bar (XP: 56%, Win7: 36%, Win8: 2%) XP dominates here. One might suspect the cause being less general buying power. Note the lack of Apple hardware in the top. Cuba: http://gs.statcounter.com/#os-CU-monthly-201212-201312-bar (WP: 51%, Win7: 32%, Linux: 6.7% Same here. Note the sudden appearance of Linux. Many Linux distros runs well on lower powered hardware. I doubt that Cubans are die hard Linux fans in general. I don’t think I’m interpreting too much from the above by stating that the popularity of older OS versions are dependent on buying power and geography, not just the existence of replacement candidates. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] First Qt 4.8.6 snapshots available ...
On Thursday 23 January 2014 18:14:12 Salovaara Akseli wrote: Hi all, We have now first snapshots available for Qt 4.8.6 on http://download.qt-project.org/snapshots/qt/4.8/2014-01-23_453/. Could you please check those and verify your fixes? Packages are built against sha1 cf179ef3e38516555ce60517aa8e085b33e75744 QWizard: Fix frame when using Vista style/MSVC2012. Debian testing/unstable users have been using a version ~4 commits before that since some days with no problems so far. Symbols looked ok (as usual, thanks a lot for that!), etc. In other words: what you can expect from a point release :) Kinds regards, Lisandro. -- May the source be with you. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ 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] Remove OSX 10.6 Build?
On sexta-feira, 24 de janeiro de 2014 03:16:54, Jan Farø wrote: XP was introduced in 2001. It’s still supported. We had a thread on that too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] Remove OSX 10.6 Build?
On sexta-feira, 24 de janeiro de 2014 06:20:23, Jan Farø wrote: Worldwide: http://gs.statcounter.com/#os-ww-monthly-201212-201312-bar (Win7: 52%, XP: 22%, Mac OS: 7%) Denmark: http://gs.statcounter.com/#os-DK-monthly-201212-201312-bar (Win7: 53%, Mac OS: 16%, iOS: 8.5%) Denmark is a country with big purchasing power. Win XP is almost gone here, below Mac OS and iOS, units usually associated with higher price. China: http://gs.statcounter.com/#os-CN-monthly-201212-201312-bar (XP: 56%, Win7: 36%, Win8: 2%) XP dominates here. One might suspect the cause being less general buying power. Note the lack of Apple hardware in the top. Cuba: http://gs.statcounter.com/#os-CU-monthly-201212-201312-bar (WP: 51%, Win7: 32%, Linux: 6.7% Same here. Note the sudden appearance of Linux. Many Linux distros runs well on lower powered hardware. I doubt that Cubans are die hard Linux fans in general. I don’t think I’m interpreting too much from the above by stating that the popularity of older OS versions are dependent on buying power and geography, not just the existence of replacement candidates. _ We don't doubt it. But the question is whether those older OS are targets for applications shipping with Qt 5.4. So it's really about the target user base of applications to be released one year from now. It's not about asking Qt users what they'd like. We know the answer: please support OS X on PPC, Windows XP, and please bring back Windows 95, OS/2 and BeOS while you're at it. It's about what will need one year from now. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] New Qt 5.2.1 snapshots available
I'm guessing it has something with the unified title and toolbar on mac fix? On 01/23/2014 10:17 PM, Adam Strzelecki wrote: I have just noticed that OSX 5.2.1 offline snapshot (clang) DMG is 60MB slimmer (396 MB) than it was in 5.2.0 (455 MB). Do you know what is the reason of such difference? Regards, ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Qt-creator] Qt Creator 3.2 dropping support for Mac OS X 10.6
On Jan 23, 2014, at 7:16 PM, Adam Light acli...@gmail.com wrote: All but one developer at my (smallish) company is still using OSX 10.6.8 because we need 10.6 to be able to build the current shipping version of our main product. We all use Qt Creator, so a Creator 3.2 that would not work on 10.6 would be a problem for us. Noted. Let’s see how many others shout. Can you please explain to me though, why you develop on 10.6? You could still target 10.6 from newer OS versions, and have your nightly build / product build machine on 10.6 to be on the safe side for the actual builds, and have a testing machine on 10.6. If you use 10.6 for development, you also use all the other old, no longer updated tools from Apple (gcc, gdb, instruments etc etc). (Can you even test retina/HiDPI on 10.6?) Also note that Qt Creator 3.1 already will no longer support Apple’s gdb, and support for the very old lldb, that you can still somehow get from the paid developer program for 10.6, will be limited. Br, Eike Adam On Thu, Jan 23, 2014 at 4:29 AM, Daniel Teske daniel.te...@digia.com wrote: Hi, Let's make this: Qt Creator 3.2: - drop support for compiling running Qt Creator on 10.6 We want to start using C++11 also in Qt Creator, and 10.6 is the only thing preventing that. Since 10.6 is deployment target only for Qt, we don’t necessarily need to keep “its IDE” running there (yes, that’s a Qt-centric way of looking at Qt Creator). a actual independant proposal (since it doesn't really depend on what qt supports) and cross post it to qt-creator for some wider exposure. Actually using C++11 would also mean bumping the minimum supported compiler for *compiling* Qt Creator. That's somewhat separate, but I would assume we would require at least lamba and auto support for compiling Qt Creator 3.2. That means MSVC 2010, clang 3.1 or g++ 4.5 if I remember correctly. daniel ___ Qt-creator mailing list qt-crea...@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator ___ Qt-creator mailing list qt-crea...@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
