Re: [Development] Loading moc plugins when running tests in CI system
On Tue, 7 Jan 2014 06:18:19 Qi Liang wrote: > Looks like it's a qml plugin, then maybe there is an example/practice in > qtquickcontrols. They are not a QML plugin, they are position and geoservices plugins that happen to have qml in there names for some reason. > https://github.com/qtproject/qtquickcontrols/blob/stable/tests/auto/auto.pro > https://github.com/qtproject/qtquickcontrols/tree/stable/tests/auto/testplu > gin > https://github.com/qtproject/qtquickcontrols/blob/stable/tests/auto/control > s/controls.pro > > controls is using the plugin from testplugin, but controls is a qmltest > here. I see from the logs that the build step the plugins are located in /home/qt/shadowbuild/qtlocation/plugins/geoservices and /home/qt/shadowbuild/qtlocation/plugins/position Is it possible to set QT_PLUGIN_PATH=/home/qt/shadowbuild/qtlocation/plugins during test runs? Cheers, -- Aaron McCarthy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtest-qml osx
Hi, Have you checked the qt auto tests? You could have a look into qtdeclarative/tests/auto (quick) and/or qtquickcontrols/tests/auto folder. There are plenty of tests there and you can probably find some that are relevant to you. Regards, Caroline From: Joshua Kolden [jos...@crackcreative.com] Sent: Monday, January 06, 2014 5:15 PM To: Chao Caroline Cc: Alan Alpert; development@qt-project.org Subject: Re: [Development] qtest-qml osx Thanks, that’s helpful. I didn’t think to just use an import in the qml test file itself. I’ll test today, but it doesn’t seem like that would work with nested objects. If it does then great, but rather non-intuitive magic. Also, currently I’m just stubbing out qml objects to represent c++ objects that would be available to the QML object being tested in the production application. This is appropriate for unit testing, but if I could include the c++ classes in my test runner then I could do integration tests too which would be lovely. Any chance you have an example of that? Thanks, j On Jan 6, 2014, at 4:40 AM, Chao Caroline wrote: > Hi, > > The TestCase doc should refer to QtQuickTest and not QtTest indeed, please > log a documentation bug for it. > > Also I have attached a small example to get you started, with a source > component to test under src/qml and the test file under specs/qml. It should > work with both qmltestrunner or a QUICK_TEST_MAIN. > > You don't need IMPORTPATH here. It is used when you want to load a module > (only qml files or a cpp plugin), which is defined by a qmldir file (in the > attached example it can be for example src/qml/qmldir containing > "module qml > MyRectangle 1.0 MyRectangle.qml") > > Regards, > Caroline > > > > > > From: Joshua Kolden [jos...@crackcreative.com] > Sent: Monday, January 06, 2014 12:40 AM > To: Alan Alpert > Cc: Chao Caroline; development@qt-project.org > Subject: Re: [Development] qtest-qml osx > > On Dec 16, 2013, at 10:44 AM, Alan Alpert <4163654...@gmail.com> wrote: > >> On Mon, Dec 16, 2013 at 3:47 AM, Chao Caroline >> wrote: >> > > > Thanks I didn’t realize any of this since the TestCase docs[0] don’t refer to > the “Qt Quick Test Reference” docs[1]. Which I would suggest is probably a > documentation bug? > > I’ve been able to get the simplest case of this working (despite the docs > being very abstract), but I think I’m seeing a bug when used in my project. > Can someone please confirm it isn't user error before I log the bug? > > In my environment I have source and tests separated into `src/qml`, and > `specs/qml` respectively. > > Regardless if I use the qmltestrunner or a QUICK_TEST_MAIN macro I’m unable > to include components from the src/qml path, so unless the tst_*.qml file is > actually present in that path no components are loaded. This is true whether > I invoke the item with a bare reference, or with `Qt.createComponent()`. > > I’ve tried using the -import command line option as documented, with all > variations on absolute and relative paths to the `src/qml` path. I’ve also > tried `IMPORTPATH`, `INCLUDEPATH`, and `QUICK_TEST_SOURCE_DIR` in the test > .pro file. > > Production qml files are simply not accessible by tests unless I contaminate > the src folder with all the tst_*.qml files (which is a non-starter on this > large of a project). > > Thanks, > j > > > [0] - http://qt-project.org/doc/qt-5/qml-qttest-testcase.html > [1] - http://qt-project.org/doc/qt-5/qtquick-qtquicktest.html > > > > On Dec 16, 2013, at 10:44 AM, Alan Alpert <4163654...@gmail.com> wrote: > >> On Mon, Dec 16, 2013 at 3:47 AM, Chao Caroline >> wrote: >>> Hi, >>> >>> Qt Quick Test is part of Qt (in the qtdeclarative repo). I think the problem >>> here is that you are trying to run a test using qmlscene directly. >>> >>> QML TestCases should be launched via a C++ harness: >>> http://qt-project.org/doc/qt-5/qtquick-qtquicktest.html >>> >> >> The other alternative is the qmltestrunner utility. >> >> qmlscene is not expected to work, nor planned to, but ideally support >> will be added to the new qml utility (such support is not currently in >> place but wouldn't be too hard to add). >> >> -- >> Alan Alpert >> >>> >>> >>> >>> From: development-bounces+caroline.chao=digia@qt-project.org >>> [development-bounces+caroline.chao=digia@qt-project.org] on behalf of >>> Joshua Kolden [jos...@studiopyxis.com] >>> Sent: Sunday, December 15, 2013 11:18 PM >>> To: development@qt-project.org >>> Subject: [Development] qtest-qml osx >>> >>> We have a fairly large qml project, and with 5.2 we are trying to switch to >>> TDD for all components (c++, js (coffescript), QML). Qt Creator and >>> qmlscene in 5.2 both seem to have the same issue that files are missing: >>> qmlscene test1.qml >>> file:///x/d/qt/testDrivenQML/test1.qml:25 Type TestCase unavailable >>> file:///Users/j
Re: [Development] Loading moc plugins when running tests in CI system
Looks like it's a qml plugin, then maybe there is an example/practice in qtquickcontrols. https://github.com/qtproject/qtquickcontrols/blob/stable/tests/auto/auto.pro https://github.com/qtproject/qtquickcontrols/tree/stable/tests/auto/testplugin https://github.com/qtproject/qtquickcontrols/blob/stable/tests/auto/controls/controls.pro controls is using the plugin from testplugin, but controls is a qmltest here. Regards, Liang From: Aaron McCarthy Sent: Tuesday, January 07, 2014 5:12 AM To: development@qt-project.org Subject: [Development] Loading moc plugins when running tests in CI system Hi, Qt Positioning and Qt Location use moc plugins in various test cases. These tests run fine locally with a developer build of Qt but fail when run in the CI system. From what it looks like this is because the moc plugins are not installed and cannot be loaded, see integration failure in [1]. The moc plugins are built under the top-level tests project which is not installed by default. My question is what is the recommended approach to ensure that moc plugins are loadable when running tests in the CI system? [1] https://codereview.qt-project.org/73984 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Loading moc plugins when running tests in CI system
Hi, Qt Positioning and Qt Location use moc plugins in various test cases. These tests run fine locally with a developer build of Qt but fail when run in the CI system. From what it looks like this is because the moc plugins are not installed and cannot be loaded, see integration failure in [1]. The moc plugins are built under the top-level tests project which is not installed by default. My question is what is the recommended approach to ensure that moc plugins are loadable when running tests in the CI system? [1] https://codereview.qt-project.org/73984 Cheers, -- Aaron McCarthy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Plans for printing in 5.3 onwards
Hi, I've spent the last few weeks going over the current print support and trying to map out a plan to improve things. We've long intended to create a new QtPrint module to replace QtPrintSupport in which we separate the painting code from the print job management code and support a more modern workflow including cloud printing. However it's been hard to get started as it's an all-or-nothing approach, and we still need to maintian the old code in parallel. The existing code itself is in a strange state and needing quite some clean-ups still, with a QPA plugin that has been only partially implemented, a lot of code still in the main module behind platform ifdef's rather than in the plugins, major inconsistencies between the behaviour of the platform implementations and even ifdef'd public api. Given my limited time, I've decided to take a different approach to try build the new code over the next few releases as a new set of QPA classes that are then used by the current public api in place of the old plugin code, before later being used for the new public api. This would allow the new code to be throurghly tested with a working front-end in progressive steps, give us a single platform plugin code-base for both apis to be maintained throughout the Qt5 life-span, improve the quality and consistency of the existing print support, and allow new cloud-print plugins to be worked on in the interim so we better understand their requirements. Working on this as a qpa also allows the api to develop organically over the next few releases without having to worry about compatability issues. Once the new qpa classes are completed, then the new public api can be developed to expose all the new features. My aims for the 5.3 release will be to * Define the new qpa print device api and implement support for the 3 core platforms * Use this new class in QPrinterInfo and QPrintEngine to replace the current print device code, ensuring behaviour is consistent across platforms * Remove all the ifdef'd api and platform-specific code from QPrinter, ensuring api and behaviour is consistent across platforms * Remove all platform-specific code from the widgets and dialogs * Improve the auto test framework Longer term, 5.4 could see the addition of the new qpa job ticket and print settings api and their integration into the engines and dialogs, and 5.5 could see the new public api. One major sub-task in there will be to try upgrade our PDF support to full PDF/A standard which may affect the timing. I have a work branch at [1] which implements the new QPlatformPrintDevice api for the 3 platforms and integrates it so far into QPrinterInfo and the Linux QPrintEngine. It also has some new classes QPageSize, QPageMargin and QPageLayout to remove lots of duplicated and error-prone page and margin handling code. Once the Windows and Mac print engine integration is completed I'll start pushing these for review. Cheers! John. P.S. If anyone wants this completed sooner, I'd be happy to discuss sponsorship to allow me to work on it full-time for the next 6 months :-) [1] https://qt.gitorious.org/qt/odysseus-qtbase/commits/a19d77f78f071c207fc07e6c5f003f789d0daa3c ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding Enginio (qtenginio) to the Qt release
On Mon, Jan 6, 2014 at 9:41 AM, Qi Liang wrote: > What is qt modularization for? We want to have different release cycles for > different qt modules. As I recall, that means we want to be able to have different release/versioning cycles, but there will still be a regular Qt release package containing some version of all essential modules (and compatible with some version of all addon modules) even if some haven't bumped their version. > Then +1 for that. > > For offline installer, I suggest, a separate installer for it, but it should > based on installed qt directory. It is compatible with 5.2.0 release in this > way. > For online installer, every module is an option, then not much difference > there. Isn't this the distinction between addon modules and essential modules? Is Frederik asking for enginio to become a "Qt Essential" module? Or am I a little behind in my terminology? -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removing QT_NO_DEBUG_STREAM?
2014/1/6 David Faure > On Monday 06 January 2014 19:43:45 Konstantin Ritt wrote: > > I don't like the idea of removing QT_NO_DEBUG_STREAM. Even if Qt itself > > doesn't build with it (which is fixable), one might define it globally > > after it built, to avoid building an unnecessary code in his/3rd-party > > modules. > > You don't gain anything by defining it in your app, compared to just not > calling qDebug. > > In my app (or in 3rd-party code), there could be classes with debug stream operators. > This isn't the intended usage of QT_NO_* - this was about reducing the > size of > Qt. > > And this remains desirable for some users. > But yeah at this point QT_NO_DEBUG_STREAM should just be removed, the > maintainance pain is not worth it. > > Which maintainance pain, exactly? The typical purpose for debug operators is a convenience, well, in debugging. But that costs. That's why many users (and me) uses a cheap qWarning(msg) for warnings and #ifndef DEBUG_MY_FEATURE \ qdebug() << various << crap; \ #endif for testing/debugging their code. I'd vote for fixing build with QT_NO_DEBUG_STREAM rather than for deleting it. Konstantin > -- > David Faure | david.fa...@kdab.com | Managing Director KDAB France > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, 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 > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removing QT_NO_DEBUG_STREAM?
On Monday 06 January 2014 19:43:45 Konstantin Ritt wrote: > I don't like the idea of removing QT_NO_DEBUG_STREAM. Even if Qt itself > doesn't build with it (which is fixable), one might define it globally > after it built, to avoid building an unnecessary code in his/3rd-party > modules. You don't gain anything by defining it in your app, compared to just not calling qDebug. This isn't the intended usage of QT_NO_* - this was about reducing the size of Qt. But yeah at this point QT_NO_DEBUG_STREAM should just be removed, the maintainance pain is not worth it. -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 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] Removing QT_NO_DEBUG_STREAM?
I don't like the idea of removing QT_NO_DEBUG_STREAM. Even if Qt itself doesn't build with it (which is fixable), one might define it globally after it built, to avoid building an unnecessary code in his/3rd-party modules. We already have #define qDebug QMessageLogger(__FILE__, __LINE__, Q_FUNC_INFO).debug Can not we simply #define qCDebug qDebug and add a respective overloads to QMessageLogger: void debug(const QLoggingCategory &category, const char *msg, ...) const; QDebug debug(onst QLoggingCategory &category) const; to make both `qCDebug(CATEGORY, "blah")` and `qCDebug(CATEGORY) << "blah"` work ? Regards, Konstantin 2014/1/6 Thiago Macieira > On segunda-feira, 6 de janeiro de 2014 15:52:35, Koehne Kai wrote: > > So, anyone would mind if I remove QT_NO_DEBUG_STREAM from the code base? > I > > already started to do so for QtCore: > > https://codereview.qt-project.org/#change,74745 . But it's a lot of > > (tedious) work to do for the other modules too, so I thought I'd ask for > > opinions here before wasting more time > > Go ahead, I don't mind removing it. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding Enginio (qtenginio) to the Qt release
What is qt modularization for? We want to have different release cycles for different qt modules. Then +1 for that. For offline installer, I suggest, a separate installer for it, but it should based on installed qt directory. It is compatible with 5.2.0 release in this way. For online installer, every module is an option, then not much difference there. Regards, Liang From: Frederik Gladhorn Sent: Monday, January 06, 2014 5:23 PM To: development@qt-project.org; releas...@qt-project.org Subject: [Development] Adding Enginio (qtenginio) to the Qt release Hello, we (some of us at Digia) have been working on Enginio - a convenient cloud storage for Qt applications. Since the library is actively maintained we would like to integrate it into the official Qt release for Qt 5.3. For those curious now, there is already the option to get it when using the Qt 5.2 online installer. For more information see http://engin.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding Enginio (qtenginio) to the Qt release
Mandag 6. januar 2014 15.35.14 skrev Thiago Macieira: > On segunda-feira, 6 de janeiro de 2014 17:23:43, Frederik Gladhorn wrote: > > Hello, > > > > we (some of us at Digia) have been working on Enginio - a convenient cloud > > storage for Qt applications. Since the library is actively maintained we > > would like to integrate it into the official Qt release for Qt 5.3. > > Suppose ownCloud wants to add their own code. Should we have another module > or should we have qtcloud as a module? This is a very good question. There are also a few more project ideas from within Digia, so a more general cloud module might make sense. -- Best regards, Frederik Gladhorn Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding Enginio (qtenginio) to the Qt release
On segunda-feira, 6 de janeiro de 2014 17:23:43, Frederik Gladhorn wrote: > Hello, > > we (some of us at Digia) have been working on Enginio - a convenient cloud > storage for Qt applications. Since the library is actively maintained we > would like to integrate it into the official Qt release for Qt 5.3. Suppose ownCloud wants to add their own code. Should we have another module or should we have qtcloud as a module? -- 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] Removing QT_NO_DEBUG_STREAM?
On segunda-feira, 6 de janeiro de 2014 15:52:35, Koehne Kai wrote: > So, anyone would mind if I remove QT_NO_DEBUG_STREAM from the code base? I > already started to do so for QtCore: > https://codereview.qt-project.org/#change,74745 . But it's a lot of > (tedious) work to do for the other modules too, so I thought I'd ask for > opinions here before wasting more time Go ahead, I don't mind removing it. -- 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] Building qtwebkit with -gstabs instead of -g on certain archs
On Monday 06 January 2014 16:08:12 Allan Sandfeld Jensen wrote: > On Monday 06 January 2014, Oswald Buddenhagen wrote: > > On Sat, Dec 28, 2013 at 02:51:41PM -0300, Lisandro Damián Nicanor Pérez > > Meyer wrote: > > > The archs arm, i386, i686, mips and s390 can get their memory exhausted > > > when building QtWebkit, so at least on Debian we are replacing -g with > > > -gstabs for those archs. As I understand this comes from a suggestion by > > > Ossi. > > > > i was only relaying info. i don't remember if that particular idea came > > from allan or somebody else. > > > > > I would like to know if you would like to have this replacement done in > > > Qt itself (ie, if you would accept a patch to do this) or if you prefer > > > us downstreamers doing it. > > > > this affects everyone making debug builds, so it should be upstream. > > however, this is something the qtwebkit team needs to decide. > > I would like to point to https://codereview.qt-project.org/#change,72361 > which reduces the memory while linking by eliminating duplicate symbols in > the dwarf2 or dwarf4 tables. It also instructs the gnu linker to use a > slower O(n) table instead of the default O(n*log(n)) table. > > Perhaps Debian can try that patch and gives us feedback? I will definitely test that patch, but saddly not in the inmediate future, but I'll do my best to do it ASAP. Thanks! -- 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
[Development] Adding Enginio (qtenginio) to the Qt release
Hello, we (some of us at Digia) have been working on Enginio - a convenient cloud storage for Qt applications. Since the library is actively maintained we would like to integrate it into the official Qt release for Qt 5.3. For those curious now, there is already the option to get it when using the Qt 5.2 online installer. For more information see http://engin.io -- Best regards, Frederik Gladhorn Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtest-qml osx
Thanks, that’s helpful. I didn’t think to just use an import in the qml test file itself. I’ll test today, but it doesn’t seem like that would work with nested objects. If it does then great, but rather non-intuitive magic. Also, currently I’m just stubbing out qml objects to represent c++ objects that would be available to the QML object being tested in the production application. This is appropriate for unit testing, but if I could include the c++ classes in my test runner then I could do integration tests too which would be lovely. Any chance you have an example of that? Thanks, j On Jan 6, 2014, at 4:40 AM, Chao Caroline wrote: > Hi, > > The TestCase doc should refer to QtQuickTest and not QtTest indeed, please > log a documentation bug for it. > > Also I have attached a small example to get you started, with a source > component to test under src/qml and the test file under specs/qml. It should > work with both qmltestrunner or a QUICK_TEST_MAIN. > > You don't need IMPORTPATH here. It is used when you want to load a module > (only qml files or a cpp plugin), which is defined by a qmldir file (in the > attached example it can be for example src/qml/qmldir containing > "module qml > MyRectangle 1.0 MyRectangle.qml") > > Regards, > Caroline > > > > > > From: Joshua Kolden [jos...@crackcreative.com] > Sent: Monday, January 06, 2014 12:40 AM > To: Alan Alpert > Cc: Chao Caroline; development@qt-project.org > Subject: Re: [Development] qtest-qml osx > > On Dec 16, 2013, at 10:44 AM, Alan Alpert <4163654...@gmail.com> wrote: > >> On Mon, Dec 16, 2013 at 3:47 AM, Chao Caroline >> wrote: >> > > > Thanks I didn’t realize any of this since the TestCase docs[0] don’t refer to > the “Qt Quick Test Reference” docs[1]. Which I would suggest is probably a > documentation bug? > > I’ve been able to get the simplest case of this working (despite the docs > being very abstract), but I think I’m seeing a bug when used in my project. > Can someone please confirm it isn't user error before I log the bug? > > In my environment I have source and tests separated into `src/qml`, and > `specs/qml` respectively. > > Regardless if I use the qmltestrunner or a QUICK_TEST_MAIN macro I’m unable > to include components from the src/qml path, so unless the tst_*.qml file is > actually present in that path no components are loaded. This is true whether > I invoke the item with a bare reference, or with `Qt.createComponent()`. > > I’ve tried using the -import command line option as documented, with all > variations on absolute and relative paths to the `src/qml` path. I’ve also > tried `IMPORTPATH`, `INCLUDEPATH`, and `QUICK_TEST_SOURCE_DIR` in the test > .pro file. > > Production qml files are simply not accessible by tests unless I contaminate > the src folder with all the tst_*.qml files (which is a non-starter on this > large of a project). > > Thanks, > j > > > [0] - http://qt-project.org/doc/qt-5/qml-qttest-testcase.html > [1] - http://qt-project.org/doc/qt-5/qtquick-qtquicktest.html > > > > On Dec 16, 2013, at 10:44 AM, Alan Alpert <4163654...@gmail.com> wrote: > >> On Mon, Dec 16, 2013 at 3:47 AM, Chao Caroline >> wrote: >>> Hi, >>> >>> Qt Quick Test is part of Qt (in the qtdeclarative repo). I think the problem >>> here is that you are trying to run a test using qmlscene directly. >>> >>> QML TestCases should be launched via a C++ harness: >>> http://qt-project.org/doc/qt-5/qtquick-qtquicktest.html >>> >> >> The other alternative is the qmltestrunner utility. >> >> qmlscene is not expected to work, nor planned to, but ideally support >> will be added to the new qml utility (such support is not currently in >> place but wouldn't be too hard to add). >> >> -- >> Alan Alpert >> >>> >>> >>> >>> From: development-bounces+caroline.chao=digia@qt-project.org >>> [development-bounces+caroline.chao=digia@qt-project.org] on behalf of >>> Joshua Kolden [jos...@studiopyxis.com] >>> Sent: Sunday, December 15, 2013 11:18 PM >>> To: development@qt-project.org >>> Subject: [Development] qtest-qml osx >>> >>> We have a fairly large qml project, and with 5.2 we are trying to switch to >>> TDD for all components (c++, js (coffescript), QML). Qt Creator and >>> qmlscene in 5.2 both seem to have the same issue that files are missing: >>> qmlscene test1.qml >>> file:///x/d/qt/testDrivenQML/test1.qml:25 Type TestCase unavailable >>> file:///Users/joshua/Qt5.2.0/5.2.0/clang_64/qml/QtTest/TestCase.qml:45 >>> module "Qt.test.qtestroot" is not installed >>> >>> >>> qt-labs/qtest-qml has a merge request under ‘review’ from 2 years ago!! It >>> refers to a problem with OSX installation (OSX is our primary development >>> environment). I have not been able to test this issue on other platforms, >>> but noticing that both the merge request and the README install directions >>> for qtest-qml a
[Development] Removing QT_NO_DEBUG_STREAM?
Hi, Today I've stumbled another time over QT_NO_DEBUG_STREAM ... you know, one of this infamous QT_NO macros that we keep 'alive' by mere copy and paste :) And because it's a new year, a new dawn , etc, I decided to do something about it. - I'm pretty sure nobody could compile QtCore with QT_NO_DEBUG_STREAM since at least 2009 ... see e.g. QTBUG-18418 . Right now it errors right at qstring.cpp. - I'd like to replace most qDebug() qWarning() calls with their qCDebug()/qCWarning() equivalents inside Qt , which would result in a whole lot of #ifdef'ing if we keep QT_NO_DEBUG_STREAM So, anyone would mind if I remove QT_NO_DEBUG_STREAM from the code base? I already started to do so for QtCore: https://codereview.qt-project.org/#change,74745 . But it's a lot of (tedious) work to do for the other modules too, so I thought I'd ask for opinions here before wasting more time :) Regards Kai PS: A less invasive patch would be to only check for QT_NO_DEBUG_STREAM when it comes to operator<< for data types outside of QtCore. Anyway, given that we don't have the check in the CI I'm pretty sure it'll break over time, again. -- Kai Köhne, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Building add-in installer
On 04.01.2014 17:04, Pau Garcia i Quiles wrote: > But it says nothing about building the installer for the Qt VS Add-in. That's because the open source repository doesn't contain the files needed to build the installers. The actual installer files where never publicly released, because they are part of the old Trolltech NSIS installers. It would be quite a bit of work to extract the add-in related parts from that Gordian knot. > If I have understood tools\buildAddin\buildAddin.cmd correctly, I need > one clone of the VS Tools repository for each version of Visual Studio I > want to support. Is that so? Are there instructions somewhere? Yes, for every supported Visual Studio version you'll need a clone. The script assumes that all VS versions are installed on the machine. For building installers it uses a magic script called iwmake. You may find it somewhere in a forgotten Qt clone on the net but I bet the addin config files will be missing. Sorry, I know this answer is disappointing, but if you need to build installers for the VS add-in it would be easiest to create installer files yourself and contribute them to the project. Regards, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] This sequence for rebuilding a new qtbase on OSX doesn't work...
cd qt5 git checkout release git submodule update git submodule foreach 'git clean -dxf' // this doesn't work properly git submodule foreach 'git reset --hard' git submodule foreach 'git checkout release ||:' git submodule foreach 'git pull --rebase ||:' ./configure -developer-build -confirm-license -opensource -no-xcb -nomake examples -nomake tests make module-qtbase-qmake_all make module-qtbase I get compilation errors. i.e. it can't find several .h files in angle brackets e.g. To fix it, I have to do this: cd qtbase git clean -dxf make Is there something wrong with git submodule foreach 'git clean -dxf' ? martin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Building qtwebkit with -gstabs instead of -g on certain archs
On Monday 06 January 2014, Oswald Buddenhagen wrote: > On Sat, Dec 28, 2013 at 02:51:41PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > > The archs arm, i386, i686, mips and s390 can get their memory exhausted > > when building QtWebkit, so at least on Debian we are replacing -g with > > -gstabs for those archs. As I understand this comes from a suggestion by > > Ossi. > > i was only relaying info. i don't remember if that particular idea came > from allan or somebody else. > > > I would like to know if you would like to have this replacement done in > > Qt itself (ie, if you would accept a patch to do this) or if you prefer > > us downstreamers doing it. > > this affects everyone making debug builds, so it should be upstream. > however, this is something the qtwebkit team needs to decide. I would like to point to https://codereview.qt-project.org/#change,72361 which reduces the memory while linking by eliminating duplicate symbols in the dwarf2 or dwarf4 tables. It also instructs the gnu linker to use a slower O(n) table instead of the default O(n*log(n)) table. Perhaps Debian can try that patch and gives us feedback? Best regards `Allan Jensen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtest-qml osx
Hello Sze-Howe, I have re-opened this bug and added a comment, thanks. Caroline From: Sze Howe Koh [szehowe@gmail.com] Sent: Monday, January 06, 2014 3:44 PM To: Chao Caroline Cc: Joshua Kolden; development@qt-project.org Subject: Re: [Development] qtest-qml osx On 6 January 2014 20:40, Chao Caroline wrote: > Hi, > > The TestCase doc should refer to QtQuickTest and not QtTest indeed, please > log a documentation bug for it. > > Also I have attached a small example to get you started, with a source > component to test under src/qml and the test file under specs/qml. It should > work with both qmltestrunner or a QUICK_TEST_MAIN. > > You don't need IMPORTPATH here. It is used when you want to load a module > (only qml files or a cpp plugin), which is defined by a qmldir file (in the > attached example it can be for example src/qml/qmldir containing > "module qml > MyRectangle 1.0 MyRectangle.qml") > > Regards, > Caroline Hi, See https://bugreports.qt-project.org/browse/QTBUG-33587. It's marked as 'Closed', but should be re-opened. Regards, Sze-Howe > > From: Joshua Kolden [jos...@crackcreative.com] > Sent: Monday, January 06, 2014 12:40 AM > To: Alan Alpert > Cc: Chao Caroline; development@qt-project.org > Subject: Re: [Development] qtest-qml osx > > On Dec 16, 2013, at 10:44 AM, Alan Alpert <4163654...@gmail.com> wrote: > >> On Mon, Dec 16, 2013 at 3:47 AM, Chao Caroline >> wrote: >> > > > Thanks I didn’t realize any of this since the TestCase docs[0] don’t refer to > the “Qt Quick Test Reference” docs[1]. Which I would suggest is probably a > documentation bug? > > I’ve been able to get the simplest case of this working (despite the docs > being very abstract), but I think I’m seeing a bug when used in my project. > Can someone please confirm it isn't user error before I log the bug? > > In my environment I have source and tests separated into `src/qml`, and > `specs/qml` respectively. > > Regardless if I use the qmltestrunner or a QUICK_TEST_MAIN macro I’m unable > to include components from the src/qml path, so unless the tst_*.qml file is > actually present in that path no components are loaded. This is true whether > I invoke the item with a bare reference, or with `Qt.createComponent()`. > > I’ve tried using the -import command line option as documented, with all > variations on absolute and relative paths to the `src/qml` path. I’ve also > tried `IMPORTPATH`, `INCLUDEPATH`, and `QUICK_TEST_SOURCE_DIR` in the test > .pro file. > > Production qml files are simply not accessible by tests unless I contaminate > the src folder with all the tst_*.qml files (which is a non-starter on this > large of a project). > > Thanks, > j > > > [0] - http://qt-project.org/doc/qt-5/qml-qttest-testcase.html > [1] - http://qt-project.org/doc/qt-5/qtquick-qtquicktest.html > > > > On Dec 16, 2013, at 10:44 AM, Alan Alpert <4163654...@gmail.com> wrote: > >> On Mon, Dec 16, 2013 at 3:47 AM, Chao Caroline >> wrote: >>> Hi, >>> >>> Qt Quick Test is part of Qt (in the qtdeclarative repo). I think the problem >>> here is that you are trying to run a test using qmlscene directly. >>> >>> QML TestCases should be launched via a C++ harness: >>> http://qt-project.org/doc/qt-5/qtquick-qtquicktest.html >>> >> >> The other alternative is the qmltestrunner utility. >> >> qmlscene is not expected to work, nor planned to, but ideally support >> will be added to the new qml utility (such support is not currently in >> place but wouldn't be too hard to add). >> >> -- >> Alan Alpert >> >>> >>> >>> >>> From: development-bounces+caroline.chao=digia@qt-project.org >>> [development-bounces+caroline.chao=digia@qt-project.org] on behalf of >>> Joshua Kolden [jos...@studiopyxis.com] >>> Sent: Sunday, December 15, 2013 11:18 PM >>> To: development@qt-project.org >>> Subject: [Development] qtest-qml osx >>> >>> We have a fairly large qml project, and with 5.2 we are trying to switch to >>> TDD for all components (c++, js (coffescript), QML). Qt Creator and >>> qmlscene in 5.2 both seem to have the same issue that files are missing: >>> qmlscene test1.qml >>> file:///x/d/qt/testDrivenQML/test1.qml:25 Type TestCase unavailable >>> file:///Users/joshua/Qt5.2.0/5.2.0/clang_64/qml/QtTest/TestCase.qml:45 >>> module "Qt.test.qtestroot" is not installed >>> >>> >>> qt-labs/qtest-qml has a merge request under ‘review’ from 2 years ago!! It >>> refers to a problem with OSX installation (OSX is our primary development >>> environment). I have not been able to test this issue on other platforms, >>> but noticing that both the merge request and the README install directions >>> for qtest-qml are both very dated I thought it might be better just to ask >>> here if this is dead, or is it supposed to work in 5.2 / OSX? Docs for >>> TestCase in 5.2 imply that it’ll work the same as any QML Type. >>> >
Re: [Development] HEADS UP: Qt 5.2.1 - merge stable into release
On Mon, Jan 06, 2014 at 02:01:53PM +0100, Frederik Gladhorn wrote: > we'd like to make Enginio part of the release. qtenginio behaves like any > other module. What are the criteria for it to become part of a regular > release? > you should start a separate thread for that. nobody complains, lars says ok, and you're in. ^^ anyway, this is 5.3 material. there is no way to promote a module in a patch release. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cleanup open requests in Gerrit?
On Mon, Dec 30, 2013 at 03:36:13PM +0100, Kurt Pattyn wrote: > I noticed that the oldest open item in Gerrit dates back to 7 October 2011. > There are around 2000 items still open. I suppose a lot of them are not > relevant anymore. > > Wouldn’t it a good idea that the maintainers of the different modules in Qt > go through them and either discard them or merge them? > a forced auto-cleanup was already agreed upon, and is going to happen Soon ™. see http://qt-project.org/wiki/Gerrit-Auto-Cleanup it actually would have already happened if the tests of my script didn't reveal yet another bug in gerrit, which means we need to wait for The Gerrit Upgrade ™. for the record, the script would have abandoned slightly over 1000 changes as of end of november. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtest-qml osx
On 6 January 2014 20:40, Chao Caroline wrote: > Hi, > > The TestCase doc should refer to QtQuickTest and not QtTest indeed, please > log a documentation bug for it. > > Also I have attached a small example to get you started, with a source > component to test under src/qml and the test file under specs/qml. It should > work with both qmltestrunner or a QUICK_TEST_MAIN. > > You don't need IMPORTPATH here. It is used when you want to load a module > (only qml files or a cpp plugin), which is defined by a qmldir file (in the > attached example it can be for example src/qml/qmldir containing > "module qml > MyRectangle 1.0 MyRectangle.qml") > > Regards, > Caroline Hi, See https://bugreports.qt-project.org/browse/QTBUG-33587. It's marked as 'Closed', but should be re-opened. Regards, Sze-Howe > > From: Joshua Kolden [jos...@crackcreative.com] > Sent: Monday, January 06, 2014 12:40 AM > To: Alan Alpert > Cc: Chao Caroline; development@qt-project.org > Subject: Re: [Development] qtest-qml osx > > On Dec 16, 2013, at 10:44 AM, Alan Alpert <4163654...@gmail.com> wrote: > >> On Mon, Dec 16, 2013 at 3:47 AM, Chao Caroline >> wrote: >> > > > Thanks I didn’t realize any of this since the TestCase docs[0] don’t refer to > the “Qt Quick Test Reference” docs[1]. Which I would suggest is probably a > documentation bug? > > I’ve been able to get the simplest case of this working (despite the docs > being very abstract), but I think I’m seeing a bug when used in my project. > Can someone please confirm it isn't user error before I log the bug? > > In my environment I have source and tests separated into `src/qml`, and > `specs/qml` respectively. > > Regardless if I use the qmltestrunner or a QUICK_TEST_MAIN macro I’m unable > to include components from the src/qml path, so unless the tst_*.qml file is > actually present in that path no components are loaded. This is true whether > I invoke the item with a bare reference, or with `Qt.createComponent()`. > > I’ve tried using the -import command line option as documented, with all > variations on absolute and relative paths to the `src/qml` path. I’ve also > tried `IMPORTPATH`, `INCLUDEPATH`, and `QUICK_TEST_SOURCE_DIR` in the test > .pro file. > > Production qml files are simply not accessible by tests unless I contaminate > the src folder with all the tst_*.qml files (which is a non-starter on this > large of a project). > > Thanks, > j > > > [0] - http://qt-project.org/doc/qt-5/qml-qttest-testcase.html > [1] - http://qt-project.org/doc/qt-5/qtquick-qtquicktest.html > > > > On Dec 16, 2013, at 10:44 AM, Alan Alpert <4163654...@gmail.com> wrote: > >> On Mon, Dec 16, 2013 at 3:47 AM, Chao Caroline >> wrote: >>> Hi, >>> >>> Qt Quick Test is part of Qt (in the qtdeclarative repo). I think the problem >>> here is that you are trying to run a test using qmlscene directly. >>> >>> QML TestCases should be launched via a C++ harness: >>> http://qt-project.org/doc/qt-5/qtquick-qtquicktest.html >>> >> >> The other alternative is the qmltestrunner utility. >> >> qmlscene is not expected to work, nor planned to, but ideally support >> will be added to the new qml utility (such support is not currently in >> place but wouldn't be too hard to add). >> >> -- >> Alan Alpert >> >>> >>> >>> >>> From: development-bounces+caroline.chao=digia@qt-project.org >>> [development-bounces+caroline.chao=digia@qt-project.org] on behalf of >>> Joshua Kolden [jos...@studiopyxis.com] >>> Sent: Sunday, December 15, 2013 11:18 PM >>> To: development@qt-project.org >>> Subject: [Development] qtest-qml osx >>> >>> We have a fairly large qml project, and with 5.2 we are trying to switch to >>> TDD for all components (c++, js (coffescript), QML). Qt Creator and >>> qmlscene in 5.2 both seem to have the same issue that files are missing: >>> qmlscene test1.qml >>> file:///x/d/qt/testDrivenQML/test1.qml:25 Type TestCase unavailable >>> file:///Users/joshua/Qt5.2.0/5.2.0/clang_64/qml/QtTest/TestCase.qml:45 >>> module "Qt.test.qtestroot" is not installed >>> >>> >>> qt-labs/qtest-qml has a merge request under ‘review’ from 2 years ago!! It >>> refers to a problem with OSX installation (OSX is our primary development >>> environment). I have not been able to test this issue on other platforms, >>> but noticing that both the merge request and the README install directions >>> for qtest-qml are both very dated I thought it might be better just to ask >>> here if this is dead, or is it supposed to work in 5.2 / OSX? Docs for >>> TestCase in 5.2 imply that it’ll work the same as any QML Type. >>> >>> Also in a separate note, the new Qt Creator crashes consistently when trying >>> to create a new qt quick project through the interface. >>> >>> Thanks for the hard work! >>> >>> Best, >>> j ___ Development mailing list Development@qt-project.org http://lists.qt-p
Re: [Development] Building qtwebkit with -gstabs instead of -g on certain archs
On Sat, Dec 28, 2013 at 02:51:41PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > The archs arm, i386, i686, mips and s390 can get their memory exhausted when > building QtWebkit, so at least on Debian we are replacing -g with -gstabs for > those archs. As I understand this comes from a suggestion by Ossi. > i was only relaying info. i don't remember if that particular idea came from allan or somebody else. > I would like to know if you would like to have this replacement done in Qt > itself (ie, if you would accept a patch to do this) or if you prefer us > downstreamers doing it. > this affects everyone making debug builds, so it should be upstream. however, this is something the qtwebkit team needs to decide. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: Qt 5.2.1 - merge stable into release
Hi, we'd like to make Enginio part of the release. qtenginio behaves like any other module. What are the criteria for it to become part of a regular release? (I can do the merge myself, but I wouldn't mind if it was part of the big merge etc.) Greetings, Frederik Fredag 3. januar 2014 13.35.30 skrev Paaso Matti: > Hi, > > We are about to start the "Qt 5.2.1" release as agreed in [1], which means > that: > > - We plan to do a fast-forward merge from 'stable' into 'release' branch > on Jan 13th. > > - After Jan 13th any changes that are required for 5.2.1 need to be > pushed to the 'release' branch. So if your changes are not in by that > day, please wait until the merge is done and re-target them to the > 'release' branch. > > The repositories that will be part of the Qt 5.2.1 release merge are: > > - qt5 > - qtactiveqt > - qtandroidextras > - qtbase > - qtconnectivity > - qtdeclarative > - qtdoc > - qtgraphicaleffects > - qtimageformats > - qtlocation > - qtmacextras > - qtmultimedia > - qtquick1 > - qtquickcontrols > - qtscript > - qtsensors > - qtserialport > - qtsvg > - qttools > - qttranslations > - qtwebkit > - qtwebkit-examples > - qtwinextras > - qtxmlpatterns > - qtx11extras > > [1]: > http://lists.qt-project.org/pipermail/releasing/2013-December/001557.html > > Cheers, > -- > Matti Paaso > SW Engineer - Digia, Qt -- Best regards, Frederik Gladhorn Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtest-qml osx
Hi, The TestCase doc should refer to QtQuickTest and not QtTest indeed, please log a documentation bug for it. Also I have attached a small example to get you started, with a source component to test under src/qml and the test file under specs/qml. It should work with both qmltestrunner or a QUICK_TEST_MAIN. You don't need IMPORTPATH here. It is used when you want to load a module (only qml files or a cpp plugin), which is defined by a qmldir file (in the attached example it can be for example src/qml/qmldir containing "module qml MyRectangle 1.0 MyRectangle.qml") Regards, Caroline From: Joshua Kolden [jos...@crackcreative.com] Sent: Monday, January 06, 2014 12:40 AM To: Alan Alpert Cc: Chao Caroline; development@qt-project.org Subject: Re: [Development] qtest-qml osx On Dec 16, 2013, at 10:44 AM, Alan Alpert <4163654...@gmail.com> wrote: > On Mon, Dec 16, 2013 at 3:47 AM, Chao Caroline > wrote: > Thanks I didn’t realize any of this since the TestCase docs[0] don’t refer to the “Qt Quick Test Reference” docs[1]. Which I would suggest is probably a documentation bug? I’ve been able to get the simplest case of this working (despite the docs being very abstract), but I think I’m seeing a bug when used in my project. Can someone please confirm it isn't user error before I log the bug? In my environment I have source and tests separated into `src/qml`, and `specs/qml` respectively. Regardless if I use the qmltestrunner or a QUICK_TEST_MAIN macro I’m unable to include components from the src/qml path, so unless the tst_*.qml file is actually present in that path no components are loaded. This is true whether I invoke the item with a bare reference, or with `Qt.createComponent()`. I’ve tried using the -import command line option as documented, with all variations on absolute and relative paths to the `src/qml` path. I’ve also tried `IMPORTPATH`, `INCLUDEPATH`, and `QUICK_TEST_SOURCE_DIR` in the test .pro file. Production qml files are simply not accessible by tests unless I contaminate the src folder with all the tst_*.qml files (which is a non-starter on this large of a project). Thanks, j [0] - http://qt-project.org/doc/qt-5/qml-qttest-testcase.html [1] - http://qt-project.org/doc/qt-5/qtquick-qtquicktest.html On Dec 16, 2013, at 10:44 AM, Alan Alpert <4163654...@gmail.com> wrote: > On Mon, Dec 16, 2013 at 3:47 AM, Chao Caroline > wrote: >> Hi, >> >> Qt Quick Test is part of Qt (in the qtdeclarative repo). I think the problem >> here is that you are trying to run a test using qmlscene directly. >> >> QML TestCases should be launched via a C++ harness: >> http://qt-project.org/doc/qt-5/qtquick-qtquicktest.html >> > > The other alternative is the qmltestrunner utility. > > qmlscene is not expected to work, nor planned to, but ideally support > will be added to the new qml utility (such support is not currently in > place but wouldn't be too hard to add). > > -- > Alan Alpert > >> >> >> >> From: development-bounces+caroline.chao=digia@qt-project.org >> [development-bounces+caroline.chao=digia@qt-project.org] on behalf of >> Joshua Kolden [jos...@studiopyxis.com] >> Sent: Sunday, December 15, 2013 11:18 PM >> To: development@qt-project.org >> Subject: [Development] qtest-qml osx >> >> We have a fairly large qml project, and with 5.2 we are trying to switch to >> TDD for all components (c++, js (coffescript), QML). Qt Creator and >> qmlscene in 5.2 both seem to have the same issue that files are missing: >> >>> qmlscene test1.qml >> file:///x/d/qt/testDrivenQML/test1.qml:25 Type TestCase unavailable >> file:///Users/joshua/Qt5.2.0/5.2.0/clang_64/qml/QtTest/TestCase.qml:45 >> module "Qt.test.qtestroot" is not installed >> >> >> qt-labs/qtest-qml has a merge request under ‘review’ from 2 years ago!! It >> refers to a problem with OSX installation (OSX is our primary development >> environment). I have not been able to test this issue on other platforms, >> but noticing that both the merge request and the README install directions >> for qtest-qml are both very dated I thought it might be better just to ask >> here if this is dead, or is it supposed to work in 5.2 / OSX? Docs for >> TestCase in 5.2 imply that it’ll work the same as any QML Type. >> >> Also in a separate note, the new Qt Creator crashes consistently when trying >> to create a new qt quick project through the interface. >> >> Thanks for the hard work! >> >> Best, >> j >> >> >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> example_qmltest.tar.gz Description: example_qmltest.tar.gz ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Coding style proposal
On Thursday 02 January 2014 21:04:27 Jiergir Ogoerg wrote: > buffer() // getter > buffer_set(..) // setter > BufferSupportsFind() // bool > > selection() // getter > SelectionMove(..) // move selection > selection_set(..) // setter > SelectionUnset(...) // unset something You might find the std policy of having the same name for getter and setter (differing in constness and argument count) interesting, then: off_t pos = buffer.pos(); buffer.pos(pos + 1); -- Marc Mutz | 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] OK to add zero/bulk copy to QVector?
On Monday 30 December 2013 00:24:58 Jiergir Ogoerg wrote: > And because of that I have to (can) resize() it, A better way is to reserve() + push_back(), but IIRC QVector never contains uninitialised memory. std::vector, however, does, and expands to less code, too, with private element types such as yours. > and resizing sucks > because it not just creates > more space for the internal buffer but also initializes each item to > the default value. ...so does new[]... > QComposeTableElement *elem; > vec->reserve(kElemCount); > > for(int i=0; i elem = (QComposeTableElement*) (buf + (i * kElemSize)); > vec->push_back(*elem); > } you should use push_back(qMove(*elem)) and implement the move operation on QComposableTableElement. -- Marc Mutz | 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] OK to add zero/bulk copy to QVector?
On Monday 30 December 2013 02:42:25 Konstantin Ritt wrote: > > the 1st one is created automatically when the parent class > > is created which holds the vector, and a second vector is created when > calling "fromRawData()" when I got the data on the heap to replace > the vector's buffer. > > >From the one side, looking to the "QVector(const T *data, int size)" API, > > one'd say QVector copies the data so that the original data could be freed > (because we do that everywhere else, look i.e. QString, QByteArray, > etc.)...surprise; > > >From the other side, creating a null QVector() (by using a default ctor) > >is > > no-alloc operation and costs you near to nothing (note Qt containers use > the power of COW). "QVector data = QVector::fromRawData(dataPtr, > dataSize)" costs you near to nothing once again but has a pretty nice, > non-ambiguous "fromRawData" name. It actually costs nothing. And if you can't co-locate definition and first assignment, use QVector::swap() for fast assignment. -- Marc Mutz | 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
