Re: [Development] QGLWidget creation with non-visible parent
Hi I had the same similar issue, I was using a parent widget, with buttons and a frame with a child qglwidget derived class. What I did was to create a method in the child qglwidget derived class to initialize the shaders, and I only calls this method inside the showEvent() of the parent widget class. Regards Joao de Deus Em Sexta-feira, 29 de Novembro de 2013 6:58, Csaba Csernai csernai.cs...@gmail.com escreveu: Hi everyone! I would like to ask your help in some Qt 5 matter. I think it's somewhat related to QTBUG-31451, but not sure. When I create a QGLWidget with a parent which not yet visible, then it seems to fail to compile shaders although QGLContext is valid( at least the isValid function returns true). e.g.: there is a tab widget, which is visible, and from code we add another tab, so that it contains a QWidget and inside the QWidget, there is a QGLWidget( yeah, i kno w it's messed up, but that's it). So when we create the QGLWidget with the QWidget parent, the QWidget is not visible, and - as far as i discovered - it has no window handle. It worked fine, in 4.8, and i compile with msvc 11.0. My question is that is it a bug or did I miss something? Would someone point me in the right direction?Should i post my findings to the mentioned bug thread or create a new one? Thanks. Bye, -- Csaba Csernai C/C++ Software Developer Mediso Medical Imaging Systems Ltd. Hungary, H-1022 Budapest, Alsótörökvész 14. ___ 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] QGLWidget creation with non-visible parent
Thanks your tip. I thought about it, but the problem is that many other object created that are depending on shaders and also all the configuration, data uploading, etc. are handled before the first showEvent occurring. It is possible to make a workaround, but really it would be a hell of a work. That's why I am hoping it will be fixed in the next release maybe, if it's an error. Best regards, Csaba Csernai 2013/11/29 joao morgado joaodeusmorg...@yahoo.com Hi I had the same similar issue, I was using a parent widget, with buttons and a frame with a child qglwidget derived class. What I did was to create a method in the child qglwidget derived class to initialize the shaders, and I only calls this method inside the showEvent() of the parent widget class. Regards Joao de Deus Em Sexta-feira, 29 de Novembro de 2013 6:58, Csaba Csernai csernai.cs...@gmail.com escreveu: Hi everyone! I would like to ask your help in some Qt 5 matter. I think it's somewhat related to QTBUG-31451, but not sure. When I create a QGLWidget with a parent which not yet visible, then it seems to fail to compile shaders although QGLContext is valid( at least the isValid function returns true). e.g.: there is a tab widget, which is visible, and from code we add another tab, so that it contains a QWidget and inside the QWidget, there is a QGLWidget( yeah, i kno w it's messed up, but that's it). So when we create the QGLWidget with the QWidget parent, the QWidget is not visible, and - as far as i discovered - it has no window handle. It worked fine, in 4.8, and i compile with msvc 11.0. My question is that is it a bug or did I miss something? Would someone point me in the right direction?Should i post my findings to the mentioned bug thread or create a new one? Thanks. Bye, -- Csaba Csernai C/C++ Software Developer Mediso Medical Imaging Systems Ltd. Hungary, H-1022 Budapest, Alsótörökvész 14. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Csaba Csernai C/C++ Software Developer Mediso Medical Imaging Systems Ltd. Hungary, H-1022 Budapest, Alsótörökvész 14. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] OpenGL drivers
Hi, As many of you might already have noticed, OpenGL drivers are not always working as well as would like. This has always been a problem, but since Qt Creator 3.0 is using Qt Quick 2.0 and Qt Quick 2.0 is also being used in more and more places, the problem is becoming more mainstream. We are aware of several issues and patched Qt to tackle them, but we expect we will need more. To figure out what needs to be done, we need a broader picture. Long term, the solution for Qt might be that we bundle a software GL implementation (llvmpipe for instance) and switch to that if a driver is too problematic for us. Hopefully, we can get by with applying workarounds in Qt though. So, I'm asking that if you encounter issues with flickering, crashes, bad rendering and similar, help us track which things are problematic by filing a bugreport on bugreports.qt-project.org and use the label driverissue in the task. Please include OS, windowing system, graphics hardware and driver version. And since most of the workarounds have been applied to Qt 5.2, do test against the 5.2 RC1 or later. Some other things that might help while identifying the problem is: - Does upgrading driver or installing latest vendor supplied driver help? - QSG_RENDER_LOOP=basic - switch Qt Quick to use the GUI thread for rendering - QSG_INFO=1 - make Qt Quick output SG and GL information. - LIBGL_ALWAYS_SOFTWARE=1 - for Linux/Mesa based only, forces use of software Mesa rendering - How does other GL applications in the system fare and what about Qt's OpenGL examples? - vsynced or not? thanks, Gunnar Please don't reply to this mail to report issues :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2 RC1 candidate packages available
On 11/29/2013 12:06 AM, development-requ...@qt-project.org wrote: Message: 5 Date: Thu, 28 Nov 2013 13:36:56 + From: Heikkinen Janijani.heikki...@digia.com Subject: [Development] Qt 5.2 RC1 candidate packages available To:development@qt-project.org development@qt-project.org Cc:releas...@qt-project.org releas...@qt-project.org Message-ID: f2d121d33acdd34db72834d8e8b2378d2a4...@it-exmb01-hki.it.local Content-Type: text/plain; charset=us-ascii Hi all, We have finally Qt 5.2 RC1 candidate packages available inhttp://download.qt-project.org/snapshots/qt/5.2/5.2.0-rc1/2013-11-28_179/ . Mirroring is ongoing so it is possible that all packages aren't visible yet but will be soon ... These packages will be RC1 packages if there isn't any new RC1 blocker found during testing. Target is to release RC1 tomorrow so please check packages as soon as possible. Please report your testing effort viahttp://testresults.qt-project.org/forms/release-testing form and in case of new bugs report those in JIRAhttps://bugreports.qt-project.org . Change after previous packages: https://codereview.qt-project.org/72647 (workaround forhttps://bugreports.qt-project.org/browse/QTBUG-35143 : Scene graph threaded render loop deadlocks on X11) Br, Jani The version of QtCreator shipped with the package crashes my x everytime i attempt to launch it. It was the Android Linux x86_64 package running on openSUSE 12.3 with Enlightenment as the window manager and the proprietary NVIDIA Driver Cheers Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2 RC1 candidate packages available
Simon Lees [simon.l...@codanradio.com] The version of QtCreator shipped with the package crashes my x everytime i attempt to launch it. It was the Android Linux x86_64 package running on openSUSE 12.3 with Enlightenment as the window manager and the proprietary NVIDIA Driver Could you try to add the '-noload Welcome' command line option when starting Qt Creator and see whether this still crashed immediately? (The option prevents loading of the Qt Quick 2 based Welcome screen, session management would still be available under Files-Sessions/ Files-Session Manager) Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL drivers
As many of you might already have noticed, OpenGL drivers are not always working as well as would like. To what extent does this apply to different platforms and vendors? Is Qt doing anything different from other GL apps on the same platform or are they facing the same issues? On 29 November 2013 12:27, Sletta Gunnar gunnar.sle...@digia.com wrote: Hi, As many of you might already have noticed, OpenGL drivers are not always working as well as would like. This has always been a problem, but since Qt Creator 3.0 is using Qt Quick 2.0 and Qt Quick 2.0 is also being used in more and more places, the problem is becoming more mainstream. We are aware of several issues and patched Qt to tackle them, but we expect we will need more. To figure out what needs to be done, we need a broader picture. Long term, the solution for Qt might be that we bundle a software GL implementation (llvmpipe for instance) and switch to that if a driver is too problematic for us. Hopefully, we can get by with applying workarounds in Qt though. So, I'm asking that if you encounter issues with flickering, crashes, bad rendering and similar, help us track which things are problematic by filing a bugreport on bugreports.qt-project.org and use the label driverissue in the task. Please include OS, windowing system, graphics hardware and driver version. And since most of the workarounds have been applied to Qt 5.2, do test against the 5.2 RC1 or later. Some other things that might help while identifying the problem is: - Does upgrading driver or installing latest vendor supplied driver help? - QSG_RENDER_LOOP=basic - switch Qt Quick to use the GUI thread for rendering - QSG_INFO=1 - make Qt Quick output SG and GL information. - LIBGL_ALWAYS_SOFTWARE=1 - for Linux/Mesa based only, forces use of software Mesa rendering - How does other GL applications in the system fare and what about Qt's OpenGL examples? - vsynced or not? thanks, Gunnar Please don't reply to this mail to report issues :) ___ 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] http://qt-project.org/wiki/Qt520-RC1-KnownIssues
Hi Jani, On Thu, Nov 28, 2013 at 6:18 PM, Heikkinen Jani jani.heikki...@digia.com mailto:jani.heikki...@digia.com wrote: Qt 5.2 RC1 is coming really soon (hoping tomorrow) so please make sure all important known issues is listed in known issues wiki: http://qt-project.org/wiki/Qt520-RC1-KnownIssues I'm having various problems with qtquick/qtwebkit failing to deploy on Mac OS X in the rc1 release - I've logged them under https://bugreports.qt-project.org/browse/QTBUG-35211 with a sample app attached. There may be a full workaround, but I've not discovered it yet. (I'm not a member of the QT project so I'm not sure if this is something that should be added to the wiki page, nor if it would be correct protocol for me to add it.) Thanks Joseph ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL drivers
On Friday 29 November 2013 14:20:48 Robert Knight wrote: As many of you might already have noticed, OpenGL drivers are not always working as well as would like. To what extent does this apply to different platforms and vendors? Is Qt doing anything different from other GL apps on the same platform or are they facing the same issues? I think it's just that we're trying to use OpenGL on many machines that would otherwise not use it and therefore finding all of the old or otherwise broken drivers or misconfigurations or problematic hardware. For anybody with an Optimus setup or running with an Intel GPU on Windows, please try updating your drivers as they have improved very rapidly in the last 12 months or so. Cheers, Sean -- 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] Integration of qt5.git
Hello all, I would like to get feedback about a change in the qt5.git integration that I have discussed with several people in Digia's Oslo office. For those that don't know what I'm talking about: we have the meta repository qt5.git that has all other modules as git submodule. When you clone qt5 and run the init-repository script it checks out the submodules according to the current state of qt5.git. Currently we have a bot doing merges and someone needs to approve them. Once a merge (this is per branch, release/stable/dev) is approved it gets run though CI, just like any other patch. Then all modules are built and all tests run. When all tests pass we have the submodules updated and the game starts anew. The good thing is that usually qt5.git is in a state where it works and it's tested. One issue is that most people working on Qt have all branches checked out to release/stable/dev to a newer state and work on that. But more importantly we need qt5.git to be updated for the release. Usually updating qt5.git works, but sometimes it turns out to take a lot of time and is major work. As you may have noticed it takes a long time to update the packages and this is one factor contributing to that. I'd like to propose the following: Automate qt5.git integration completely (the bot updates the modules and instantly stages the update), this could happen around 3 times per day. This integration would not run any tests and should generally just succeed unless we break compilation of one modules by changing it's dependencies (happens very seldom). Failures send email to this mailing list. Since we lose the test runs for all modules at the same time I'd like to have a second and new job in Jenkins that runs nightly and builds and runs all tests of all modules (according to qt5.git state). This job doesn't mean anything for the integration and doesn't block but simply sends mail to this list whenever any test fails. I actually expect it to fail regularily since we have quite a few unstable unit tests that every once in a while fail. I hope that this approach gives actually more visibility to failing auto tests than what we currently have. I hope all in all this lets us move faster and get releases out with less pain and stress since it's faster to include a patch or two in the release branch. And it lessens the different experiences people have when checking out qt5.git. Cheers Frederik ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] http://qt-project.org/wiki/Qt520-RC1-KnownIssues
On sexta-feira, 29 de novembro de 2013 14:48:23, Joseph Heenan wrote: (I'm not a member of the QT project so I'm not sure if this is something that should be added to the wiki page, nor if it would be correct protocol for me to add it.) You're a member of the Qt Project if you want to be a member. Just start doing work and you can consider yourself a member :-) -- 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] OpenGL drivers
On sexta-feira, 29 de novembro de 2013 12:27:44, Sletta Gunnar wrote: So, I'm asking that if you encounter issues with flickering, crashes, bad rendering and similar, help us track which things are problematic by filing a bugreport on bugreports.qt-project.org and use the label driverissue in the task. Please include OS, windowing system, graphics hardware and driver version. And since most of the workarounds have been applied to Qt 5.2, do test against the 5.2 RC1 or later. Do you consider fonts looking the wrong size to be bad rendering and a driver issue? Fonts in the Creator welcome screen look to be of a different size than the rest of Creator. I'd consider it a font issue only, not a driver issue. -- 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
[Development] isValid() as a property
Is it common/uncommon/unheard-of to have a 'valid' property: Q_PROPERTY( bool valid READ isValid NOTIFY validChanged ) I'm thinking about classes like 'DeviceLocation' which would update with GPS changes, but at some point might just become invalid (or start invalid, until GPS turns on, etc). So should isValid() only be used for 'typical' cases of, like default-constructed value-types, or is it fine as a property? Thoughts? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] isValid() as a property
Imho isValid is fine, but generally I would suggest a more context specific name, i.e. locationKnown for example. Think about how much sense valid makes in the context of the caller code and see of you can find a better name perhaps. Simon Fra: Tony Van Eerd Sendt: 20:16 fredag 29. november 2013 Til: development@qt-project.org Emne: [Development] isValid() as a property Is it common/uncommon/unheard-of to have a 'valid' property: Q_PROPERTY( bool valid READ isValid NOTIFY validChanged ) I'm thinking about classes like 'DeviceLocation' which would update with GPS changes, but at some point might just become invalid (or start invalid, until GPS turns on, etc). So should isValid() only be used for 'typical' cases of, like default-constructed value-types, or is it fine as a property? Thoughts? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ 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] isValid() as a property
Oh, the other thing I wanted to mention: in the cases I am looking at, if isValid() == false, then all the other properties are invalid, and return , -1, etc. It really does mean the whole object is invalid. (except maybe an 'id', in the case of, say, a Battery object - the id telling you which battery, and then isValid() saying that battery doesn't (currently) exist.) ie it means isValid() in the same sense as all the other uses of isValid() in Qt classes. That's why I was leaning towards the same name. Although, yes, I was considering a different name per class, more context specific. From: Hausmann Simon [mailto:simon.hausm...@digia.com] Sent: Friday, November 29, 2013 2:20 PM To: Tony Van Eerd; development@qt-project.org Subject: SV: [Development] isValid() as a property Imho isValid is fine, but generally I would suggest a more context specific name, i.e. locationKnown for example. Think about how much sense valid makes in the context of the caller code and see of you can find a better name perhaps. Simon Fra: Tony Van Eerd Sendt: 20:16 fredag 29. november 2013 Til: development@qt-project.org Emne: [Development] isValid() as a property Is it common/uncommon/unheard-of to have a 'valid' property: Q_PROPERTY( bool valid READ isValid NOTIFY validChanged ) I'm thinking about classes like 'DeviceLocation' which would update with GPS changes, but at some point might just become invalid (or start invalid, until GPS turns on, etc). So should isValid() only be used for 'typical' cases of, like default-constructed value-types, or is it fine as a property? Thoughts? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Integration of qt5.git
On Fri, Nov 29, 2013 at 05:16:31PM +, Gladhorn Frederik wrote: Hello all, I would like to get feedback about a change in the qt5.git integration that I have discussed with several people in Digia's Oslo office. For those that don't know what I'm talking about: we have the meta repository qt5.git that has all other modules as git submodule. When you clone qt5 and run the init-repository script it checks out the submodules according to the current state of qt5.git. Currently we have a bot doing merges and someone needs to approve them. Once a merge (this is per branch, release/stable/dev) is approved it gets run though CI, just like any other patch. Then all modules are built and all tests run. When all tests pass we have the submodules updated and the game starts anew. The good thing is that usually qt5.git is in a state where it works and it's tested. One issue is that most people working on Qt have all branches checked out to release/stable/dev to a newer state and work on that. But more importantly we need qt5.git to be updated for the release. Usually updating qt5.git works, but sometimes it turns out to take a lot of time and is major work. As you may have noticed it takes a long time to update the packages and this is one factor contributing to that. I'd like to propose the following: Automate qt5.git integration completely (the bot updates the modules and instantly stages the update), this could happen around 3 times per day. This integration would not run any tests and should generally just succeed unless we break compilation of one modules by changing it's dependencies (happens very seldom). Failures send email to this mailing list. Since we lose the test runs for all modules at the same time I'd like to have a second and new job in Jenkins that runs nightly and builds and runs all tests of all modules (according to qt5.git state). This job doesn't mean anything for the integration and doesn't block but simply sends mail to this list whenever any test fails. I actually expect it to fail regularily since we have quite a few unstable unit tests that every once in a while fail. I hope that this approach gives actually more visibility to failing auto tests than what we currently have. I hope all in all this lets us move faster and get releases out with less pain and stress since it's faster to include a patch or two in the release branch. And it lessens the different experiences people have when checking out qt5.git. I am very much in favour. In an ideal world, this should not be needed, but the world does not appear to be ideal... The scheme is fairly close to what Qt Creator's use of CI looks like (non-blocking, nag mails if things break, nothing stopping quick fixes), and it's a state that I am rather happy with. Sure, things can break theoretically, and do in practice every now and then, but a build breakage can be fixed in a minute - the latter part slightly in contrast to qt5.git. Since the main use of qt5.git is to _release_ stuff, its setup and policies should cater to exactly that need first. If it works for other use cases that's fine, but in no way essential. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Integration of qt5.git
Once scenario I'm worried about is when a less active module (say qtscript) has a regression test failure due to a change in an active module (qtbase) and it's only visible in the qt5.git integration (because nobody submits a change to qtscript). We will see the failure still, but we will also be very very tempted to still cut a release from qt5.git because of schedules etc. , despite the failure. Currently we have a mechanism in place that makes it very hard to release in such a situation. We are removing this protection and am replacing an automated mechanism with a human gate keeper. I'm not against trying this, but we have to be very careful I think, more discipline will be required from the release side or else we will release with known regressions. Simon Fra: Gladhorn Frederik Sendt: 18:16 fredag 29. november 2013 Til: development@qt-project.org Emne: [Development] Integration of qt5.git Hello all, I would like to get feedback about a change in the qt5.git integration that I have discussed with several people in Digia's Oslo office. For those that don't know what I'm talking about: we have the meta repository qt5.git that has all other modules as git submodule. When you clone qt5 and run the init-repository script it checks out the submodules according to the current state of qt5.git. Currently we have a bot doing merges and someone needs to approve them. Once a merge (this is per branch, release/stable/dev) is approved it gets run though CI, just like any other patch. Then all modules are built and all tests run. When all tests pass we have the submodules updated and the game starts anew. The good thing is that usually qt5.git is in a state where it works and it's tested. One issue is that most people working on Qt have all branches checked out to release/stable/dev to a newer state and work on that. But more importantly we need qt5.git to be updated for the release. Usually updating qt5.git works, but sometimes it turns out to take a lot of time and is major work. As you may have noticed it takes a long time to update the packages and this is one factor contributing to that. I'd like to propose the following: Automate qt5.git integration completely (the bot updates the modules and instantly stages the update), this could happen around 3 times per day. This integration would not run any tests and should generally just succeed unless we break compilation of one modules by changing it's dependencies (happens very seldom). Failures send email to this mailing list. Since we lose the test runs for all modules at the same time I'd like to have a second and new job in Jenkins that runs nightly and builds and runs all tests of all modules (according to qt5.git state). This job doesn't mean anything for the integration and doesn't block but simply sends mail to this list whenever any test fails. I actually expect it to fail regularily since we have quite a few unstable unit tests that every once in a while fail. I hope that this approach gives actually more visibility to failing auto tests than what we currently have. I hope all in all this lets us move faster and get releases out with less pain and stress since it's faster to include a patch or two in the release branch. And it lessens the different experiences people have when checking out qt5.git. Cheers Frederik ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] isValid() as a property
On Fri, 29 Nov 2013, Tony Van Eerd wrote: in the cases I am looking at, if isValid() == false, then all the other properties are invalid, and return , -1, etc. It really does mean the whole object is invalid. (except maybe an 'id', in the case of, say, a Battery object - the id telling you which battery, and then isValid() saying that battery doesn't (currently) exist.) Why not use exists, present, active or something like it? But a C++ object for a physical object that does not exist... why is it there in the first place? Harri.___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Integration of qt5.git
On Fri, Nov 29, 2013 at 09:19:33PM +, Hausmann Simon wrote: Once scenario I'm worried about is when a less active module (say qtscript) has a regression test failure due to a change in an active module (qtbase) and it's only visible in the qt5.git integration (because nobody submits a change to qtscript). We will see the failure still, but we will also be very very tempted to still cut a release from qt5.git because of schedules etc. , despite the failure. That's not really different from severe performance regressions, or regressions that hit most user setups, but accidentally not the CI machines etc etc. As an example, for a bit more than two weeks now I have quite a few test cases failing locally which happily pass CI. _Of course_ this means that something is broken with my local setup, especially since this happened after a distro upgrade, but what system makes sure that the Real World is more similar to what the CI system sees to what my system sees? I can easily produce dozens of examples from the past where fundamentally wrong changes got CI approval, as well as examples of case where good changes got rejected. There are examples of unwanted behaviour changes that passed CI because the same change also changed the auto-test, etc. No CI system is infallible, and if we accept that, it's better to have a way to recover quickly, and not wait a full day, or two, to get obvious fixes in. Currently we have a mechanism in place that makes it very hard to release in such a situation. I am afraid this is a misconception. And even if it was not, the benefits would have to be weighed against the costs. Not every CI failure is fatal for the release, and CI checks only a small fraction of possible failures. This should be handled at face value: an advice, strong advice even, but not as a final judgement. We are removing this protection and am replacing an automated mechanism with a human gate keeper. Indeed. And that's a good thing, since it allows a balanced decision. I'm not against trying this, but we have to be very careful I think, more discipline will be required from the release side or else we will release with known regressions. Not different from now. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] isValid() as a property
On Fri, 29 Nov 2013, Tony Van Eerd wrote: in the cases I am looking at, if isValid() == false, then all the other properties are invalid, and return , -1, etc. It really does mean the whole object is invalid. (except maybe an 'id', in the case of, say, a Battery object - the id telling you which battery, and then isValid() saying that battery doesn't (currently) exist.) Why not use exists, present, active or something like it? 'present' was in fact my first choice (for battery at least). But since the behaviour seems to match that of isValid(), why not isValid()? If we could (ie if we didn't care about compatibility), would we rename all the other isValid() functions on existing Qt classes? If not, what is the difference? If there is a difference, and a clear rule when to use isValid() and when not to, I'd be quite happy. But I want to understand the difference first. But a C++ object for a physical object that does not exist... why is it there in the first place? Essentially because we don't throw exceptions in constructors. BatteryInfo battery(5); // the 5th battery. if (battery.exists()) We could have a battery-manager that instead hands out the batteries (so never hands out an invalid one) but: - BatteryInfo is a QObject (for signals, like the battery level changing) and I'd prefer not to return allocated objects (and then need to deal with ownership). It would be fine if they were value-types, but they aren't. - even if the BatteryInfo started out existing, it could be removed while still running (on some devices) Harri. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] isValid() as a property
On Fri, Nov 29, 2013 at 3:03 PM, Tony Van Eerd tvane...@blackberry.com wrote: On Fri, 29 Nov 2013, Tony Van Eerd wrote: in the cases I am looking at, if isValid() == false, then all the other properties are invalid, and return , -1, etc. It really does mean the whole object is invalid. (except maybe an 'id', in the case of, say, a Battery object - the id telling you which battery, and then isValid() saying that battery doesn't (currently) exist.) Why not use exists, present, active or something like it? 'present' was in fact my first choice (for battery at least). But since the behaviour seems to match that of isValid(), why not isValid()? If we could (ie if we didn't care about compatibility), would we rename all the other isValid() functions on existing Qt classes? If not, what is the difference? If there is a difference, and a clear rule when to use isValid() and when not to, I'd be quite happy. But I want to understand the difference first. As I understand it, we want to use isValid in all those cases where the behavior matches exactly - this makes the Qt APIs more memorable and more guessable (used a previous class with this behavior? Just try isValid, see if it compiles ;) ). But a C++ object for a physical object that does not exist... why is it there in the first place? Essentially because we don't throw exceptions in constructors. BatteryInfo battery(5); // the 5th battery. if (battery.exists()) If you start on a QML API, a similar issue occurs. Because there's no way to handle construction exceptions gracefully, you'd need to be able to declare an object and then for error handling (which could mean no backing object could be created) then they bind to a property like this. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Integration of qt5.git
On Fri, Nov 29, 2013 at 12:50 PM, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: On Fri, Nov 29, 2013 at 05:16:31PM +, Gladhorn Frederik wrote: Hello all, [...] Since we lose the test runs for all modules at the same time I'd like to have a second and new job in Jenkins that runs nightly and builds and runs all tests of all modules (according to qt5.git state). This job doesn't mean anything for the integration and doesn't block but simply sends mail to this list whenever any test fails. I actually expect it to fail regularily since we have quite a few unstable unit tests that every once in a while fail. I hope that this approach gives actually more visibility to failing auto tests than what we currently have. Regular emails from a bot broadcast to devel when the break could be anywhere in qt5.git's submodules... I'm not sure that will be effective for getting it fixed. Despite the recent marketing blitz, people only really step up to fix someone else's tests when it's blocking their integration. Is it possible to have a more targeted approach, like it emailing the relevant maintainer(s) instead (or a QA team, if we still have one)? [...] Since the main use of qt5.git is to _release_ stuff, its setup and policies should cater to exactly that need first. If it works for other use cases that's fine, but in no way essential. I concur. The only time I hear about qt5.git is around release time and I'd rather not hear about it at all (that is to say, the process should work so smoothly and well that it never comes up ;) ). Do what you feel is necessary. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
