From thiago.macieira at intel.com Tue Nov 1 00:01:04 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 31 Oct 2016 16:01:04 -0700 Subject: [Development] Nominating James McDonnell for approver status In-Reply-To: <20161031175759.GA19662@polaris.localdomain> References: <20161031175759.GA19662@polaris.localdomain> Message-ID: <2600534.btVR8lGgpv@tjmaciei-mobl1> On segunda-feira, 31 de outubro de 2016 15:58:00 PDT Rafael Roquetto wrote: > Hello, > > I would like to propose the nomination of James McDonnell for approver > status. James works at QNX and has been actively contributing with the > maintenance of Qt on QNX. Apart from all the patches he submitted and > general bugfixing, he has also been a very good helping hand when it comes > to testing pre-release versions of Qt on QNX. +1 He's very knowledgeable and it would be very good to have more people with QNX knowledge with the right to approve changes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lars.knoll at qt.io Tue Nov 1 09:14:19 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 1 Nov 2016 08:14:19 +0000 Subject: [Development] Nominating James McDonnell for approver status In-Reply-To: <2600534.btVR8lGgpv@tjmaciei-mobl1> References: <20161031175759.GA19662@polaris.localdomain> <2600534.btVR8lGgpv@tjmaciei-mobl1> Message-ID: <3CE23C32-5971-4D09-8CFD-9B03019FD765@qt.io> +1 from my side. Another hand on QNX will be very welcome :) Cheers, Lars On 01/11/16 00:01, "Development on behalf of Thiago Macieira" wrote: >On segunda-feira, 31 de outubro de 2016 15:58:00 PDT Rafael Roquetto wrote: >> Hello, >> >> I would like to propose the nomination of James McDonnell for approver >> status. James works at QNX and has been actively contributing with the >> maintenance of Qt on QNX. Apart from all the patches he submitted and >> general bugfixing, he has also been a very good helping hand when it comes >> to testing pre-release versions of Qt on QNX. > >+1 > >He's very knowledgeable and it would be very good to have more people with QNX >knowledge with the right to approve changes. > >-- >Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From coroberti at gmail.com Tue Nov 1 09:41:24 2016 From: coroberti at gmail.com (Robert Iakobashvili) Date: Tue, 1 Nov 2016 10:41:24 +0200 Subject: [Development] Dictation Issues with Qt-built software Message-ID: Dear Qt-Management and Developers, People cannot dictate to Qt-software at Mac as filed: https://bugreports.qt.io/browse/QTBUG-56811 The very reason to bother you and write this email is because a similar previous dictation related issue at Windows filed in 2014 is still pending without being resolved: https://bugreports.qt.io/browse/QTBUG-43046 Dictation on Mac and Windows platforms is improving, and it is vital as the input method for many people with dyslexia, dysgraphia and motoric disorders. Fixing these issues is not something that is supposed to bring high profits; notwithstanding, I hope that it could get priority. Thank you in advance. Kind regards, Robert From oswald.buddenhagen at qt.io Tue Nov 1 12:17:52 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 1 Nov 2016 12:17:52 +0100 Subject: [Development] Distributing 3rd party closed source libs In-Reply-To: <4ceeae28-2a26-d636-ef54-29c034d60815@theharmers.co.uk> References: <2158717.MPJuvCE9X9@tjmaciei-mobl1> <4ceeae28-2a26-d636-ef54-29c034d60815@theharmers.co.uk> Message-ID: <20161101111752.GB23099@troll08> On Mon, Oct 31, 2016 at 01:06:04PM +0000, Sean Harmer wrote: > On 31/10/2016 09:22, Lars Knoll wrote: > > It might make sense to rethink this, and provide those plugins as > > standalone source packages, that can be easily compiled within > > creator by our users. That would of probably also require that they > > live in a repository separate from qtbase (for SQL) or qt3d (in your > > case). > > I like that idea. We could add those repos as source only options to > the Qt SDK installer to make it easy for end user developers. > > To this end, could somebody create us a qt3d-plugins git repo and > gerrit project please? > no way. every repository adds effort with merging and releasing, and i see no compelling reason to do this here. one way to deal with this is having some fragmentation logic at the packaging level, to create multiple (heterogenous) packages from the same repository. however, our releasing folks don't like that too much for quite understandable reasons. an alternative would be adding some magic to treat selected plugin projects specially, just as we do with examples: the "binary" build actually install only sources if -no-compile-plugins is passed to configure. how should the project structure look like? $$[QT_INSTALL_DATA]/plugins would actually put the sources right next to the compiled plugins in a default install. From thiago.macieira at intel.com Tue Nov 1 16:44:41 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 01 Nov 2016 08:44:41 -0700 Subject: [Development] Distributing 3rd party closed source libs In-Reply-To: <4ceeae28-2a26-d636-ef54-29c034d60815@theharmers.co.uk> References: <4ceeae28-2a26-d636-ef54-29c034d60815@theharmers.co.uk> Message-ID: <1743462.0RUgK5pCXM@tjmaciei-mobl1> On segunda-feira, 31 de outubro de 2016 13:06:04 PDT Sean Harmer wrote: > > It might make sense to rethink this, and provide those plugins as > > standalone source packages, that can be easily compiled within creator by > > our users. That would of probably also require that they live in a > > repository separate from qtbase (for SQL) or qt3d (in your case). > I like that idea. We could add those repos as source only options to the > Qt SDK installer to make it easy for end user developers. > > To this end, could somebody create us a qt3d-plugins git repo and gerrit > project please? Is it really too difficult to download the qt3d source tarball, cd somewhere, type qmake && make? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Wed Nov 2 09:15:29 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 2 Nov 2016 08:15:29 +0000 Subject: [Development] Qt 5.8.0 Beta packages for testing Message-ID: Hi all, We have Qt 5.8.0 beta packages available here: Linux: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/558/ Windows: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/634/ Mac: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/581/ src:http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/latest_src/ Unfortunately iOS one is still missing (we have some weird timestamp issue there), hoping we can get it soon. But all other packages are there & RTA smoke tested. All known blockers are fixed & packages seems to be OK according to RTA so please test the packages. We will release these packages as Qt 5.8.0 beta later (this week?) if no new blockers found during testing. Packages are based on https://codereview.qt-project.org/#/c/175057/ br, Jani From sirspudd at gmail.com Wed Nov 2 13:31:47 2016 From: sirspudd at gmail.com (Donald Carr) Date: Wed, 02 Nov 2016 12:31:47 +0000 Subject: [Development] Distributing 3rd party closed source libs In-Reply-To: <1743462.0RUgK5pCXM@tjmaciei-mobl1> References: <4ceeae28-2a26-d636-ef54-29c034d60815@theharmers.co.uk> <1743462.0RUgK5pCXM@tjmaciei-mobl1> Message-ID: > Is it really too difficult to download the qt3d source tarball, cd somewhere, > type qmake && make? It does make this kind of functionality hard to test for people outside of the hardened Qt community. Well documented manual processes are always an acceptable baseline, but they introduce a barrier to entry which is why I am glad this discussion is occurring. > $$[QT_INSTALL_DATA]/plugins would actually put the sources right next to > the compiled plugins in a default install. sounds very transparent and would allow someone to see every proprietary plugin available to them, but only for users who build their own Qt, and only once they stub their toes on this practice. To a certain extent it is a pity there is no tool similar to the Qt SDK installer client for Qt itself, which would allow you to at least centrally pull down modules requiring manual intervention. Deploying modules which need to be manually compiled in a massive larger tarball completely occludes their existence to all but the familiar. Compare a list of 6 or available plugins which require further requirements and compilation to a subdir somewhere in the complete qt versioned source package. The argument about going outside of distro package management is moot since we are talking about proprietary license restricted plugins and every other development platform on earth now steps on the toes of the local distro package manager in the name of convenience. > It might make sense to rethink this, and provide those plugins as standalone source packages, that can be easily compiled within creator by our users. The discrete source package (created when the qt release tarball is created?) sounds like a good start to centralizing these for localized consideration. //* Looking forward to qt-plugins-dirty packages in the package manager :p If I were to use this plugin itself, the first thing I would currently do is create an aur recipe for it (doing exactly what Thiago suggested) under Arch Linux, but this is clearly a suboptimal reality since it does not improve/solve visibility, hits one narrow audience and still is a hacky extension to the package manager.) *// On Tue, Nov 1, 2016 at 3:45 PM Thiago Macieira wrote: > On segunda-feira, 31 de outubro de 2016 13:06:04 PDT Sean Harmer wrote: > > > It might make sense to rethink this, and provide those plugins as > > > standalone source packages, that can be easily compiled within creator > by > > > our users. That would of probably also require that they live in a > > > repository separate from qtbase (for SQL) or qt3d (in your case). > > I like that idea. We could add those repos as source only options to the > > Qt SDK installer to make it easy for end user developers. > > > > To this end, could somebody create us a qt3d-plugins git repo and gerrit > > project please? > > Is it really too difficult to download the qt3d source tarball, cd > somewhere, > type qmake && make? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From perezmeyer at gmail.com Wed Nov 2 15:31:39 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Wed, 02 Nov 2016 11:31:39 -0300 Subject: [Development] Distributing 3rd party closed source libs In-Reply-To: References: Message-ID: <2914152.2a7U7Lfnok@tonks> On lunes, 31 de octubre de 2016 9:22:34 A. M. ART Lars Knoll wrote: [snip] > We’re facing the same problem in a couple of places in Qt. For > postgres/mysql we provide a precompiles plugin, but don’t ship the client > libs which has proven to be problematic, as users wonder why it doesn’t > work, or because of BC issues on Windows. > Other SQL plugins such as Oracle or DB2 are only reachable through compiling > the source code. Unfortunately we don’t make that easy currently, as these > plugins are shipped as part of qtbase, not as a standalone package. > It might make sense to rethink this, and provide those plugins as standalone > source packages, that can be easily compiled within creator by our users. > That would of probably also require that they live in a repository separate > from qtbase (for SQL) or qt3d (in your case). I don't know for sure if this is similar to the eglfs backends situation, that require proprietary stuff to be present in order to let Qt support them (if this is really the case, feel free to correct me). But if it is the chance to have a separate source to be able to compile the required plugin would be just great, specially for distros. Again, feel free to correct me here, I'll really appreciate it :) -- 1: Una computadora sirve: * Para tratar de dominar el mundo, un caso conocido de esto fue el de Skinet Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Wed Nov 2 22:35:00 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Nov 2016 14:35:00 -0700 Subject: [Development] Is DirectFB dead? In-Reply-To: <2727141.SGAePnMyrS@tjmaciei-mobl4> References: <19012436.GgXnARiVH2@tjmaciei-mobl4> <2727141.SGAePnMyrS@tjmaciei-mobl4> Message-ID: <2460062.EK0QnxepRt@tjmaciei-mobl1> Em quarta-feira, 16 de março de 2016, às 10:17:01 PDT, Thiago Macieira escreveu: > On quarta-feira, 16 de março de 2016 09:13:23 PDT Holger Freyther wrote: > > But your approach seems fine, deprecate it in 5.7 (and print a big warning > > on configure?) and see if any of the users are willing to invest in the > > maintenance. > > https://codereview.qt-project.org/152522 > > ChangeLog note only, no configure output. Note that DirectFB seems to be back, but under a new domain because the old one got squatted. http://directfb.net -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From cf.natali at gmail.com Thu Nov 3 08:14:50 2016 From: cf.natali at gmail.com (=?UTF-8?Q?Charles=2DFran=C3=A7ois_Natali?=) Date: Thu, 3 Nov 2016 07:14:50 +0000 Subject: [Development] QAbstractSocket::ShareAddress, SO_REUSEADDR and SO_REUSEPORT Message-ID: Hello, I'm not familiar with the Qt development process so apologies if it's not the correct list, but I'd like to know if someone could have a look at this issue: https://bugreports.qt.io/browse/QTBUG-33419 Basically QAbstractSocket::ShareAddress uses SO_REUSEPORT on recent-ish Linux kernels, and unfortunately it doesn't have the same semantics as SO_REUSEADDR, which broke several valid use cases. The bug report contains more details and a proposed patch. Cheers, Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From milla.pohjanheimo at qt.io Thu Nov 3 10:17:57 2016 From: milla.pohjanheimo at qt.io (Milla Pohjanheimo) Date: Thu, 3 Nov 2016 09:17:57 +0000 Subject: [Development] Removal of some of the blacklisted (non-working) autotests? Message-ID: Hi all, I would like to challenge you a bit about removal of (some of) the blacklisted autotests. We have around fifty autotest functions in different Qt modules that have been blacklisted on all platforms. (The list of those can be found at the end of this email). In total there are over 300 tests in all Qt modules that are blacklisted on some plaforms including those fifty I mentioned earlier. The blacklisted tests are one (big) problem we have, but another problem is that the blacklisted tests also burden our CI, since even though a test is blacklisted, it is still compiled and run in the CI. So basically we have dead code that gets compiled and run, but it's not used anywhere, just sucking up CI resources. Should we just delete at least those tests that are blacklisted on all platforms? Or remove all those that have been blacklisted more than 6 months ago? Ideally those should be fixed/rewritten of course, but who would do that? Fixing the tests requires knowledge of the code itself it's testing. Don't be scared of loosing the tests completely. If something is removed from gerrit it still leaves a mark and one can get the deleted tests back rather easily, right? There should be a bug report in jira for every blacklisted test and if one adds 'Task-number' to the commit message, then the commit is attached to the bug report too, which makes it easy to spot what has been removed. If there is no such bug report, it needs to be done so that the tracking of the removed tests is easy. I would like to get your comments on this and also if you have improvement ideas on the matter, I'm all ears. Also if you have an itch to fix some autotests, feel free to do so. :) It's a common effort to improve the overall quality of Qt and the autotests play an essential role in spotting the possible defects quickly, so let's keep Qt in a good shape without unnecessarily burdening our CI system. In hope of getting feedback from you, Milla Pohjanheimo (the official autotest snoop in the Qt Company) Blacklisted tests on all platforms (dev branch) (with '*' on the BLACKLIST file) (blacklisted date): - qtnetworkauth/tests/auto/oauth1/BLACKLIST 2016-08-22 [getToken] 2016-08-22 [grant] 2016-08-22 [authenticatedCalls] - qtdeclarative/tests/auto/qml/animation/qsequentialanimationgroupjob/BLACKLIST 2015-06-04 [finishWithUncontrolledAnimation] - qtdeclarative/tests/auto/qmltest/BLACKLIST 2015-06-02 [SelfTests::test_blacklisted_fail] 2015-06-02 [SelfTests::test_blacklistWithData:test2] - qtdeclarative/tests/auto/quick/qquicktext/BLACKLIST (2015-06-04) 2015-06-04[dependentImplicitSizes] 2015-06-04 [mouseSelection] - qtdeclarative/tests/auto/quick/qquickmultipointtoucharea/BLACKLIST 2015-06-04 [inFlickable] - qtdeclarative/tests/auto/quick/qquicktextedit/BLACKLIST 2015-06-04 [mouseSelection] - qtdeclarative/tests/auto/quick/qquicklistview/BLACKLIST 2015-03-26 [QTBUG_38209] - qtbase/tests/auto/corelib/animation/qpauseanimation/BLACKLIST 2015-05-24 [pauseAndPropertyAnimations] - qtbase/tests/auto/corelib/thread/qsemaphore/BLACKLIST 2015-06-15 [tryAcquireWithTimeout] - qtbase/tests/auto/testlib/selftests/blacklisted/BLACKLIST 2015-04-28 [pass] 2015-04-28 [skip] 2015-04-28 [fail] 2015-04-28 [xpass] 2015-04-28 [xfail] 2015-04-28 [messages] - qtbase/tests/auto/network/socket/qsocks5socketengine/BLACKLIST 2014-11-12 [udpTest] 2014-11-12 [passwordAuth] - qtbase/tests/auto/network/socket/qudpsocket/BLACKLIST 2015-10-29 [multicast:same bind, group ipv6 address] - qtbase/tests/auto/network/access/qftp/BLACKLIST 2015-11-17 [list:epsvNotSupported] - qtbase/tests/auto/network/access/qnetworkreply/BLACKLIST 2014-09-16 [httpAbort] 2014-11-13 [backgroundRequestInterruption:ftp, bg, nobg] - qtbase/tests/auto/network/ssl/qsslsocket/BLACKLIST 2014-11-25 [waitForConnectedEncryptedReadyRead:WithSocks5ProxyAuth] - qtbase/tests/auto/network/ssl/qsslcertificate/BLACKLIST 2015-08-04 [subjectAndIssuerAttributes] - qtspeech/tests/auto/texttospeech/BLACKLIST 2016-08-11 [say_hello] 2016-08-11 [speech_rate] 2016-08-11 [pitch] 2016-08-11 [set_voice] - qtwebengine/tests/auto/quick/qmltests/BLACKLIST 2016-02-29 [DesktopWebEngineViewLinkHovered::test_linkHovered] 2016-02-29 [WebViewGeopermission::test_geoPermissionRequest] - qtwebengine/tests/auto/quick/qquickwebengineviewgraphics/BLACKLIST 2016-07-15 [showHideShow] - qtwebengine/tests/auto/widgets/qwebenginepage/BLACKLIST 2015-10-29 [geolocationRequestJS] - qtquickcontrols2/tests/auto/sanity/BLACKLIST 2016-04-12 [signalHandlers:material/SpinBox.qml] 2015-10-30 [signalHandlers:material/TextArea.qml] 2015-10-30 [signalHandlers:material/TextField.qml] 2015-11-26 [attachedObjects:controls/ComboBox.qml] 2015-11-26 [attachedObjects:material/ComboBox.qml] 2016-05-10 [attachedObjects:material/Switch.qml] 2016-05-10 [attachedObjects:material/SwitchDelegate.qml] 2015-11-26 [attachedObjects:universal/ComboBox.qml] 2016-07-12 [functions:material/RectangularGlow.qml] 2016-07-12 [anchors:material/RectangularGlow.qml] - qtlocation/tests/auto/declarative_ui/BLACKLIST 2016-08-10 [MapKeepGrabAndPreventSteal::test_map_preventsteal] -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Thu Nov 3 11:39:28 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 3 Nov 2016 10:39:28 +0000 Subject: [Development] Removal of some of the blacklisted (non-working) autotests? In-Reply-To: References: Message-ID: Milla Pohjanheimo said: > I would like to challenge you a bit about removal of (some of) the > blacklisted autotests. Do we have a documented policy on when black-listing should be used ? We can mark tests as expected fail if they reliably fail, so I presume black-listing is reserved for flaky tests. Flakiness should be considered a bug in the test, so indeed every blacklisting should come with a bug report, which should be recorded in a comment in the BLACKLIST file. (Lines starting with # are comments in the relevant format.) There is value in having flaky tests in the source tree, even if it is only to illustrate how to use the relevant APIs (dealing with all the complications); they can also serve as start-points from which folk can attempt to develop less flaky tests. If the test *isn't* good in either of these senses, though - if it uses the APIs badly and a proper test of them wouldn't start from here - then deleting the test makes sense. We should ideally replace bad tests with ones that do at least illustrate best practice use of APIs; but deleting a badly-written test will do. If there's no reliable way to test some API, I have trouble seeing how that API can reliably be used, so we should treat that as an issue with the API itself. It's still worth having some test of such an API, even if it is unreliable, if only to give folk investigating the problem a way to reproduce the flakiness. We just don't want to burden CI with having to run such tests - it's essentially a manual test, in practice. Perhaps the right answer is for the test runner to simply leave out black-listed tests - have CI not run them. This may be tricky to implement, though. It may make sense to move some flaky tests from auto to manual, rather than deleting them. Eddy. From Morten.Sorvig at qt.io Thu Nov 3 14:50:51 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Thu, 3 Nov 2016 13:50:51 +0000 Subject: [Development] Dictation Issues with Qt-built software In-Reply-To: References: Message-ID: <90A518D8-DF8D-4664-92E1-700DCFCAD8DA@qt.io> > On 1 Nov 2016, at 09:41, Robert Iakobashvili wrote: > > Dear Qt-Management and Developers, > > People cannot dictate to Qt-software at Mac as filed: > > https://bugreports.qt.io/browse/QTBUG-56811 Hi, I see two possible ways to solve this: 1) Add cross-platform speech-to-text capabilities to Qt’s text input classes. This would be implemented using native API such as NSSpeechRecognizer, or an open source speech recognition library bundled with Qt. The behavior we get from this option may not be exactly native. 2) Use NSTextField in Qt applications. This gives us the exact native behavior, for speech recognition and everything else, including future NSTextEdit features. However, NSTextEdit would integrate on the QWindow level, and not for example as a Qt Quick scene graph item. Neither of these are straightforward, which is one reason why the bug remains open. > > The very reason to bother you and write this email > is because a similar previous dictation related issue at Windows filed in 2014 > is still pending without being resolved: > > https://bugreports.qt.io/browse/QTBUG-43046 This is an iOS (not Windows) bug. Also worth looking at though :) In general a good way to improve and maintain the accessibility implementation in Qt would be to give it a second user. UI testing and automation comes to mind as a good candidate. Morten From giuseppe.dangelo at kdab.com Thu Nov 3 16:25:20 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 3 Nov 2016 15:25:20 +0000 Subject: [Development] Removal of some of the blacklisted (non-working) autotests? In-Reply-To: References: Message-ID: <7d4e5871-9325-8566-01a1-8fd53395d35b@kdab.com> Howdy, On 03/11/16 09:17, Milla Pohjanheimo wrote: > I would like to challenge you a bit about removal of (some of) the > blacklisted autotests. We have around fifty autotest functions in > different Qt modules that have been blacklisted on all platforms. (The > list of those can be found at the end of this email). In total there are > over 300 tests in all Qt modules that are blacklisted on some plaforms > including those fifty I mentioned earlier. The blacklisted tests are one > (big) problem we have, but another problem is that the blacklisted tests > also burden our CI, since even though a test is blacklisted, it is still > compiled and run in the CI. So basically we have dead code that gets > compiled and run, but it's not used anywhere, just sucking up CI resources. The very fact that this test code successfully compiles *is* a test. It is also be beneficial to run these tests from time to time (say, every 1-2 days or so, instead of every integration): this may reveal that a blacklisted test is actually passing, so it should be removed from the blacklist. So my personal vote would be against removing any code, but (if possible and wanted) just not running these tests at every CI integration. > Should we just delete at least those tests that are blacklisted on all > platforms? Or remove all those that have been blacklisted more than 6 > months ago? Ideally those should be fixed/rewritten of course, but who > would do that? Fixing the tests requires knowledge of the code itself > it's testing. > > Don't be scared of loosing the tests completely. If something is removed > from gerrit it still leaves a mark and one can get the deleted tests > back rather easily, right? There should be a bug report in jira for > every blacklisted test and if one adds 'Task-number' to the commit > message, then the commit is attached to the bug report too, which makes > it easy to spot what has been removed. If there is no such bug report, > it needs to be done so that the tracking of the removed tests is easy. While this is true from a technical point of view, a crude removal of the code makes it way harder to figure out if certain code paths have a test at all. If I'm working on some code and look into adding or extending or fixing its tests, I will never realize that some useful test code existed but got removed and I can search into the history to find it. (But this is just me, so I realize that this isn't an argument, it's an opinion.) My 2 cents, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: S/MIME Cryptographic Signature URL: From thiago.macieira at intel.com Thu Nov 3 16:37:55 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Nov 2016 08:37:55 -0700 Subject: [Development] QAbstractSocket::ShareAddress, SO_REUSEADDR and SO_REUSEPORT In-Reply-To: References: Message-ID: <5801523.0xBmssxg4b@tjmaciei-mobl1> Em quinta-feira, 3 de novembro de 2016, às 07:14:50 PDT, Charles-François Natali escreveu: > Hello, > > I'm not familiar with the Qt development process so apologies if it's not > the correct list, but I'd like to know if someone could have a look at this > issue: https://bugreports.qt.io/browse/QTBUG-33419 This is the right list. > Basically QAbstractSocket::ShareAddress uses SO_REUSEPORT on recent-ish > Linux kernels, and unfortunately it doesn't have the same semantics as > SO_REUSEADDR, which broke several valid use cases. > > The bug report contains more details and a proposed patch. Unfortunately, non-trivial patches can't be accepted via the bugtracker. Anyway, we decided to use the SO_REUSEPORT semantic because it makes most sense with the explanation given in the documentation and with behaviour found on other platforms. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From aleixpol at kde.org Thu Nov 3 17:15:34 2016 From: aleixpol at kde.org (Aleix Pol) Date: Thu, 3 Nov 2016 17:15:34 +0100 Subject: [Development] Dictation Issues with Qt-built software In-Reply-To: <90A518D8-DF8D-4664-92E1-700DCFCAD8DA@qt.io> References: <90A518D8-DF8D-4664-92E1-700DCFCAD8DA@qt.io> Message-ID: On Thu, Nov 3, 2016 at 2:50 PM, Morten Sorvig wrote: > >> On 1 Nov 2016, at 09:41, Robert Iakobashvili wrote: >> >> Dear Qt-Management and Developers, >> >> People cannot dictate to Qt-software at Mac as filed: >> >> https://bugreports.qt.io/browse/QTBUG-56811 > > Hi, > > I see two possible ways to solve this: > > 1) Add cross-platform speech-to-text capabilities to Qt’s text input classes. > This would be implemented using native API such as NSSpeechRecognizer, or an > open source speech recognition library bundled with Qt. The behavior we get from > this option may not be exactly native. > > 2) Use NSTextField in Qt applications. This gives us the exact native behavior, > for speech recognition and everything else, including future NSTextEdit features. > However, NSTextEdit would integrate on the QWindow level, and not for example > as a Qt Quick scene graph item. > > Neither of these are straightforward, which is one reason why the bug remains > open. > >> >> The very reason to bother you and write this email >> is because a similar previous dictation related issue at Windows filed in 2014 >> is still pending without being resolved: >> >> https://bugreports.qt.io/browse/QTBUG-43046 > > This is an iOS (not Windows) bug. Also worth looking at though :) > > In general a good way to improve and maintain the accessibility implementation > in Qt would be to give it a second user. UI testing and automation comes to > mind as a good candidate. > > Morten There's also this approach in QtSpeech, is it a dead end? https://github.com/qt/qtspeech/tree/wip/speech-recognition Aleix From jedrzej.nowacki at qt.io Fri Nov 4 09:10:01 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Fri, 4 Nov 2016 09:10:01 +0100 Subject: [Development] Removal of some of the blacklisted (non-working) autotests? In-Reply-To: References: Message-ID: <2359234.gRZqLRHN8L@42> On torsdag 3. november 2016 09.17.57 CET Milla Pohjanheimo wrote: > I would like to challenge you a bit about removal of (some of) the > blacklisted autotests. > (...) Hi, In your email you wrote that blacklisted is just a burden for CI. In general it is true, but mark that currently they are compiling and they are _not_ crashing. So they do contribute to the quality of Qt. On the other hand they artificially increase test coverage level hiding untested code paths and they may affect other tests. Partial conclusion: delete them, but watch code coverage and add new ones where needed. Eddy mentioned that tests are documenting certain Qt usages. There are two aspects of it. In many cases, we do not know what author of a test wanted to test, sometimes it was a use case, sometimes it was just an internal code path in the implementation. On the other hand, we know that the code is not working in a reliable way, therefore in reality it is a misleading documentation. Moreover developers tends to do copy&paste coding and coping a blacklisted test is just plain wrong, while being very difficult to catch in code review. Partial conclusion: delete them, but add a policy that every test should contain a short comment what is the purpose of the test. Some tests are blacklisted only on certain platforms. Depending on the reason why the test is not working on a specific platform, we need to handle them differently. In general it is ok to assume that Qt as well as Qt bugs are cross platform. So a test failing only on one of them is failing because of a platform specific code (we do not have so much of it) or it is wrongly blacklisted or it hits a bug in a platform itself. Partial conclusion: the test delivers an interesting information. It is worth to spend a bit of time and check what is going on. A tool that do a stress test of a test would be a really good addition, as it would simplify debugging. Conclusion: I believe we should delete them, but be smart about that. Don't just go and remove all of them, but first build infrastructure / process that allows us to not decrease the test coverage. Even more, we need something that would not allow flaky, badly written test to be merged to Qt in the first place, otherwise we would have that discussion again in next 12 months. Cheers, Jędrek From announce at qt-project.org Fri Nov 4 09:12:30 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Fri, 4 Nov 2016 08:12:30 +0000 Subject: [Development] [Announce] Qt 5.7.0 beta released Message-ID: Hi all, Qt 5.8.0 beta is finally released, see http://blog.qt.io/blog/2016/11/04/qt-5-8-beta-released/ Big thanks for everyone involved! br, Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From announce at qt-project.org Fri Nov 4 09:14:12 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Fri, 4 Nov 2016 08:14:12 +0000 Subject: [Development] [Announce] Qt 5.8.0 beta released In-Reply-To: References: Message-ID: Sorry for spamming, the title was wrong. Of course it is Qt 5.8.0 beta... br, Jani ________________________________________ From: Jani Heikkinen Sent: Friday, November 4, 2016 10:12 AM To: announce at qt-project.org Subject: Qt 5.7.0 beta released Hi all, Qt 5.8.0 beta is finally released, see http://blog.qt.io/blog/2016/11/04/qt-5-8-beta-released/ Big thanks for everyone involved! br, Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From edward.welbourne at qt.io Fri Nov 4 09:36:03 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 4 Nov 2016 08:36:03 +0000 Subject: [Development] Removal of some of the blacklisted (non-working) autotests? In-Reply-To: <2359234.gRZqLRHN8L@42> References: , <2359234.gRZqLRHN8L@42> Message-ID: Jędrzej Nowacki contributed: > Even more, we need something that would not allow flaky, badly written > test to be merged to Qt in the first place, otherwise we would have > that discussion again in next 12 months. How practical would it be to coax CI/Gerrit into recognising when a commit adds new tests, so as to include stress-testing of the new test as part of the CI testing ? A half-way-decent start would be to notice any tests/auto/* files modified by the commit and have the testing make check in the affected directories several times, instead of just once. For bonus marks, when the test branch has several commits in it, only fail the commits that do touch those test files, if those tests show a mix of passes and fails. Eddy. From coroberti at gmail.com Fri Nov 4 09:53:13 2016 From: coroberti at gmail.com (Robert Iakobashvili) Date: Fri, 4 Nov 2016 10:53:13 +0200 Subject: [Development] Dictation Issues with Qt-built software In-Reply-To: <90A518D8-DF8D-4664-92E1-700DCFCAD8DA@qt.io> References: <90A518D8-DF8D-4664-92E1-700DCFCAD8DA@qt.io> Message-ID: On Thu, Nov 3, 2016 at 3:50 PM, Morten Sorvig wrote: >> People cannot dictate to Qt-software at Mac as filed: >> https://bugreports.qt.io/browse/QTBUG-56811 > > Hi, > > I see two possible ways to solve this: > > 1) Add cross-platform speech-to-text capabilities to Qt’s text input classes. > This would be implemented using native API such as NSSpeechRecognizer, or an > open source speech recognition library bundled with Qt. The behavior we get from > this option may not be exactly native. > > 2) Use NSTextField in Qt applications. This gives us the exact native behavior, > for speech recognition and everything else, including future NSTextEdit features. > However, NSTextEdit would integrate on the QWindow level, and not for example > as a Qt Quick scene graph item. > > Neither of these are straightforward, which is one reason why the bug remains > open. Users are wondering why Qt-applications at Mac are not behaving like others. They are expecting to be the same as TextEdit, Pages, Word, Safari, Firefox. Just dictate the same way with the same microphone window coming, etc. Since Apple's future behavior is not predictable, I'd vote for as more native approach as it could be done. >> is because a similar previous dictation related issue at Windows filed in 2014 >> is still pending without being resolved: >> >> https://bugreports.qt.io/browse/QTBUG-43046 > > This is an iOS (not Windows) bug. Also worth looking at though :) There is a dictation issue at Windows as well. When dictating at Window-7 using native capabilities, text to speech to QTextEdit was normal, but giving any dictation-api commands like changing a word, deleting, etc. is broken. If somebody indeed is planning to try to fix it, I will sit on that to create a good bug report. > In general a good way to improve and maintain the accessibility implementation > in Qt would be to give it a second user. UI testing and automation comes to > mind as a good candidate. Sorry, I do not understand. The issues are easily reproducible. > > Morten > Thank you for your attention. Sincerely, Robert From christian.kandeler at qt.io Fri Nov 4 10:06:41 2016 From: christian.kandeler at qt.io (Christian Kandeler) Date: Fri, 4 Nov 2016 10:06:41 +0100 Subject: [Development] Removal of some of the blacklisted (non-working) autotests? In-Reply-To: <2359234.gRZqLRHN8L@42> References: <2359234.gRZqLRHN8L@42> Message-ID: On 11/04/2016 09:10 AM, Jędrzej Nowacki wrote: > In your email you wrote that blacklisted is just a burden for CI. In > general it is true, but mark that currently they are compiling and they are > _not_ crashing. So they do contribute to the quality of Qt. On the other hand > they artificially increase test coverage level hiding untested code paths and > they may affect other tests. > > Partial conclusion: delete them, but watch code coverage and add new ones > where needed. If there's still value in having them compiled, can't you just remove the "testcase" value from CONFIG? Christian From milla.pohjanheimo at qt.io Fri Nov 4 11:38:45 2016 From: milla.pohjanheimo at qt.io (Milla Pohjanheimo) Date: Fri, 4 Nov 2016 10:38:45 +0000 Subject: [Development] Removal of some of the blacklisted (non-working) autotests? In-Reply-To: <2359234.gRZqLRHN8L@42> References: , <2359234.gRZqLRHN8L@42> Message-ID: Good to see that discussion arose from this. > In your email you wrote that blacklisted is just a burden for CI. In >general it is true, but mark that currently they are compiling and they are >_not_ crashing. So they do contribute to the quality of Qt. I didn't think it that way. It's true what you say, but I think you also agree that the contribution from the blacklisted tests to the quality of Qt isn't very big. >On the other hand >they artificially increase test coverage level hiding untested code paths and >they may affect other tests. This is my concern also. It gives a false feeling that the coverage is on a good level, since in QtBase only, there are 201 tests blacklisted which must have an effect on the coverage for sure. And here we are only talking about those 50 tests that have been blacklisted on all platforms and some of them have been so for over 2 years now. >Partial conclusion: the test delivers an interesting information. It is worth >to spend a bit of time and check what is going on. A tool that do a stress >test of a test would be a really good addition, as it would simplify >debugging. Jędrek's suggestion about new tests following a separate stress test path is very interesting and I'm really looking forward of having this in place in COIN. This way we could be rather certain that we don't introduce new flakiness to the system and when a test starts to fail randomly it's most probably due to a real issue in Qt code, rather than a "flaky" test. >Conclusion: I believe we should delete them, but be smart about that. Don't >just go and remove all of them, but first build infrastructure / process that >allows us to not decrease the test coverage. Even more, we need something that >would not allow flaky, badly written test to be merged to Qt in the first place, >otherwise we would have that discussion again in next 12 months. Of course. [😊] I wouldn't go about and delete everything in one go. That's why I started this thread to raise discussion. Also Eddy's suggestion of moving (some) of those tests to manual testing is a good one. That way the test wouldn't be deleted, but moved to "manual" directory. That way it wouldn't get built and wouldn't burden the CI. I'm still all ears if you have other improvement ideas about the autotests. - Milla ________________________________ From: Jedrzej Nowacki Sent: Friday, November 4, 2016 10:10 AM To: development at qt-project.org Cc: Milla Pohjanheimo Subject: Re: [Development] Removal of some of the blacklisted (non-working) autotests? On torsdag 3. november 2016 09.17.57 CET Milla Pohjanheimo wrote: > I would like to challenge you a bit about removal of (some of) the > blacklisted autotests. > (...) Hi, In your email you wrote that blacklisted is just a burden for CI. In general it is true, but mark that currently they are compiling and they are _not_ crashing. So they do contribute to the quality of Qt. On the other hand they artificially increase test coverage level hiding untested code paths and they may affect other tests. Partial conclusion: delete them, but watch code coverage and add new ones where needed. Eddy mentioned that tests are documenting certain Qt usages. There are two aspects of it. In many cases, we do not know what author of a test wanted to test, sometimes it was a use case, sometimes it was just an internal code path in the implementation. On the other hand, we know that the code is not working in a reliable way, therefore in reality it is a misleading documentation. Moreover developers tends to do copy&paste coding and coping a blacklisted test is just plain wrong, while being very difficult to catch in code review. Partial conclusion: delete them, but add a policy that every test should contain a short comment what is the purpose of the test. Some tests are blacklisted only on certain platforms. Depending on the reason why the test is not working on a specific platform, we need to handle them differently. In general it is ok to assume that Qt as well as Qt bugs are cross platform. So a test failing only on one of them is failing because of a platform specific code (we do not have so much of it) or it is wrongly blacklisted or it hits a bug in a platform itself. Partial conclusion: the test delivers an interesting information. It is worth to spend a bit of time and check what is going on. A tool that do a stress test of a test would be a really good addition, as it would simplify debugging. Conclusion: I believe we should delete them, but be smart about that. Don't just go and remove all of them, but first build infrastructure / process that allows us to not decrease the test coverage. Even more, we need something that would not allow flaky, badly written test to be merged to Qt in the first place, otherwise we would have that discussion again in next 12 months. Cheers, Jędrek -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OutlookEmoji-😊.png Type: image/png Size: 488 bytes Desc: OutlookEmoji-😊.png URL: From Morten.Sorvig at qt.io Fri Nov 4 12:51:14 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Fri, 4 Nov 2016 11:51:14 +0000 Subject: [Development] Dictation Issues with Qt-built software In-Reply-To: References: <90A518D8-DF8D-4664-92E1-700DCFCAD8DA@qt.io> Message-ID: > On 4 Nov 2016, at 09:53, Robert Iakobashvili wrote: > > On Thu, Nov 3, 2016 at 3:50 PM, Morten Sorvig wrote: >>> People cannot dictate to Qt-software at Mac as filed: >>> https://bugreports.qt.io/browse/QTBUG-56811 >> >> Hi, >> >> I see two possible ways to solve this: >> >> 1) Add cross-platform speech-to-text capabilities to Qt’s text input classes. >> This would be implemented using native API such as NSSpeechRecognizer, or an >> open source speech recognition library bundled with Qt. The behavior we get from >> this option may not be exactly native. >> >> 2) Use NSTextField in Qt applications. This gives us the exact native behavior, >> for speech recognition and everything else, including future NSTextEdit features. >> However, NSTextEdit would integrate on the QWindow level, and not for example >> as a Qt Quick scene graph item. >> >> Neither of these are straightforward, which is one reason why the bug remains >> open. > > Users are wondering why Qt-applications at Mac are not behaving like others. > They are expecting to be the same as TextEdit, Pages, Word, Safari, Firefox. Qt text edit support is more like the Google Docs editor in this regard; a custom implementation that may not support all native features. But I do agree that users are right in expecting that this should work. Morten From Morten.Sorvig at qt.io Fri Nov 4 12:51:18 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Fri, 4 Nov 2016 11:51:18 +0000 Subject: [Development] Dictation Issues with Qt-built software In-Reply-To: References: <90A518D8-DF8D-4664-92E1-700DCFCAD8DA@qt.io> Message-ID: > On 3 Nov 2016, at 17:15, Aleix Pol wrote: > > There's also this approach in QtSpeech, is it a dead end? > https://github.com/qt/qtspeech/tree/wip/speech-recognition To me this looks like something solution 1) could build on. Morten From coroberti at gmail.com Fri Nov 4 13:00:28 2016 From: coroberti at gmail.com (Robert Iakobashvili) Date: Fri, 4 Nov 2016 14:00:28 +0200 Subject: [Development] Dictation Issues with Qt-built software In-Reply-To: References: <90A518D8-DF8D-4664-92E1-700DCFCAD8DA@qt.io> Message-ID: On Fri, Nov 4, 2016 at 1:51 PM, Morten Sorvig wrote: > > > On 4 Nov 2016, at 09:53, Robert Iakobashvili > wrote: > > > > On Thu, Nov 3, 2016 at 3:50 PM, Morten Sorvig > wrote: > >>> People cannot dictate to Qt-software at Mac as filed: > >>> https://bugreports.qt.io/browse/QTBUG-56811 > >> > >> Hi, > >> > >> I see two possible ways to solve this: > >> > >> 1) Add cross-platform speech-to-text capabilities to Qt’s text input > classes. > >> This would be implemented using native API such as NSSpeechRecognizer, > or an > >> open source speech recognition library bundled with Qt. The behavior we > get from > >> this option may not be exactly native. > >> > >> 2) Use NSTextField in Qt applications. This gives us the exact native > behavior, > >> for speech recognition and everything else, including future NSTextEdit > features. > >> However, NSTextEdit would integrate on the QWindow level, and not for > example > >> as a Qt Quick scene graph item. > >> > >> Neither of these are straightforward, which is one reason why the bug > remains > >> open. > > > > Users are wondering why Qt-applications at Mac are not behaving like > others. > > They are expecting to be the same as TextEdit, Pages, Word, Safari, > Firefox. > > Qt text edit support is more like the Google Docs editor in this regard; a > custom > implementation that may not support all native features. But I do agree > that > users are right in expecting that this should work. > > Morten Right. Most users of dictation are people with learning or motoric disabilities. When these users are used to a certain pattern of platform-specific habits working for them, any other options to do the same could be seen as usability issues breaking these habits. Kind regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Sat Nov 5 03:34:50 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 05 Nov 2016 03:34:50 +0100 Subject: [Development] Distributing 3rd party closed source libs References: <2158717.MPJuvCE9X9@tjmaciei-mobl1> Message-ID: Sean Harmer wrote: > Yeah, trouble with that approach is we are always chasing feature > support and we'd rather focus efforts elsewhere. And just running Blender's Python FBX converter (https://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/Autodesk_FBX) as is and then working with the Blender format is not an option? As a Fedora packager, I can say that the proprietary FBX SDK will never be in Fedora, so either you use the Blender code or Qt 3D will not be built with FBX support in Fedora, no matter how you ship it. (And if you ship part of the SDK in the Qt 3D source tarball, we will really hate you because it would force us to respin your tarball with the proprietary code/binaries removed. So please don't do that, ever.) Kevin Kofler From sean.harmer at kdab.com Sat Nov 5 14:02:23 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Sat, 5 Nov 2016 13:02:23 +0000 Subject: [Development] Distributing 3rd party closed source libs In-Reply-To: References: <2158717.MPJuvCE9X9@tjmaciei-mobl1> Message-ID: <85d38f8b-3ec1-79a9-d939-8eae53013562@kdab.com> Hi, On 05/11/2016 02:34, Kevin Kofler wrote: > Sean Harmer wrote: >> Yeah, trouble with that approach is we are always chasing feature >> support and we'd rather focus efforts elsewhere. > > And just running Blender's Python FBX converter > (https://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/Autodesk_FBX) > as is and then working with the Blender format is not an option? No, the whole point is to have support for a format that is efficient at runtime. Blender's format is designed for allowing editing, not runtime efficiency. Also as I mentioned before we would always be lacking full support. In an ideal world the format would be open and documented. But it isn't, and the reality is that users want to use this format. We have some support via assimp but like Blender's importer it is incomplete. > > As a Fedora packager, I can say that the proprietary FBX SDK will never be > in Fedora, so either you use the Blender code or Qt 3D will not be built > with FBX support in Fedora, no matter how you ship it. That's your prerogative of course but if we ship the source or have a plugin that dlopen's the fbx libs then Fedora users still have the option to use this format if they wish, they just won't be able to do it via your package manager. (And if you ship part > of the SDK in the Qt 3D source tarball, we will really hate you because it > would force us to respin your tarball with the proprietary code/binaries > removed. So please don't do that, ever.) Nobody is suggesting bundling the FBX SDK at all. In fact it's not allowed by the Autodesk licensing terms. Cheers, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From mardy at users.sourceforge.net Sun Nov 6 12:44:20 2016 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Sun, 6 Nov 2016 14:44:20 +0300 Subject: [Development] QtQuickControls for desktop: what's the plan? Message-ID: <7ca68a12-8433-dd2e-3d1d-530ba2fe4202@users.sourceforge.net> Hi there! I'm working on a project of a desktop application using the QtQuickControls module. I occasionally run into small issue, but I'm generally satisfied with the state of the controls (I'm working on Linux, I hope that other platforms are working equally well). What makes me worry a bit is that I don't see much development happening on the module, and I wonder if that's because the module is complete and stable, or because we are invited to switch to the QtQuickControls 2 module. A related question is whether there are plans to offer desktop native themes to the QQC2 module and, if not, whether that would be feasible at all. Or, in other words, where would my efforts (as a developer willing to contribute to Qt, but with little free time to do it) be best invested in, if my ultimate goal is to have a QML desktop application working with native style in Linux, OS X and Windows? Ciao, Alberto From perezmeyer at gmail.com Sun Nov 6 14:07:39 2016 From: perezmeyer at gmail.com (=?UTF-8?Q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?=) Date: Sun, 6 Nov 2016 10:07:39 -0300 Subject: [Development] Help required with QTBUG-56932 Message-ID: On Debian we've got affected by this bug which renders KDE/sddm unusable. Strange enough it does not happens in Qt's CI but it does on our tests... and users :-P The bug has a small test case and a possible commit that created the issue. Thanks! -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ From notmart at gmail.com Mon Nov 7 12:53:20 2016 From: notmart at gmail.com (Marco Martin) Date: Mon, 7 Nov 2016 12:53:20 +0100 Subject: [Development] QtQuickControls for desktop: what's the plan? In-Reply-To: <7ca68a12-8433-dd2e-3d1d-530ba2fe4202@users.sourceforge.net> References: <7ca68a12-8433-dd2e-3d1d-530ba2fe4202@users.sourceforge.net> Message-ID: <201611071253.20830.notmart@gmail.com> On Sunday 06 November 2016, Alberto Mardegan wrote: > Hi there! > I'm working on a project of a desktop application using the > QtQuickControls module. I occasionally run into small issue, but I'm > generally satisfied with the state of the controls (I'm working on > Linux, I hope that other platforms are working equally well). > > What makes me worry a bit is that I don't see much development happening > on the module, and I wonder if that's because the module is complete and > stable, or because we are invited to switch to the QtQuickControls 2 > module. > > A related question is whether there are plans to offer desktop native > themes to the QQC2 module and, if not, whether that would be feasible at > all. > > Or, in other words, where would my efforts (as a developer willing to > contribute to Qt, but with little free time to do it) be best invested > in, if my ultimate goal is to have a QML desktop application working > with native style in Linux, OS X and Windows? We have a similar problem within the KDE project, As we have an entire desktop environment whose entire styling depends on QStyle, continuing to use QStyle to theme desktop apps, at least on a limited extent is vital. As there doesn't seem to be interest in the upstream project in such a thing, I started writing a QtQuickControls2 style that actually uses the very same StyleItem used internally in QtQuickControls1, it can be checked out at: https://quickgit.kde.org/?p=scratch%2Fmart%2Fdesktopqqc2style.git to be installed and then export QT_QUICK_CONTROLS_STYLE=Desktop (probably i'll have to rename it to avoid possible future conflicts with upstream ones) Even if is still incomplete (and are things that unfortunately can't be fully styled yet in a fully desktop friendly way) it seems to work remarkably well. -- Marco Martin From milian.wolff at kdab.com Mon Nov 7 14:15:05 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Mon, 07 Nov 2016 14:15:05 +0100 Subject: [Development] QtWebChannel: Upstreaming of Python client In-Reply-To: References: <200afb57-55a0-14f7-c27e-bf9852cca9e4@menlosystems.com> Message-ID: <1569600.Pk6evcrFsl@milian-kdab2> On Wednesday, October 26, 2016 10:32:32 AM CET Arno Rehn wrote: > On 25.10.2016 13:36, Johannes Lochmann wrote: > > Hi Arno, > > > >> On 24 October 2016 at 00:53, Arno Rehn > >> > >> wrote: > >>> Hey everybody, > >>> > >>> At my company we've developed a Python client for QtWebChannel. > >>> It consists of a more or less direct translation of > >>> qwebchannel.js and an additional layer on top of it, providing > >>> async/await syntax support for Python3.5+. Ideally, we'd like to > >>> push this upstream. Before I post a patch to gerrit, I'd like to > >>> get some feedback on whether this is wanted at all. QtWebChannel > >>> seems to be pretty much focused on HTML and the web, but the > >>> infrastructure behind it can be used for remoting from pretty > >>> much any scripting language. I'd also plan on implementing a C++ > >>> client, maybe also Ruby and Matlab (since we're using this in a > >>> scientific setting). > >>> > >>> What's your take on this? > >> > >> Seems useful. Would be interested to try it out. > > > > I agree, this sounds pretty useful, especially given that we’re also > > working again on pyside since this spring. > > > > ...especially an implementation in Python and C++ both from the Qt > > Project could be a really nice combo - sign me up! > > Thanks for all the feedback! Nice to know that people are interested :) > I'll polish the code a little and create a review request. Late reply from my side as I just got back from vacation: As the WebChannel maintainer, I'm very much in favor of getting your changes integrated upstream. Cheers -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From edward.welbourne at qt.io Mon Nov 7 15:57:23 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 7 Nov 2016 14:57:23 +0000 Subject: [Development] [Releasing] Qt 5.8.0 API review In-Reply-To: References: , , , , Message-ID: With the 5.8.0 release now close at hand, I've updated the API reviews: https://codereview.qt-project.org/170634 - qtbase https://codereview.qt-project.org/170635 - qtdeclarative https://codereview.qt-project.org/170636 - qtactiveqt https://codereview.qt-project.org/170637 - qtmultimedia https://codereview.qt-project.org/170640 - qtconnectivity https://codereview.qt-project.org/170641 - qtwayland https://codereview.qt-project.org/170642 - qt3d https://codereview.qt-project.org/170643 - qtserialbus https://codereview.qt-project.org/170644 - qtserialport https://codereview.qt-project.org/170645 - qtandroidextras https://codereview.qt-project.org/170646 - qtwebsockets https://codereview.qt-project.org/170647 - qtwebengine https://codereview.qt-project.org/170648 - qtcanvas3d https://codereview.qt-project.org/170649 - qtcharts https://codereview.qt-project.org/170650 - qtdatavis3d https://codereview.qt-project.org/170652 - qtscxml https://codereview.qt-project.org/176059 - qtquickcontrols2 Note that, although Gerrit thinks of these as proposals to change 5.8, they are actually commits based on tag v5.7.0 showing what's changed in 5.8's API, with lots of boring bits filtered out. It would be nice if some of these did in fact get reviewed ... Eddy. From louai.al-khanji at qt.io Tue Nov 8 05:33:45 2016 From: louai.al-khanji at qt.io (Louai Al-Khanji) Date: Tue, 8 Nov 2016 04:33:45 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: Message-ID: Hi, Indeed, we are. My fault, sorry. I second the request for a git repository. I have a preliminary set of scripts that I used to generate the preview site. Those are ready to go, along with the initial QUIPs I sent out. I would like to suggest that we use that to seed the repository. There has been interest in writing other QUIPs already, those can then follow immediately. André, to answer your question once more – this is not a bureaucratization process. It’s not really about new features either. Instead, the intent is to gather in a well-defined and maintained place information that we, the community of Qt contributors, have produced. For instance, this could be some process that we have agreed upon, or a technical study that was done before some large component was refactored, just to give two examples. Currently we often have to refer to e-mail conversations which might or might not be archived, aren’t discoverable, and are difficult to search for. If we’re lucky it’s in a wiki, but looking at the number of wikis that we’ve gone through in recent years, and information lost in them, it’s easy to see that it’s not a very stable format. If you don’t feel that any of this applies to you, then you will likely never have to think about it. At least, not produce any QUIP yourself – maybe you will over time find some of them useful to read, however. Does that address your concerns? I would like to fold this question into the next revision of the initial QUIPs. :-) Cheers, Louai On 10/26/16, 11:50 PM, "Kai Koehne" wrote: Hi, I'd like to request a QUIP number for the handling of 3rd party code in Qt repositories. Anyhow, it seems to me that we're stuck currently in the bootstrapping process of QUIPs: http://quips-qt-io.herokuapp.com/quip-0003.html >The minimum QUIP boostrapping process was discussed: > >1. Post QUIP 1 to qt-development mailing list for discussion. >2. Arrange for hosting of HTML generated from QUIPs (ed. note: quips.qt.io has since been made available) >3. Create new git repository to hold QUIPs So I'd like to request a gerrit repository for holding QUIPs, .e.g codereview.qt-project.org/qt/quips.git . Regards Kai > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Tero Kojo > Sent: Monday, September 26, 2016 9:01 AM > To: Louai Al-Khanji ; development at qt-project.org > Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt > > Hi, > > This initiative is much appreciated, thank you Louai! > Having been in the session at QtCon, I don't have any problems with the > proposed format and process as outlined in the initial QUIPS. > > I'd like to request two QUIP numbers "Qt Community Code of Conduct", and > another one for "Code of Conduct for Qt Events". > I guess the repo isn't there yet, do we wait on the lazy agreement process > until it is created? > > Tero > > > -----Original Message----- > > From: Development [mailto:development-bounces+tero.kojo=qt.io at qt- > > project.org] On Behalf Of Louai Al-Khanji > > Sent: tiistai 20. syyskuuta 2016 1.45 > > To: development at qt-project.org > > Subject: [Development] QCS2016 Session Notes - QUIPs for Qt > > > > Hi all, > > > > Here are my notes from the QUIPs session. Thank you for your patience. > > :-) > > > > QUIPs are a proposed design process for Qt, modeled after Python’s PEPs. > > > > QUIP 1 introduces the general concept: > > > > http://quips-qt-io.herokuapp.com/quip-0001.html > > > > QUIP 2 details the Qt governance model, it’s simply the current wiki > > page converted into a QUIP: > > > > http://quips-qt-io.herokuapp.com/quip-0002.html > > > > QUIP 3 is an informational QUIP containing the session notes, which > > are repeated below: > > > > http://quips-qt-io.herokuapp.com/quip-0003.html > > > > The heroku domain is obviously a placeholder. > > > > I have also attached the source files for proposed QUIPs 1, 2, and 3 > > to this e- mail. > > > > One item left open was licensing of the QUIPs themselves. For these I > > propose Creative Commons CC0. > > > > Any and all feedback welcome. > > > > Cheers, > > Louai > > > > ---------------- BEGIN NOTES ---------------- > > > > At the Qt Contributors' Summit 2016 in Berlin a session was held to > > discuss the idea of introducing QUIPs as a new process for Qt governance. > > > > The general idea was introduced by looking at QUIPs 1 and 2, and by > > looking at some Python PEPs. The general feedback was positive. An > > attempt was made to identify the minimum set of work required to > > bootstrap QUIP, which was the main theme of the session. > > > > The overall discussion is summarized below, in roughly chronological order. > > > > - Discussed background of QUIP, the process and the documents. > > Referred to > > Python and looked at QUIP 1 and QUIP 2 which had been prepared prior > > to the > > session. > > > > - The idea is to have a new git repository with the QUIP text files > > > > - Managed through Qt's normal work flow, currently gerrit code > > review > > > > - The maintainer of the quips repository takes on required editorial > > duties > > - Agreed that the text documents should be limited to 80 character lines. > > > > - Agreed that care must be taken to ensure that QUIPs are written in > > "proper" > > English so as to be clear, understandable and concise. > > > > - Talked about how a new QUIP is introduced. The most important thing is > to > > reserve a number, which is the identifier of any one QUIP. The title can > > change, and is expected to do so from time to time. > > > > - New QUIP documents will go through a review process like any other > > patch to > > Qt. The author of the QUIP is responsible for logging this discussion in the > > evolving QUIP itself. > > > > - The important thing is to bootstrap the process. Once it is bootstrapped, it > > is possible to fine-tune the QUIP process through QUIPs. It is expected > that > > this will happen. > > > > - The question of what goes into a QUIP was discussed. QUIP 1 gives a > rough > > overview of the different kinds of possible QUIPs. It is expected that the > > content be further specified in revisions of QUIP 1 or in follow-up QUIPs. > > > > - Like any other part of Qt, QUIPs are living documents. They can be > updated, > > amended or entirely superseded by later ones. > > > > - QUIP licensing was discussed. Python's PEPs are required to be > > either placed > > in the public domain or licensed under the Open Publication License. The > > former is not possible in all jurisdictions and the latter has apparently > > been superseded by the Creative Commons licenses the CC0 license was > > suggested. > > > > - The minimum QUIP boostrapping process was discussed: > > > > 1. Post QUIP 1 to qt-development mailing list for discussion. > > > > 2. Arrange for hosting of HTML generated from QUIPs (ed. note: > quips.qt.io > > has since been made available) > > > > 3. Create new git repository to hold QUIPs > > > > - The initial QUIP process was discussed: > > > > 1. Author of QUIP reserves new number in QUIP 0 (the index QUIP) > through > > gerrit > > > > 2. The author gives notice of new QUIP by sending it to qt-development, > > either inline or as a text attachment (things like this can be refined > > later through QUIPs) > > > > 3. Concurrently the author pushes the draft to gerrit where further > > discussion can take place. This discussion must be described in the QUIP. > > > > 4. Decisions are achieved through the same lazy consensus mechanism > that > > is in place today. In that respect nothing changes. > > > > 5. A final +2 from the QUIP maintainer(s) is required. This differs slightly > > from other parts of Qt as only the maintainer(s) can +2 changes to this > > repository. > > > > - Louai naively volunteered to convert existing material on the wiki into a > > series of QUIPs. > > > > - There was a question whether community guidelines could be described > > in a > > QUIP. The answer is a resounding yes. > > > > - The QUIP lifecycle was discussed. The following two items were explored: > > > > 1. Superseding QUIPs. These are QUIPs that both change some > mechanism > > described in an earlier QUIP and change the content of that QUIP > > substantially. For small changes existing QUIPs can be updated. > > > > 2. Retroactive QUIPs are possible. That is to say, QUIPs can be written > > to describe a change that occured in the past. For instance, an > > Implementation Track QUIP can be written after something has been > > added. > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From mardy at users.sourceforge.net Tue Nov 8 08:52:43 2016 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Tue, 8 Nov 2016 10:52:43 +0300 Subject: [Development] QtQuickControls for desktop: what's the plan? In-Reply-To: <201611071253.20830.notmart@gmail.com> References: <7ca68a12-8433-dd2e-3d1d-530ba2fe4202@users.sourceforge.net> <201611071253.20830.notmart@gmail.com> Message-ID: On 07/11/2016 14:53, Marco Martin wrote: > We have a similar problem within the KDE project, > As we have an entire desktop environment whose entire styling depends on > QStyle, continuing to use QStyle to theme desktop apps, at least on a limited > extent is vital. > As there doesn't seem to be interest in the upstream project in such a thing, > I started writing a QtQuickControls2 style that actually uses the very same > StyleItem used internally in QtQuickControls1, it can be checked out at: > https://quickgit.kde.org/?p=scratch%2Fmart%2Fdesktopqqc2style.git > > to be installed and then export QT_QUICK_CONTROLS_STYLE=Desktop (probably i'll > have to rename it to avoid possible future conflicts with upstream ones) > > Even if is still incomplete (and are things that unfortunately can't be fully > styled yet in a fully desktop friendly way) it seems to work remarkably well. That looks smart and simple! Any plans for submitting that to Qt, maybe as a playground project? Anyway, do you have a bug tracker? Ciao, Alberto From edward.welbourne at qt.io Tue Nov 8 09:41:12 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 8 Nov 2016 08:41:12 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: , Message-ID: Louai Al-Khanji said: > this is not a bureaucratization process. It is about having a way to document the final conclusions of discussions we already have. In the process, it shall also force us to be explicit and leave fewer dangling ambiguities, where different parties have subtly different interpretations, because the final QUIP shall be one document, rather than a scattered mess of correspondence spread across several months of a mailing list archive, with references back to earlier discussions relating to similar topics. Newcomers shall only have one place to look to get up to speed. (I should note, though, that this *is* a bureaucratization process; it's just that it's *the good kind* - yes, those do exist. Bureaucracy may have spawned some heinous and easily-noticed messes; but it's actually a technology - an information technology, no less - that helped revolutionise the way the world was run (roughly a quarter millennium ago) and usher in the modern era.) I'll third the motion that we should start a repo for QUIPs, Eddy. From alexander.blasche at qt.io Tue Nov 8 09:42:33 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Tue, 8 Nov 2016 08:42:33 +0000 Subject: [Development] Upcoming Jira outage (9 Nov 2:00-4:00 UTC) Message-ID: Hi, Due to maintenance on the Jira machine, bugreports.qt.io will be temporarily unavailable on November 9 , 2:00 AM ~ 4:00AM UTC+0 We apologize for the inconvenience that this might cause. -- Alex From lars.knoll at qt.io Tue Nov 8 10:11:23 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 8 Nov 2016 09:11:23 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt Message-ID: Yes, let’s get the repo created and this whole thing off the ground. As noted, we need a better way to document results of discussions, decisions and processes. Grepping through a mailing list archive and trying to figure out which opinion prevailed in the end is not that ;-) Cheers, Lars On 08/11/16 09:41, "Development on behalf of Edward Welbourne" wrote: Louai Al-Khanji said: > this is not a bureaucratization process. It is about having a way to document the final conclusions of discussions we already have. In the process, it shall also force us to be explicit and leave fewer dangling ambiguities, where different parties have subtly different interpretations, because the final QUIP shall be one document, rather than a scattered mess of correspondence spread across several months of a mailing list archive, with references back to earlier discussions relating to similar topics. Newcomers shall only have one place to look to get up to speed. (I should note, though, that this *is* a bureaucratization process; it's just that it's *the good kind* - yes, those do exist. Bureaucracy may have spawned some heinous and easily-noticed messes; but it's actually a technology - an information technology, no less - that helped revolutionise the way the world was run (roughly a quarter millennium ago) and usher in the modern era.) I'll third the motion that we should start a repo for QUIPs, Eddy. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From notmart at gmail.com Tue Nov 8 10:45:10 2016 From: notmart at gmail.com (Marco Martin) Date: Tue, 8 Nov 2016 10:45:10 +0100 Subject: [Development] QtQuickControls for desktop: what's the plan? In-Reply-To: References: <7ca68a12-8433-dd2e-3d1d-530ba2fe4202@users.sourceforge.net> <201611071253.20830.notmart@gmail.com> Message-ID: <201611081045.10355.notmart@gmail.com> On Tuesday 08 November 2016, Alberto Mardegan wrote: > > Even if is still incomplete (and are things that unfortunately can't be > > fully styled yet in a fully desktop friendly way) it seems to work > > remarkably well. > > That looks smart and simple! Any plans for submitting that to Qt, maybe > as a playground project? > > Anyway, do you have a bug tracker? I was planning to keep it a KDE project, probably as a tier 1 framework. -- Marco Martin From oswald.buddenhagen at qt.io Tue Nov 8 11:14:58 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 8 Nov 2016 11:14:58 +0100 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: Message-ID: <20161108101458.GD22297@troll08> On Tue, Nov 08, 2016 at 09:11:23AM +0000, Lars Knoll wrote: > Yes, let’s get the repo created and this whole thing off the ground. > so, anyone has a concrete proposal for a fully qualified repository name? www/quips? > As noted, we need a better way to document results of discussions, decisions and processes. Grepping through a mailing list archive and trying to figure out which opinion prevailed in the end is not that ;-) > > Cheers, > Lars > > On 08/11/16 09:41, "Development on behalf of Edward Welbourne" wrote: > > Louai Al-Khanji said: > > this is not a bureaucratization process. > > It is about having a way to document the final conclusions of > discussions we already have. In the process, it shall also force us to > be explicit and leave fewer dangling ambiguities, where different > parties have subtly different interpretations, because the final QUIP > shall be one document, rather than a scattered mess of correspondence > spread across several months of a mailing list archive, with references > back to earlier discussions relating to similar topics. Newcomers shall > only have one place to look to get up to speed. > > (I should note, though, that this *is* a bureaucratization process; it's > just that it's *the good kind* - yes, those do exist. Bureaucracy may > have spawned some heinous and easily-noticed messes; but it's actually a > technology - an information technology, no less - that helped > revolutionise the way the world was run (roughly a quarter millennium > ago) and usher in the modern era.) > > I'll third the motion that we should start a repo for QUIPs, > > Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Kai.Koehne at qt.io Tue Nov 8 12:48:34 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Tue, 8 Nov 2016 11:48:34 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <20161108101458.GD22297@troll08> References: <20161108101458.GD22297@troll08> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Oswald Buddenhagen > Sent: Tuesday, November 08, 2016 11:15 AM > To: development at qt-project.org > Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt > > On Tue, Nov 08, 2016 at 09:11:23AM +0000, Lars Knoll wrote: > > Yes, let’s get the repo created and this whole thing off the ground. > > > so, anyone has a concrete proposal for a fully qualified repository name? > www/quips? I'd slightly prefer qt/quips because it's not directly related to the website, even if we'll generate an html presentation out of it. We might even consider adding it to qt/qt5.git at one point ... Kai From tony.sarajarvi at qt.io Tue Nov 8 13:22:28 2016 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Tue, 8 Nov 2016 12:22:28 +0000 Subject: [Development] CI has workitem creation problems Message-ID: Hi all You all might have noticed the problems we're facing with the CI not able to produce workitems. The culprit is most likely a buggy lru_cache in Python. We've tried a few work-arounds, but as you've seen none of them have really made a difference. The buggy lru_cache came with a new version of Python that came with the distro upgrade we did for the CI server. Without a proper fix in sight, it looks like we just have to disable the usage of caches in the code, which will bring some performance hit on the builds. But they should at least start working then. We apologize for the inconvenience this causes -Tony Tony Sarajärvi CI Tech Lead The Qt Company Elektroniikkatie 10 90590, Oulu Finland tony.sarajarvi at qt.io +358 50 4821416 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7132 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 940 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 869 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 832 bytes Desc: image004.png URL: From alexis.jeandet at member.fsf.org Tue Nov 8 13:30:45 2016 From: alexis.jeandet at member.fsf.org (Jeandet Alexis) Date: Tue, 08 Nov 2016 13:30:45 +0100 Subject: [Development] Qt Charts poor dynamic/resolution with OpenGL In-Reply-To: <1be818f4-de31-f7e0-e630-f468ec15919e@kdab.com> References: <1468949187.3072.83.camel@member.fsf.org> <1be818f4-de31-f7e0-e630-f468ec15919e@kdab.com> Message-ID: <1478608245.3562.7.camel@member.fsf.org> Hi Qt devs, To continue on this topic, in my lab we plan to take an intern to work on this. It would be a 6 month Master degree internship, starting around February 2017. Does QtCharts maintainers/experts have some time to help us to advise our intern? It would just be for short discussions like is the new design Ok? Can we modify this? Is QtCharts really doing this like this?... Most of this questions would go through this list but if we can also do few(2-3) call-conf it might be better. Our goal is to improve QtCharts to be able to use it in our scientific softwares. So we need to improve the current dynamic with OpenGL and/or improve performances of non OpenGL plots. Best regards, Alexis. Le mardi 19 juillet 2016 à 20:26 +0100, Sean Harmer a écrit : > > On 19/07/2016 18:26, jeandet wrote: > > Hi All, > > > > We are developing in my lab a scientific data plot/analysis > > software > > using Qt Charts module. In order to plot quite large data-sets > > (XYSeries) we enabled OpenGL which produce unexpected behavior. The > > plots values are grouped by X values see here: > > https://ao.lpp.polytechnique.fr/s/T2HcZDtrdL0DcDi > > passwd:àààà > > -Plot0 with OpenGL > > -Plot1 without OpenGL > > > > We found that it was due to float conversion with OpenGL, as far as > > I > > know we can't safely use doubles with OpenGL since not al > > GPU/drivers > > support it(and it increase version requirement). So for now it > > really > > limits plots quality since float has a 23+1 bits mantissa so +/-8M > > relative dynamic. > > > > For example data with X values representing seconds since > > epoch(1970) > > would have to store: > > (2016-1970)*365*24*60*60 = 1450656000 seconds ~2^31 > > This indeed doesn't fit in 23 bits, to store it in a float you will > > need to truncate it and you would get something close to 3 minutes > > resolution. > > Here is a tool to see what append. > > http://babbage.cs.qc.cuny.edu/IEEE-754.old/Decimal.html > > > > It will also fail with  non uniform X values, packets of data with > > a > > small dX spaced by bigger dX. For example 8kSps time series grouped > > in > > packets of 1000 points with few minutes between each packets would > > fail. > > > > That said there seems to be solutions to make the situation better. > > I think that before plotting te data we should perform a coordinate > > change to fit float dynamic. > > This pipeline might be implemented like this?: > > > > CPU:  -Data domain analysis (min, max, dynamic) > > CPU:  -Produce a Temporary vector of visible data centered and > > reduced > > CPU:  -Push Temporary vector to GPU > > GPU:  -Generate Vertices with or without downsampling strategy > > CPU:  -Build Axes from visible bounds in data coordinates > > That's essentially the same strategy I've implemented in the past. I  > don't know the code of Qt Charts or how easily this woudl fit into > it  > but as an approach I think it's sound. > > Cheers, > > Sean > > > > > Note that this would also work without OpenGL and the downsampling > > insanely increase performances. On QCustomPlot if we replace data > > containers which are QMap by QVector you can plot more than 10M > > points > > without problems. > > Here is one example with 3M points with QCustomPlot and without > > OpenGL: > > https://hephaistos.lpp.polytechnique.fr/data/QLop_new_Features2.web > > m > > > > This would imply to store two coordinate systems for Data and View. > > We are happy to discuss about that and contribute to the > > development if > > we agree on a solution. > > Anyway I would be happy to have any feedback on this. > > > > Some readings: > > http://blogs.agi.com/insight3d/index.php/2008/09/03/precisions- > > precisio > > ns/ > > http://www.urbanrobots.com/Blogs/WW/2006/01/working-to-solution-in- > > prec > > ision.html > > http://www.urbanrobots.com/Blogs/WW/2006/01/solving-coordinate- > > precisio > > n-problems.html > > > > > > Best regards > > Alexis Jeandet > > Laboratory of Plasma Physics(LPP) > > http://www.lpp.fr/?lang=en > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darkbasic at linuxsystems.it Tue Nov 8 15:57:40 2016 From: darkbasic at linuxsystems.it (=?iso-8859-1?Q?Niccol=F2_Belli?=) Date: Tue, 08 Nov 2016 15:57:40 +0100 Subject: [Development] [HiDPI] Rethinking the scaling algorithm Message-ID: Hi, My laptop's monitor is a 13" with a 16:9 aspect ratio and a 3200x1800 resolution. As you can see[1] the EDID[2] is perfectly correct. QT computes the scaling factor using a formula like this: scaling_factor=qRound(yourDpi/96) This is far from ideal in my opinion, because if we want to scale to 96 logical PPI it means that on a 13" 16:9 screen we want to target a 1088x612 logical resolution. In fact qRound(282.42/96) computes a 3x scaling factor for my laptop, which is not a scaling factor that *anybody* would like to have (except maybe my old grandfather with poor eyesight). In fact a logical resolution of *less* than 1088x612 (it's lesser because qRound actually rounded up the value) is too tiny even for a 13" screen and people would prefer a 2x scaling factor instead, which would give you a logical resolution of 1600x900 (instead of an useless 1067x600). I have some suggestions to improve the current scaling algorithm: 1) Always round down. With your current formula a 145ppi screen gets scaled by a 2x factor, while every other toolkit (GTK3 for example[3]) starts scaling at 192ppi. This is also what people expect and it would return the correct 2x scaling factor for my laptop. So the formula should be scaling_factor=qRoundDown(yourDpi/96) 2) Expose an environmental variable to allow people to choose which logical PPI they want to target. Such a variable should default to 96ppi. In fact some people might have poor eyesight or might desire a different viewing distance and thus they would like to target a different logical PPI. So the formula should be scaling_factor=qRoundDown(yourDpi/EnvVar) The current algorithm does not work well (this is a matter of fact), question is if we can improve it. I thought alot about it and I can't see any negative impact with my proposed solution, but obviously I would like to hear the opinions from other developers. Niccolo' Belli [1]http://www.edidreader.com/ [2]https://bpaste.net/show/e2f39fad5f5e [3]https://wiki.gnome.org/HowDoI/HiDpi From darkbasic at linuxsystems.it Tue Nov 8 16:04:32 2016 From: darkbasic at linuxsystems.it (=?iso-8859-1?Q?Niccol=F2_Belli?=) Date: Tue, 08 Nov 2016 16:04:32 +0100 Subject: [Development] [HiDPI] Rethinking the scaling algorithm In-Reply-To: References: Message-ID: On martedì 8 novembre 2016 15:57:40 CET, Niccolò Belli wrote: > [2]https://bpaste.net/show/e2f39fad5f5e Wrong link for the EDID, this is the correct one: https://bpaste.net/show/0e34f12832d9 From Uwe.Rathmann at tigertal.de Tue Nov 8 16:06:58 2016 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Tue, 8 Nov 2016 15:06:58 +0000 (UTC) Subject: [Development] Qt Charts poor dynamic/resolution with OpenGL References: <1468949187.3072.83.camel@member.fsf.org> <1be818f4-de31-f7e0-e630-f468ec15919e@kdab.com> <1478608245.3562.7.camel@member.fsf.org> Message-ID: On Tue, 08 Nov 2016 13:30:45 +0100, Jeandet Alexis wrote: > Our goal is to improve QtCharts to be able to use it in our scientific > softwares. So we need to improve the current dynamic with OpenGL and/or > improve performances of non OpenGL plots. Have you ever considered to use a 3rd party library like Qwt or QCustomPlot. Both packages are available since years and focus on scientific plots. Being the maintainer of the Qwt package I'm some sort of a biased, but my impression is, that the Qt Chart package has never reached a state being even close to other solutions. And as I never saw anyone responding to related questions on the mailing lists it also does not look like being a very actively maintained module. ciao, Uwe From alexis.jeandet at member.fsf.org Tue Nov 8 16:32:37 2016 From: alexis.jeandet at member.fsf.org (Jeandet Alexis) Date: Tue, 08 Nov 2016 16:32:37 +0100 Subject: [Development] Qt Charts poor dynamic/resolution with OpenGL In-Reply-To: References: <1468949187.3072.83.camel@member.fsf.org> <1be818f4-de31-f7e0-e630-f468ec15919e@kdab.com> <1478608245.3562.7.camel@member.fsf.org> Message-ID: <1478619157.3562.11.camel@member.fsf.org> Hi Uwe, Le mardi 08 novembre 2016 à 15:06 +0000, Uwe Rathmann a écrit : > On Tue, 08 Nov 2016 13:30:45 +0100, Jeandet Alexis wrote: > > > Our goal is to improve QtCharts to be able to use it in our > > scientific > > softwares. So we need to improve the current dynamic with OpenGL > > and/or > > improve performances of non OpenGL plots. > > Have you ever considered to use a 3rd party library like Qwt or  > QCustomPlot. Both packages are available since years and focus on  > scientific plots. Indeed I do use QCP on others projects. I would say that QCP is really nice, its downsampling method is efficient. For QWT I only checked in the past and I had the feeling that by default you had to do many things before you get a plot. On QCP, the main drawbacks are the usage of QMap on pre 2.0 revisions, the amalgamate on sources(insane for compiler). We made the choice to use QtCharts for this new software because it is a Qt module which reduce dependencies and its features are not that far from what we want. We mainly focus on data browsing and plot interactions where QtCharts appears to be good. That said QWT and QCP are still good candidates too. > > Being the maintainer of the Qwt package I'm some sort of a biased, > but my  > impression is, that the Qt Chart package has never reached a state > being  > even close to other solutions. And as I never saw anyone responding > to  > related questions on the mailing lists it also does not look like > being a  > very actively maintained module. You are right but I want to give it a chance since it got opened recently. I don't know why it got opened. I don't know if it is considered as mature, is it just a toy? Is it abandoned by Digia/Qt? Personally I don't know many data visualisation applications where QtCharts would work as-is, as soon as you plot time stamped data you may quickly fall in our trap. On the other hand we can see activity on the repository. So my hope is to get a decent and official Qt plotting module in the future. > > ciao, > Uwe > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From louai.al-khanji at qt.io Tue Nov 8 16:50:00 2016 From: louai.al-khanji at qt.io (Louai Al-Khanji) Date: Tue, 8 Nov 2016 15:50:00 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: <20161108101458.GD22297@troll08>, Message-ID: +1 for qt/quips, I don't think of it as a web site thing either. -Louai _____________________________ From: Kai Koehne > Sent: Tuesday, November 8, 2016 3:48 AM Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt To: Oswald Buddenhagen >, > > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- > project.org] On Behalf Of Oswald Buddenhagen > Sent: Tuesday, November 08, 2016 11:15 AM > To: development at qt-project.org > Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt > > On Tue, Nov 08, 2016 at 09:11:23AM +0000, Lars Knoll wrote: > > Yes, let's get the repo created and this whole thing off the ground. > > > so, anyone has a concrete proposal for a fully qualified repository name? > www/quips? I'd slightly prefer qt/quips because it's not directly related to the website, even if we'll generate an html presentation out of it. We might even consider adding it to qt/qt5.git at one point ... Kai _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Petroules at qt.io Tue Nov 8 19:47:06 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 8 Nov 2016 18:47:06 +0000 Subject: [Development] QtQuickControls for desktop: what's the plan? In-Reply-To: <201611081045.10355.notmart@gmail.com> References: <7ca68a12-8433-dd2e-3d1d-530ba2fe4202@users.sourceforge.net> <201611071253.20830.notmart@gmail.com> <201611081045.10355.notmart@gmail.com> Message-ID: <31032ACE-FFD1-409A-B0A9-CBEA7B56B69F@qt.io> > On Nov 8, 2016, at 1:45 AM, Marco Martin wrote: > > On Tuesday 08 November 2016, Alberto Mardegan wrote: >>> Even if is still incomplete (and are things that unfortunately can't be >>> fully styled yet in a fully desktop friendly way) it seems to work >>> remarkably well. >> >> That looks smart and simple! Any plans for submitting that to Qt, maybe >> as a playground project? >> >> Anyway, do you have a bug tracker? > > I was planning to keep it a KDE project, probably as a tier 1 framework. That seems like a bad idea. Let's submit it to Qt so that everyone can benefit and it can be kept better maintained alongside Qt and for all platforms. > -- > Marco Martin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From thiago.macieira at intel.com Tue Nov 8 23:02:04 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 09 Nov 2016 06:02:04 +0800 Subject: [Development] [HiDPI] Rethinking the scaling algorithm In-Reply-To: References: Message-ID: <2619849.Lo779ZvXFM@tjmaciei-mobl1> Em terça-feira, 8 de novembro de 2016, às 15:57:40 CST, Niccolò Belli escreveu: > 1) Always round down. With your current formula a 145ppi screen gets scaled > by a 2x factor, while every other toolkit (GTK3 for example[3]) starts > scaling at 192ppi. This is also what people expect and it would return the > correct 2x scaling factor for my laptop. So the formula should be > scaling_factor=qRoundDown(yourDpi/96) Agreed we need to adjust the formula. I'm not sure a full round down (i.e., an integer division) is what we want. Another option is qRound(dpi / 96.0 - 0.75); That would make: DPI < 168 1x DPI < 264 2x etc. > 2) Expose an environmental variable to allow people to choose which logical > PPI they want to target. Such a variable should default to 96ppi. In fact > some people might have poor eyesight or might desire a different viewing > distance and thus they would like to target a different logical PPI. So the > formula should be scaling_factor=qRoundDown(yourDpi/EnvVar) We have plenty of environment variables already. I personally set QT_SCREEN_SCALE_FACTORS to 2 on my 13" 3200x1800 display (font DPI is 216). # 0 "eDP-1" Depth: 24 Primary: yes Geometry: 1600x900+0+0 (native: 3200x1800+0+0) Available: 1600x876+0+0 Physical size: 294x165 mm Refresh: 59 Hz Power state: 0 Physical DPI: 138.231,138.545 Logical DPI: 108.085,108.341 (native: 216.17,216.682) Subpixel_None High DPI scaling factor: 2 DevicePixelRatio: 2 Pixel density: 3 Primary orientation: 2 Orientation: 2 Native orientation: 0 OrientationUpdateMask: 0 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kde at carewolf.com Tue Nov 8 23:34:48 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Tue, 8 Nov 2016 23:34:48 +0100 Subject: [Development] [HiDPI] Rethinking the scaling algorithm In-Reply-To: References: Message-ID: <201611082334.49057.kde@carewolf.com> On Tuesday 08 November 2016, Niccolò Belli wrote: > 1) Always round down. With your current formula a 145ppi screen gets scaled > by a 2x factor, while every other toolkit (GTK3 for example[3]) starts > scaling at 192ppi. This is also what people expect and it would return the > correct 2x scaling factor for my laptop. So the formula should be > scaling_factor=qRoundDown(yourDpi/96) > We have a two factor scaling system. We also scale by DPI. 144/2 == 72 for instance, which happens to be the standard on Macs. Therefore 144DPI become a normal 2x scaling of standard 72 Mac DPI. And having 2x with smaller text, is a lot better than 1x with large text on a 27" 4K desktop screen. `Allan From alexander.blasche at qt.io Wed Nov 9 08:41:46 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Wed, 9 Nov 2016 07:41:46 +0000 Subject: [Development] Upcoming Jira outage (9 Nov 2:00-4:00 UTC) In-Reply-To: References: Message-ID: Hi, The changes are completed.You may need to clean the cache to load the site. Compression was enabled during the changes,see https://bugreports.qt.io/browse/QTJIRA-300 -- Alex ________________________________________ From: Development on behalf of Alexander Blasche Sent: Tuesday, 8 November 2016 9:42:33 AM To: development at qt-project.org; qt-creator at qt-project.org; interest at qt-project.org Interest Subject: [Development] Upcoming Jira outage (9 Nov 2:00-4:00 UTC) Hi, Due to maintenance on the Jira machine, bugreports.qt.io will be temporarily unavailable on November 9 , 2:00 AM ~ 4:00AM UTC+0 We apologize for the inconvenience that this might cause. -- Alex _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Jedrzej.Nowacki at qt.io Wed Nov 9 10:04:17 2016 From: Jedrzej.Nowacki at qt.io (Jedrzej Nowacki) Date: Wed, 9 Nov 2016 09:04:17 +0000 Subject: [Development] Removal of some of the blacklisted (non-working) autotests? In-Reply-To: References: , <2359234.gRZqLRHN8L@42>, Message-ID: As you wrote, in the first iteration of the functionality I would go for an easy solution and I would detect just all modifications to tests/auto/* On the other hand I do not want to have the definition of stress testing in Coin code. Every one should be able to run it therefore it should be a make target. So everyone could just type: make stress-test in a test folder and after 10 min get the result. Cheers, Jędrek ________________________________________ From: Edward Welbourne Sent: Friday, November 4, 2016 9:36 AM To: Jedrzej Nowacki Cc: development at qt-project.org Subject: Re: [Development] Removal of some of the blacklisted (non-working) autotests? Jędrzej Nowacki contributed: > Even more, we need something that would not allow flaky, badly written > test to be merged to Qt in the first place, otherwise we would have > that discussion again in next 12 months. How practical would it be to coax CI/Gerrit into recognising when a commit adds new tests, so as to include stress-testing of the new test as part of the CI testing ? A half-way-decent start would be to notice any tests/auto/* files modified by the commit and have the testing make check in the affected directories several times, instead of just once. For bonus marks, when the test branch has several commits in it, only fail the commits that do touch those test files, if those tests show a mix of passes and fails. Eddy. From miikka.heikkinen at qt.io Wed Nov 9 10:04:23 2016 From: miikka.heikkinen at qt.io (Miikka Heikkinen) Date: Wed, 9 Nov 2016 09:04:23 +0000 Subject: [Development] Qt Charts poor dynamic/resolution with OpenGL In-Reply-To: <1478619157.3562.11.camel@member.fsf.org> References: <1468949187.3072.83.camel@member.fsf.org> <1be818f4-de31-f7e0-e630-f468ec15919e@kdab.com> <1478608245.3562.7.camel@member.fsf.org> <1478619157.3562.11.camel@member.fsf.org> Message-ID: Hi. I’m Qt Charts maintainer. It is true that Charts have been on back burner for a good while now, as I’ve been assigned to other tasks, but it’s not abandoned by any means. We do welcome third party contributions and I’m certainly willing to discuss the design and review any contributions. On this issue, simple fix for resolution would be to handle normal value axes like log value axes in GLXYSeriesDataManager::setPoints(). It uses domain->calculateGeometryPoints() function to resolve the geometry points for logarithmic domains on CPU side and feeds those to shader instead of relying in shader to resolve the geometry like it does in case of regular value axes. I suspect this would cause a significant performance impact with large data sets, though, so that’s why it wasn’t implemented like that to begin with. An obvious way to improve performance with large data sets would be to prune the off-screen points early, but given the fact that charts makes no assumptions about data being ordered on any axis makes this bit tricky. Maybe keeping track if the data is ordered as it’s appended to the set and do the pruning if it is ordered would be a feasible solution. -Miikka From: Development [mailto:development-bounces+miikka.heikkinen=qt.io at qt-project.org] On Behalf Of Jeandet Alexis Sent: 8. marraskuuta 2016 17:33 To: development at qt-project.org Subject: Re: [Development] Qt Charts poor dynamic/resolution with OpenGL Hi Uwe, Le mardi 08 novembre 2016 à 15:06 +0000, Uwe Rathmann a écrit : On Tue, 08 Nov 2016 13:30:45 +0100, Jeandet Alexis wrote: Our goal is to improve QtCharts to be able to use it in our scientific softwares. So we need to improve the current dynamic with OpenGL and/or improve performances of non OpenGL plots. Have you ever considered to use a 3rd party library like Qwt or QCustomPlot. Both packages are available since years and focus on scientific plots. Indeed I do use QCP on others projects. I would say that QCP is really nice, its downsampling method is efficient. For QWT I only checked in the past and I had the feeling that by default you had to do many things before you get a plot. On QCP, the main drawbacks are the usage of QMap on pre 2.0 revisions, the amalgamate on sources(insane for compiler). We made the choice to use QtCharts for this new software because it is a Qt module which reduce dependencies and its features are not that far from what we want. We mainly focus on data browsing and plot interactions where QtCharts appears to be good. That said QWT and QCP are still good candidates too. Being the maintainer of the Qwt package I'm some sort of a biased, but my impression is, that the Qt Chart package has never reached a state being even close to other solutions. And as I never saw anyone responding to related questions on the mailing lists it also does not look like being a very actively maintained module. You are right but I want to give it a chance since it got opened recently. I don't know why it got opened. I don't know if it is considered as mature, is it just a toy? Is it abandoned by Digia/Qt? Personally I don't know many data visualisation applications where QtCharts would work as-is, as soon as you plot time stamped data you may quickly fall in our trap. On the other hand we can see activity on the repository. So my hope is to get a decent and official Qt plotting module in the future. ciao, Uwe _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Uwe.Rathmann at tigertal.de Wed Nov 9 10:51:07 2016 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Wed, 9 Nov 2016 09:51:07 +0000 (UTC) Subject: [Development] Qt Charts poor dynamic/resolution with OpenGL References: <1468949187.3072.83.camel@member.fsf.org> <1be818f4-de31-f7e0-e630-f468ec15919e@kdab.com> <1478608245.3562.7.camel@member.fsf.org> <1478619157.3562.11.camel@member.fsf.org> Message-ID: On Wed, 09 Nov 2016 09:04:23 +0000, Miikka Heikkinen wrote: Hi Mikka, > I’m Qt Charts maintainer. It is true that Charts have been on back > burner for a good while now, as I’ve been assigned to other tasks, but > it’s not abandoned by any means. Maybe you could shed some light on the future of this module: what has happened is, that Qt project has started a new module, that naturally was/is behind 3rd party projects, that exist since many years. AFAIK the motivation to start this project was more a commercial driven decision than, that the existing solutions were not good enough. I'm doing the Qwt project for almost 18 years now and I'm fine if at some point it can be replaced by an official package. But to me Qt Charts looks like something that didn't work as a commercial idea and now rests more or less idle in the repositories ? Or if you don't intend to make it the best solution: what is the motivation of the Qt project in having this module at all, when there are several free and actively maintained chart packages around ? ciao, Uwe From edward.welbourne at qt.io Wed Nov 9 11:05:24 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 9 Nov 2016 10:05:24 +0000 Subject: [Development] Removal of some of the blacklisted (non-working) autotests? In-Reply-To: References: , <2359234.gRZqLRHN8L@42>, , Message-ID: Jedrzej Nowacki said: > As you wrote, in the first iteration of the functionality I would go > for an easy solution and I would detect just all modifications to > tests/auto/* > On the other hand I do not want to have the definition of stress > testing in Coin code. Every one should be able to run it Fair enough. > therefore it should be a make target. So everyone could just type: > make stress-test > in a test folder and after 10 min get the result. Makes sense - nice target, well worth adding to Makefiles. Now: what should it do ? Eddy. From frederik.gladhorn at qt.io Wed Nov 9 11:44:16 2016 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Wed, 9 Nov 2016 11:44:16 +0100 Subject: [Development] Dictation Issues with Qt-built software In-Reply-To: <90A518D8-DF8D-4664-92E1-700DCFCAD8DA@qt.io> References: <90A518D8-DF8D-4664-92E1-700DCFCAD8DA@qt.io> Message-ID: <3266250.ZoSeju5Rsp@frederik-thinkcentre-m93p> On torsdag 3. november 2016 13.50.51 CET Morten Sorvig wrote: > > On 1 Nov 2016, at 09:41, Robert Iakobashvili wrote: > > > > Dear Qt-Management and Developers, > > > > People cannot dictate to Qt-software at Mac as filed: > > > > https://bugreports.qt.io/browse/QTBUG-56811 > > > Hi, > > I see two possible ways to solve this: > > 1) Add cross-platform speech-to-text capabilities to Qt’s text input > classes. This would be implemented using native API such as > NSSpeechRecognizer, or an open source speech recognition library bundled > with Qt. The behavior we get from this option may not be exactly native. > > 2) Use NSTextField in Qt applications. This gives us the exact native > behavior, for speech recognition and everything else, including future > NSTextEdit features. However, NSTextEdit would integrate on the QWindow > level, and not for example as a Qt Quick scene graph item. > > Neither of these are straightforward, which is one reason why the bug > remains open. I think this is a mis-understanding. From my understanding both Windows and macOS offer dictation out of the box. The task for us should be to make sure that these work with Qt's text inputs. I haven't looked into this, but there are two options these tools could be taking: input methods or accessibility in some form. I suspect that it's using accessibility, but of course research is needed first, this is completely guesswork for now. Assuming it's a11y, we need to find out what we're lacking, then we can fix the problem. For Windows, if it is accessibility, we should check if it can work with applications using IAccessible2, or if there's something required from UIAutomation. For mac, I suspect we simply don't implement some property in the accessibility protocol. Cheers, Frederik > > > > > > The very reason to bother you and write this email > > is because a similar previous dictation related issue at Windows filed in > > 2014 is still pending without being resolved: > > > > https://bugreports.qt.io/browse/QTBUG-43046 > > > This is an iOS (not Windows) bug. Also worth looking at though :) > > In general a good way to improve and maintain the accessibility > implementation in Qt would be to give it a second user. UI testing and > automation comes to mind as a good candidate. > > Morten > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Jedrzej.Nowacki at qt.io Wed Nov 9 12:29:22 2016 From: Jedrzej.Nowacki at qt.io (Jedrzej Nowacki) Date: Wed, 9 Nov 2016 11:29:22 +0000 Subject: [Development] Removal of some of the blacklisted (non-working) autotests? In-Reply-To: References: , <2359234.gRZqLRHN8L@42>, , , Message-ID: > Now: what should it do ? Compile the test with additional debugging flags. On Linux it would be looking like that: for 10 min (minimum 3000 runs): Run the test Run the test with valgrind Use taskset to reduce CPU affinity to one CPU Put external load on the CPU to re-arrange threads schedule Use other tools? If it failed even once the change should be rejected. I'm not sure what should we do with warnings I guess we can not thread them as errors, but definitely we can print them out. Cheers, Jędrek ________________________________________ From: Edward Welbourne Sent: Wednesday, November 9, 2016 11:05:24 AM To: Jedrzej Nowacki Cc: development at qt-project.org Subject: Re: [Development] Removal of some of the blacklisted (non-working) autotests? Jedrzej Nowacki said: > As you wrote, in the first iteration of the functionality I would go > for an easy solution and I would detect just all modifications to > tests/auto/* > On the other hand I do not want to have the definition of stress > testing in Coin code. Every one should be able to run it Fair enough. > therefore it should be a make target. So everyone could just type: > make stress-test > in a test folder and after 10 min get the result. Makes sense - nice target, well worth adding to Makefiles. Now: what should it do ? Eddy. From miikka.heikkinen at qt.io Wed Nov 9 12:32:31 2016 From: miikka.heikkinen at qt.io (Miikka Heikkinen) Date: Wed, 9 Nov 2016 11:32:31 +0000 Subject: [Development] Qt Charts poor dynamic/resolution with OpenGL In-Reply-To: References: <1468949187.3072.83.camel@member.fsf.org> <1be818f4-de31-f7e0-e630-f468ec15919e@kdab.com> <1478608245.3562.7.camel@member.fsf.org> <1478619157.3562.11.camel@member.fsf.org> Message-ID: Hi. I wasn't involved with Charts at its inception, so I don't really know the original motivations. I suspect the aim was to provide easy to use module for simple charting use cases without needing 3rd party libraries, but not be the be-all-end-all charting solution for all users. That's how I see it these days, at any rate. There certainly isn't enough development resources put towards it to aspire to much else at the moment. -Miikka -----Original Message----- From: Development [mailto:development-bounces+miikka.heikkinen=qt.io at qt-project.org] On Behalf Of Uwe Rathmann Sent: 9. marraskuuta 2016 11:51 To: development at qt-project.org Subject: Re: [Development] Qt Charts poor dynamic/resolution with OpenGL On Wed, 09 Nov 2016 09:04:23 +0000, Miikka Heikkinen wrote: Hi Mikka, > I’m Qt Charts maintainer. It is true that Charts have been on back > burner for a good while now, as I’ve been assigned to other tasks, but > it’s not abandoned by any means. Maybe you could shed some light on the future of this module: what has happened is, that Qt project has started a new module, that naturally was/is behind 3rd party projects, that exist since many years. AFAIK the motivation to start this project was more a commercial driven decision than, that the existing solutions were not good enough. I'm doing the Qwt project for almost 18 years now and I'm fine if at some point it can be replaced by an official package. But to me Qt Charts looks like something that didn't work as a commercial idea and now rests more or less idle in the repositories ? Or if you don't intend to make it the best solution: what is the motivation of the Qt project in having this module at all, when there are several free and actively maintained chart packages around ? ciao, Uwe _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From oswald.buddenhagen at qt.io Wed Nov 9 16:01:19 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 9 Nov 2016 16:01:19 +0100 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: <20161108101458.GD22297@troll08> Message-ID: <20161109150119.GD12761@troll08> On Tue, Nov 08, 2016 at 04:50:00PM +0100, Louai Al-Khanji wrote: > +1 for qt/quips, I don't think of it as a web site thing either. > well, i don't want it in qt/ - this is not a generic namespace for stuff that doesn't fit elsewhere. everything in there *should* be aggregated by qt5.git (with an accurate status field), or be a submodule of an aggregated module. i can offer meta/ as an alternative. or maybe qtqt/ - that one already exists, but i suspect the objections will be the same as to www/. > Kai Koehne wrote: > > I'd slightly prefer > > > > qt/quips > > > > because it's not directly related to the website, even if we'll generate an > > html presentation out of it. We might even consider adding it to qt/qt5.git at > > one point ... > that makes no sense to me at all. the scope if this is certainly wider than the qt product itself. From andrew.knight at intopalo.com Wed Nov 9 16:04:49 2016 From: andrew.knight at intopalo.com (Andrew Knight) Date: Wed, 9 Nov 2016 16:04:49 +0100 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <20161109150119.GD12761@troll08> References: <20161108101458.GD22297@troll08> <20161109150119.GD12761@troll08> Message-ID: <5ec4aff6-7df9-3ec6-11bd-4374f9f5a4c8@intopalo.com> On 11/09/16 16:01, Oswald Buddenhagen wrote: > > i can offer meta/ as an alternative. +1 From Kai.Koehne at qt.io Wed Nov 9 16:11:08 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Wed, 9 Nov 2016 15:11:08 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <20161109150119.GD12761@troll08> References: <20161108101458.GD22297@troll08> <20161109150119.GD12761@troll08> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Oswald Buddenhagen > Sent: Wednesday, November 09, 2016 4:01 PM > To: development at qt-project.org > Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt > > On Tue, Nov 08, 2016 at 04:50:00PM +0100, Louai Al-Khanji wrote: > > +1 for qt/quips, I don't think of it as a web site thing either. > > > well, i don't want it in qt/ - this is not a generic namespace for stuff that > doesn't fit elsewhere. everything in there *should* be aggregated by qt5.git > (with an accurate status field), or be a submodule of an aggregated module. > > i can offer meta/ as an alternative. meta/quips would work for me, too. or qt-project/quips? > or maybe qtqt/ - that one already exists, but i suspect the objections will be > the same as to www/. No idea what qtqt/ should stand for :) > > Kai Koehne wrote: > > > I'd slightly prefer > > > > > > qt/quips > > > > > > because it's not directly related to the website, even if we'll > > > generate an html presentation out of it. We might even consider > > > adding it to qt/qt5.git at one point ... > > > that makes no sense to me at all. the scope if this is certainly wider than the > qt product itself. Why do you think so? This is the repository where we want to document processes and design decisions for Qt, the project _and_ the product. It's surely more meta than most of the modules, but we've also projects like qt/qtqa and qt/qtrepotools, which do not contain a qt module, either. Regards Kai From notmart at gmail.com Wed Nov 9 16:30:32 2016 From: notmart at gmail.com (Marco Martin) Date: Wed, 09 Nov 2016 16:30:32 +0100 Subject: [Development] QtQuickControls for desktop: what's the plan? In-Reply-To: <31032ACE-FFD1-409A-B0A9-CBEA7B56B69F@qt.io> References: <7ca68a12-8433-dd2e-3d1d-530ba2fe4202@users.sourceforge.net> <201611081045.10355.notmart@gmail.com> <31032ACE-FFD1-409A-B0A9-CBEA7B56B69F@qt.io> Message-ID: <1575014.3k6hiOkjt0@phobos> On Tuesday 08 November 2016 18:47:06 Jake Petroules wrote: > > I was planning to keep it a KDE project, probably as a tier 1 framework. > > That seems like a bad idea. Let's submit it to Qt so that everyone can > benefit and it can be kept better maintained alongside Qt and for all > platforms. Being maintained as as an upstream Qt project, may be appealing, yes. However, aslo it being a KDE project everyone can benefit. we plan to keep it multiplatform and with no external dependency other than Qt modules (that's what KDE framework tier 1 means). A big reason is actually that it would be quite easier to contribute to it. -- Marco Martin From Jake.Petroules at qt.io Wed Nov 9 18:49:53 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 9 Nov 2016 17:49:53 +0000 Subject: [Development] QtQuickControls for desktop: what's the plan? In-Reply-To: <1575014.3k6hiOkjt0@phobos> References: <7ca68a12-8433-dd2e-3d1d-530ba2fe4202@users.sourceforge.net> <201611081045.10355.notmart@gmail.com> <31032ACE-FFD1-409A-B0A9-CBEA7B56B69F@qt.io> <1575014.3k6hiOkjt0@phobos> Message-ID: <416F0995-CD37-4DED-A473-90B13101E288@qt.io> > On Nov 9, 2016, at 7:30 AM, Marco Martin wrote: > > On Tuesday 08 November 2016 18:47:06 Jake Petroules wrote: >>> I was planning to keep it a KDE project, probably as a tier 1 framework. >> >> That seems like a bad idea. Let's submit it to Qt so that everyone can >> benefit and it can be kept better maintained alongside Qt and for all >> platforms. > > Being maintained as as an upstream Qt project, may be appealing, yes. > However, aslo it being a KDE project everyone can benefit. Everyone, as long as they use LGPL. That's not everyone. > we plan to keep it > multiplatform and with no external dependency other than Qt modules (that's > what KDE framework tier 1 means). A big reason is actually that it would be > quite easier to contribute to it. And when we do the work ourselves because we'll eventually have to, your work will be obsoleted and have been for nothing because no one will have a reason to use it when the upstream solution will be maintained by the Qt Project and on by default. Whereas if we work *together*, no one wastes time and we have a unified experience for everyone. All this does is fragment Qt, and look how well fragmentation has worked for Android. > > -- > Marco Martin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From louai.al-khanji at qt.io Wed Nov 9 19:11:38 2016 From: louai.al-khanji at qt.io (Louai Al-Khanji) Date: Wed, 9 Nov 2016 18:11:38 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: <20161108101458.GD22297@troll08> <20161109150119.GD12761@troll08> Message-ID: As far as I am concerned meta/quips will do just fine. It’s not worth a bikeshed. Cheers, Louai On 11/9/16, 7:11 AM, "Development on behalf of Kai Koehne" wrote: > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Oswald Buddenhagen > Sent: Wednesday, November 09, 2016 4:01 PM > To: development at qt-project.org > Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt > > On Tue, Nov 08, 2016 at 04:50:00PM +0100, Louai Al-Khanji wrote: > > +1 for qt/quips, I don't think of it as a web site thing either. > > > well, i don't want it in qt/ - this is not a generic namespace for stuff that > doesn't fit elsewhere. everything in there *should* be aggregated by qt5.git > (with an accurate status field), or be a submodule of an aggregated module. > > i can offer meta/ as an alternative. meta/quips would work for me, too. or qt-project/quips? > or maybe qtqt/ - that one already exists, but i suspect the objections will be > the same as to www/. No idea what qtqt/ should stand for :) > > Kai Koehne wrote: > > > I'd slightly prefer > > > > > > qt/quips > > > > > > because it's not directly related to the website, even if we'll > > > generate an html presentation out of it. We might even consider > > > adding it to qt/qt5.git at one point ... > > > that makes no sense to me at all. the scope if this is certainly wider than the > qt product itself. Why do you think so? This is the repository where we want to document processes and design decisions for Qt, the project _and_ the product. It's surely more meta than most of the modules, but we've also projects like qt/qtqa and qt/qtrepotools, which do not contain a qt module, either. Regards Kai _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From darkbasic at linuxsystems.it Wed Nov 9 19:15:14 2016 From: darkbasic at linuxsystems.it (=?iso-8859-1?Q?Niccol=F2_Belli?=) Date: Wed, 09 Nov 2016 19:15:14 +0100 Subject: [Development] [HiDPI] Rethinking the scaling algorithm In-Reply-To: <201611082334.49057.kde@carewolf.com> References: <201611082334.49057.kde@carewolf.com> Message-ID: <80671659-db01-486a-8683-043cc35dcf2d@linuxsystems.it> (resend for the mailing list) On martedì 8 novembre 2016 23:34:48 CET, Allan Sandfeld Jensen wrote: > On Tuesday 08 November 2016, Niccolò Belli wrote: >> 1) Always round down. With your current formula a 145ppi >> screen gets scaled >> by a 2x factor, while every other toolkit (GTK3 for example[3]) starts >> scaling at 192ppi. This is also what people expect and it would return the >> correct 2x scaling factor for my laptop. So the formula should be >> scaling_factor=qRoundDown(yourDpi/96) >> > We have a two factor scaling system. We also scale by DPI. 144/2 == 72 for > instance, which happens to be the standard on Macs. Therefore > 144DPI become a > normal 2x scaling of standard 72 Mac DPI. > > And having 2x with smaller text, is a lot better than 1x with > large text on a > 27" 4K desktop screen. > > `Allan > > From Jake.Petroules at qt.io Wed Nov 9 19:20:31 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 9 Nov 2016 18:20:31 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: <20161108101458.GD22297@troll08> <20161109150119.GD12761@troll08> Message-ID: <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> Agree with meta/quips > On Nov 9, 2016, at 10:11 AM, Louai Al-Khanji wrote: > > As far as I am concerned meta/quips will do just fine. It’s not worth a bikeshed. > > Cheers, > Louai > > On 11/9/16, 7:11 AM, "Development on behalf of Kai Koehne" wrote: > > > >> -----Original Message----- >> From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- >> project.org] On Behalf Of Oswald Buddenhagen >> Sent: Wednesday, November 09, 2016 4:01 PM >> To: development at qt-project.org >> Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt >> >> On Tue, Nov 08, 2016 at 04:50:00PM +0100, Louai Al-Khanji wrote: >>> +1 for qt/quips, I don't think of it as a web site thing either. >>> >> well, i don't want it in qt/ - this is not a generic namespace for stuff that >> doesn't fit elsewhere. everything in there *should* be aggregated by qt5.git >> (with an accurate status field), or be a submodule of an aggregated module. >> >> i can offer meta/ as an alternative. > > meta/quips would work for me, too. or qt-project/quips? > >> or maybe qtqt/ - that one already exists, but i suspect the objections will be >> the same as to www/. > > No idea what qtqt/ should stand for :) > >>> Kai Koehne wrote: >>>> I'd slightly prefer >>>> >>>> qt/quips >>>> >>>> because it's not directly related to the website, even if we'll >>>> generate an html presentation out of it. We might even consider >>>> adding it to qt/qt5.git at one point ... >>> >> that makes no sense to me at all. the scope if this is certainly wider than the >> qt product itself. > > Why do you think so? This is the repository where we want to document processes > and design decisions for Qt, the project _and_ the product. It's surely more meta than > most of the modules, but we've also projects like qt/qtqa and qt/qtrepotools, which > do not contain a qt module, either. > > Regards > > Kai > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From darkbasic at linuxsystems.it Wed Nov 9 19:40:14 2016 From: darkbasic at linuxsystems.it (=?iso-8859-1?Q?Niccol=F2_Belli?=) Date: Wed, 09 Nov 2016 19:40:14 +0100 Subject: [Development] [HiDPI] Rethinking the scaling algorithm In-Reply-To: <2619849.Lo779ZvXFM@tjmaciei-mobl1> References: <2619849.Lo779ZvXFM@tjmaciei-mobl1> Message-ID: <6ede8a8b-85a9-48e2-821d-45f34572fae9@linuxsystems.it> On martedì 8 novembre 2016 23:02:04 CET, Thiago Macieira wrote: > Agreed we need to adjust the formula. I'm not sure a full round > down (i.e., an > integer division) is what we want. Another option is > > qRound(dpi / 96.0 - 0.75); > > That would make: > DPI < 168 1x > DPI < 264 2x > etc. I suggested a full round down because it mimics the behaviour of GTK3, which seems to work pretty well for them: https://wiki.gnome.org/HowDoI/HiDpi Anyway anythink else will probably work better than the current implementation which is simply broken and must be changed ASAP. > We have plenty of environment variables already. I personally set > QT_SCREEN_SCALE_FACTORS to 2 on my 13" 3200x1800 display (font DPI is 216). > > # 0 "eDP-1" Depth: 24 Primary: yes > Geometry: 1600x900+0+0 (native: 3200x1800+0+0) Available: 1600x876+0+0 > Physical size: 294x165 mm Refresh: 59 Hz Power state: 0 > Physical DPI: 138.231,138.545 Logical DPI: 108.085,108.341 (native: > 216.17,216.682) Subpixel_None > High DPI scaling factor: 2 DevicePixelRatio: 2 Pixel density: 3 > Primary orientation: 2 Orientation: 2 Native orientation: 0 > OrientationUpdateMask: 0 AFAIK QT_SCREEN_SCALE_FACTORS doesn't scale fonts, so you will still have to rely on QT_SCALE_FACTOR, which forces you to change the variable every time that you switch to another monitor. From darkbasic at linuxsystems.it Wed Nov 9 19:44:35 2016 From: darkbasic at linuxsystems.it (=?iso-8859-1?Q?Niccol=F2_Belli?=) Date: Wed, 09 Nov 2016 19:44:35 +0100 Subject: [Development] [HiDPI] Rethinking the scaling algorithm In-Reply-To: <80671659-db01-486a-8683-043cc35dcf2d@linuxsystems.it> References: <201611082334.49057.kde@carewolf.com> <80671659-db01-486a-8683-043cc35dcf2d@linuxsystems.it> Message-ID: <415182b4-d04c-4098-9cba-ffa417e770c1@linuxsystems.it> > On martedì 8 novembre 2016 23:34:48 CET, Allan Sandfeld Jensen wrote: >> We have a two factor scaling system. We also scale by DPI. >> 144/2 == 72 for instance, which happens to be the standard on >> Macs. Therefore 144DPI become a normal 2x scaling of standard >> 72 Mac DPI. >> >> And having 2x with smaller text, is a lot better than 1x with >> large text on a 27" 4K desktop screen. Unfortunately 4K 27" monitors are almost impossibile to scale well without floating point scaling. The right resolution for a 27" monitor would be 5K, but they are still too expensive and the current displayport/tuhnderbolt ports don't have enough bandwidth to drive two of them. From edward.welbourne at qt.io Wed Nov 9 19:49:08 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 9 Nov 2016 18:49:08 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> References: <20161108101458.GD22297@troll08> <20161109150119.GD12761@troll08> , <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> Message-ID: > Agree with meta/quips +1, Eddy. From harald.vistnes at gmail.com Wed Nov 9 21:46:56 2016 From: harald.vistnes at gmail.com (Harald Vistnes) Date: Wed, 9 Nov 2016 21:46:56 +0100 Subject: [Development] Problems compiling QtWebEngine in 5.8.0 beta Message-ID: Hi, I'm having problems compiling 5.8.0 beta from source. It fails when making qtwebengine. D:\qt-everywhere-opensource-src-5.8.0-beta\qtwebengine\src\3rdparty\ninja\ninja.exe -C D:/qt-everywhere-opensource-src-5.8.0-beta/qtwebengine/src/core/Release_x64 ninja: Entering directory `D:/qt-everywhere-opensource-src-5.8.0-beta/qtwebengine/src/core/Release_x64' ninja: error: WriteFile(obj\src\3rdparty\chromium\third_party\WebKit\Source\core\gen\blink\bindings\core\v8\webcore_generated.HTMLImageElementOrHTMLVideoElementOrHTMLCanvasElementOrBlobOrImageDataOrImageBitmap.obj.rsp): Unable to create file. No such file or directory ninja: build stopped: . NMAKE : fatal error U1077: 'D:\qt-everywhere-opensource-src-5.8.0-beta\qtwebengine\src\3rdparty\ninja\ninja.exe' : return code '0x1' Stop. NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe"' : return code '0x2' Stop. NMAKE : fatal error U1077: '(' : return code '0x2' Stop. NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. Environment: Windows 10 VS2015 x64 Windows 10 SDK ninja Any help would be appreciated. Thanks, Harald -------------- next part -------------- An HTML attachment was scrubbed... URL: From egor.pugin at gmail.com Wed Nov 9 22:55:00 2016 From: egor.pugin at gmail.com (Egor Pugin) Date: Thu, 10 Nov 2016 00:55:00 +0300 Subject: [Development] Problems compiling QtWebEngine in 5.8.0 beta In-Reply-To: References: Message-ID: Probably file path is too long. MS improved situation since win10.1607 (up to 32k symbols) but almost every program today (even from MS) is not able to handle such paths. They require special handling. See https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx for more info. I had same issues with cmake+msbuild invocations. On 9 November 2016 at 23:46, Harald Vistnes wrote: > Hi, > > I'm having problems compiling 5.8.0 beta from source. It fails when making > qtwebengine. > > > D:\qt-everywhere-opensource-src-5.8.0-beta\qtwebengine\src\3rdparty\ninja\ninja.exe > -C > D:/qt-everywhere-opensource-src-5.8.0-beta/qtwebengine/src/core/Release_x64 > ninja: Entering directory > `D:/qt-everywhere-opensource-src-5.8.0-beta/qtwebengine/src/core/Release_x64' > ninja: error: > WriteFile(obj\src\3rdparty\chromium\third_party\WebKit\Source\core\gen\blink\bindings\core\v8\webcore_generated.HTMLImageElementOrHTMLVideoElementOrHTMLCanvasElementOrBlobOrImageDataOrImageBitmap.obj.rsp): > Unable to create file. No such file or directory > > ninja: build stopped: . > NMAKE : fatal error U1077: > 'D:\qt-everywhere-opensource-src-5.8.0-beta\qtwebengine\src\3rdparty\ninja\ninja.exe' > : return code '0x1' > Stop. > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio > 14.0\VC\BIN\amd64\nmake.exe"' : return code '0x2' > Stop. > NMAKE : fatal error U1077: '(' : return code '0x2' > Stop. > NMAKE : fatal error U1077: 'cd' : return code '0x2' > Stop. > NMAKE : fatal error U1077: 'cd' : return code '0x2' > Stop. > NMAKE : fatal error U1077: 'cd' : return code '0x2' > Stop. > > Environment: > Windows 10 > VS2015 x64 > Windows 10 SDK > ninja > > Any help would be appreciated. > > Thanks, > Harald > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Egor Pugin From kde at carewolf.com Wed Nov 9 23:25:41 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Wed, 9 Nov 2016 23:25:41 +0100 Subject: [Development] [HiDPI] Rethinking the scaling algorithm In-Reply-To: <6ede8a8b-85a9-48e2-821d-45f34572fae9@linuxsystems.it> References: <2619849.Lo779ZvXFM@tjmaciei-mobl1> <6ede8a8b-85a9-48e2-821d-45f34572fae9@linuxsystems.it> Message-ID: <201611092325.41417.kde@carewolf.com> On Wednesday 09 November 2016, Niccolò Belli wrote: > On martedì 8 novembre 2016 23:02:04 CET, Thiago Macieira wrote: > > Agreed we need to adjust the formula. I'm not sure a full round > > down (i.e., an > > integer division) is what we want. Another option is > > > > qRound(dpi / 96.0 - 0.75); > > > > That would make: > > DPI < 168 1x > > DPI < 264 2x > > > > etc. > > I suggested a full round down because it mimics the behaviour of GTK3, > which seems to work pretty well for them: > https://wiki.gnome.org/HowDoI/HiDpi > Anyway anythink else will probably work better than the current > implementation which is simply broken and must be changed ASAP. > GTK has only just recently implemented HiDPI, much much later than Qt. What makes you think it is "working well for them"? Since most of the common configuration of HiDPI screens are following Mac standards, they have been designed to work at 2x scaling with 72DPI. We can not ignore all the Apple style screens out there like 4k 27" screen for instance. Which are specifically designed for 2x scaling. 144DPI must cause 2x scaling to follow what most HiDPI hardware have been designed for. What we need is a better tool and configuration for high-DPI tablets, phones and hybrids where the ideal virtual DPI is not 72 or 96 DPI. `Allan From thiago.macieira at intel.com Wed Nov 9 23:53:19 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 10 Nov 2016 06:53:19 +0800 Subject: [Development] [HiDPI] Rethinking the scaling algorithm In-Reply-To: <6ede8a8b-85a9-48e2-821d-45f34572fae9@linuxsystems.it> References: <2619849.Lo779ZvXFM@tjmaciei-mobl1> <6ede8a8b-85a9-48e2-821d-45f34572fae9@linuxsystems.it> Message-ID: <3361832.SS4tk5dK6H@tjmaciei-mobl1> On quarta-feira, 9 de novembro de 2016 19:40:14 CST Niccolò Belli wrote: > > We have plenty of environment variables already. I personally set > > QT_SCREEN_SCALE_FACTORS to 2 on my 13" 3200x1800 display (font DPI is > > 216). > AFAIK QT_SCREEN_SCALE_FACTORS doesn't scale fonts, so you will still have > to rely on QT_SCALE_FACTOR, which forces you to change the variable every > time that you switch to another monitor. Note what I said above: "font DPI is 216". That's a global X setting, not a Qt one. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From aleixpol at kde.org Thu Nov 10 00:40:34 2016 From: aleixpol at kde.org (Aleix Pol) Date: Thu, 10 Nov 2016 00:40:34 +0100 Subject: [Development] QtQuickControls for desktop: what's the plan? In-Reply-To: <416F0995-CD37-4DED-A473-90B13101E288@qt.io> References: <7ca68a12-8433-dd2e-3d1d-530ba2fe4202@users.sourceforge.net> <201611081045.10355.notmart@gmail.com> <31032ACE-FFD1-409A-B0A9-CBEA7B56B69F@qt.io> <1575014.3k6hiOkjt0@phobos> <416F0995-CD37-4DED-A473-90B13101E288@qt.io> Message-ID: On Wed, Nov 9, 2016 at 6:49 PM, Jake Petroules wrote: > >> On Nov 9, 2016, at 7:30 AM, Marco Martin wrote: >> >> On Tuesday 08 November 2016 18:47:06 Jake Petroules wrote: >>>> I was planning to keep it a KDE project, probably as a tier 1 framework. >>> >>> That seems like a bad idea. Let's submit it to Qt so that everyone can >>> benefit and it can be kept better maintained alongside Qt and for all >>> platforms. >> >> Being maintained as as an upstream Qt project, may be appealing, yes. >> However, aslo it being a KDE project everyone can benefit. > > Everyone, as long as they use LGPL. That's not everyone. That's arguable. >> we plan to keep it >> multiplatform and with no external dependency other than Qt modules (that's >> what KDE framework tier 1 means). A big reason is actually that it would be >> quite easier to contribute to it. > > And when we do the work ourselves because we'll eventually have to, your work will be obsoleted and have been for nothing because no one will have a reason to use it when the upstream solution will be maintained by the Qt Project and on by default. Whereas if we work *together*, no one wastes time and we have a unified experience for everyone. > > All this does is fragment Qt, and look how well fragmentation has worked for Android. I don't think this is the correct way to have this conversation. Threatening that if things are developed outside Qt licensing policies we're breaking the Qt project is way out of line, especially considering the long collaboration history we've had between KDE and Qt. Aleix From darkbasic at linuxsystems.it Thu Nov 10 02:40:34 2016 From: darkbasic at linuxsystems.it (=?iso-8859-1?Q?Niccol=F2_Belli?=) Date: Thu, 10 Nov 2016 02:40:34 +0100 Subject: [Development] [HiDPI] Rethinking the scaling algorithm In-Reply-To: <201611092325.41417.kde@carewolf.com> References: <2619849.Lo779ZvXFM@tjmaciei-mobl1> <6ede8a8b-85a9-48e2-821d-45f34572fae9@linuxsystems.it> <201611092325.41417.kde@carewolf.com> Message-ID: <9fbb8271-553f-4ccb-9d5c-ae8ee65eda6c@linuxsystems.it> On mercoledì 9 novembre 2016 23:25:41 CET, Allan Sandfeld Jensen wrote: > GTK has only just recently implemented HiDPI, much much later than Qt. > What makes you think it is "working well for them"? I think it's working well just because I didn't hear as many complaints as QT's, but may be as well because it still didn't receive as much testing. > Since most of the common configuration of HiDPI screens are following Mac > standards, they have been designed to work at 2x scaling with 72DPI. We can > not ignore all the Apple style screens out there like 4k 27" screen for > instance. Which are specifically designed for 2x scaling. > 144DPI must cause 2x > scaling to follow what most HiDPI hardware have been designed for. You're right, such monitor (which would be 82dpi once scaled) wouldn't benefit from rounding down, because it would get no scaling at all with my formula. > What we need is a better tool and configuration for high-DPI > tablets, phones > and hybrids where the ideal virtual DPI is not 72 or 96 DPI. Definitely yes, but I think we should also switch to a better formula which also takes into account monitors designed to work at ~140dpi once scaled. It doesn't mean that we shouldn't care for monitors engineered for different PPIs, it simply means that my point number one about rounding down wasn't correct and we still have to find another formula. Trying to get a better one I took into account two monitors (monitor A is a 27" 4K with 163.82 PPI and monitor B is a 13" 3200x1800 with 282.42 PPI) and I did some math to find a formula which gets the correct scaling (2x) for both. To achieve this result the slightest modification to the current formula that you can do is: scaling_factor=qRound(yourDpi/121.02 + 0.156) which gets qRound(1.51)=2 for monitor A and qRound(2.49)=2 for monitor B. This formula still works quite well if you need to scale higher than 2x, but the safety margin for the rounding operation is quite small. So I increased the safety margin getting scaling_factor=qRound(yourDpi/160.27 + 0.728) which gets qRound(1.75)=2 for monitor A and qRound(2.49)=2 for monitor B (currently we get a 3x scaling for monitor B so even 2.49 is a great improvement). Unfortunately it doesn't work as well if you need to scale higher than 2x. Knowing which monitor is the worst case scenario for case A (not-so-hi-dpi 2x scaling) and which one for case B (very-high-dpi 2x scaling) would help alot finding the best compromise. If you have better ideas I'm all ears. From Jake.Petroules at qt.io Thu Nov 10 05:10:49 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Thu, 10 Nov 2016 04:10:49 +0000 Subject: [Development] QtQuickControls for desktop: what's the plan? In-Reply-To: References: <7ca68a12-8433-dd2e-3d1d-530ba2fe4202@users.sourceforge.net> <201611081045.10355.notmart@gmail.com> <31032ACE-FFD1-409A-B0A9-CBEA7B56B69F@qt.io> <1575014.3k6hiOkjt0@phobos> <416F0995-CD37-4DED-A473-90B13101E288@qt.io> Message-ID: > On Nov 9, 2016, at 3:40 PM, Aleix Pol wrote: >>> we plan to keep it >>> multiplatform and with no external dependency other than Qt modules (that's >>> what KDE framework tier 1 means). A big reason is actually that it would be >>> quite easier to contribute to it. >> >> And when we do the work ourselves because we'll eventually have to, your work will be obsoleted and have been for nothing because no one will have a reason to use it when the upstream solution will be maintained by the Qt Project and on by default. Whereas if we work *together*, no one wastes time and we have a unified experience for everyone. >> >> All this does is fragment Qt, and look how well fragmentation has worked for Android. > > I don't think this is the correct way to have this conversation. > > Threatening that if things are developed outside Qt licensing policies > we're breaking the Qt project is way out of line, especially > considering the long collaboration history we've had between KDE and > Qt. There's a big difference between creating a new module that provides completely new functionality (in which case it would be disappointing yet completely fair to keep it out of the Qt Project if that's your choice), and adding a missing feature to an existing Qt module while deliberately keeping it out of the hands of the Qt Project and its commercial customers who pay for Qt to exist in the first place. That's rather selfish, and also rather shortsighted, because we WILL have to do this ourselves eventually if we want anyone to take QQC2 seriously. So why duplicate the work and let it all go to waste? > > Aleix -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From Kai.Koehne at qt.io Thu Nov 10 09:20:32 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Thu, 10 Nov 2016 08:20:32 +0000 Subject: [Development] Problems compiling QtWebEngine in 5.8.0 beta In-Reply-To: References: Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Egor Pugin > Sent: Wednesday, November 09, 2016 10:55 PM > To: Harald Vistnes > Cc: development at qt-project.org > Subject: Re: [Development] Problems compiling QtWebEngine in 5.8.0 beta > > Probably file path is too long. > MS improved situation since win10.1607 (up to 32k symbols) but almost > every program today (even from MS) is not able to handle such paths. > They require special handling. > See https://msdn.microsoft.com/en- > us/library/windows/desktop/aa365247(v=vs.85).aspx > for more info. Sigh. We've been tweaking webengine already in the past to use relative paths, but it seems we didn't succeed everywhere. Yeah, please make sure that the checkout path for qtwebengine is not too deep. Reggards Kai > I had same issues with cmake+msbuild invocations. > > On 9 November 2016 at 23:46, Harald Vistnes > wrote: > > Hi, > > > > I'm having problems compiling 5.8.0 beta from source. It fails when > > making qtwebengine. > > > > > > D:\qt-everywhere-opensource-src-5.8.0- > beta\qtwebengine\src\3rdparty\ni > > nja\ninja.exe > > -C > > D:/qt-everywhere-opensource-src-5.8.0- > beta/qtwebengine/src/core/Releas > > e_x64 > > ninja: Entering directory > > `D:/qt-everywhere-opensource-src-5.8.0- > beta/qtwebengine/src/core/Release_x64' > > ninja: error: > > > WriteFile(obj\src\3rdparty\chromium\third_party\WebKit\Source\core\gen > \blink\bindings\core\v8\webcore_generated.HTMLImageElementOrHTMLVi > deoElementOrHTMLCanvasElementOrBlobOrImageDataOrImageBitmap.obj. > rsp): > > Unable to create file. No such file or directory > > > > ninja: build stopped: . > > NMAKE : fatal error U1077: > > 'D:\qt-everywhere-opensource-src-5.8.0- > beta\qtwebengine\src\3rdparty\ninja\ninja.exe' > > : return code '0x1' > > Stop. > > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual > > Studio 14.0\VC\BIN\amd64\nmake.exe"' : return code '0x2' > > Stop. > > NMAKE : fatal error U1077: '(' : return code '0x2' > > Stop. > > NMAKE : fatal error U1077: 'cd' : return code '0x2' > > Stop. > > NMAKE : fatal error U1077: 'cd' : return code '0x2' > > Stop. > > NMAKE : fatal error U1077: 'cd' : return code '0x2' > > Stop. > > > > Environment: > > Windows 10 > > VS2015 x64 > > Windows 10 SDK > > ninja > > > > Any help would be appreciated. > > > > Thanks, > > Harald > > > > > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > > > > -- > Egor Pugin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Morten.Sorvig at qt.io Thu Nov 10 09:47:08 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Thu, 10 Nov 2016 08:47:08 +0000 Subject: [Development] Dictation Issues with Qt-built software In-Reply-To: References: <90A518D8-DF8D-4664-92E1-700DCFCAD8DA@qt.io> Message-ID: > On 4 Nov 2016, at 13:00, Robert Iakobashvili wrote: > > Right. Most users of dictation are people with learning or motoric disabilities. > > When these users are used to a certain pattern of platform-specific habits > working for them, any other options to do the same could be seen as usability issues > breaking these habits. Hi, after some further investigation and offline discussion (thanks Frederik!), I think we’re closer to solving this: Dictation input can be handled via our current input method support, where we implement the NSTextInputClient protocol. As a matter fact this almost works today (Qt 5.6): select text in a Qt text editor; starting dictation via the fn key should now work. So what we are looking at then is developing a bug fix to our NSTextInputClient protocol implementation to make dictation work in all cases. Morten From frederik.gladhorn at qt.io Thu Nov 10 09:55:00 2016 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Thu, 10 Nov 2016 09:55:00 +0100 Subject: [Development] QtQuickControls for desktop: what's the plan? In-Reply-To: <416F0995-CD37-4DED-A473-90B13101E288@qt.io> References: <7ca68a12-8433-dd2e-3d1d-530ba2fe4202@users.sourceforge.net> <1575014.3k6hiOkjt0@phobos> <416F0995-CD37-4DED-A473-90B13101E288@qt.io> Message-ID: <2067556.CUMk66bXVn@frederik-thinkcentre-m93p> Hello all, let's take a step back and get back into a productive discussion :) I'm sorry that Jake uses so harsh words and I hope everyone understands he expresses his personal opinion since he's not even directly involved in the Qt Quick Controls (1/2) project. Yesterday we had some debate here in Oslo about what is needed for controls in the near future and where we see things heading. I should have joined the discussion earlier, but I perfer to ponder things a bit before shouting out loud. >From our point of view, one of the biggest show stoppers in the near future is the lack of table view support (which touches listview and related). This is a topic that keeps comming up and we want to get it right, since in qcc1 you could hardly have more than 10 columns without massive performance issues. So the current focus for us is polishing what we have and looking at the lists and tables. At the same time there seem to be three big gaps in styling. We have researched an iOS style, there are some legal concerns around it since it's unclear what Apple allows in the app store, so that's somewhat on hold, maybe we'll just publish it without any guarantees (that it's viable to get apps on the store with it) since we cannot give any. In the mean time, using custom styles should be perfectly fine for the iOS case. Slightly ironic. With that said, macOS is another candidate where we're starting to look. Again, Apple is not making it exactly easy by basically not providing public APIs, but we'll see what we end up with. Especially animations will be interesting. Any insights and help is of course appreciated. The last gap are Linux styles. The situation with KDE is actually quite interesting, since the platform is QStyle based. We do not believe in QStyle based styles for QQC2 as it stands. They will never have the same performance level of the other styles. Changing QStyle is not exactly trivial either, but maybe we can find a way to make it efficent and share code. Maybe we in the end conclude that it's all too much work and we want to have a QStyle based theme in controls 2, but let's first explore the options. I don't know the code enough to have any kind of opinion at this point and I'd propose people that actually have better insights explore which way makes most sense. Now we're back to where we started the discussion and I hope we'll find out how to cooperate best, inside or outside the controls repository. Kind regards, Frederik From harald.vistnes at gmail.com Thu Nov 10 10:07:36 2016 From: harald.vistnes at gmail.com (Harald Vistnes) Date: Thu, 10 Nov 2016 10:07:36 +0100 Subject: [Development] Problems compiling QtWebEngine in 5.8.0 beta In-Reply-To: References: Message-ID: Thanks for the input. Creating a file named webcore_generated.HTMLImageElementOrHTMLVideoEle mentOrHTMLCanvasElementOrBlobOrImageDataOrImageBitmap.obj.rsp in a shallow folder was no problem. However, if I try to create it in the folder where it should be generated: D:\qt-everywhere-opensource-src-5.8.0-beta\qtwebengine\src\core\Release_x64\obj\src\3rdparty\chromium\third_party\WebKit\Source\core\gen\blink\bindings\core\v8 then Windows pops up an error message: 'Destination Path Too Long The file name(s) would be too long for the destination folder...' That complete path would be 270 characters, which is longer than the 260 characters maximum. I've started a new build in a folder with a shorter name than D:\qt-everywhere-opensource-src-5.8.0-beta, so all paths should hopefully be less than 260 characters. Harald 2016-11-10 9:50 GMT+01:00 Edward Welbourne : > Harald Vistnes quoted an unhappy compiler: > > ...\webcore_generated.HTMLImageElementOrHTMLVideoEle > mentOrHTMLCanvasElementOrBlobOrImageDataOrImageBitmap.obj.rsp): Unable to > create file. No such file or directory > > That's 110 bytes of file-name: does your file-system have a problem with > names that long ? > Try creating a file with that name and see what happens ... > Not sure what to do if it refuses, but it's at least a diagnostic test, > > Eddy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Morten.Sorvig at qt.io Thu Nov 10 10:43:06 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Thu, 10 Nov 2016 09:43:06 +0000 Subject: [Development] [HiDPI] Rethinking the scaling algorithm In-Reply-To: References: Message-ID: > On 8 Nov 2016, at 15:57, Niccolò Belli wrote: > > Hi, > My laptop's monitor is a 13" with a 16:9 aspect ratio and a 3200x1800 resolution. As you can see[1] the EDID[2] is perfectly correct. > QT computes the scaling factor using a formula like this: scaling_factor=qRound(yourDpi/96) > This is far from ideal in my opinion, because if we want to scale to 96 logical PPI it means that on a 13" 16:9 screen we want to target a 1088x612 logical resolution. In fact qRound(282.42/96) computes a 3x scaling factor for my laptop, which is not a scaling factor that *anybody* would like to have (except maybe my old grandfather with poor eyesight). In fact a logical resolution of *less* than 1088x612 (it's lesser because qRound actually rounded up the value) is too tiny even for a 13" screen and people would prefer a 2x scaling factor instead, which would give you a logical resolution of 1600x900 (instead of an useless 1067x600). > > I have some suggestions to improve the current scaling algorithm: > > 1) Always round down. With your current formula a 145ppi screen gets scaled by a 2x factor, while every other toolkit (GTK3 for example[3]) starts scaling at 192ppi. This is also what people expect and it would return the correct 2x scaling factor for my laptop. So the formula should be scaling_factor=qRoundDown(yourDpi/96) Hi, thanks for bringing this up. I agree with this point; mathematically correct rounding may not be the best kind of correct in this case. In fact a change is already in review: https://codereview.qt-project.org/#/c/157174/ This introduces QT_SCALE_FACTOR_ROUNDING_POLICY with the following options: Round qRound(), as today Ceil qCeil() Floor qFloor() RoundPreferFloor Round up for .75 and higher PassThrough Do not round and allow fractional scale factors RoundPreferFloor is the new default. Do you think this is sufficient? Adding more options is possible, as is adding a C++ API if needed. Morten From Morten.Sorvig at qt.io Thu Nov 10 10:43:08 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Thu, 10 Nov 2016 09:43:08 +0000 Subject: [Development] [HiDPI] Rethinking the scaling algorithm In-Reply-To: <201611092325.41417.kde@carewolf.com> References: <2619849.Lo779ZvXFM@tjmaciei-mobl1> <6ede8a8b-85a9-48e2-821d-45f34572fae9@linuxsystems.it> <201611092325.41417.kde@carewolf.com> Message-ID: <8E262DA0-4327-4B6F-9B97-692878F75216@qt.io> > On 9 Nov 2016, at 23:25, Allan Sandfeld Jensen wrote: > > > Since most of the common configuration of HiDPI screens are following Mac > standards, they have been designed to work at 2x scaling with 72DPI. We can > not ignore all the Apple style screens out there like 4k 27" screen for > instance. Which are specifically designed for 2x scaling. 144DPI must cause 2x > scaling to follow what most HiDPI hardware have been designed for. > > What we need is a better tool and configuration for high-DPI tablets, phones > and hybrids where the ideal virtual DPI is not 72 or 96 DPI. On the other hand, Windows 200% must also result in 2x scaling. And windows will return 2 * 96 DPI for that case. What I have in my patches is API where the platform plugin reports the base DPI in addition to the current DPI. So in the Windows case the values would be 96 and 192, respectively. See https://codereview.qt-project.org/#/c/157174 . In theory, a platform like Android could then return its base DPI of 160 along with the current DPI, and we would apply the correct scale factor according to the device class. (In practice I think the Android platform plugin currently normalizes the base DPI to 96) Would this allow enough configurability to handle your 4K 27” case? We have user API for setting the DPI (QT_FONT_DPI) as well, but this is currently a global setter and not that useful for multi-screen setups. Morten From Morten.Sorvig at qt.io Thu Nov 10 10:43:11 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Thu, 10 Nov 2016 09:43:11 +0000 Subject: [Development] [HiDPI] Rethinking the scaling algorithm In-Reply-To: <415182b4-d04c-4098-9cba-ffa417e770c1@linuxsystems.it> References: <201611082334.49057.kde@carewolf.com> <80671659-db01-486a-8683-043cc35dcf2d@linuxsystems.it> <415182b4-d04c-4098-9cba-ffa417e770c1@linuxsystems.it> Message-ID: <3D9CACE0-0B75-4604-A029-25D131109220@qt.io> > On 9 Nov 2016, at 19:44, Niccolò Belli wrote: > >> On martedì 8 novembre 2016 23:34:48 CET, Allan Sandfeld Jensen wrote: >>> We have a two factor scaling system. We also scale by DPI. 144/2 == 72 for instance, which happens to be the standard on Macs. Therefore 144DPI become a normal 2x scaling of standard 72 Mac DPI. And having 2x with smaller text, is a lot better than 1x with large text on a 27" 4K desktop screen. > > Unfortunately 4K 27" monitors are almost impossibile to scale well without floating point scaling. The right resolution for a 27" monitor would be 5K, but they are still too expensive and the current displayport/tuhnderbolt ports don't have enough bandwidth to drive two of them. Agreed, if you look at pixel density then 24” seems to be the best option for 4K. This gives a PPI of 186, which is close enough to for example the rMBP at 227 PPI to make 2x an option. (Even more so if you allow a slightly larger intended viewing distance for the desktop monitor.) Morten From olivier at woboq.com Thu Nov 10 11:11:35 2016 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 10 Nov 2016 11:11:35 +0100 Subject: [Development] QtQuickControls for desktop: what's the plan? In-Reply-To: <2067556.CUMk66bXVn@frederik-thinkcentre-m93p> References: <7ca68a12-8433-dd2e-3d1d-530ba2fe4202@users.sourceforge.net> <416F0995-CD37-4DED-A473-90B13101E288@qt.io> <2067556.CUMk66bXVn@frederik-thinkcentre-m93p> Message-ID: <1941230.BoOzVkPR3A@maurice> On Donnerstag, 10. November 2016 09:55:00 CET Frederik Gladhorn wrote: > Hello all, > let's take a step back and get back into a productive discussion :) > > I'm sorry that Jake uses so harsh words and I hope everyone understands he > expresses his personal opinion since he's not even directly involved in the > Qt Quick Controls (1/2) project. Thanks for the apology. (It's a bit rude to demand that someone contribute for free to someone else's commercial product.) > Yesterday we had some debate here in Oslo about what is needed for controls > in the near future and where we see things heading. [...] > We have researched an iOS style [...] macOS is another candidate where we're > starting to look. Great to hear that you are looking at the desktop again. Also... don't forget Windows and GTK+ styles. > The situation with KDE is actually quite interesting, since the platform is > QStyle based. It does not have to be. I believe there will be an QQC2 Oxygen style soon enough. > We do not believe in QStyle based styles for QQC2 as it stands. They will > never have the same performance level of the other styles. þ...] Regarding performance maybe it's good enough for desktop. But there are other reasons why QStyle might not be desirable: dependency on QtWidget and alien abstraction. > Maybe we in the end conclude that it's all too much work and we want to have > a QStyle based theme in controls 2, but let's first explore the options. Writing and polishing styles to pixel perfection is indeed lot of work. And QStyle has the advantage hat it already exists. However one can copy-paste the code to turn existing styles into QCC2 style. (You will have two style to maintain since QtWidgets is still maintained) The proxy style to QStyle that Marco is developing is a good intermediate solution for people wanting to develop cross platform desktop applications, while waiting for proper native looking themes on each platform. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From oswald.buddenhagen at qt.io Thu Nov 10 12:29:12 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 10 Nov 2016 12:29:12 +0100 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: <20161108101458.GD22297@troll08> <20161109150119.GD12761@troll08> <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> Message-ID: <20161110112912.GB9877@troll08> On Wed, Nov 09, 2016 at 06:49:08PM +0000, Edward Welbourne wrote: > > Agree with meta/quips > > +1, > the repository has been created. next point: permissions. i don't think the regular ones are appropriate - they are way too anarchic for a process that is supposed to reflect *actual* community consensus. the easiest would be going with the normal approval rights, but limit the submit button to a "QUIP owners" group which would consist of lars (and possibly a _few_ deputies). From rawoul at gmail.com Thu Nov 10 12:39:14 2016 From: rawoul at gmail.com (Arnaud Vrac) Date: Thu, 10 Nov 2016 11:39:14 +0000 Subject: [Development] cdn.qt.digia.com SSL certificate has expired Message-ID: Hi, I'm trying to run MaintenanceTool on my Qt commercial install and it fails, apparently because the SSL certificate to cdn.qt.digia.com has expired. This also prevents using the online installer. Can this please be fixed ? Thanks, -Arnaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From jedrzej.nowacki at qt.io Thu Nov 10 13:33:17 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Thu, 10 Nov 2016 13:33:17 +0100 Subject: [Development] cdn.qt.digia.com SSL certificate has expired In-Reply-To: References: Message-ID: <8807471.mYBqfqo8nS@42> On torsdag 10. november 2016 11.39.14 CET Arnaud Vrac wrote: > Hi, > > I'm trying to run MaintenanceTool on my Qt commercial install and it fails, > apparently because the SSL certificate to cdn.qt.digia.com has expired. > This also prevents using the online installer. > > Can this please be fixed ? > > Thanks, > > -Arnaud I have forwarded this email to our IT. Should be fixed soon. Thanks, Jędrek From jani.heikkinen at qt.io Thu Nov 10 13:38:41 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 10 Nov 2016 12:38:41 +0000 Subject: [Development] Change file process & improvement proposal In-Reply-To: References: Message-ID: Hi all, Lately it has been quite hard to get change files done for the releases. It should be maintainers responsibility to make sure those will be done for every release and those are containing proper data. We have tried to help maintainers by doing initial ones for them (running script to collect all changes containing [ChangeLog] -tag). Unfortunately it seems that tag is really rarely used (at least in most of modules) even there is lots of changes in:( In my opinion (almost) all changes in patch level release should be worth of change file entry: If change isn't critical enough for change file entry does it belong in patch level release at all? Could we change our template/sanitybot so that it encourage developers to add change file entries more often and forces them to do it in release branches? One unclear issue related to change files is when we should have one? Should we create one only if there really is some critical changes in the submodule or should we create one in any case? I think the latter one could be more clear one: In first case it is unclear why one is missing? Is it because maintainer hasn't done his job or just because there isn't important changes to be mentioned? In latter case there is that change file for every release and it contains info if there is important changes or not. And another issue is the 'base release' for change files. Someones seems to think change files should contain diff from previous official release (meaning 5.7.1 change files should contain delta from 5.6.2) and others that diff should be from previous release of same series (meaning 5.7.1 change files should contain delta from 5.7.0). I have thought it is latter one and created initial ones based on that assumption. So I propose: 1) Let's enable [ChangeLog] -tag by default in commit template. After that you must remove/comment out it by purpose if you don't want add it. And in addition to this update sanity bot so that it will give '-1' if change log entry isn't given in release branch. This can be bypassed by giving '+1' manually for sanity review if really needed... That way we could get more ready change files directly by running script and so on less work for maintainer. 2) Let's agree every submodule in the release needs to have a change file (to make things clear) 3) Let's agree the change log is the diff between new & previous release in same series (in case of patch level release, meaning delta from x.y.z -> x.y.z+1). And for new major release the diff is from last patch release from previous series Jani Heikkinen Release Manager The Qt Company From jedrzej.nowacki at qt.io Thu Nov 10 14:21:18 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Thu, 10 Nov 2016 14:21:18 +0100 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <20161110112912.GB9877@troll08> References: <20161110112912.GB9877@troll08> Message-ID: <2537366.LM4OPadTkB@42> On torsdag 10. november 2016 12.29.12 CET Oswald Buddenhagen wrote: > the easiest would be going with the normal approval rights, but limit > the submit button to a "QUIP owners" group which would consist of lars > (and possibly a _few_ deputies). Considering expected traffic there it could be only Lars :-) Cheers, Jędrek From harald.vistnes at gmail.com Thu Nov 10 14:42:34 2016 From: harald.vistnes at gmail.com (Harald Vistnes) Date: Thu, 10 Nov 2016 14:42:34 +0100 Subject: [Development] Problems compiling QtWebEngine in 5.8.0 beta In-Reply-To: References: Message-ID: FYI, using a shorter folder name solved the problem. Thanks for your help. Harald 2016-11-10 10:58 GMT+01:00 Edward Welbourne : > > I've started a new build in a folder with a shorter name > > Good luck, > > Eddy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From notmart at gmail.com Thu Nov 10 15:08:40 2016 From: notmart at gmail.com (Marco Martin) Date: Thu, 10 Nov 2016 15:08:40 +0100 Subject: [Development] QtQuickControls for desktop: what's the plan? In-Reply-To: <1941230.BoOzVkPR3A@maurice> References: <7ca68a12-8433-dd2e-3d1d-530ba2fe4202@users.sourceforge.net> <2067556.CUMk66bXVn@frederik-thinkcentre-m93p> <1941230.BoOzVkPR3A@maurice> Message-ID: <2002988.WUrOxaYX9B@phobos> On Thursday 10 November 2016 11:11:35 Olivier Goffart wrote: > Writing and polishing styles to pixel perfection is indeed lot of work. And > QStyle has the advantage hat it already exists. However one can copy-paste > the code to turn existing styles into QCC2 style. (You will have two style > to maintain since QtWidgets is still maintained) > > The proxy style to QStyle that Marco is developing is a good intermediate > solution for people wanting to develop cross platform desktop applications, > while waiting for proper native looking themes on each platform. yeah, I also see it more like as a temporary solution as well, if not else for the fact that it can work only on QApplication instances. For us it's important to get in a short enough time span a good compelling reasons for applications to start using qtquickcontrols2, but I agree on the long run something else not linking to qwidgets is needed (which also speaks against official inclusion in Qt, as would get deprecated soon-ish in that case) -- Marco Martin From oswald.buddenhagen at qt.io Thu Nov 10 15:23:06 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 10 Nov 2016 15:23:06 +0100 Subject: [Development] Change file process & improvement proposal In-Reply-To: References: Message-ID: <20161110142306.GC9877@troll08> On Thu, Nov 10, 2016 at 12:38:41PM +0000, Jani Heikkinen wrote: > Lately it has been quite hard to get change files done for the releases. > oh, it's that time of the year again. :D > 1) Let's enable [ChangeLog] -tag by default in commit template. After > that you must remove/comment out it by purpose if you don't want add > it. > i really don't think this will make a positive difference. the problem is that many people just don't have the right audience-oriented mindset. we *already* have lots of garbage changelog entries, and this will just worsen the S/N ratio. > And in addition to this update sanity bot so that it will give '-1' if > change log entry isn't given in release branch. > this is probably not sensible. most last-minute fixes relate to recently introduced problems, which means that they specifically *don't* need changelog entries. here's what i think would actually make a difference (based on historical evidence within trolltech): https://bugreports.qt.io/browse/QTQAINFRA-933 > 2) Let's agree every submodule in the release needs to have a change > file (to make things clear) > yes > 3) Let's agree the change log is the diff between new & previous > release in same series (in case of patch level release, meaning delta > from x.y.z -> x.y.z+1). And for new major release the diff is from > last patch release from previous series > that seems a no-brainer to me. the tricky question is what to do with LTS vs. stable, but we already resolved this: we duplicate the relevant log entries. From edward.welbourne at qt.io Thu Nov 10 17:18:05 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 10 Nov 2016 16:18:05 +0000 Subject: [Development] Neat feature in gerrit: drafts Message-ID: A review puzzled several of us today by (apparently) starting at patch set 6. Jesus had discovered a gerrit feature we hadn't heard of: drafts. If you push to refs/drafts/blah instead of refs/for/blah, you get a review on gerrit with much of the effect we normally achieve using WIP but without the sanity-bot's complaint about WIP and without the buttons that would allow staging. Folk can comment on it, they just can't actually accept it yet. Later you can push to refs/for/blah as usual and the review turns into a real review. Further pushes to refs/drafts/blah will be added as later patch sets without spamming those watching the review, while being visible to anyone actually looking at it; and you can delete drafts from the history once all they are is clutter. There's probably more fun I've yet to learn. This seemed worth publicizing; so now you all know :-) Eddy. From annulen at yandex.ru Thu Nov 10 17:20:15 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 10 Nov 2016 19:20:15 +0300 Subject: [Development] Neat feature in gerrit: drafts In-Reply-To: References: Message-ID: <321851478794815@web4j.yandex.ru> 10.11.2016, 19:18, "Edward Welbourne" : > A review puzzled several of us today by (apparently) starting at patch > set 6. Jesus had discovered a gerrit feature we hadn't heard of: > drafts. FYI, it was around for ages, since 2.3 release > If you push to refs/drafts/blah instead of refs/for/blah, you > get a review on gerrit with much of the effect we normally achieve using > WIP but without the sanity-bot's complaint about WIP and without the > buttons that would allow staging. Folk can comment on it, they just > can't actually accept it yet. Later you can push to refs/for/blah as > usual and the review turns into a real review. Further pushes to > refs/drafts/blah will be added as later patch sets without spamming > those watching the review, while being visible to anyone actually > looking at it; and you can delete drafts from the history once all they > are is clutter. There's probably more fun I've yet to learn. > > This seemed worth publicizing; so now you all know :-) > >         Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From Jake.Petroules at qt.io Thu Nov 10 19:37:44 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Thu, 10 Nov 2016 18:37:44 +0000 Subject: [Development] QtQuickControls for desktop: what's the plan? In-Reply-To: <2002988.WUrOxaYX9B@phobos> References: <7ca68a12-8433-dd2e-3d1d-530ba2fe4202@users.sourceforge.net> <2067556.CUMk66bXVn@frederik-thinkcentre-m93p> <1941230.BoOzVkPR3A@maurice> <2002988.WUrOxaYX9B@phobos> Message-ID: <3A1EDC97-F8FB-42BE-8A4C-40719B663BD0@qt.io> > On Nov 10, 2016, at 6:08 AM, Marco Martin wrote: > > On Thursday 10 November 2016 11:11:35 Olivier Goffart wrote: >> Writing and polishing styles to pixel perfection is indeed lot of work. And >> QStyle has the advantage hat it already exists. However one can copy-paste >> the code to turn existing styles into QCC2 style. (You will have two style >> to maintain since QtWidgets is still maintained) >> >> The proxy style to QStyle that Marco is developing is a good intermediate >> solution for people wanting to develop cross platform desktop applications, >> while waiting for proper native looking themes on each platform. > > yeah, I also see it more like as a temporary solution as well, if not else for > the fact that it can work only on QApplication instances. > For us it's important to get in a short enough time span a good compelling > reasons for applications to start using qtquickcontrols2, but I agree on the > long run something else not linking to qwidgets is needed (which also speaks > against official inclusion in Qt, as would get deprecated soon-ish in that case) OK, I think that's a very reasonable assessment. After that, if you have any ideas around creating a proper long term solution for QQC2 that doesn't rely on QStyle, we'd love to hear them! Patches are welcome as well. :) > -- > Marco Martin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From annulen at yandex.ru Thu Nov 10 19:41:42 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 10 Nov 2016 21:41:42 +0300 Subject: [Development] QtQuickControls for desktop: what's the plan? In-Reply-To: <2002988.WUrOxaYX9B@phobos> References: <7ca68a12-8433-dd2e-3d1d-530ba2fe4202@users.sourceforge.net> <2067556.CUMk66bXVn@frederik-thinkcentre-m93p> <1941230.BoOzVkPR3A@maurice> <2002988.WUrOxaYX9B@phobos> Message-ID: <458551478803302@web26m.yandex.ru> 10.11.2016, 17:08, "Marco Martin" : > On Thursday 10 November 2016 11:11:35 Olivier Goffart wrote: >>  Writing and polishing styles to pixel perfection is indeed lot of work. And >>  QStyle has the advantage hat it already exists. However one can copy-paste >>  the code to turn existing styles into QCC2 style. (You will have two style >>  to maintain since QtWidgets is still maintained) >> >>  The proxy style to QStyle that Marco is developing is a good intermediate >>  solution for people wanting to develop cross platform desktop applications, >>  while waiting for proper native looking themes on each platform. > > yeah, I also see it more like as a temporary solution as well, if not else for > the fact that it can work only on QApplication instances. > For us it's important to get in a short enough time span a good compelling > reasons for applications to start using qtquickcontrols2, but I agree on the > long run something else not linking to qwidgets is needed (which also speaks > against official inclusion in Qt, as would get deprecated soon-ish in that case) Such deprecation would mean that users of 3rd-party QStyle themes will need to port their themes away from QStyle to make QCC2 applications look native > > -- > Marco Martin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From sahumada at texla.cl Thu Nov 10 21:35:09 2016 From: sahumada at texla.cl (Sergio Ahumada) Date: Thu, 10 Nov 2016 21:35:09 +0100 Subject: [Development] Neat feature in gerrit: drafts In-Reply-To: <321851478794815@web4j.yandex.ru> References: <321851478794815@web4j.yandex.ru> Message-ID: <2afdd680-c6d0-c66a-4edb-3d5fb440a3a6@texla.cl> On 10.11.2016 17:20, Konstantin Tokarev wrote: > > > 10.11.2016, 19:18, "Edward Welbourne" : >> A review puzzled several of us today by (apparently) starting at patch >> set 6. Jesus had discovered a gerrit feature we hadn't heard of: >> drafts. > > FYI, it was around for ages, since 2.3 release git-gpush has it since 2014 https://codereview.qt-project.org/88136 >> If you push to refs/drafts/blah instead of refs/for/blah, you >> get a review on gerrit with much of the effect we normally achieve using >> WIP but without the sanity-bot's complaint about WIP and without the >> buttons that would allow staging. Folk can comment on it, they just >> can't actually accept it yet. Later you can push to refs/for/blah as >> usual and the review turns into a real review. Further pushes to >> refs/drafts/blah will be added as later patch sets without spamming >> those watching the review, while being visible to anyone actually >> looking at it; and you can delete drafts from the history once all they >> are is clutter. There's probably more fun I've yet to learn. >> >> This seemed worth publicizing; so now you all know :-) >> >> Eddy. -- Sergio Ahumada sahumada at texla.cl From tobias.hunger at gmail.com Fri Nov 11 07:27:52 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Fri, 11 Nov 2016 07:27:52 +0100 Subject: [Development] Neat feature in gerrit: drafts In-Reply-To: References: Message-ID: Hi Edward, Am 10.11.2016 17:18 schrieb "Edward Welbourne" : > > A review puzzled several of us today by (apparently) starting at patch > set 6. Jesus had discovered a gerrit feature we hadn't heard of: > drafts. If you push to refs/drafts/blah instead of refs/for/blah, you > get a review on gerrit with much of the effect we normally achieve using > WIP but without the sanity-bot's complaint about WIP and without the > buttons that would allow staging. Folk can comment on it, they just > can't actually accept it yet. Later you can push to refs/for/blah as > usual and the review turns into a real review. Further pushes to > refs/drafts/blah will be added as later patch sets without spamming > those watching the review, while being visible to anyone actually > looking at it; and you can delete drafts from the history once all they > are is clutter. There's probably more fun I've yet to learn. > > This seemed worth publicizing; so now you all know :-) Qt Creator supports drafts, too. You can also push a draft over an existing patch set in review. That draft can then be discussed and "published" to become a "real" patch in the patch set. Best Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From mardy at users.sourceforge.net Fri Nov 11 09:02:46 2016 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Fri, 11 Nov 2016 11:02:46 +0300 Subject: [Development] QtQuickControls for desktop: what's the plan? In-Reply-To: <2067556.CUMk66bXVn@frederik-thinkcentre-m93p> References: <7ca68a12-8433-dd2e-3d1d-530ba2fe4202@users.sourceforge.net> <1575014.3k6hiOkjt0@phobos> <416F0995-CD37-4DED-A473-90B13101E288@qt.io> <2067556.CUMk66bXVn@frederik-thinkcentre-m93p> Message-ID: <2b7adf22-5a50-85cc-3574-dac6aa85521b@users.sourceforge.net> On 10/11/2016 11:55, Frederik Gladhorn wrote: > The last gap are Linux styles. The situation with KDE is actually quite > interesting, since the platform is QStyle based. We do not believe in QStyle > based styles for QQC2 as it stands. They will never have the same performance > level of the other styles. If QStyle is used by QWidgets, which have been used in apps since well before QML existed, it's reasonable to expect that its performance is more than acceptable for modern desktop machines. > Changing QStyle is not exactly trivial either, but > maybe we can find a way to make it efficent and share code. Maybe we in the end > conclude that it's all too much work and we want to have a QStyle based theme > in controls 2, but let's first explore the options. I don't know the code > enough to have any kind of opinion at this point and I'd propose people that > actually have better insights explore which way makes most sense. And I've been away from Windows and OS X for so long, that I have no idea how widgets have evolved there. As I understand, QStyle is for drawing static elements, but you mentioned that in OSX we now have widget animations... Maybe we might have to give up on the idea of a single implementation, and instead have a different style for each toolkit? At least with Gtk, it might be possible to use native Gtk widgets, as we are already using the glib mainloop in Linux, and GtkWidgets allow for offscreen drawing... That sounds like a lot of work :-) Ciao, Alberto From hein at kde.org Fri Nov 11 09:33:06 2016 From: hein at kde.org (Eike Hein) Date: Fri, 11 Nov 2016 17:33:06 +0900 Subject: [Development] QtQuickControls for desktop: what's the plan? In-Reply-To: <2b7adf22-5a50-85cc-3574-dac6aa85521b@users.sourceforge.net> References: <7ca68a12-8433-dd2e-3d1d-530ba2fe4202@users.sourceforge.net> <1575014.3k6hiOkjt0@phobos> <416F0995-CD37-4DED-A473-90B13101E288@qt.io> <2067556.CUMk66bXVn@frederik-thinkcentre-m93p> <2b7adf22-5a50-85cc-3574-dac6aa85521b@users.sourceforge.net> Message-ID: On 11/11/2016 05:02 PM, Alberto Mardegan wrote: > If QStyle is used by QWidgets, which have been used in apps since well > before QML existed, it's reasonable to expect that its performance is > more than acceptable for modern desktop machines. Not necessarily. This isn't about native QStyle painting, it's about QStyle going through Qt Quick's rendering stack, which involves additional indirection. > Maybe we might have to give up on the idea of a single implementation, > and instead have a different style for each toolkit? At least with Gtk, > it might be possible to use native Gtk widgets, as we are already using > the glib mainloop in Linux, and GtkWidgets allow for offscreen drawing... > That sounds like a lot of work :-) That's more or less what QGtkStyle does. > Ciao, > Alberto Cheers, Eike From lars.knoll at qt.io Fri Nov 11 09:46:00 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 11 Nov 2016 08:46:00 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <2537366.LM4OPadTkB@42> References: <20161110112912.GB9877@troll08> <2537366.LM4OPadTkB@42> Message-ID: <2CA69E2F-3517-44CF-A2DE-C0E61D1DC15D@qt.io> On 10/11/16 14:21, "Development on behalf of Jędrzej Nowacki" wrote: On torsdag 10. november 2016 12.29.12 CET Oswald Buddenhagen wrote: > the easiest would be going with the normal approval rights, but limit > the submit button to a "QUIP owners" group which would consist of lars > (and possibly a _few_ deputies). Considering expected traffic there it could be only Lars :-) Let's do it that way for now. We can always nominate additional QUIP owners later on if we think it's required. Cheers, Lars From edward.welbourne at qt.io Fri Nov 11 11:14:26 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 11 Nov 2016 10:14:26 +0000 Subject: [Development] Change file process & improvement proposal In-Reply-To: <20161110142306.GC9877@troll08> References: , <20161110142306.GC9877@troll08> Message-ID: On Thu, Nov 10, 2016 at 12:38:41PM +0000, Jani Heikkinen wrote: >> Lately it has been quite hard to get change files done for the releases. and Ossi replied: > oh, it's that time of the year again. :D Speaking of which, it's also hard to get API reviews done, even though they are now much easier (because they get represented properly as gerrit reviews that show the change properly). See recent mail: of 17 modules with API reviews, one has a +2 and one a +1 on the latest PS; one has +1 on the previous; two are new reviews (I may have lost an earlier review) with no comments; three have comments on earlier PSs; qtwebengine's team concocted a better review (that's rather out of date) and have reviewed it; qtserialbus's maintainers note the need for a full API review; but seven add-on modules have had no comments. (Three of these were new in 5.7; the rest have been add-ons since at least 5.6.) Gerrit's diffs between patch sets work for you here: if you've reviewed an earlier patch set, you can review the change since in the usual useful way. No rebasing has happened. Please review (changelogs and) changes to your module APIs, Eddy. From mitch.curtis at qt.io Fri Nov 11 16:13:51 2016 From: mitch.curtis at qt.io (Mitch Curtis) Date: Fri, 11 Nov 2016 15:13:51 +0000 Subject: [Development] Naming of path/directory-related environment variables in Qt Message-ID: I'd like to establish some kind of convention for naming path/directory-related environment variables in Qt, with the hope that it could be set in stone with e.g. one of these newfangled QUIPs. Pelagicore (via Gordan) kindly contributed a patch to Qt Virtual Keyboard, where they introduced a QT_VIRTUALKEYBOARD_LAYOUTS_FOLDER environment variable: https://codereview.qt-project.org/#/c/174616/ I then asked Gordan to change this to QT_VIRTUALKEYBOARD_LAYOUTS_DIR, as it seemed we had a few other environment variables using this naming scheme. JP then pushed a patch that adds QT_QUICK_CONTROLS_STYLE_PATH to Qt Quick Controls 2: https://codereview.qt-project.org/#/c/176512/ He found more examples of where we've used "PATH" than where we used "DIR", so it seems like a good time to continue with that trend so that we don't have any more inconsistencies. My hope is that enough approvers see this email (or QUIP) and its conclusion (whatever it may be) and -1 patches that go against the convention. So, can we all agree on using "PATH" when naming environment variables that refer to paths? From christian.kandeler at qt.io Fri Nov 11 16:42:29 2016 From: christian.kandeler at qt.io (Christian Kandeler) Date: Fri, 11 Nov 2016 16:42:29 +0100 Subject: [Development] Naming of path/directory-related environment variables in Qt In-Reply-To: References: Message-ID: <75ff0cfd-2408-468f-e42f-ac764d4eca7f@qt.io> On 11/11/2016 04:13 PM, Mitch Curtis wrote: > I'd like to establish some kind of convention for naming path/directory-related environment variables in Qt, with the hope that it could be set in stone with e.g. one of these newfangled QUIPs. > > Pelagicore (via Gordan) kindly contributed a patch to Qt Virtual Keyboard, where they introduced a QT_VIRTUALKEYBOARD_LAYOUTS_FOLDER environment variable: > > https://codereview.qt-project.org/#/c/174616/ > > I then asked Gordan to change this to QT_VIRTUALKEYBOARD_LAYOUTS_DIR, as it seemed we had a few other environment variables using this naming scheme. > > JP then pushed a patch that adds QT_QUICK_CONTROLS_STYLE_PATH to Qt Quick Controls 2: > > https://codereview.qt-project.org/#/c/176512/ > > He found more examples of where we've used "PATH" than where we used "DIR", so it seems like a good time to continue with that trend so that we don't have any more inconsistencies. > > My hope is that enough approvers see this email (or QUIP) and its conclusion (whatever it may be) and -1 patches that go against the convention. > > So, can we all agree on using "PATH" when naming environment variables that refer to paths? But note that "path" is more generic than "dir": A "file path" is not (necessarily) a directory. So the latter name conveys more information to me as a user. Christian From edward.welbourne at qt.io Fri Nov 11 16:51:16 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 11 Nov 2016 15:51:16 +0000 Subject: [Development] Naming of path/directory-related environment variables in Qt In-Reply-To: References: Message-ID: Mitch Curtis gave examples and proposed a convention: > I'd like to establish some kind of convention for naming > path/directory-related environment variables in Qt, with the hope that > it could be set in stone with e.g. one of these newfangled QUIPs. > > Pelagicore (via Gordan) kindly contributed a patch to Qt Virtual > Keyboard, where they introduced a QT_VIRTUALKEYBOARD_LAYOUTS_FOLDER > environment variable: > > https://codereview.qt-project.org/#/c/174616/ > > I then asked Gordan to change this to QT_VIRTUALKEYBOARD_LAYOUTS_DIR, > as it seemed we had a few other environment variables using this > naming scheme. > > JP then pushed a patch that adds QT_QUICK_CONTROLS_STYLE_PATH to Qt > Quick Controls 2: > > https://codereview.qt-project.org/#/c/176512/ > > He found more examples of where we've used "PATH" than where we used > "DIR", so it seems like a good time to continue with that trend so > that we don't have any more inconsistencies. > > My hope is that enough approvers see this email (or QUIP) and its > conclusion (whatever it may be) and -1 patches that go against the > convention. > > So, can we all agree on using "PATH" when naming environment variables > that refer to paths? PATH is also used to indicate a *list* of directory names. Given its other meaning (below), however, it might be better to identify such lists by environment variables ending in DIRS to make clear they're plural and that each entry is a directory. When used to identify just one thing on the file system, PATH is generic: it applies as much to single files as to directories, where DIR is quite specific about applying only to a directory (or folder, or whatever else these get called on diverse systems). There is some value to being able to distinguish "this variable names a directory" (not uncommonly: one in which we'll scan for paths of diverse other things) from "this is where that thing is found" (e.g. a config file or style sheet). Is it worth retaining such a distinction between PATH and DIR ? To what extent do the existing names conform to such a difference ? Eddy. From mitch.curtis at qt.io Fri Nov 11 16:52:05 2016 From: mitch.curtis at qt.io (Mitch Curtis) Date: Fri, 11 Nov 2016 15:52:05 +0000 Subject: [Development] Naming of path/directory-related environment variables in Qt In-Reply-To: <75ff0cfd-2408-468f-e42f-ac764d4eca7f@qt.io> References: <75ff0cfd-2408-468f-e42f-ac764d4eca7f@qt.io> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt- > project.org] On Behalf Of Christian Kandeler > Sent: Friday, 11 November 2016 4:42 PM > To: development at qt-project.org > Subject: Re: [Development] Naming of path/directory-related environment > variables in Qt > > On 11/11/2016 04:13 PM, Mitch Curtis wrote: > > I'd like to establish some kind of convention for naming path/directory- > related environment variables in Qt, with the hope that it could be set in > stone with e.g. one of these newfangled QUIPs. > > > > Pelagicore (via Gordan) kindly contributed a patch to Qt Virtual Keyboard, > where they introduced a QT_VIRTUALKEYBOARD_LAYOUTS_FOLDER > environment variable: > > > > https://codereview.qt-project.org/#/c/174616/ > > > > I then asked Gordan to change this to > QT_VIRTUALKEYBOARD_LAYOUTS_DIR, as it seemed we had a few other > environment variables using this naming scheme. > > > > JP then pushed a patch that adds QT_QUICK_CONTROLS_STYLE_PATH to > Qt Quick Controls 2: > > > > https://codereview.qt-project.org/#/c/176512/ > > > > He found more examples of where we've used "PATH" than where we > used "DIR", so it seems like a good time to continue with that trend so that > we don't have any more inconsistencies. > > > > My hope is that enough approvers see this email (or QUIP) and its > conclusion (whatever it may be) and -1 patches that go against the > convention. > > > > So, can we all agree on using "PATH" when naming environment variables > that refer to paths? > > But note that "path" is more generic than "dir": A "file path" is not > (necessarily) a directory. So the latter name conveys more information to me > as a user. I agree, and that's something I thought of too, but then I thought about PATH in Windows and it didn't seem so strange. > > Christian > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From mwoehlke.floss at gmail.com Fri Nov 11 17:10:11 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 11 Nov 2016 11:10:11 -0500 Subject: [Development] Naming of path/directory-related environment variables in Qt In-Reply-To: References: Message-ID: On 2016-11-11 10:13, Mitch Curtis wrote: > I'd like to establish some kind of convention for naming > path/directory-related environment variables in Qt, with the hope > that it could be set in stone with e.g. one of these newfangled > QUIPs. [...] So, can we all agree on using "PATH" when naming > environment variables that refer to paths? I believe that `FOO_DIR` is typical for variables that name a *single* directory. For multiple directories, XDG prefers `FOO_DIRS`, but otherwise `FOO_PATH` seems most common. Examples: PATH (duh) LD_LIBRARY_PATH PYTHONPATH LUA_PATH QT_PLUGIN_PATH LIBPATH COMPILER_PATH LIBRARY_PATH CPATH C_INCLUDE_PATH CPLUS_INCLUDE_PATH TMPDIR KDEDIRS XDG_DATA_DIRS XDG_RUNTIME_DIR I think a good rule would be single directories should use _DIR if anything (some cases e.g. HOME may be exceptions), and list of directories should use _PATH. Please don't use `FOO_FOLDER` :-). -- Matthew From kevin.kofler at chello.at Sat Nov 12 09:18:44 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 12 Nov 2016 09:18:44 +0100 Subject: [Development] QtQuickControls for desktop: what's the plan? References: <7ca68a12-8433-dd2e-3d1d-530ba2fe4202@users.sourceforge.net> <2067556.CUMk66bXVn@frederik-thinkcentre-m93p> <1941230.BoOzVkPR3A@maurice> <2002988.WUrOxaYX9B@phobos> Message-ID: Marco Martin wrote: > yeah, I also see it more like as a temporary solution as well, if not else > for the fact that it can work only on QApplication instances. > For us it's important to get in a short enough time span a good compelling > reasons for applications to start using qtquickcontrols2, but I agree on > the long run something else not linking to qwidgets is needed (which also > speaks against official inclusion in Qt, as would get deprecated soon-ish > in that case) What should also be pointed out is that your code depends on QQC1, which makes its long-term viability somewhat dubious. But please don't take that as (harsh) criticism! In fact, many thanks for working on this! I think it is absolutely essential that applications fit into the environment's look&feel. So it is great that you are taking care of this for QQC2. As a user, I don't even really care about what it uses behind the scenes, as long as it integrates. Kevin Kofler From jani.heikkinen at qt.io Mon Nov 14 09:44:08 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 14 Nov 2016 08:44:08 +0000 Subject: [Development] [Releasing] Qt 5.8.0 API review In-Reply-To: References: , , , , , Message-ID: Hi all, It seems this is still badly ongoing, only few '+1' and only one '+2' there :( Please try to finalize the review during this week: We need to have reviews done & possible changes in '5.8' before we can start branching from '5.8' to '5.8.0' br, Jani ________________________________________ From: Edward Welbourne Sent: Monday, November 7, 2016 4:57 PM To: releasing at qt-project.org Cc: Jani Heikkinen; Sune Vuorela; development at qt-project.org Subject: Re: [Releasing] Qt 5.8.0 API review With the 5.8.0 release now close at hand, I've updated the API reviews: https://codereview.qt-project.org/170634 - qtbase https://codereview.qt-project.org/170635 - qtdeclarative https://codereview.qt-project.org/170636 - qtactiveqt https://codereview.qt-project.org/170637 - qtmultimedia https://codereview.qt-project.org/170640 - qtconnectivity https://codereview.qt-project.org/170641 - qtwayland https://codereview.qt-project.org/170642 - qt3d https://codereview.qt-project.org/170643 - qtserialbus https://codereview.qt-project.org/170644 - qtserialport https://codereview.qt-project.org/170645 - qtandroidextras https://codereview.qt-project.org/170646 - qtwebsockets https://codereview.qt-project.org/170647 - qtwebengine https://codereview.qt-project.org/170648 - qtcanvas3d https://codereview.qt-project.org/170649 - qtcharts https://codereview.qt-project.org/170650 - qtdatavis3d https://codereview.qt-project.org/170652 - qtscxml https://codereview.qt-project.org/176059 - qtquickcontrols2 Note that, although Gerrit thinks of these as proposals to change 5.8, they are actually commits based on tag v5.7.0 showing what's changed in 5.8's API, with lots of boring bits filtered out. It would be nice if some of these did in fact get reviewed ... Eddy. From lars.knoll at qt.io Mon Nov 14 10:37:21 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 14 Nov 2016 09:37:21 +0000 Subject: [Development] [Releasing] Qt 5.8.0 API review Message-ID: <6018DA9C-2641-4B7B-A493-BDE69C21117D@qt.io> Hi, I went through all modules now, and added my comments. Mainly small issues, with the exception of Qt 3D, where I see some real BC breakages. Sean, could you please look at https://codereview.qt-project.org/#/c/170642/ asap. Thanks, Lars On 14/11/16 09:44, "Jani Heikkinen" wrote: Hi all, It seems this is still badly ongoing, only few '+1' and only one '+2' there :( Please try to finalize the review during this week: We need to have reviews done & possible changes in '5.8' before we can start branching from '5.8' to '5.8.0' br, Jani ________________________________________ From: Edward Welbourne Sent: Monday, November 7, 2016 4:57 PM To: releasing at qt-project.org Cc: Jani Heikkinen; Sune Vuorela; development at qt-project.org Subject: Re: [Releasing] Qt 5.8.0 API review With the 5.8.0 release now close at hand, I've updated the API reviews: https://codereview.qt-project.org/170634 - qtbase https://codereview.qt-project.org/170635 - qtdeclarative https://codereview.qt-project.org/170636 - qtactiveqt https://codereview.qt-project.org/170637 - qtmultimedia https://codereview.qt-project.org/170640 - qtconnectivity https://codereview.qt-project.org/170641 - qtwayland https://codereview.qt-project.org/170642 - qt3d https://codereview.qt-project.org/170643 - qtserialbus https://codereview.qt-project.org/170644 - qtserialport https://codereview.qt-project.org/170645 - qtandroidextras https://codereview.qt-project.org/170646 - qtwebsockets https://codereview.qt-project.org/170647 - qtwebengine https://codereview.qt-project.org/170648 - qtcanvas3d https://codereview.qt-project.org/170649 - qtcharts https://codereview.qt-project.org/170650 - qtdatavis3d https://codereview.qt-project.org/170652 - qtscxml https://codereview.qt-project.org/176059 - qtquickcontrols2 Note that, although Gerrit thinks of these as proposals to change 5.8, they are actually commits based on tag v5.7.0 showing what's changed in 5.8's API, with lots of boring bits filtered out. It would be nice if some of these did in fact get reviewed ... Eddy. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Mon Nov 14 11:09:43 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 14 Nov 2016 10:09:43 +0000 Subject: [Development] Heads up - 5.8 string freeze In-Reply-To: References: Message-ID: Hi all, As warned a week ago string freeze is now in effect. Please, no changes to translatable strings from this point, unless approved by the documentation team. Br, Jani ________________________________________ From: Jani Heikkinen Sent: Monday, November 7, 2016 3:06 PM To: localization at qt-project.org Subject: Heads up - 5.8 soft string freeze Hi all, Qt 5.8 beta is out & work towards final release continues. One step on the way is String Freeze which should happen really soon to be able to minimize time needed between beta and RC. So let's have the string freeze 14th Nov 2016. Br, Jani From sean.harmer at kdab.com Mon Nov 14 11:34:38 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 14 Nov 2016 10:34:38 +0000 Subject: [Development] [Releasing] Qt 5.8.0 API review In-Reply-To: <6018DA9C-2641-4B7B-A493-BDE69C21117D@qt.io> References: <6018DA9C-2641-4B7B-A493-BDE69C21117D@qt.io> Message-ID: <2575973.eXtFWvdmcO@cartman> On Monday 14 November 2016 09:37:21 Lars Knoll wrote: > Hi, > > I went through all modules now, and added my comments. Mainly small issues, > with the exception of Qt 3D, where I see some real BC breakages. > > Sean, could you please look at https://codereview.qt-project.org/#/c/170642/ > asap. I'm just back from vacation today. Paul is taking a look now. Cheers, Sean > > Thanks, > Lars > > On 14/11/16 09:44, "Jani Heikkinen" wrote: > > Hi all, > > It seems this is still badly ongoing, only few '+1' and only one '+2' > there :( > > Please try to finalize the review during this week: We need to have > reviews done & possible changes in '5.8' before we can start branching from > '5.8' to '5.8.0' > > br, > Jani > > ________________________________________ > From: Edward Welbourne > Sent: Monday, November 7, 2016 4:57 PM > To: releasing at qt-project.org > Cc: Jani Heikkinen; Sune Vuorela; development at qt-project.org > Subject: Re: [Releasing] Qt 5.8.0 API review > > With the 5.8.0 release now close at hand, I've updated the API reviews: > > https://codereview.qt-project.org/170634 - qtbase > https://codereview.qt-project.org/170635 - qtdeclarative > https://codereview.qt-project.org/170636 - qtactiveqt > https://codereview.qt-project.org/170637 - qtmultimedia > https://codereview.qt-project.org/170640 - qtconnectivity > https://codereview.qt-project.org/170641 - qtwayland > https://codereview.qt-project.org/170642 - qt3d > https://codereview.qt-project.org/170643 - qtserialbus > https://codereview.qt-project.org/170644 - qtserialport > https://codereview.qt-project.org/170645 - qtandroidextras > https://codereview.qt-project.org/170646 - qtwebsockets > https://codereview.qt-project.org/170647 - qtwebengine > https://codereview.qt-project.org/170648 - qtcanvas3d > https://codereview.qt-project.org/170649 - qtcharts > https://codereview.qt-project.org/170650 - qtdatavis3d > https://codereview.qt-project.org/170652 - qtscxml > https://codereview.qt-project.org/176059 - qtquickcontrols2 > > Note that, although Gerrit thinks of these as proposals to change 5.8, > they are actually commits based on tag v5.7.0 showing what's changed in > 5.8's API, with lots of boring bits filtered out. > > It would be nice if some of these did in fact get reviewed ... > > Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From sean.harmer at kdab.com Mon Nov 14 11:42:09 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 14 Nov 2016 10:42:09 +0000 Subject: [Development] [Releasing] Qt 5.8.0 API review In-Reply-To: <2575973.eXtFWvdmcO@cartman> References: <6018DA9C-2641-4B7B-A493-BDE69C21117D@qt.io> <2575973.eXtFWvdmcO@cartman> Message-ID: <5104005.omF1Iu4K4i@cartman> On Monday 14 November 2016 10:34:38 Sean Harmer wrote: > On Monday 14 November 2016 09:37:21 Lars Knoll wrote: > > Hi, > > > > I went through all modules now, and added my comments. Mainly small > > issues, > > with the exception of Qt 3D, where I see some real BC breakages. > > > > Sean, could you please look at > > https://codereview.qt-project.org/#/c/170642/ asap. > > I'm just back from vacation today. Paul is taking a look now. Fixes in https://codereview.qt-project.org/#/c/176569/ https://codereview.qt-project.org/#/c/176570/ are integrating... Cheers, Sean From lars.knoll at qt.io Mon Nov 14 11:44:30 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 14 Nov 2016 10:44:30 +0000 Subject: [Development] [Releasing] Qt 5.8.0 API review In-Reply-To: <5104005.omF1Iu4K4i@cartman> References: <6018DA9C-2641-4B7B-A493-BDE69C21117D@qt.io> <2575973.eXtFWvdmcO@cartman> <5104005.omF1Iu4K4i@cartman> Message-ID: Thanks, Looks good once these two changes are integrated. Cheers, Lars On 14/11/16 11:42, "Development on behalf of Sean Harmer" wrote: On Monday 14 November 2016 10:34:38 Sean Harmer wrote: > On Monday 14 November 2016 09:37:21 Lars Knoll wrote: > > Hi, > > > > I went through all modules now, and added my comments. Mainly small > > issues, > > with the exception of Qt 3D, where I see some real BC breakages. > > > > Sean, could you please look at > > https://codereview.qt-project.org/#/c/170642/ asap. > > I'm just back from vacation today. Paul is taking a look now. Fixes in https://codereview.qt-project.org/#/c/176569/ https://codereview.qt-project.org/#/c/176570/ are integrating... Cheers, Sean _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From paul.lemire at kdab.com Mon Nov 14 15:15:16 2016 From: paul.lemire at kdab.com (Paul Lemire) Date: Mon, 14 Nov 2016 15:15:16 +0100 Subject: [Development] =?utf-8?b?Tm9taW5hdGluZyBBbnR0aSBNw6TDpHR0w6QgYXMg?= =?utf-8?q?Qt3D_approver?= Message-ID: <3379777.7RlVj0Nj30@454> Hi I would like to propose the nomination of Antti Määttä for approver status. Antti has been contributing many patches to Qt3D adding new features and providing bug fixes. In addition, having another approver would be a great help to reduce the amount of time patches are spent awaiting a review. Thanks, Paul -- Paul Lemire | paul.lemire at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel: France +33 (0)4 90 84 08 53, http://www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts From sean.harmer at kdab.com Mon Nov 14 16:19:13 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 14 Nov 2016 15:19:13 +0000 Subject: [Development] =?utf-8?b?Tm9taW5hdGluZyBBbnR0aSBNw6TDpHR0w6QgYXMg?= =?utf-8?q?Qt3D_approver?= In-Reply-To: <3379777.7RlVj0Nj30@454> References: <3379777.7RlVj0Nj30@454> Message-ID: <4625893.daMKahMxrn@cartman> On Monday 14 November 2016 15:15:16 Paul Lemire wrote: > Hi > > I would like to propose the nomination of Antti Määttä for approver status. > Antti has been contributing many patches to Qt3D adding new features and > providing bug fixes. In addition, having another approver would be a great > help to reduce the amount of time patches are spent awaiting a review. +1 from me. Cheers, Sean From pasi.keranen at qt.io Tue Nov 15 06:16:06 2016 From: pasi.keranen at qt.io (=?utf-8?B?UGFzaSBLZXLDpG5lbg==?=) Date: Tue, 15 Nov 2016 05:16:06 +0000 Subject: [Development] =?utf-8?b?Tm9taW5hdGluZyBBbnR0aSBNw6TDpHR0w6QgYXMg?= =?utf-8?q?Qt3D_approver?= In-Reply-To: <4625893.daMKahMxrn@cartman> References: <3379777.7RlVj0Nj30@454> <4625893.daMKahMxrn@cartman> Message-ID: +1 from me as well. Regards, Pasi On 14/11/16 17:19, "Development on behalf of Sean Harmer" wrote: On Monday 14 November 2016 15:15:16 Paul Lemire wrote: > Hi > > I would like to propose the nomination of Antti Määttä for approver status. > Antti has been contributing many patches to Qt3D adding new features and > providing bug fixes. In addition, having another approver would be a great > help to reduce the amount of time patches are spent awaiting a review. +1 from me. Cheers, Sean _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From coroberti at gmail.com Tue Nov 15 08:10:48 2016 From: coroberti at gmail.com (Robert Iakobashvili) Date: Tue, 15 Nov 2016 09:10:48 +0200 Subject: [Development] Dictation Issues with Qt-built software In-Reply-To: References: <90A518D8-DF8D-4664-92E1-700DCFCAD8DA@qt.io> Message-ID: On Thu, Nov 10, 2016 at 10:47 AM, Morten Sorvig wrote: > >> On 4 Nov 2016, at 13:00, Robert Iakobashvili wrote: >> >> Right. Most users of dictation are people with learning or motoric disabilities. >> >> When these users are used to a certain pattern of platform-specific habits >> working for them, any other options to do the same could be seen as usability issues >> breaking these habits. > > > Hi, after some further investigation and offline discussion (thanks Frederik!), > I think we’re closer to solving this: > > Dictation input can be handled via our current input method support, where we > implement the NSTextInputClient protocol. As a matter fact this almost works > today (Qt 5.6): select text in a Qt text editor; starting dictation via the > fn key should now work. > > So what we are looking at then is developing a bug fix to our NSTextInputClient > protocol implementation to make dictation work in all cases. > > Morten > Dear Morten, Please, let me know when you have patches for 5.6.2. I can apply them, rebuild and verify the fix for the common case. Thanks! Kind regards, Robert From Morten.Sorvig at qt.io Tue Nov 15 08:36:24 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Tue, 15 Nov 2016 07:36:24 +0000 Subject: [Development] Dictation Issues with Qt-built software In-Reply-To: References: <90A518D8-DF8D-4664-92E1-700DCFCAD8DA@qt.io> Message-ID: > On 15 Nov 2016, at 08:10, Robert Iakobashvili wrote: > > On Thu, Nov 10, 2016 at 10:47 AM, Morten Sorvig wrote: >> >>> On 4 Nov 2016, at 13:00, Robert Iakobashvili wrote: >>> >>> Right. Most users of dictation are people with learning or motoric disabilities. >>> >>> When these users are used to a certain pattern of platform-specific habits >>> working for them, any other options to do the same could be seen as usability issues >>> breaking these habits. >> >> >> Hi, after some further investigation and offline discussion (thanks Frederik!), >> I think we’re closer to solving this: >> >> Dictation input can be handled via our current input method support, where we >> implement the NSTextInputClient protocol. As a matter fact this almost works >> today (Qt 5.6): select text in a Qt text editor; starting dictation via the >> fn key should now work. >> >> So what we are looking at then is developing a bug fix to our NSTextInputClient >> protocol implementation to make dictation work in all cases. >> >> Morten >> > Dear Morten, > Please, let me know when you have patches for 5.6.2. > I can apply them, rebuild and verify the fix for the common case. > Patch is here: https://codereview.qt-project.org/#/c/176441 It is already merged, but please let me know how it works for your use case. Morten > Thanks! > > Kind regards, > Robert From coroberti at gmail.com Tue Nov 15 12:02:50 2016 From: coroberti at gmail.com (Robert Iakobashvili) Date: Tue, 15 Nov 2016 13:02:50 +0200 Subject: [Development] Dictation Issues with Qt-built software In-Reply-To: References: <90A518D8-DF8D-4664-92E1-700DCFCAD8DA@qt.io> Message-ID: >>>> >>>> Right. Most users of dictation are people with learning or motoric disabilities. >>>> >>>> When these users are used to a certain pattern of platform-specific habits >>>> working for them, any other options to do the same could be seen as usability issues >>>> breaking these habits. >>> >>> >>> Hi, after some further investigation and offline discussion (thanks Frederik!), >>> I think we’re closer to solving this: >>> >>> Dictation input can be handled via our current input method support, where we >>> implement the NSTextInputClient protocol. As a matter fact this almost works >>> today (Qt 5.6): select text in a Qt text editor; starting dictation via the >>> fn key should now work. >>> >>> So what we are looking at then is developing a bug fix to our NSTextInputClient >>> protocol implementation to make dictation work in all cases. >>> >>> Morten >>> >> Dear Morten, >> Please, let me know when you have patches for 5.6.2. >> I can apply them, rebuild and verify the fix for the common case. >> > > Patch is here: https://codereview.qt-project.org/#/c/176441 > > It is already merged, but please let me know how it works for your use case. > > Morten > Yes, it works! Thank you so much! Kind regards, Robert From jani.heikkinen at qt.io Wed Nov 16 06:07:51 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 16 Nov 2016 05:07:51 +0000 Subject: [Development] Qt 5.7.1 packages available Message-ID: Hi all, We have finally Qt 5.7.1 packages: Linux: http://download.qt.io/snapshots/qt/5.7/5.7.1/570/ Windows: http://download.qt.io/snapshots/qt/5.7/5.7.1/650/ Mac: http://download.qt.io/snapshots/qt/5.7/5.7.1/598/ Src:http://download.qt.io/snapshots/qt/5.7/5.7.1/latest_src/ According to RTA smoke testing packages seems to be OK so please test the packages as soon as possible. All known blockers should be fixed, please verify fixes for open ones ( https://bugreports.qt.io/issues/?filter=17833 ). We will release these packages as Qt 5.7.1 later (maybe already this Thu) if nothing really serious found during testing. Please update the known issues page when needed: https://wiki.qt.io/Qt_5.7.1_Known_Issues Known issues in the packages: https://bugreports.qt.io/issues/?filter=18129 br, Jani From dmitry.volosnykh at gmail.com Wed Nov 16 07:29:25 2016 From: dmitry.volosnykh at gmail.com (Dmitry Volosnykh) Date: Wed, 16 Nov 2016 06:29:25 +0000 Subject: [Development] Qt 5.7.1 packages available In-Reply-To: References: Message-ID: Should QTBUG-37095 be removed from Known Issues since it is closed as Done? On Wed, Nov 16, 2016 at 8:08 AM Jani Heikkinen wrote: > Hi all, > > We have finally Qt 5.7.1 packages: > > Linux: http://download.qt.io/snapshots/qt/5.7/5.7.1/570/ > Windows: http://download.qt.io/snapshots/qt/5.7/5.7.1/650/ > Mac: http://download.qt.io/snapshots/qt/5.7/5.7.1/598/ > Src:http://download.qt.io/snapshots/qt/5.7/5.7.1/latest_src/ > > According to RTA smoke testing packages seems to be OK so please test the > packages as soon as possible. All known blockers should be fixed, please > verify fixes for open ones ( https://bugreports.qt.io/issues/?filter=17833 > ). We will release these packages as Qt 5.7.1 later (maybe already this > Thu) if nothing really serious found during testing. > > Please update the known issues page when needed: > https://wiki.qt.io/Qt_5.7.1_Known_Issues > > Known issues in the packages: > https://bugreports.qt.io/issues/?filter=18129 > > br, > Jani > > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Erik.Verbruggen at qt.io Wed Nov 16 09:58:48 2016 From: Erik.Verbruggen at qt.io (Erik Verbruggen) Date: Wed, 16 Nov 2016 08:58:48 +0000 Subject: [Development] Qt 5.7.1 packages available In-Reply-To: References: , Message-ID: For my "use case" (the qml profiler in creator) it's done. But I don't know if more patches have to go in. Maybe Morton can enlighten us? -- Erik ________________________________ From: Development on behalf of Dmitry Volosnykh Sent: 16 November 2016 07:29:25 To: Jani Heikkinen; development at qt-project.org Subject: Re: [Development] Qt 5.7.1 packages available Should QTBUG-37095 be removed from Known Issues since it is closed as Done? On Wed, Nov 16, 2016 at 8:08 AM Jani Heikkinen > wrote: Hi all, We have finally Qt 5.7.1 packages: Linux: http://download.qt.io/snapshots/qt/5.7/5.7.1/570/ Windows: http://download.qt.io/snapshots/qt/5.7/5.7.1/650/ Mac: http://download.qt.io/snapshots/qt/5.7/5.7.1/598/ Src:http://download.qt.io/snapshots/qt/5.7/5.7.1/latest_src/ According to RTA smoke testing packages seems to be OK so please test the packages as soon as possible. All known blockers should be fixed, please verify fixes for open ones ( https://bugreports.qt.io/issues/?filter=17833 ). We will release these packages as Qt 5.7.1 later (maybe already this Thu) if nothing really serious found during testing. Please update the known issues page when needed: https://wiki.qt.io/Qt_5.7.1_Known_Issues Known issues in the packages: https://bugreports.qt.io/issues/?filter=18129 br, Jani _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From helio at kde.org Wed Nov 16 11:36:37 2016 From: helio at kde.org (Helio Chissini de Castro) Date: Wed, 16 Nov 2016 11:36:37 +0100 Subject: [Development] Qt 5.7.1 packages available In-Reply-To: References: Message-ID: Hi Png configure detection is adding 3rd party directory to compile even if told -system-png. Attached a patch to fix it. Should i submit to 5.7 branch on gerrit ? On Wed, Nov 16, 2016 at 9:58 AM, Erik Verbruggen wrote: > For my "use case" (the qml profiler in creator) it's done. But I don't > know if more patches have to go in. Maybe Morton can enlighten us? > > -- Erik > ------------------------------ > *From:* Development org> on behalf of Dmitry Volosnykh > *Sent:* 16 November 2016 07:29:25 > *To:* Jani Heikkinen; development at qt-project.org > *Subject:* Re: [Development] Qt 5.7.1 packages available > > Should QTBUG-37095 be removed from Known Issues since it is closed as Done? > > On Wed, Nov 16, 2016 at 8:08 AM Jani Heikkinen > wrote: > >> Hi all, >> >> We have finally Qt 5.7.1 packages: >> >> Linux: http://download.qt.io/snapshots/qt/5.7/5.7.1/570/ >> Windows: http://download.qt.io/snapshots/qt/5.7/5.7.1/650/ >> Mac: http://download.qt.io/snapshots/qt/5.7/5.7.1/598/ >> Src:http://download.qt.io/snapshots/qt/5.7/5.7.1/latest_src/ >> >> According to RTA smoke testing packages seems to be OK so please test the >> packages as soon as possible. All known blockers should be fixed, please >> verify fixes for open ones ( https://bugreports.qt.io/ >> issues/?filter=17833 ). We will release these packages as Qt 5.7.1 later >> (maybe already this Thu) if nothing really serious found during testing. >> >> Please update the known issues page when needed: >> https://wiki.qt.io/Qt_5.7.1_Known_Issues >> >> Known issues in the packages: https://bugreports.qt.io/ >> issues/?filter=18129 >> >> br, >> Jani >> >> >> >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt5-qtbase-5.7.1-libpng.patch Type: text/x-patch Size: 1250 bytes Desc: not available URL: From jpnurmi at qt.io Wed Nov 16 13:06:43 2016 From: jpnurmi at qt.io (J-P Nurmi) Date: Wed, 16 Nov 2016 12:06:43 +0000 Subject: [Development] Naming of path/directory-related environment variables in Qt In-Reply-To: References: Message-ID: <8D5A222F-7AA9-456C-9FE6-71EF9297F336@qt.io> > On 11 Nov 2016, at 17:10, Matthew Woehlke wrote: > > On 2016-11-11 10:13, Mitch Curtis wrote: >> I'd like to establish some kind of convention for naming >> path/directory-related environment variables in Qt, with the hope >> that it could be set in stone with e.g. one of these newfangled >> QUIPs. [...] So, can we all agree on using "PATH" when naming >> environment variables that refer to paths? > > I believe that `FOO_DIR` is typical for variables that name a *single* > directory. For multiple directories, XDG prefers `FOO_DIRS`, but > otherwise `FOO_PATH` seems most common. > > Examples: > PATH (duh) > LD_LIBRARY_PATH > PYTHONPATH > LUA_PATH > QT_PLUGIN_PATH > LIBPATH > COMPILER_PATH > LIBRARY_PATH > CPATH > C_INCLUDE_PATH > CPLUS_INCLUDE_PATH > > TMPDIR > KDEDIRS > XDG_DATA_DIRS > XDG_RUNTIME_DIR > > I think a good rule would be single directories should use _DIR if > anything (some cases e.g. HOME may be exceptions), and list of > directories should use _PATH. > > Please don't use `FOO_FOLDER` :-). +1 for _DIR for single directories, and _PATH for list of directories. -- J-P Nurmi From darkbasic at linuxsystems.it Wed Nov 16 17:22:41 2016 From: darkbasic at linuxsystems.it (=?iso-8859-1?Q?Niccol=F2_Belli?=) Date: Wed, 16 Nov 2016 17:22:41 +0100 Subject: [Development] [HiDPI] Rethinking the scaling algorithm In-Reply-To: References: Message-ID: Hi Morten, I'm sorry, I missed your reply. > RoundPreferFloor Round up for .75 and higher > RoundPreferFloor is the new default. Do you think this is > sufficient? qFloor would help for my monitor, of course. Unfortunately the default (RoundPreferFloor) wouldn't be enough, because my monitor is 282.42 PPI and 282.42/96=2.94 Also RoundPreferFloor would break the 4K 27" monitor previously mentioned, because 161.18/96=1.6998 I thought about a better default: round up for ratios lesser than 2 but always round down for ratios higher than 2. Such a way the new formula will work for both categories of monitors: it will basically keep the current algorithm but it will be a bit more conservative when handling extreme scalings (>=3x). The 4K 27" will get 2x scaling, the 13" 3200x1800 will get 2x scaling and both a 13" and a 15" 4K monitors will get 3x scaling. It seems perfect to me, especially if you plan to change the base DPI on a per-OS basis. Niccolò Belli On giovedì 10 novembre 2016 10:43:06 CET, Morten Sorvig wrote: >> On 8 Nov 2016, at 15:57, Niccolò Belli wrote: >> >> Hi, >> My laptop's monitor is a 13" with a 16:9 aspect ratio and a >> 3200x1800 resolution. As you can see[1] the EDID[2] is >> perfectly correct. >> QT computes the scaling factor using a formula like this: >> scaling_factor=qRound(yourDpi/96) >> This is far from ideal in my opinion, because if we want to >> scale to 96 logical PPI it means that on a 13" 16:9 screen we >> want to target a 1088x612 logical resolution. In fact >> qRound(282.42/96) computes a 3x scaling factor for my laptop, >> which is not a scaling factor that *anybody* would like to have >> (except maybe my old grandfather with poor eyesight). In fact a >> logical resolution of *less* than 1088x612 (it's lesser because >> qRound actually rounded up the value) is too tiny even for a >> 13" scree ... > > > Hi, thanks for bringing this up. I agree with this point; > mathematically correct rounding > may not be the best kind of correct in this case. > > In fact a change is already in review: > > https://codereview.qt-project.org/#/c/157174/ > > This introduces QT_SCALE_FACTOR_ROUNDING_POLICY with the following options: > > Round qRound(), as today > Ceil qCeil() > Floor qFloor() > RoundPreferFloor Round up for .75 and higher > PassThrough Do not round and allow fractional scale factors > > RoundPreferFloor is the new default. Do you think this is > sufficient? Adding more options is > possible, as is adding a C++ API if needed. > > Morten > From cfeck at kde.org Wed Nov 16 17:52:59 2016 From: cfeck at kde.org (Christoph Feck) Date: Wed, 16 Nov 2016 17:52:59 +0100 Subject: [Development] [HiDPI] Rethinking the scaling algorithm In-Reply-To: References: Message-ID: On 16.11.2016 17:22, Niccolò Belli wrote: > Hi Morten, > I'm sorry, I missed your reply. > >> RoundPreferFloor Round up for .75 and higher >> RoundPreferFloor is the new default. Do you think this is sufficient? > > qFloor would help for my monitor, of course. > > Unfortunately the default (RoundPreferFloor) wouldn't be enough, because > my monitor is 282.42 PPI and 282.42/96=2.94 > Also RoundPreferFloor would break the 4K 27" monitor previously > mentioned, because 161.18/96=1.6998 > > I thought about a better default: round up for ratios lesser than 2 but > always round down for ratios higher than 2. > > Such a way the new formula will work for both categories of monitors: it > will basically keep the current algorithm but it will be a bit more > conservative when handling extreme scalings (>=3x). > The 4K 27" will get 2x scaling, the 13" 3200x1800 will get 2x scaling > and both a 13" and a 15" 4K monitors will get 3x scaling. It seems > perfect to me, especially if you plan to change the base DPI on a per-OS > basis. There is no perfect solution except to make sure the user can configure the pixmap scale (as he can configure the font size). I have Firefox set to 1.5 scaling on a 163 DPI display. Neither 1, nor 2 looks good. From darkbasic at linuxsystems.it Wed Nov 16 17:59:10 2016 From: darkbasic at linuxsystems.it (=?iso-8859-1?Q?Niccol=F2_Belli?=) Date: Wed, 16 Nov 2016 17:59:10 +0100 Subject: [Development] [HiDPI] Rethinking the scaling algorithm In-Reply-To: References: Message-ID: <7fc5f017-e781-4445-b0fb-7361e51fca3d@linuxsystems.it> On mercoledì 16 novembre 2016 17:52:59 CET, Christoph Feck wrote: > There is no perfect solution except to make sure the user can > configure the pixmap scale (as he can configure the font size). Of course, but there are solutions which solve a problem for 90% of the userbase and solution which only solve it for 60% ;) Not being able to aim for perfection doesn't mean you should stop improving. From thiago.macieira at intel.com Wed Nov 16 17:59:53 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 16 Nov 2016 08:59:53 -0800 Subject: [Development] Qt 5.7.1 packages available In-Reply-To: References: Message-ID: <4746253.gamls0fcbj@tjmaciei-mobl1> On quarta-feira, 16 de novembro de 2016 11:36:37 PST Helio Chissini de Castro wrote: > Hi > > Png configure detection is adding 3rd party directory to compile even if > told -system-png. > > Attached a patch to fix it. > Should i submit to 5.7 branch on gerrit ? Yes, unless it also applies to 5.6, in which case send to 5.6. Note that you can merge the two condition lines in one in both hunks and avoid reindentation of the conditional code. By extension of what you've found, is qtzlib being compiled even if -system- zlib is on? I don't think that's the case because QT_CONFIG contains either "zlib" or "system-zlib", but not both, whereas it may contain both "png" and "system-png", ditto for "jpeg" and "system-jpeg". The wonders of hand-rolled scripts... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Marco.Bubke at qt.io Wed Nov 16 18:11:02 2016 From: Marco.Bubke at qt.io (Marco Bubke) Date: Wed, 16 Nov 2016 17:11:02 +0000 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? Message-ID: Hi This is a Qt Creator topic only so sorry to disturb every body else. Like you maybe have learned there are C++ Core Guidelines. They are already very comprehensive. What about basing the Qt Creator Code Style on it? I see advantages like new developer can easier grasp out rules because they are already familiar with it. We may have to exclude some rules too because they don't fit to us. We can enable Qt Creator partially with the ownership flag so the static analyser can do a much better job. In the long run we had to add that to Qt too but that is a different story. We would then a testbed for better support of static analyses for Qt too. Something which are our users would maybe value quite high. https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md [https://avatars1.githubusercontent.com/u/13841574?v=3&s=400] CppCoreGuidelines/CppCoreGuidelines.md at master · isocpp ... github.com CppCoreGuidelines - The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++ -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Nov 16 19:39:43 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 16 Nov 2016 10:39:43 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: Message-ID: <4448293.XkAZ11bryX@tjmaciei-mobl1> On quarta-feira, 16 de novembro de 2016 17:11:02 PST Marco Bubke wrote: > Like you maybe have learned there are C++ Core Guidelines. They are already > very comprehensive. What about basing the Qt Creator Code Style on it? > > > I see advantages like new developer can easier grasp out rules because they > are already familiar with it. > > We may have to exclude some rules too because they don't fit to us. "very comprehensive" is an understatement. Can you point out examples of rules you're more interested in? Maybe we should start with a whitelist of rules we do want and progressively expand from there. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Jake.Petroules at qt.io Wed Nov 16 20:06:46 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 16 Nov 2016 19:06:46 +0000 Subject: [Development] Naming of path/directory-related environment variables in Qt In-Reply-To: <8D5A222F-7AA9-456C-9FE6-71EF9297F336@qt.io> References: <8D5A222F-7AA9-456C-9FE6-71EF9297F336@qt.io> Message-ID: <4AB74859-A16F-4438-80BE-D13BBDB045BE@qt.io> > On Nov 16, 2016, at 4:06 AM, J-P Nurmi wrote: > >> On 11 Nov 2016, at 17:10, Matthew Woehlke wrote: >> >> On 2016-11-11 10:13, Mitch Curtis wrote: >>> I'd like to establish some kind of convention for naming >>> path/directory-related environment variables in Qt, with the hope >>> that it could be set in stone with e.g. one of these newfangled >>> QUIPs. [...] So, can we all agree on using "PATH" when naming >>> environment variables that refer to paths? >> >> I believe that `FOO_DIR` is typical for variables that name a *single* >> directory. For multiple directories, XDG prefers `FOO_DIRS`, but >> otherwise `FOO_PATH` seems most common. >> >> Examples: >> PATH (duh) >> LD_LIBRARY_PATH >> PYTHONPATH >> LUA_PATH >> QT_PLUGIN_PATH >> LIBPATH >> COMPILER_PATH >> LIBRARY_PATH >> CPATH >> C_INCLUDE_PATH >> CPLUS_INCLUDE_PATH >> >> TMPDIR >> KDEDIRS >> XDG_DATA_DIRS >> XDG_RUNTIME_DIR >> >> I think a good rule would be single directories should use _DIR if >> anything (some cases e.g. HOME may be exceptions), and list of >> directories should use _PATH. >> >> Please don't use `FOO_FOLDER` :-). > > +1 for _DIR for single directories, and _PATH for list of directories. Also +1 > > -- > J-P Nurmi > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From edward.welbourne at qt.io Thu Nov 17 10:46:24 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 17 Nov 2016 09:46:24 +0000 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <4448293.XkAZ11bryX@tjmaciei-mobl1> References: , <4448293.XkAZ11bryX@tjmaciei-mobl1> Message-ID: On quarta-feira, 16 de novembro de 2016 17:11:02 PST Marco Bubke wrote: >> Like you maybe have learned there are C++ Core Guidelines. They are >> already very comprehensive. What about basing the Qt Creator Code >> Style on it? >> >> I see advantages like new developer can easier grasp out rules >> because they are already familiar with it. >> >> We may have to exclude some rules too because they don't fit to us. Thiago Macieira replied: > "very comprehensive" is an understatement. Can you point out examples > of rules you're more interested in? Maybe we should start with a > whitelist of rules we do want and progressively expand from there. The guidelines' introduction does, after all, countenance gradual adoption - especially for existing code-bases - and a general opt-in approach. Presumably QtC's style is also used for new projects; it may be worth using a larger subset of the guidelines for new projects as compared to old; and it probably makes sense to make it easy for users to configure which of the guidelines they opt in to, for each project. Eddy. From edward.welbourne at qt.io Thu Nov 17 10:49:02 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 17 Nov 2016 09:49:02 +0000 Subject: [Development] Naming of path/directory-related environment variables in Qt In-Reply-To: <4AB74859-A16F-4438-80BE-D13BBDB045BE@qt.io> References: <8D5A222F-7AA9-456C-9FE6-71EF9297F336@qt.io>, <4AB74859-A16F-4438-80BE-D13BBDB045BE@qt.io> Message-ID: ________________________________________ From: Development on behalf of Jake Petroules Sent: 16 November 2016 20:06 To: J-P Nurmi Cc: development Subject: Re: [Development] Naming of path/directory-related environment variables in Qt >> On 11 Nov 2016, at 17:10, Matthew Woehlke wrote: >> Please don't use `FOO_FOLDER` :-). +1 > On Nov 16, 2016, at 4:06 AM, J-P Nurmi wrote: > +1 for _DIR for single directories, and _PATH for list of directories. Jake Petroules > Also +1 +1 Eddy. From marc.mutz at kdab.com Thu Nov 17 11:35:54 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 17 Nov 2016 11:35:54 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: <4448293.XkAZ11bryX@tjmaciei-mobl1> Message-ID: <201611171135.54832.marc.mutz@kdab.com> On Thursday 17 November 2016 10:46:24 Edward Welbourne wrote: > On quarta-feira, 16 de novembro de 2016 17:11:02 PST Marco Bubke wrote: > >> Like you maybe have learned there are C++ Core Guidelines. They are > >> already very comprehensive. What about basing the Qt Creator Code > >> Style on it? > >> > >> I see advantages like new developer can easier grasp out rules > >> because they are already familiar with it. > >> > >> We may have to exclude some rules too because they don't fit to us. > > Thiago Macieira replied: > > "very comprehensive" is an understatement. Can you point out examples > > of rules you're more interested in? Maybe we should start with a > > whitelist of rules we do want and progressively expand from there. > > The guidelines' introduction does, after all, countenance gradual > adoption - especially for existing code-bases - and a general opt-in > approach. Presumably QtC's style is also used for new projects; it may > be worth using a larger subset of the guidelines for new projects as > compared to old; and it probably makes sense to make it easy for users > to configure which of the guidelines they opt in to, for each project. If we do nothing else, we should at least use owner whereever possible. We can add it to QtGlobal, since we require now enough C++11 to support it: namespace gsl { template using owner = T; } There, done. It doesn't even interfere with client code including a more comprehensive GSL library, because they will define it the same way, and it's just a type alias. One problem is that in Qt, who is the owner is often not clear. But that should not prevent us from using it everywhere else. Than again, no compiler actually checks for this atm, not even MSVC, afaik, so if we get it wrong, there's no-one but reviewers to call the mistake... The bigger problem is that while owner does not affect the ABI, all other GSL types do, and we're back to our §$%&!§ rule that we can't accept other libs' types in our ABI, preventing anything other than owner from being added to Qt. My personal opinion is that we're way, WAY, past the tipping point where this policy started to hurt Qt more than the convenience of interchanging libc++ and libstdc++ on OS X gives to the 5 people in the world that use this feature. And I'm not at all happy that QtCS chickened out on a decision this year. I don't think we can afford to wait for next year's QtCS to maybe-maybe- not get rid of that nonsensical rule. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From Marco.Bubke at qt.io Thu Nov 17 11:41:25 2016 From: Marco.Bubke at qt.io (Marco Bubke) Date: Thu, 17 Nov 2016 10:41:25 +0000 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <201611171135.54832.marc.mutz@kdab.com> References: <4448293.XkAZ11bryX@tjmaciei-mobl1> , <201611171135.54832.marc.mutz@kdab.com> Message-ID: I want to remind you this is about Qt Creator, not Qt. Please use a different thread for it. [?] ________________________________ From: Development on behalf of Marc Mutz Sent: Thursday, November 17, 2016 11:35:54 AM To: development at qt-project.org Subject: Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? On Thursday 17 November 2016 10:46:24 Edward Welbourne wrote: > On quarta-feira, 16 de novembro de 2016 17:11:02 PST Marco Bubke wrote: > >> Like you maybe have learned there are C++ Core Guidelines. They are > >> already very comprehensive. What about basing the Qt Creator Code > >> Style on it? > >> > >> I see advantages like new developer can easier grasp out rules > >> because they are already familiar with it. > >> > >> We may have to exclude some rules too because they don't fit to us. > > Thiago Macieira replied: > > "very comprehensive" is an understatement. Can you point out examples > > of rules you're more interested in? Maybe we should start with a > > whitelist of rules we do want and progressively expand from there. > > The guidelines' introduction does, after all, countenance gradual > adoption - especially for existing code-bases - and a general opt-in > approach. Presumably QtC's style is also used for new projects; it may > be worth using a larger subset of the guidelines for new projects as > compared to old; and it probably makes sense to make it easy for users > to configure which of the guidelines they opt in to, for each project. If we do nothing else, we should at least use owner whereever possible. We can add it to QtGlobal, since we require now enough C++11 to support it: namespace gsl { template using owner = T; } There, done. It doesn't even interfere with client code including a more comprehensive GSL library, because they will define it the same way, and it's just a type alias. One problem is that in Qt, who is the owner is often not clear. But that should not prevent us from using it everywhere else. Than again, no compiler actually checks for this atm, not even MSVC, afaik, so if we get it wrong, there's no-one but reviewers to call the mistake... The bigger problem is that while owner does not affect the ABI, all other GSL types do, and we're back to our ?$%&!? rule that we can't accept other libs' types in our ABI, preventing anything other than owner from being added to Qt. My personal opinion is that we're way, WAY, past the tipping point where this policy started to hurt Qt more than the convenience of interchanging libc++ and libstdc++ on OS X gives to the 5 people in the world that use this feature. And I'm not at all happy that QtCS chickened out on a decision this year. I don't think we can afford to wait for next year's QtCS to maybe-maybe- not get rid of that nonsensical rule. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitya57.ml at gmail.com Thu Nov 17 20:04:14 2016 From: mitya57.ml at gmail.com (Dmitry Shachnev) Date: Thu, 17 Nov 2016 22:04:14 +0300 Subject: [Development] Doing a new release of qtstyleplugins? Message-ID: <20161117190414.tcn6sprepe7eet47@mitya57.me> Hi all, I sent the below mail to releasing mailing list a week ago, and got no reply. I wanted a new qtstyleplugins release so that I could package it for Debian. Is there anyone here who can make it, or would it be better for me to just package the latest Git snapshot? ----- My message to releasing mailing list below ----- Dear release team, In Qt 5.7, the GTK+ style has been moved from qtbase to qtstyleplugins [1]. However, the last released tarball of qtstyleplugins [2] is from 2014, and does not include that style yet. Can someone please generate a new tarball for the latest qtstyleplugin code and update the page linked above? For me any version number would work, and I can wait a bit in case you want that release to be synchronized with Qt 5.7.1. [1]: https://code.qt.io/cgit/qt/qtstyleplugins.git [2]: http://download.qt.io/community_releases/additional_qt_src_pkgs/ -- Dmitry Shachnev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From thiago.macieira at intel.com Thu Nov 17 23:03:16 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 17 Nov 2016 14:03:16 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <201611171135.54832.marc.mutz@kdab.com> References: <201611171135.54832.marc.mutz@kdab.com> Message-ID: <3180741.cRJAskENCj@tjmaciei-mobl1> On quinta-feira, 17 de novembro de 2016 11:35:54 PST Marc Mutz wrote: > The bigger problem is that while owner does not affect the ABI, all other > GSL types do, and we're back to our §$%&!§ rule that we can't accept other > libs' types in our ABI, preventing anything other than owner from being > added to Qt. We can't accept the Standard Library ABI in our ABI as per previous decisions (that I guess will be revisited once we get the QUIP on it up). But GSL is another story. If it is sensibly developed, with a promise to binary compatibility for extended periods of time and no nonsense stuff like inline namespaces, we could accept it. Especially the header-only parts of it. As for whether we can accept in our *API*, that depends on whether we would force our users to learn something alien to Qt or it, and what the benefits would be. Similar to the "empty()" function case. PS: IMO, the name of the library is inconvenient. It's too close to GLSL and GST (GStreamer). Of course, not a reason not to use it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Thu Nov 17 23:15:31 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 18 Nov 2016 01:15:31 +0300 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <3180741.cRJAskENCj@tjmaciei-mobl1> References: <201611171135.54832.marc.mutz@kdab.com> <3180741.cRJAskENCj@tjmaciei-mobl1> Message-ID: <9181479420931@web16g.yandex.ru> 18.11.2016, 01:03, "Thiago Macieira" : > On quinta-feira, 17 de novembro de 2016 11:35:54 PST Marc Mutz wrote: >>  The bigger problem is that while owner does not affect the ABI, all other >>  GSL types do, and we're back to our §$%&!§ rule that we can't accept other >>  libs' types in our ABI, preventing anything other than owner from being >>  added to Qt. > > We can't accept the Standard Library ABI in our ABI as per previous decisions > (that I guess will be revisited once we get the QUIP on it up). > > But GSL is another story. If it is sensibly developed, with a promise to > binary compatibility for extended periods of time and no nonsense stuff like > inline namespaces, we could accept it. Especially the header-only parts of it. > > As for whether we can accept in our *API*, that depends on whether we would > force our users to learn something alien to Qt or it, and what the benefits > would be. Similar to the "empty()" function case. > > PS: IMO, the name of the library is inconvenient. It's too close to GLSL and > GST (GStreamer). Of course, not a reason not to use it. "GSL" was standing for GNU Scientific Library for a long time. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From madigens at gmail.com Thu Nov 17 23:53:50 2016 From: madigens at gmail.com (Nikolaus Waxweiler) Date: Thu, 17 Nov 2016 23:53:50 +0100 Subject: [Development] Font rendering on X11/Wayland: New FreeType API to toggle LCD filters and stem darkening on a per-font basis, would love a review In-Reply-To: <616401a8-5e41-bf4b-e5eb-a4deed27ff6c@gmail.com> References: <616401a8-5e41-bf4b-e5eb-a4deed27ff6c@gmail.com> Message-ID: <9f4ae250-9d1a-a450-b669-37c4cf2cfad8@gmail.com> Hi! people in #qt-labs directed me here. I'm working on FreeType and want to merge a new API (FT_Face_Option) that would allow setting LCD filter weights and stem darkening properties on a per-face basis. The goal is to enable toolkits like Qt to finally turn on linear alpha blending and gamma correction on X11/Wayland for font rendering without users filing bugs like https://bugreports.qt.io/browse/QTBUG-41590. Stem darkening thickens glyphs depending on pixel size and the font design itself to prevent them from thinning out with LAB+GC. This would properly solve the above bug. A side issue this is trying to solve is making the API thread-safer, i.e. threads can now toggle stem darkening and modify LCD filter weights directly on their own FT_Face object without contending for a shared FT_Library or the font-driver-wide setting. I'd love to get feedback on the API before we make it official because I want to make sure it's actually useful in practice. The patches for FT are the top 3 commits at https://github.com/madig/freetype2/commits/stem-darkening-api. You can clone the repo somewhere and modify your compiler's include directives to look for FreeType there, then load the new library with `LD_PRELOAD=/somewhere/freetype2/objs/.libs/libfreetype.so some-application`. API usage examples are at https://github.com/madig/freetype2/commit/297b68621c020c8d6e61a04b8e91ac829a6bc13d#diff-9a8d509c02006aa497c68bcbcd32d505R3618 Best regards, Nikolaus From lars.knoll at qt.io Fri Nov 18 09:30:03 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 18 Nov 2016 08:30:03 +0000 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <3180741.cRJAskENCj@tjmaciei-mobl1> References: <201611171135.54832.marc.mutz@kdab.com> <3180741.cRJAskENCj@tjmaciei-mobl1> Message-ID: <05EB4094-933F-4B45-AFA2-A389F978E275@qt.io> On 17/11/16 23:03, "Development on behalf of Thiago Macieira" wrote: > On quinta-feira, 17 de novembro de 2016 11:35:54 PST Marc Mutz wrote: > > The bigger problem is that while owner does not affect the ABI, all other > > GSL types do, and we're back to our §$%&!§ rule that we can't accept other > > libs' types in our ABI, preventing anything other than owner from being > > added to Qt. > > We can't accept the Standard Library ABI in our ABI as per previous decisions > (that I guess will be revisited once we get the QUIP on it up). Yes, once we have the QUIP process up and running (very soon now), I am open to revisiting this and start creating QUIP containing a whitelist of stuff from the STL that we want to allow in our APIs. > But GSL is another story. If it is sensibly developed, with a promise to > binary compatibility for extended periods of time and no nonsense stuff like > inline namespaces, we could accept it. Especially the header-only parts of it. > > As for whether we can accept in our *API*, that depends on whether we would > force our users to learn something alien to Qt or it, and what the benefits > would be. Similar to the "empty()" function case. > > PS: IMO, the name of the library is inconvenient. It's too close to GLSL and > GST (GStreamer). Of course, not a reason not to use it. Let's wait a bit how this develops, and whether they are even interested in keeping compatibility between versions. But it would be another dependency, something I don't want to introduce without getting enough benefit out of it. Cheers, Lars From madigens at gmail.com Fri Nov 18 11:46:43 2016 From: madigens at gmail.com (Nikolaus Waxweiler) Date: Fri, 18 Nov 2016 11:46:43 +0100 Subject: [Development] Font rendering on X11/Wayland: New FreeType API to toggle LCD filters and stem darkening on a per-font basis, would love a review In-Reply-To: References: <616401a8-5e41-bf4b-e5eb-a4deed27ff6c@gmail.com> <9f4ae250-9d1a-a450-b669-37c4cf2cfad8@gmail.com> Message-ID: <0f75656c-4c3b-edab-330b-279505515caa@gmail.com> >> I'm working on FreeType and want to merge a new API (FT_Face_Option) >> that would allow setting LCD filter weights and stem darkening >> properties on a per-face basis. > > I'm fascinated but clueless ! https://www.freetype.org/freetype2/docs/text-rendering-general.html#experimental-stem-darkening-for-the-auto-hinter Correct font rendering with linear alpha blending and gamma correction can make text look pale like reported in https://bugreports.qt.io/browse/QTBUG-41590 due to the way the math behind it works out. Stem darkening compensates for the paleness. The new API is trying to make it practical for toolkits to opt into correct rendering of fonts by making it easy to toggle stem darkening (older toolkits without opt-in will get the same glyphs as before to keep backwards compatibility). No more bug reports about pale text! (Windows, macOS and Adobe's own font software render fonts correctly (read: compose glyphs correctly onto surfaces). macOS and I think Adobe software also use stem darkening to counteract paleness. The effect is most obvious on macOS. No toolkit on X11/Wayland does any of this currently. I want to change that. Stem darkening was introduced to FreeType by Adobe, by the way.) >> A side issue this is trying to solve is making the API thread-safer, > > The concept "thread-safer" amuses me. As far as I understand, FT is not by itself thread-safe, the developer has to use the API in a certain way to not blow things up. This API is supposed to be another stepping stone towards usefulness/pain-lesser-ness in a multithreading context. > I've (as ediosyncratic) reviewed; nothing struck me as obviously > problematic. I am not, however, a graphics expert. Thanks! :) From marc.mutz at kdab.com Fri Nov 18 20:37:26 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 18 Nov 2016 20:37:26 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <05EB4094-933F-4B45-AFA2-A389F978E275@qt.io> References: <3180741.cRJAskENCj@tjmaciei-mobl1> <05EB4094-933F-4B45-AFA2-A389F978E275@qt.io> Message-ID: <201611182037.26392.marc.mutz@kdab.com> On Friday 18 November 2016 09:30:03 Lars Knoll wrote: > On 17/11/16 23:03, "Development on behalf of Thiago Macieira" wrote: > > On quinta-feira, 17 de novembro de 2016 11:35:54 PST Marc Mutz wrote: > > > The bigger problem is that while owner does not affect the ABI, > > > all other > > > > > > GSL types do, and we're back to our §$%&!§ rule that we can't accept > > > other libs' types in our ABI, preventing anything other than > > > owner from being added to Qt. > > > > We can't accept the Standard Library ABI in our ABI as per previous > > decisions (that I guess will be revisited once we get the QUIP on it > > up). > > Yes, once we have the QUIP process up and running (very soon now), I am > open to revisiting this and start creating QUIP containing a whitelist of > stuff from the STL that we want to allow in our APIs. > > > But GSL is another story. If it is sensibly developed, with a promise > > to binary compatibility for extended periods of time and no nonsense > > stuff like inline namespaces, we could accept it. Especially the > > header-only parts of it. > > > > As for whether we can accept in our *API*, that depends on whether we > > would force our users to learn something alien to Qt or it, and what > > the benefits would be. Similar to the "empty()" function case. > > > > PS: IMO, the name of the library is inconvenient. It's too close to > > GLSL and GST (GStreamer). Of course, not a reason not to use it. > > Let's wait a bit how this develops, and whether they are even interested in > keeping compatibility between versions. But it would be another > dependency, something I don't want to introduce without getting enough > benefit out of it. The GSL is header-only. There are no BC guarantees, and, "worse", there are different implementations. All the compiler, or a static checker, cares about is the name of type: ::gsl::owner, ::gsl::non_null, ::gsl::string_span. It does not care about the implementation. There's no reason for Qt to extend its BC guarantees to other libraries. STL, GSL, Boost, std::exception, you name it. They are outside of Qt's realm and therefore do not fall under the Qt BC rules. As with every other C++ library: if a user wants BC, it's his job to pin libs without BC guarantees to a fixed version. Not Qts. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Fri Nov 18 20:38:58 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 18 Nov 2016 20:38:58 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: <201611171135.54832.marc.mutz@kdab.com> Message-ID: <201611182038.58955.marc.mutz@kdab.com> On Thursday 17 November 2016 11:41:25 Marco Bubke wrote: > I want to remind you this is about Qt Creator, not Qt. Please use a > different thread for it. [?] I guess QtC also has some API/BC rules for its plugins? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Fri Nov 18 22:12:44 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 18 Nov 2016 13:12:44 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <201611182037.26392.marc.mutz@kdab.com> References: <05EB4094-933F-4B45-AFA2-A389F978E275@qt.io> <201611182037.26392.marc.mutz@kdab.com> Message-ID: <2973175.c5za8zjegP@tjmaciei-mobl1> Em sexta-feira, 18 de novembro de 2016, às 20:37:26 PST, Marc Mutz escreveu: > There's no reason for Qt to extend its BC guarantees to other libraries. > STL, GSL, Boost, std::exception, you name it. They are outside of Qt's > realm and therefore do not fall under the Qt BC rules. Which is the reason we can't accept them in our ABI. The rules are incompatible. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Marco.Bubke at qt.io Sat Nov 19 00:24:15 2016 From: Marco.Bubke at qt.io (Marco Bubke) Date: Fri, 18 Nov 2016 23:24:15 +0000 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <2973175.c5za8zjegP@tjmaciei-mobl1> References: <05EB4094-933F-4B45-AFA2-A389F978E275@qt.io> <201611182037.26392.marc.mutz@kdab.com> <2973175.c5za8zjegP@tjmaciei-mobl1> Message-ID: On November 18, 2016 22:13:03 Thiago Macieira wrote: > Em sexta-feira, 18 de novembro de 2016, às 20:37:26 PST, Marc Mutz escreveu: >> There's no reason for Qt to extend its BC guarantees to other libraries. >> STL, GSL, Boost, std::exception, you name it. They are outside of Qt's >> realm and therefore do not fall under the Qt BC rules. > > Which is the reason we can't accept them in our ABI. The rules are > incompatible. Actually GSL owner is simply definded as as alias to *T, so you can add it without breaking any ABI or API. And I want to remind you it is about QtCreator, which has no guarantees. So it would be nice if you get in context. Actually it looks like you cannot agree on your assumptions, so it's maybe time to find arguments to provide some agreeable fundamentals. Otherwise I don't see how this discussion can be reach any cooperative level at all. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From madigens at gmail.com Sat Nov 19 01:25:13 2016 From: madigens at gmail.com (Nikolaus Waxweiler) Date: Sat, 19 Nov 2016 01:25:13 +0100 Subject: [Development] Font rendering on X11/Wayland: New FreeType API to toggle LCD filters and stem darkening on a per-font basis, would love a review In-Reply-To: <201611181740.25658.allan.jensen@qt.io> References: <616401a8-5e41-bf4b-e5eb-a4deed27ff6c@gmail.com> <0f75656c-4c3b-edab-330b-279505515caa@gmail.com> <201611181740.25658.allan.jensen@qt.io> Message-ID: <64346f09-41b2-d1e4-5ceb-70926249102b@gmail.com> >> Correct font rendering with linear alpha blending and gamma correction >> can make text look pale like reported in >> https://bugreports.qt.io/browse/QTBUG-41590 due to the way the math >> behind it works out. Stem darkening compensates for the paleness. > > Any idea why exactly? I'm not sure what you're asking. Do you mean why LAB+GC results in pale(r) text? The paleness is an expected side-effect of gamma correction on low-DPI screens. Have a look at https://www.freetype.org/image/BlendingExamples.png. All (grayscale) examples are composed onto the surface using linear alpha blending. Column 1 has no gamma correction, column 2 uses a gamma correction factor of 1.8. The result in column 2 is clean but paler text. The glyphs that FreeType outputs are really 8-bit alpha maps in linear space: a pixel that has zero coverage of a glyph is white (255), one with 100% coverage is black (0), one with 50% coverage is set to a value of 127, or a middle shade of gray. Since most monitors out there do not have a linear gamma curve, you need to bend your alpha map after you have composited onto a surface. The 50% coverage or 127 value in linear space maps to a value of around 180 or so on a standard sRGB surface, 127 would be much darker. So now you go and bump that 127 up to 180 -- tada, the pixel and by extension the entire glyph is now lighter, or paler. But also nice and clean. You can also have a look at ftview from the freetype2-demos package. It uses LAB+GC by default. Using LCD filtered rendering actually makes little difference to my own surprise (press 'A' and 'C' to switch between grayscale and LCD filtered rendering, respectively). Since 1) a pixel's chance of being 100% covered is much higher on HiDPI screens and 2) black is the same thing in linear space and all other gamma curves, this is primarily an issue on LoDPI screens, so 99% of screens out there. > Anyway from an API point of view, the easiest implementation would be if Qt > could read on initialization if freetype can do stem darkening on all outline > fonts. Since it can't do that currently, an alternative would be to be able to > query it per face, and then carry the information on. If the new FT_Face_Option() is present, FT can do stem darkening on (almost entirely) all outline fonts :) The toolkit just has to invoke the function on all FT_Faces to be rendered. From thiago.macieira at intel.com Sat Nov 19 02:06:55 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 18 Nov 2016 17:06:55 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: <2973175.c5za8zjegP@tjmaciei-mobl1> Message-ID: <2961320.ggQiz8ZCq2@tjmaciei-mobl1> Em sexta-feira, 18 de novembro de 2016, às 23:24:15 PST, Marco Bubke escreveu: > Actually it looks like you cannot agree on your assumptions, so it's maybe > time to find arguments to provide some agreeable fundamentals. Otherwise I > don't see how this discussion can be reach any cooperative level at all. Marco, I asked you to list the rules you specifically want to see adopted at first. You haven't replied with that yet. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Sat Nov 19 02:17:27 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sat, 19 Nov 2016 04:17:27 +0300 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <201611171135.54832.marc.mutz@kdab.com> References: <4448293.XkAZ11bryX@tjmaciei-mobl1> <201611171135.54832.marc.mutz@kdab.com> Message-ID: <7260551479518247@web34j.yandex.ru> 17.11.2016, 13:33, "Marc Mutz" : > On Thursday 17 November 2016 10:46:24 Edward Welbourne wrote: >>  On quarta-feira, 16 de novembro de 2016 17:11:02 PST Marco Bubke wrote: >>  >> Like you maybe have learned there are C++ Core Guidelines. They are >>  >> already very comprehensive. What about basing the Qt Creator Code >>  >> Style on it? >>  >> >>  >> I see advantages like new developer can easier grasp out rules >>  >> because they are already familiar with it. >>  >> >>  >> We may have to exclude some rules too because they don't fit to us. >> >>  Thiago Macieira replied: >>  > "very comprehensive" is an understatement. Can you point out examples >>  > of rules you're more interested in? Maybe we should start with a >>  > whitelist of rules we do want and progressively expand from there. >> >>  The guidelines' introduction does, after all, countenance gradual >>  adoption - especially for existing code-bases - and a general opt-in >>  approach. Presumably QtC's style is also used for new projects; it may >>  be worth using a larger subset of the guidelines for new projects as >>  compared to old; and it probably makes sense to make it easy for users >>  to configure which of the guidelines they opt in to, for each project. > > If we do nothing else, we should at least use owner whereever possible. Wouldn't it be a better idea to use standard language feature to indicate ownership, i.e. std::unique_ptr, wherever it makes sense? > We > can add it to QtGlobal, since we require now enough C++11 to support it: > >   namespace gsl { >       template using owner = T; >   } > > There, done. It doesn't even interfere with client code including a more > comprehensive GSL library, because they will define it the same way, and it's > just a type alias. > > One problem is that in Qt, who is the owner is often not clear. But that > should not prevent us from using it everywhere else. > > Than again, no compiler actually checks for this atm, not even MSVC, afaik, so > if we get it wrong, there's no-one but reviewers to call the mistake... > > The bigger problem is that while owner does not affect the ABI, all other > GSL types do, and we're back to our §$%&!§ rule that we can't accept other > libs' types in our ABI, preventing anything other than owner from being > added to Qt. > > My personal opinion is that we're way, WAY, past the tipping point where this > policy started to hurt Qt more than the convenience of interchanging libc++ > and libstdc++ on OS X gives to the 5 people in the world that use this > feature. And I'm not at all happy that QtCS chickened out on a decision this > year. I don't think we can afford to wait for next year's QtCS to maybe-maybe- > not get rid of that nonsensical rule. > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From marc.mutz at kdab.com Sat Nov 19 07:49:25 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 19 Nov 2016 07:49:25 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <7260551479518247@web34j.yandex.ru> References: <201611171135.54832.marc.mutz@kdab.com> <7260551479518247@web34j.yandex.ru> Message-ID: <201611190749.25346.marc.mutz@kdab.com> On Saturday 19 November 2016 02:17:27 Konstantin Tokarev wrote: > > If we do nothing else, we should at least use owner whereever > > possible. > > Wouldn't it be a better idea to use standard language feature to indicate > ownership, i.e. std::unique_ptr, wherever it makes sense? Yes, if we could. But BC (see above) and SC will make this impossible for a long time to come. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Sat Nov 19 08:04:19 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 19 Nov 2016 08:04:19 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <2973175.c5za8zjegP@tjmaciei-mobl1> References: <201611182037.26392.marc.mutz@kdab.com> <2973175.c5za8zjegP@tjmaciei-mobl1> Message-ID: <201611190804.20045.marc.mutz@kdab.com> On Friday 18 November 2016 22:12:44 Thiago Macieira wrote: > Em sexta-feira, 18 de novembro de 2016, às 20:37:26 PST, Marc Mutz escreveu: > > There's no reason for Qt to extend its BC guarantees to other libraries. > > STL, GSL, Boost, std::exception, you name it. They are outside of Qt's > > realm and therefore do not fall under the Qt BC rules. > > Which is the reason we can't accept them in our ABI. The rules are > incompatible. If you extend this argument to its logical conclusion, Qt should be BC between debug and releases on MSVC. Many libraries manage. Gpgme, e.g. Why doesn't Qt? You see, that argument is completely empty. The STL is forbidden because people are uncomfortable with it, not because it causes BiC. The debug/release stuff on MSVC is allowed to be BiC because people have come to accept it as reality. Neither one is any more right or wrong inherently, than the other. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From abbapoh at gmail.com Sat Nov 19 10:22:18 2016 From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Sat, 19 Nov 2016 12:22:18 +0300 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <201611190804.20045.marc.mutz@kdab.com> References: <201611182037.26392.marc.mutz@kdab.com> <2973175.c5za8zjegP@tjmaciei-mobl1> <201611190804.20045.marc.mutz@kdab.com> Message-ID: Maybe we should start another thread about BC? I'm not convinced that MacOS is the only system when mixing libc++/stdlib makes sence. On linux you can do the same. If we will use stl, the Qt version installed from packages can't be used for development, you should use libc++/stdlib Qt version from Qt site. Not a problem, really. The problem is the incompatibility between compiler versions. I had a plugin build with gcc 4.7 and i spent 2 hours to find the reason why it crashed with library build with gcc 4.8 (i didn't know that compiler updated on build host). The problem was that std::unordered_map was BiC. So, Qt have to support each gcc (actually, stdlib/libc++ version) major version. And you will have reinstall Qt (almost) each time you update the compiler package. Correct me if i'm wrong. 2016-11-19 10:04 GMT+03:00 Marc Mutz : > On Friday 18 November 2016 22:12:44 Thiago Macieira wrote: > > Em sexta-feira, 18 de novembro de 2016, às 20:37:26 PST, Marc Mutz > escreveu: > > > There's no reason for Qt to extend its BC guarantees to other > libraries. > > > STL, GSL, Boost, std::exception, you name it. They are outside of Qt's > > > realm and therefore do not fall under the Qt BC rules. > > > > Which is the reason we can't accept them in our ABI. The rules are > > incompatible. > > If you extend this argument to its logical conclusion, Qt should be BC > between > debug and releases on MSVC. Many libraries manage. Gpgme, e.g. Why doesn't > Qt? > > You see, that argument is completely empty. The STL is forbidden because > people are uncomfortable with it, not because it causes BiC. The > debug/release > stuff on MSVC is allowed to be BiC because people have come to accept it as > reality. Neither one is any more right or wrong inherently, than the other. > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nassian at bitshift-dynamics.de Sat Nov 19 10:34:36 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Sat, 19 Nov 2016 10:34:36 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: <201611182037.26392.marc.mutz@kdab.com> <2973175.c5za8zjegP@tjmaciei-mobl1> <201611190804.20045.marc.mutz@kdab.com> Message-ID: <52173FDB-219A-429A-A99D-216BAAB1E20E@bitshift-dynamics.de> Will there be now 10 BC discussions every year? At least it feels like. Why can't it be decided and then accepted by everyone as is? In my personal opinion I don't care much about BC but I'm happy that it blocks STL usage because its brutally unnatural and I stumbled so often over different behaviors of it on different platforms and compilers that I have a real hate on the STL. Beste Grüße / Best regards, Alexander Nassian > Am 19.11.2016 um 10:22 schrieb Иван Комиссаров : > > Maybe we should start another thread about BC? > I'm not convinced that MacOS is the only system when mixing libc++/stdlib makes sence. On linux you can do the same. If we will use stl, the Qt version installed from packages can't be used for development, you should use libc++/stdlib Qt version from Qt site. Not a problem, really. > The problem is the incompatibility between compiler versions. I had a plugin build with gcc 4.7 and i spent 2 hours to find the reason why it crashed with library build with gcc 4.8 (i didn't know that compiler updated on build host). The problem was that std::unordered_map was BiC. > So, Qt have to support each gcc (actually, stdlib/libc++ version) major version. > And you will have reinstall Qt (almost) each time you update the compiler package. > Correct me if i'm wrong. > > 2016-11-19 10:04 GMT+03:00 Marc Mutz : >> On Friday 18 November 2016 22:12:44 Thiago Macieira wrote: >> > Em sexta-feira, 18 de novembro de 2016, às 20:37:26 PST, Marc Mutz escreveu: >> > > There's no reason for Qt to extend its BC guarantees to other libraries. >> > > STL, GSL, Boost, std::exception, you name it. They are outside of Qt's >> > > realm and therefore do not fall under the Qt BC rules. >> > >> > Which is the reason we can't accept them in our ABI. The rules are >> > incompatible. >> >> If you extend this argument to its logical conclusion, Qt should be BC between >> debug and releases on MSVC. Many libraries manage. Gpgme, e.g. Why doesn't Qt? >> >> You see, that argument is completely empty. The STL is forbidden because >> people are uncomfortable with it, not because it causes BiC. The debug/release >> stuff on MSVC is allowed to be BiC because people have come to accept it as >> reality. Neither one is any more right or wrong inherently, than the other. >> >> Thanks, >> Marc >> >> -- >> Marc Mutz | Senior Software Engineer >> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company >> Tel: +49-30-521325470 >> KDAB - The Qt, C++ and OpenGL Experts >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From abbapoh at gmail.com Sat Nov 19 11:17:25 2016 From: abbapoh at gmail.com (=?utf-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Sat, 19 Nov 2016 13:17:25 +0300 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <52173FDB-219A-429A-A99D-216BAAB1E20E@bitshift-dynamics.de> References: <201611182037.26392.marc.mutz@kdab.com> <2973175.c5za8zjegP@tjmaciei-mobl1> <201611190804.20045.marc.mutz@kdab.com> <52173FDB-219A-429A-A99D-216BAAB1E20E@bitshift-dynamics.de> Message-ID: <02EC2B2C-609E-45E2-B7D6-8EF8EA4D3998@gmail.com> The problem is that Qt stuck at some point. We can’t use STL in our API, so we forced to have QVector, …, QSharedPointer, .... On the other hand, we doesn’t develop those classes, because stl already have them. So, we’re missing QUniquePtr, qMakeShared, append(T&&) (yeah, COW, i know) and so on. We have to move from that point somewhere, either extending our classes to make them standard-compatible (when possible) or replace them with stl ones. Иван Комиссаров 19 нояб. 2016 г., в 12:34, Alexander Nassian написал(а): > Will there be now 10 BC discussions every year? At least it feels like. Why can't it be decided and then accepted by everyone as is? In my personal opinion I don't care much about BC but I'm happy that it blocks STL usage because its brutally unnatural and I stumbled so often over different behaviors of it on different platforms and compilers that I have a real hate on the STL. > > Beste Grüße / Best regards, > Alexander Nassian From fredrik at kde.org Sat Nov 19 11:56:58 2016 From: fredrik at kde.org (Fredrik =?iso-8859-1?q?H=F6glund?=) Date: Sat, 19 Nov 2016 11:56:58 +0100 Subject: [Development] Font rendering on X11/Wayland: New FreeType API to toggle LCD filters and stem darkening on a per-font basis, would love a review In-Reply-To: <64346f09-41b2-d1e4-5ceb-70926249102b@gmail.com> References: <616401a8-5e41-bf4b-e5eb-a4deed27ff6c@gmail.com> <201611181740.25658.allan.jensen@qt.io> <64346f09-41b2-d1e4-5ceb-70926249102b@gmail.com> Message-ID: <201611191156.58583.fredrik@kde.org> On Saturday 19 November 2016, Nikolaus Waxweiler wrote: > > Anyway from an API point of view, the easiest implementation would be if Qt > > could read on initialization if freetype can do stem darkening on all outline > > fonts. Since it can't do that currently, an alternative would be to be able to > > query it per face, and then carry the information on. > > If the new FT_Face_Option() is present, FT can do stem darkening on > (almost entirely) all outline fonts :) The toolkit just has to invoke > the function on all FT_Faces to be rendered. But will stem darkening work with the bytecode interpreter? Fredrik From madigens at gmail.com Sat Nov 19 12:15:06 2016 From: madigens at gmail.com (Nikolaus Waxweiler) Date: Sat, 19 Nov 2016 12:15:06 +0100 Subject: [Development] Font rendering on X11/Wayland: New FreeType API to toggle LCD filters and stem darkening on a per-font basis, would love a review In-Reply-To: <201611191156.58583.fredrik@kde.org> References: <616401a8-5e41-bf4b-e5eb-a4deed27ff6c@gmail.com> <201611181740.25658.allan.jensen@qt.io> <64346f09-41b2-d1e4-5ceb-70926249102b@gmail.com> <201611191156.58583.fredrik@kde.org> Message-ID: >> If the new FT_Face_Option() is present, FT can do stem darkening on >> (almost entirely) all outline fonts :) The toolkit just has to invoke >> the function on all FT_Faces to be rendered. > > But will stem darkening work with the bytecode interpreter? It won't until I implement it in the TrueType engine, and only for the v40 interpreter in backwards compatibility mode. I don't think the concept of stem darkening is compatible with the explicit glyph modifications on both axes that are possible in v40 native ClearType mode and v35. Turning on stem darkening currently triggers the autohinter for all outlines formats except .otf, where the font driver can do it natively. From marc.mutz at kdab.com Sat Nov 19 13:00:58 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 19 Nov 2016 13:00:58 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <52173FDB-219A-429A-A99D-216BAAB1E20E@bitshift-dynamics.de> References: <52173FDB-219A-429A-A99D-216BAAB1E20E@bitshift-dynamics.de> Message-ID: <201611191300.58948.marc.mutz@kdab.com> On Saturday 19 November 2016 10:34:36 Alexander Nassian wrote: > Will there be now 10 BC discussions every year? No, just one for each time Qt suffers more from this policy. :) That's how this came up: it prevents the use of the GSL in Qt. The STL was really just for simile. This is about the GSL. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Sat Nov 19 13:07:04 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 19 Nov 2016 13:07:04 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: <201611190804.20045.marc.mutz@kdab.com> Message-ID: <201611191307.04423.marc.mutz@kdab.com> On Saturday 19 November 2016 10:22:18 Иван Комиссаров wrote: > Maybe we should start another thread about BC? > I'm not convinced that MacOS is the only system when mixing libc++/stdlib > makes sence. On linux you can do the same. As soon as someone explains to me what the material difference is between a) supporting mixing libc++ and libstdc++ on Unix platforms and b) supporting mixing release and debug runtimes on Windows, I'm open for discussing the merits of the former. Until then, I refuse to see a difference between the two, refuse to accept that we need to support one and not the other, and suggest to just compile two versions of Qt: libQt5*Foo-libc++.so and libQt5*Foo-libstdc++.so. If this solves the problem on Windows, someone needs to explain to me why it's not an option on Unix. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From abbapoh at gmail.com Sat Nov 19 14:18:20 2016 From: abbapoh at gmail.com (=?utf-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Sat, 19 Nov 2016 16:18:20 +0300 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <201611191307.04423.marc.mutz@kdab.com> References: <201611190804.20045.marc.mutz@kdab.com> <201611191307.04423.marc.mutz@kdab.com> Message-ID: IMO, we can mix libc++/libstd because we have some BC guarantees, not we have BC guarantees because we *need* to mix them. There’s no real difference between debug/release and libc++/libstd. Still, we need those guarantees not to rebuild whole KDE packages in linux distros each time new Qt version (or new stdlib version if we’ll support std:: in API) is released (also, users should reinstall those packages too) Иван Комиссаров 19 нояб. 2016 г., в 15:07, Marc Mutz написал(а): > As soon as someone explains to me what the material difference is between a) > supporting mixing libc++ and libstdc++ on Unix platforms and b) supporting > mixing release and debug runtimes on Windows, I'm open for discussing the > merits of the former. Until then, I refuse to see a difference between the > two, refuse to accept that we need to support one and not the other, and > suggest to just compile two versions of Qt: libQt5*Foo-libc++.so and > libQt5*Foo-libstdc++.so. If this solves the problem on Windows, someone needs > to explain to me why it's not an option on Unix. > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From kde at carewolf.com Sat Nov 19 14:29:54 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Sat, 19 Nov 2016 14:29:54 +0100 Subject: [Development] Font rendering on X11/Wayland: New FreeType API to toggle LCD filters and stem darkening on a per-font basis, would love a review In-Reply-To: <64346f09-41b2-d1e4-5ceb-70926249102b@gmail.com> References: <616401a8-5e41-bf4b-e5eb-a4deed27ff6c@gmail.com> <201611181740.25658.allan.jensen@qt.io> <64346f09-41b2-d1e4-5ceb-70926249102b@gmail.com> Message-ID: <201611191429.54730.kde@carewolf.com> On Saturday 19 November 2016, Nikolaus Waxweiler wrote: > >> Correct font rendering with linear alpha blending and gamma correction > >> can make text look pale like reported in > >> https://bugreports.qt.io/browse/QTBUG-41590 due to the way the math > >> behind it works out. Stem darkening compensates for the paleness. > > > > Any idea why exactly? > > I'm not sure what you're asking. Do you mean why LAB+GC results in > pale(r) text? The paleness is an expected side-effect of gamma > correction on low-DPI screens. > No I understand the math. I am just curious from a philosophical point of view how come stem darkening is even needed. Gamma-corrected blending might end up paler, but it should be a more correct result, so it just odd that it looks wrong and that a compensation is needed. Somewhere we must have done something that relied on naive blending. Maybe in the design of the fonts? Also I notice in your example you also use a too low gamma value. The standard in screens in between 2.2 and 2.4, and when using that I generally see an inversion in the contrast balance. Look at the attached example. Ideally with correct blending text should look equally "bold" regardless of background and foreground color. It is obvious white on black with naive blending is too weak, but the color on white text with GC blending is just as weak, while white on black is now as bold as color on white used to be. If I used a gamma of 1.6 it would look more balanced, but my screen has a gamma of either 2.4 or sRGB , so why does using the right value give the an unbalanced result? Anyway, on the API front. Forcing to autohinter is probably not acceptable. So we could enable stem darkening where native available, but then we need to know if what engine a face is using, or better yet specifically if the engine used right now on this face did stem darkening. Best regards `Allan -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot_20161119_142046.png Type: image/png Size: 65570 bytes Desc: not available URL: From madigens at gmail.com Sat Nov 19 15:28:34 2016 From: madigens at gmail.com (Nikolaus Waxweiler) Date: Sat, 19 Nov 2016 15:28:34 +0100 Subject: [Development] Font rendering on X11/Wayland: New FreeType API to toggle LCD filters and stem darkening on a per-font basis, would love a review In-Reply-To: <201611191429.54730.kde@carewolf.com> References: <616401a8-5e41-bf4b-e5eb-a4deed27ff6c@gmail.com> <201611181740.25658.allan.jensen@qt.io> <64346f09-41b2-d1e4-5ceb-70926249102b@gmail.com> <201611191429.54730.kde@carewolf.com> Message-ID: > I am just curious from a philosophical point of view how come stem > darkening is even needed. Gamma-corrected blending might end up > paler, but it should be a more correct result, so it just odd that it > looks wrong and that a compensation is needed. Somewhere we must have > done something that relied on naive blending. Maybe in the design of > the fonts? The result is indeed more correct, but LoDPI screens ruin everything ;) You could say that this is indirectly the fault of the font's design. Stem darkening is a pragmatic solution to increase contrast. The algorithm used by FT adjusts the darkening depending on the pixel size and font design. Thinner fonts are darkened more than bolder fonts. The darkening becomes stronger at smaller pixel sizes. Above a threshold (at larger pixel sizes), no darkening is applied. This implies that the font engine must have more control over the final appearance of a glyph and this is... difficult if it involves the explicit nature of TrueType hinting. > Also I notice in your example you also use a too low gamma value. The > standard in screens in between 2.2 and 2.4, and when using that I > generally see an inversion in the contrast balance. The 1.8 comes from internal testing at Adobe. I was told they tested font rendering on a variety of screens and determined 1.8 to be a good compromise. I think Microsoft uses 1.4 for GDI font rendering? > Look at the attached example. Ideally with correct blending text > should look equally "bold" regardless of background and foreground > color. It is obvious white on black with naive blending is too weak, > but the color on white text with GC blending is just as weak, while > white on black is now as bold as color on white used to be. If I > used a gamma of 1.6 it would look more balanced, but my screen has a > gamma of either 2.4 or sRGB , so why does using the right value give > the an unbalanced result? Hm, I think this is a perception issue. In your example, I find the third column to be more balanced than the first. The brain sees white-on-black differently than black-on-white, so a designer has to compensate for the non-linearity :) This is especially noticeable if your brain is accustomed to naive blending. White-on-black looks similar on macOS. > Anyway, on the API front. Forcing to autohinter is probably not > acceptable. So we could enable stem darkening where native available, > but then we need to know if what engine a face is using, or better > yet specifically if the engine used right now on this face did stem > darkening. I can implement something for the TT engine (v40 backwards compat. mode), maybe even soon. You can test for native stem darkening like so (src/base/ftobjs.c:633): ``` error = FT_Property_Get( library, driver->clazz->root.module_name, "no-stem-darkening", &stem_darkening_driver ); if ( error ) { driver_can_darken_stems = FALSE; stem_darkening_driver = FALSE; } else { driver_can_darken_stems = TRUE; stem_darkening_driver = !stem_darkening_driver; } ``` (Gotta run, look up the doc for FT_Property_Get. Getting an error back means that the font driver probably won't do stem darkening. TT is tricky as noted above, must implement first before I can give a definite answer) From thiago.macieira at intel.com Sat Nov 19 18:02:45 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 19 Nov 2016 09:02:45 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <52173FDB-219A-429A-A99D-216BAAB1E20E@bitshift-dynamics.de> References: <52173FDB-219A-429A-A99D-216BAAB1E20E@bitshift-dynamics.de> Message-ID: <1512055.zTViZuxnkC@tjmaciei-mobl1> Em sábado, 19 de novembro de 2016, às 10:34:36 PST, Alexander Nassian escreveu: > Will there be now 10 BC discussions every year? No, that's why we need a QUIP for it so that we don't rediscuss it every year, unless the circumstances change. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Nov 19 18:17:02 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 19 Nov 2016 09:17:02 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <201611191307.04423.marc.mutz@kdab.com> References: <201611191307.04423.marc.mutz@kdab.com> Message-ID: <1593226.lWUe2LCNfV@tjmaciei-mobl1> Em sábado, 19 de novembro de 2016, às 13:07:04 PST, Marc Mutz escreveu: > As soon as someone explains to me what the material difference is between a) > supporting mixing libc++ and libstdc++ on Unix platforms and b) supporting > mixing release and debug runtimes on Windows, libc++ and libstdc++ are designed to interoperate, because they share operator new, std::exception and the base typeinfos, if compiled properly[*]. That means memory new'ed with one can be delete'd in the other, exceptions thrown in one can be caught in the other, dynamic casts work, etc. The MSVC CRTs are currently not designed to interoperate. Not only do they each have their own operator new, one's delete cannot delete the other's pointers. That said, we *could* build a debug mode Qt against the release runtime (-Od -MT), we just don't. It's one of those "it was like that when I arrived" problems of Qt 4.0, though I helped fix the Unix debug/release problem for 4.2. Another reason is that no one deploys debug-mode. So there's little danger of mixing because it doesn't happen in customers' hands. And then there's the fact that MS keeps breaking BC if you change the compiler, so anyone using MSVC needs to be careful anyway to avoid polluting one build with plugins from another, something that elsewhere is permitted. Just think of how pointless our discussion on whether we should upgrade our packaging system to MSVC 2015 Update 3 or not... Finally, MS has said it will start keeping binary compatibility with Visual Studio 2017 onwards (or was it 2015 onwards?), so this is actually a good time to revisit this. [*] Apple compiles them properly. I have yet to see someone compiling them properly on Linux. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Nov 19 18:05:10 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 19 Nov 2016 09:05:10 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <201611191300.58948.marc.mutz@kdab.com> References: <52173FDB-219A-429A-A99D-216BAAB1E20E@bitshift-dynamics.de> <201611191300.58948.marc.mutz@kdab.com> Message-ID: <6948647.CNsyYnAym9@tjmaciei-mobl1> Em sábado, 19 de novembro de 2016, às 13:00:58 PST, Marc Mutz escreveu: > That's how this came up: it prevents the use of the GSL in Qt And as Marco points out, this thread is NOT about GSL in Qt. It's about (maybe) GSL in Qt Creator. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Sat Nov 19 19:57:57 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 19 Nov 2016 19:57:57 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: <201611191307.04423.marc.mutz@kdab.com> Message-ID: <201611191957.57663.marc.mutz@kdab.com> On Saturday 19 November 2016 14:18:20 Иван Комиссаров wrote: > Still, we need those guarantees not to rebuild whole KDE packages in linux > distros each time new Qt version (or new stdlib version if we’ll support > std:: in API) is released (also, users should reinstall those packages > too) You see, this is a perfect example of why we _don't_. (Some parts of) KF5 use boost and STL in the API (ever since KDE 4 or even 3). It hasn't been a problem for KDE to keep BC guarantees comparable to what Qt does. What makes you think that Qt would be any different? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From kevin.kofler at chello.at Sat Nov 19 21:08:00 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 19 Nov 2016 21:08 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? References: <201611182037.26392.marc.mutz@kdab.com> <2973175.c5za8zjegP@tjmaciei-mobl1> <201611190804.20045.marc.mutz@kdab.com> <52173FDB-219A-429A-A99D-216BAAB1E20E@bitshift-dynamics.de> Message-ID: Alexander Nassian wrote: > Will there be now 10 BC discussions every year? At least it feels like. > Why can't it be decided and then accepted by everyone as is? In my > personal opinion I don't care much about BC but I'm happy that it blocks > STL usage because its brutally unnatural and I stumbled so often over > different behaviors of it on different platforms and compilers that I have > a real hate on the STL. I am glad that I am not alone with that feeling. And by the way, with my distribution packager hat on, I have to frown upon the idea of dragging in yet another dependency just to enforce the C++ language inventor's personal, not uncontroversial stylistic preferences. Kevin Kofler From philwave at gmail.com Sat Nov 19 21:15:44 2016 From: philwave at gmail.com (Philippe) Date: Sat, 19 Nov 2016 21:15:44 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: <52173FDB-219A-429A-A99D-216BAAB1E20E@bitshift-dynamics.de> Message-ID: <20161119211543.E6CD.6F0322A@gmail.com> On Sat, 19 Nov 2016 21:08 +0100 Kevin Kofler wrote: > Alexander Nassian wrote: >> In my personal opinion I don't care much about BC but I'm happy that it blocks > > STL usage because its brutally unnatural and I stumbled so often over > > different behaviors of it on different platforms and compilers that I have > > a real hate on the STL. > > I am glad that I am not alone with that feeling. +1 Philippe From annulen at yandex.ru Sat Nov 19 21:51:41 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sat, 19 Nov 2016 23:51:41 +0300 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <201611190749.25346.marc.mutz@kdab.com> References: <201611171135.54832.marc.mutz@kdab.com> <7260551479518247@web34j.yandex.ru> <201611190749.25346.marc.mutz@kdab.com> Message-ID: <8099681479588701@web34j.yandex.ru> 19.11.2016, 09:46, "Marc Mutz" : > On Saturday 19 November 2016 02:17:27 Konstantin Tokarev wrote: >>  > If we do nothing else, we should at least use owner whereever >>  > possible. >> >>  Wouldn't it be a better idea to use standard language feature to indicate >>  ownership, i.e. std::unique_ptr, wherever it makes sense? > > Yes, if we could. But BC (see above) and SC will make this impossible for a > long time to come. IIRC Qt Creator keeps BC and SC compatibility only between patch releases, so there is no real urge to introduce surrogate types instead of migration to std::unique_ptr > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt, C++ and OpenGL Experts -- Regards, Konstantin From thiago.macieira at intel.com Sat Nov 19 22:30:51 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 19 Nov 2016 13:30:51 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <201611191957.57663.marc.mutz@kdab.com> References: <201611191957.57663.marc.mutz@kdab.com> Message-ID: <2464166.EJcljRpKSs@tjmaciei-mobl1> Em sábado, 19 de novembro de 2016, às 19:57:57 PST, Marc Mutz escreveu: > You see, this is a perfect example of why we _don't_. > > (Some parts of) KF5 use boost and STL in the API (ever since KDE 4 or even > 3). It hasn't been a problem for KDE to keep BC guarantees comparable to > what Qt does. What makes you think that Qt would be any different? Those parts of KDE don't keep BC guarantees. Distros have to rebuild everything when their dependencies change. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From dangelog at gmail.com Sat Nov 19 22:44:19 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Sat, 19 Nov 2016 22:44:19 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: Message-ID: On Wed, Nov 16, 2016 at 6:11 PM, Marco Bubke wrote: > Hi > > > This is a Qt Creator topic only so sorry to disturb every body else. > > > Like you maybe have learned there are C++ Core Guidelines. They are > already very comprehensive. What about basing the Qt Creator Code Style on > it? > > > I see advantages like new developer can easier grasp out rules because > they are already familiar with it. > > We may have to exclude some rules too because they don't fit to us. > I'm terribly sad that this thread has been derailed in an unrelated discussion. Please, could we all *stop* doing that and let's discuss that (*extremely important*) matter on another thread. Staying on track: I would love to see (again) Creator as a playground for how well the GSL can be integrated into a Qt project. Apart from owner, have you identified some other guideline that you think it might be useful for everyone? Thanks, -- Giuseppe D'Angelo -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Sun Nov 20 08:33:23 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sun, 20 Nov 2016 08:33:23 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <2464166.EJcljRpKSs@tjmaciei-mobl1> References: <201611191957.57663.marc.mutz@kdab.com> <2464166.EJcljRpKSs@tjmaciei-mobl1> Message-ID: <201611200833.23979.marc.mutz@kdab.com> On Saturday 19 November 2016 22:30:51 Thiago Macieira wrote: > Em sábado, 19 de novembro de 2016, às 19:57:57 PST, Marc Mutz escreveu: > > You see, this is a perfect example of why we _don't_. > > > > > > > > (Some parts of) KF5 use boost and STL in the API (ever since KDE 4 or > > even 3). It hasn't been a problem for KDE to keep BC guarantees > > comparable to what Qt does. What makes you think that Qt would be any > > different? > > Those parts of KDE don't keep BC guarantees. Distros have to rebuild > everything when their dependencies change. I wonder why we used d-pointers and virtual_hook in, say, libkdepim if it doesn't guarantee BC... -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From apoenitz at t-online.de Sun Nov 20 12:53:11 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Sun, 20 Nov 2016 12:53:11 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <201611182037.26392.marc.mutz@kdab.com> References: <3180741.cRJAskENCj@tjmaciei-mobl1> <05EB4094-933F-4B45-AFA2-A389F978E275@qt.io> <201611182037.26392.marc.mutz@kdab.com> Message-ID: <20161120115311.GA1482@klara.mpi.htwm.de> On Fri, Nov 18, 2016 at 08:37:26PM +0100, Marc Mutz wrote: > There's no reason for Qt to extend its BC guarantees to other libraries. STL, > GSL, Boost, std::exception, you name it. They are outside of Qt's realm and > therefore do not fall under the Qt BC rules. As with every other C++ library: > if a user wants BC, it's his job to pin libs without BC guarantees to a fixed > version. Not Qts. If Qt *requires* a dependency that does not care about BC and leaks it into its interface, this effectively voids the value of Qt's current BC promise for the user, as, as you correctly stated, the burden of taking care of dependencies is now shifted to the sholders of a user caring for BC. Now we can discuss how much of a total loss of value of Qt that would be. My personal guess on a first approximation is "zero, because nobody is really affected". Typical users of Qt are: - people using Qt in a restricted environment that ship their application themselves, bundled with everything they use (read "Windows", or "certified environment", or "devices") They are not affected by BC breakages. If they need to update stuff they go from one blob to another blob, the only difference Qt BC in that scenario might be is the size of the delta blob. - people using Qt in applications distributed by packaging systems (read "Linux distributions"). They are not affected by BC breakages. - people providing packaging systems. They *are* affected. But since they already take care of a lot of other dependencies not caring for BC, Qt being on one side of the fence or the other does not make a fundamental difference. So: If you want to argue that using GSL, and std::exception would be beneficial for Qt, you might want to start with making a point about the value of the current BC promise. Andre' From apoenitz at t-online.de Sun Nov 20 13:32:34 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Sun, 20 Nov 2016 13:32:34 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: Message-ID: <20161120123234.GA1675@klara.mpi.htwm.de> On Sat, Nov 19, 2016 at 10:44:19PM +0100, Giuseppe D'Angelo wrote: > On Wed, Nov 16, 2016 at 6:11 PM, Marco Bubke wrote: > I'm terribly sad that this thread has been derailed in an unrelated > discussion. Asking about Creator and BC on @dev was a perfect attempt at trolling as far as I can tell. > Please, could we all *stop* doing that and let's discuss that (*extremely > important*) matter on another thread. > > Staying on track: I would love to see (again) Creator as a playground for > how well the GSL can be integrated into a Qt project. For me it still is one of the main reasons to have Qt Creator at all, and I still think it serves this purpose well in practice. For the concrete matter of owner I *personally* see not much a reason to have it, as for some reason I seemingly rarely ever run into those unclear ownerships of naked T* and consequently don't understand where all this hatred comes from. But then, owner is as non-intrusive as it gets, and since I have a couple of '// owned' or '// not owned' comments in my code it looks like having that compiler-checkable would actually make sense. So I would not oppose using owner in Creator code. Andre' From madigens at gmail.com Sun Nov 20 14:50:38 2016 From: madigens at gmail.com (Nikolaus Waxweiler) Date: Sun, 20 Nov 2016 14:50:38 +0100 Subject: [Development] Font rendering on X11/Wayland: New FreeType API to toggle LCD filters and stem darkening on a per-font basis, would love a review In-Reply-To: <201611191429.54730.kde@carewolf.com> References: <616401a8-5e41-bf4b-e5eb-a4deed27ff6c@gmail.com> <201611181740.25658.allan.jensen@qt.io> <64346f09-41b2-d1e4-5ceb-70926249102b@gmail.com> <201611191429.54730.kde@carewolf.com> Message-ID: > Anyway, on the API front. Forcing to autohinter is probably not acceptable. So > we could enable stem darkening where native available, but then we need to > know if what engine a face is using, or better yet specifically if the engine > used right now on this face did stem darkening. I was just thinking. Can Qt mix font rendering modes on a face-by-face basis? Even without FT_Face_Option(), you can query the font driver for a face and the autohinter for stem darkening as described in [1]. If FT_Property_Get returns an error for the property, the driver has no means of darkening stems at all. Note that this is a font driver/autohinter wide setting, affecting all faces that pass through them. So, how about something like this: for each face that should be rendered, first query the driver (or the autohinter if it's to be used) if it supports stem darkening. If so, turn it on while rendering the face and use linear alpha blending and gamma correction (maybe with a factor of 1.8 like Adobe recommends). If there is no stem darkening support, blend naively. Or: also blend correctly, but use a lower gamma correction factor (e.g. 1.4 like GDI uses iirc). As it stands, this would only enable correct rendering for .otf and if the autohinter is involved. Support for more font drivers could then be done from within FreeType without source modifications in Qt. [1]: https://www.freetype.org/freetype2/docs/reference/ft2-cff_driver.html#no-stem-darkening(cff) -- Use FT_Property_Get instead, obviously. From kde at carewolf.com Sun Nov 20 18:38:04 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Sun, 20 Nov 2016 18:38:04 +0100 Subject: [Development] Font rendering on X11/Wayland: New FreeType API to toggle LCD filters and stem darkening on a per-font basis, would love a review In-Reply-To: References: <616401a8-5e41-bf4b-e5eb-a4deed27ff6c@gmail.com> <201611191429.54730.kde@carewolf.com> Message-ID: <201611201838.04296.kde@carewolf.com> On Sunday 20 November 2016, Nikolaus Waxweiler wrote: > > Anyway, on the API front. Forcing to autohinter is probably not > > acceptable. So we could enable stem darkening where native available, > > but then we need to know if what engine a face is using, or better yet > > specifically if the engine used right now on this face did stem > > darkening. > > I was just thinking. Can Qt mix font rendering modes on a face-by-face > basis? Even without FT_Face_Option(), you can query the font driver for > a face and the autohinter for stem darkening as described in [1]. If > FT_Property_Get returns an error for the property, the driver has no > means of darkening stems at all. Note that this is a font > driver/autohinter wide setting, affecting all faces that pass through them. > > So, how about something like this: for each face that should be > rendered, first query the driver (or the autohinter if it's to be used) > if it supports stem darkening. If so, turn it on while rendering the > face and use linear alpha blending and gamma correction (maybe with a > factor of 1.8 like Adobe recommends). If there is no stem darkening > support, blend naively. Qt can't do that right now, right now it can only be controlled all or nothing by QPA platform or font-engine, but controlling it on a face-by-face basis was exactly the possible solution I was considering, but it requires exposing the data from the face-specific QFontEngine class to the drawing back-end. At least for the rasterizing engine. The whole thing first needs some cleanup in 5.9 though, it has been adjusted a bit too much for separate platforms to match native text rendering, and is not very consistent or elegant at the moment. `Allan From thiago.macieira at intel.com Sun Nov 20 18:53:45 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 20 Nov 2016 09:53:45 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <201611200833.23979.marc.mutz@kdab.com> References: <2464166.EJcljRpKSs@tjmaciei-mobl1> <201611200833.23979.marc.mutz@kdab.com> Message-ID: <1607127.41cskLAHSs@tjmaciei-mobl1> Em domingo, 20 de novembro de 2016, às 08:33:23 PST, Marc Mutz escreveu: > > Those parts of KDE don't keep BC guarantees. Distros have to rebuild > > everything when their dependencies change. > > I wonder why we used d-pointers and virtual_hook in, say, libkdepim if it > doesn't guarantee BC... There's a difference between breaking BC when Boost is upgraded and in every single patch release and even applied bugfix patch. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Sun Nov 20 19:49:09 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sun, 20 Nov 2016 19:49:09 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <20161120115311.GA1482@klara.mpi.htwm.de> References: <201611182037.26392.marc.mutz@kdab.com> <20161120115311.GA1482@klara.mpi.htwm.de> Message-ID: <201611201949.10069.marc.mutz@kdab.com> On Sunday 20 November 2016 12:53:11 André Pönitz wrote: > So: If you want to argue that using GSL, and std::exception > would be beneficial for Qt, you might want to start with > making a point about the value of the current BC promise. Right. I wasn't going to attack the BC promise on such a fundamental level, but I agree that its value is limited in a world where not even the compiler vendors can agree on a platform's C++ ABI. I just intended to indicate that with 5.0, when we dropped QT_NO_STL, but failed to take advantage of the STL containers, with 5.2, when Q_STRINGTABLE missed to be merged because it dared to use Boost (which Qt3D freely uses, now, in something called "assimp"), and now with the GSL, which promises much stronger statig type-checking because the new vocabulary types can be used to decalre intend much better, ... With each of these, and probably more, the pendulum swings more into the direction of more harm than good for Qt as a project. As a consequence, I'm advocating at least reverting the BC guarantees to their old meaning of "two versions of Qt are BC if, for a given platform, compiler, and set of dependencies, one Qt compiled against these can be replaced by the other without breaking code compiled against the former". There are so many knobs to turn that make two C++ compilates binary incompatible, from ms-compatible bitfields, fortran-compatible double alignment, to compiler and standard library versions, that for any library to try to draw through that messy jungle a line labelled "this is where Qt BC begins" is just a logically nonsensical endeavour. Sometimes, it's just better to compile separate library versions. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Sun Nov 20 19:54:58 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 20 Nov 2016 10:54:58 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <201611201949.10069.marc.mutz@kdab.com> References: <20161120115311.GA1482@klara.mpi.htwm.de> <201611201949.10069.marc.mutz@kdab.com> Message-ID: <2317884.nrKlijQ8fV@tjmaciei-mobl1> Em domingo, 20 de novembro de 2016, às 19:49:09 PST, Marc Mutz escreveu: > which Qt3D freely uses, > now, in something called "assimp" You mean the worst offender of warnings and code quality issues inside Qt? Sorry, that's not a good example and doesn't support your cause. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From dangelog at gmail.com Sun Nov 20 20:29:01 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Sun, 20 Nov 2016 20:29:01 +0100 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <3672068.6VsPie5nrh@tjmaciei-mobl1> References: <5a2ab55b-80c2-c606-83c1-335e7c7e1d49@familiesomers.nl> <3672068.6VsPie5nrh@tjmaciei-mobl1> Message-ID: On Tue, Sep 20, 2016 at 9:27 AM, Thiago Macieira wrote: > > Can you remember the list of C++11 features we're allowed to use? We had a > discussion on the mailing list. Going back to this particular point: so should this list go into the QUIPs repository, or in qtbase? (The idea of putting it in qtbase was to re-use the same branching scheme, so for a given branch you can know which features you are allowed to use). Thanks, -- Giuseppe D'Angelo From dangelog at gmail.com Sun Nov 20 20:38:50 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Sun, 20 Nov 2016 20:38:50 +0100 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <20161110112912.GB9877@troll08> References: <20161108101458.GD22297@troll08> <20161109150119.GD12761@troll08> <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> <20161110112912.GB9877@troll08> Message-ID: On Thu, Nov 10, 2016 at 12:29 PM, Oswald Buddenhagen wrote: > the repository has been created. I would also like to point out that, despite we have a repository, we still don't have a tool for properly discussing the actual content of QUIPs. * Gerrit does not work because comments cannot be threaded, they don't stick to multiple reviews, and they can be ignored * Email does not work (it may work for the overall direction, but not for the in depth discussion) because a single message may cover multiple discussion points, disrupting the threading, and discussion points can get ignored (*) Any idea to how to actually make this work? Try reviewboard maybe? My 2 cents, -- Giuseppe D'Angelo (*) This still happens all the time. User A proposes something; user B replies with "I don't think it works in scenarios X, Y, Z"; user A counter-replies "but Z is not a scenario we consider" and the discussion derails about Z. Noone talks about X and Y, which instead *must* be talked about, for the proposal to be accepted. We need something that makes it impossible to ignore the comment about X and Y. From Marco.Bubke at qt.io Sun Nov 20 21:13:49 2016 From: Marco.Bubke at qt.io (Marco Bubke) Date: Sun, 20 Nov 2016 20:13:49 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: <20161108101458.GD22297@troll08> <20161109150119.GD12761@troll08> <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> <20161110112912.GB9877@troll08> Message-ID: On November 20, 2016 20:39:08 Giuseppe D'Angelo wrote: > On Thu, Nov 10, 2016 at 12:29 PM, Oswald Buddenhagen > wrote: >> the repository has been created. > > I would also like to point out that, despite we have a repository, we > still don't have a tool for properly discussing the actual content of > QUIPs. > > * Gerrit does not work because comments cannot be threaded, they don't > stick to multiple reviews, and they can be ignored > * Email does not work (it may work for the overall direction, but not > for the in depth discussion) because a single message may cover > multiple discussion points, disrupting the threading, and discussion > points can get ignored (*) > > Any idea to how to actually make this work? Try reviewboard maybe? > > My 2 cents, > -- > Giuseppe D'Angelo > > > (*) This still happens all the time. User A proposes something; user B > replies with "I don't think it works in scenarios X, Y, Z"; user A > counter-replies "but Z is not a scenario we consider" and the > discussion derails about Z. Noone talks about X and Y, which instead > *must* be talked about, for the proposal to be accepted. We need > something that makes it impossible to ignore the comment about X and > Y. Do you think about a wiki where you can comment? I think you want something with the capability to describe, comment, argument and poll with a version history. Like you described email is a terrible tool for it. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From philwave at gmail.com Sun Nov 20 23:20:11 2016 From: philwave at gmail.com (Philippe) Date: Sun, 20 Nov 2016 23:20:11 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <201611201949.10069.marc.mutz@kdab.com> References: <20161120115311.GA1482@klara.mpi.htwm.de> <201611201949.10069.marc.mutz@kdab.com> Message-ID: <20161120232010.4E00.6F0322A@gmail.com> On Sun, 20 Nov 2016 19:49:09 +0100 Marc Mutz wrote: > I just intended to indicate that with 5.0, when we dropped QT_NO_STL, but > failed to take advantage of the STL containers, ...good that STL containers were not used... Look at _this month_ Visual Studio 2017 announcement: <<<< std::vector has been overhauled for correctness and performance: aliasing during insertion/emplacement is now correctly handled as required by the Standard, the strong exception guarantee is now provided when required by the Standard via move_if_noexcept() and other logic, and insertion/emplacement perform fewer element operations. (https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes) >>>> Being the "standard library" does not mean "bug free and equal on all platforms". Dependencies with other libraries must be careful checked. Philippe From dangelog at gmail.com Sun Nov 20 23:33:51 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Sun, 20 Nov 2016 23:33:51 +0100 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: <20161108101458.GD22297@troll08> <20161109150119.GD12761@troll08> <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> <20161110112912.GB9877@troll08> Message-ID: On Sun, Nov 20, 2016 at 9:13 PM, Marco Bubke wrote: > Do you think about a wiki where you can comment? I think you want something with the capability to describe, comment, argument and poll with a version history. Like you described email is a terrible tool for it. If a wiki allows for all of this, then sure, let's use a wiki. Does MediaWiki support these features? I've got the impression that discussion pages are totally independent from the "main" page. The threading must be somehow manually managed and I don't think there's a way to mark some argumentative point as "this requires a resolution". (Maybe the right tool does not exist, but we'll need to settle for using an existing one "in the right way") Cheers, -- Giuseppe D'Angelo From marc.mutz at kdab.com Mon Nov 21 09:04:59 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 21 Nov 2016 09:04:59 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <20161120232010.4E00.6F0322A@gmail.com> References: <20161120115311.GA1482@klara.mpi.htwm.de> <201611201949.10069.marc.mutz@kdab.com> <20161120232010.4E00.6F0322A@gmail.com> Message-ID: <201611210904.59824.marc.mutz@kdab.com> On Sunday 20 November 2016 23:20:11 Philippe wrote: > On Sun, 20 Nov 2016 19:49:09 +0100 > > Marc Mutz wrote: > > I just intended to indicate that with 5.0, when we dropped QT_NO_STL, but > > failed to take advantage of the STL containers, > > ...good that STL containers were not used... Look at _this month_ Visual > Studio 2017 announcement: > > <<<< > std::vector has been overhauled for correctness and performance: aliasing > during insertion/emplacement is now correctly handled as required by the > Standard, the strong exception guarantee is now provided when required by > the Standard via move_if_noexcept() and other logic, and > insertion/emplacement perform fewer element operations. > (https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes) > > > Being the "standard library" does not mean "bug free and equal on all > platforms". Dependencies with other libraries must be careful checked. And you think Qt provides what MS added to std::vector here, in QVector? -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From philwave at gmail.com Mon Nov 21 09:37:38 2016 From: philwave at gmail.com (Philippe) Date: Mon, 21 Nov 2016 09:37:38 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <201611210904.59824.marc.mutz@kdab.com> References: <20161120232010.4E00.6F0322A@gmail.com> <201611210904.59824.marc.mutz@kdab.com> Message-ID: <20161121093736.7370.6F0322A@gmail.com> > And you think Qt provides what MS added to std::vector here, in QVector? Of course not. I just point the danger of dependencies on the usage of STL APIs, especially corner APIs. I understand the #1 target of Qt is to behave the same on all platforms (as much as possible...). This is what users expects, at least. Philippe On Mon, 21 Nov 2016 09:04:59 +0100 Marc Mutz wrote: > On Sunday 20 November 2016 23:20:11 Philippe wrote: > > On Sun, 20 Nov 2016 19:49:09 +0100 > > > > Marc Mutz wrote: > > > I just intended to indicate that with 5.0, when we dropped QT_NO_STL, but > > > failed to take advantage of the STL containers, > > > > ...good that STL containers were not used... Look at _this month_ Visual > > Studio 2017 announcement: > > > > <<<< > > std::vector has been overhauled for correctness and performance: aliasing > > during insertion/emplacement is now correctly handled as required by the > > Standard, the strong exception guarantee is now provided when required by > > the Standard via move_if_noexcept() and other logic, and > > insertion/emplacement perform fewer element operations. > > (https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes) > > > > > > Being the "standard library" does not mean "bug free and equal on all > > platforms". Dependencies with other libraries must be careful checked. > > And you think Qt provides what MS added to std::vector here, in QVector? > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Mon Nov 21 10:15:24 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 21 Nov 2016 10:15:24 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <20161121093736.7370.6F0322A@gmail.com> References: <20161120232010.4E00.6F0322A@gmail.com> <201611210904.59824.marc.mutz@kdab.com> <20161121093736.7370.6F0322A@gmail.com> Message-ID: <201611211015.24533.marc.mutz@kdab.com> On Monday 21 November 2016 09:37:38 Philippe wrote: > > And you think Qt provides what MS added to std::vector here, in QVector? > > Of course not. I just point the danger of dependencies on the usage of STL > APIs, especially corner APIs. > > I understand the #1 target of Qt is to behave the same on all platforms > (as much as possible...). This is what users expects, at least. These fixes mostly sound like they were enabled by - finally - implementing missing core C++11 features. We know we can't rely on MS to provide all C++11 features atm, so we know not to rely on std::vector using std::move_if_noexcept, e.g., too. The aliasing thing, though, sounds like a genuine bug, and GCC's nth_element was buggy for some time, too. OTOH, QList does not at all behave the same on different platforms, either, in a much more fundamental way than any std::vector behaviour differs between platforms these days. People make mistakes. The difference is that, in the STL, by way of a larger target audience, mistakes tend to be fewer than in Qt (looked at qtimageformats, lately?), and more easily fixed, because of largely no BC support, so it seems a bit skewed to throw one such STL bug on the table as an argument not to use the STL. If Qt consistently did a better job at implementing such things, the world might be different. But looking at the Qt containers, and the Qt image format plugins, I'd much rather use an external library (STL, lib{jpeg,png,tiff,...) that everyone else also uses, than to reinvent the wheel and create bugs exclusive to Qt. Thanks, Marc > Philippe > > On Mon, 21 Nov 2016 09:04:59 +0100 > > Marc Mutz wrote: > > On Sunday 20 November 2016 23:20:11 Philippe wrote: > > > On Sun, 20 Nov 2016 19:49:09 +0100 > > > > > > Marc Mutz wrote: > > > > I just intended to indicate that with 5.0, when we dropped QT_NO_STL, > > > > but failed to take advantage of the STL containers, > > > > > > ...good that STL containers were not used... Look at _this month_ > > > Visual Studio 2017 announcement: > > > > > > <<<< > > > std::vector has been overhauled for correctness and performance: > > > aliasing during insertion/emplacement is now correctly handled as > > > required by the Standard, the strong exception guarantee is now > > > provided when required by the Standard via move_if_noexcept() and > > > other logic, and > > > insertion/emplacement perform fewer element operations. > > > (https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes) > > > > > > > > > Being the "standard library" does not mean "bug free and equal on all > > > platforms". Dependencies with other libraries must be careful checked. > > > > And you think Qt provides what MS added to std::vector here, in QVector? > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Mon Nov 21 10:47:52 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 21 Nov 2016 10:47:52 +0100 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: <3672068.6VsPie5nrh@tjmaciei-mobl1> Message-ID: <201611211047.53089.marc.mutz@kdab.com> On Sunday 20 November 2016 20:29:01 Giuseppe D'Angelo wrote: > On Tue, Sep 20, 2016 at 9:27 AM, Thiago Macieira > > wrote: > > Can you remember the list of C++11 features we're allowed to use? We had > > a discussion on the mailing list. > > Going back to this particular point: so should this list go into the > QUIPs repository, or in qtbase? (The idea of putting it in qtbase was > to re-use the same branching scheme, so for a given branch you can > know which features you are allowed to use). IMHO, we need a QUIP that says where in each Qt module such a file should be located, what its format is, what the process is to update it, whether it should be machine-readable (read: run from configure checks), etc. Neither the wiki, nor the QUIP itself is the place to put the actual lists. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From edward.welbourne at qt.io Mon Nov 21 12:06:52 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 21 Nov 2016 11:06:52 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: <20161108101458.GD22297@troll08> <20161109150119.GD12761@troll08> <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> <20161110112912.GB9877@troll08> , Message-ID: Giuseppe D'Angelo: >> I would also like to point out that, despite we have a repository, we >> still don't have a tool for properly discussing the actual content of >> QUIPs. >> >> * Gerrit does not work because comments cannot be threaded, they >> don't stick to multiple reviews, and they can be ignored >> * Email does not work (it may work for the overall direction, but not >> for the in depth discussion) because a single message may cover >> multiple discussion points, disrupting the threading, and >> discussion points can get ignored (*) All of which plays into my desire to introduce you all to Critic [0], a code-review tool my former colleague Jens wrote at Opera. It knows how to carry comments forward from one patch set to another, even through rebases (within limits), it knows the range of lines a comment relates to, it distinguishes issues (which must be resolved) from comments (which can be discussed). Discussions on a particular issue are linear - i.e. forking off side-threads to separately discuss different parts of a comment or follow-up would need to be implemented. It handles whole branches, making it possible to review a set of related changes together; the reviewer can chose whether to review all changes to a file together or each commit's changes separately; it helps keep track of what you have reviewed so that you can tell when you're done. [0] https://github.com/jensl/critic I would dearly love to replace Gerrit with it - I realise that's hoping for too much - but, for a new repository on which Gerrit isn't adequate, maybe we could consider it ... Eddy. From oswald.buddenhagen at qt.io Mon Nov 21 12:58:31 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 21 Nov 2016 12:58:31 +0100 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: <20161108101458.GD22297@troll08> <20161109150119.GD12761@troll08> <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> <20161110112912.GB9877@troll08> Message-ID: <20161121115831.GC22079@troll08> On Sun, Nov 20, 2016 at 08:38:50PM +0100, Giuseppe D'Angelo wrote: > On Thu, Nov 10, 2016 at 12:29 PM, Oswald Buddenhagen wrote: > > the repository has been created. > > I would also like to point out that, despite we have a repository, we > still don't have a tool for properly discussing the actual content of > QUIPs. > > * Gerrit does not work because comments cannot be threaded, > when you use inline comments, the locality is good enough to make threading generally unnecessary. > they don't stick to multiple reviews, > this is true, but becomes a real problem only if the change owner doesn't bother handling all comments before pushing new changesets. > and they can be ignored > that's correct, and having real issue tracking would be advantageous (which gerrit upstream knows very well). otoh, it's the responsibility of the reviewers and the submitter (a role we have intentionally restricted in this repo, mind you) to verify that all comments have been (actually) acted upon. > Any idea to how to actually make this work? > how about taking the existing processes seriously and exercising social pressure on those who think they are above them? From dangelog at gmail.com Mon Nov 21 13:26:15 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Mon, 21 Nov 2016 13:26:15 +0100 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <20161121115831.GC22079@troll08> References: <20161108101458.GD22297@troll08> <20161109150119.GD12761@troll08> <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> <20161110112912.GB9877@troll08> <20161121115831.GC22079@troll08> Message-ID: On Mon, Nov 21, 2016 at 12:58 PM, Oswald Buddenhagen wrote: >> Any idea to how to actually make this work? >> > how about taking the existing processes seriously and exercising social > pressure on those who think they are above them? May I just say that prefer a tool that mandates a workflow over using political and social pressures, which in the long term hurt the project? Cheers, -- Giuseppe D'Angelo From annulen at yandex.ru Mon Nov 21 13:29:01 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 21 Nov 2016 15:29:01 +0300 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: <20161108101458.GD22297@troll08> <20161109150119.GD12761@troll08> <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> <20161110112912.GB9877@troll08> <20161121115831.GC22079@troll08> Message-ID: <2077421479731341@web9g.yandex.ru> 21.11.2016, 15:26, "Giuseppe D'Angelo" : > On Mon, Nov 21, 2016 at 12:58 PM, Oswald Buddenhagen > wrote: >>>  Any idea to how to actually make this work? >>  how about taking the existing processes seriously and exercising social >>  pressure on those who think they are above them? > > May I just say that prefer a tool that mandates a workflow over using > political and social pressures, which in the long term hurt the > project? Well, tools cannot help with social issues, and ignoring review comments is more like the latter. -- Regards, Konstantin From Marco.Bubke at qt.io Mon Nov 21 13:37:50 2016 From: Marco.Bubke at qt.io (Marco Bubke) Date: Mon, 21 Nov 2016 12:37:50 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <20161121115831.GC22079@troll08> References: <20161108101458.GD22297@troll08> <20161109150119.GD12761@troll08> <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> <20161110112912.GB9877@troll08> <20161121115831.GC22079@troll08> Message-ID: On November 21, 2016 12:58:59 Oswald Buddenhagen wrote: > On Sun, Nov 20, 2016 at 08:38:50PM +0100, Giuseppe D'Angelo wrote: >> On Thu, Nov 10, 2016 at 12:29 PM, Oswald Buddenhagen wrote: >> > the repository has been created. >> >> I would also like to point out that, despite we have a repository, we >> still don't have a tool for properly discussing the actual content of >> QUIPs. >> >> * Gerrit does not work because comments cannot be threaded, >> > when you use inline comments, the locality is good enough to > make threading generally unnecessary. > >> they don't stick to multiple reviews, >> > this is true, but becomes a real problem only if the change owner > doesn't bother handling all comments before pushing new changesets. > >> and they can be ignored >> > that's correct, and having real issue tracking would be advantageous > (which gerrit upstream knows very well). > otoh, it's the responsibility of the reviewers and the submitter (a role > we have intentionally restricted in this repo, mind you) to verify that > all comments have been (actually) acted upon. > >> Any idea to how to actually make this work? >> > how about taking the existing processes seriously and exercising social > pressure on those who think they are above them? Sorry, not everybody likes to use social pressure (mobbing). And could it be that the outcome of the argumentation is be quite different of what we would describe as good in the long run. My impression is generally that many smart people don't like too spend their time for that games. But people who thinks that their arguments are smarter think that they deserve to be chosen. Or let our describe it that way, the rationality of people is quite limited and you need a good framework to get a better outcome. You can easily derail cooperation with a dysfunctional framework. Is shown in many experiments and believe me, we are not different. Actually people who working in IT have more trouble because they often describe the world not as contingent but as based on a all-time, universal fundament (truth). So it's hard to compromise because that would be deviate from truth. If the discussion is based on experience it is actually quite positive to compromise because all arguments together give a bigger picture, based on much more experience. So the truth based world description leds to few 'specialists' discuss that matter but the latter is a cooperation of all people with experience about that matter. Neither is guaranteed to succeed but if you get the last in a cooperative mode you have a good chance. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From kde at carewolf.com Mon Nov 21 13:40:48 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Mon, 21 Nov 2016 13:40:48 +0100 Subject: [Development] Font rendering on X11/Wayland: New FreeType API to toggle LCD filters and stem darkening on a per-font basis, would love a review In-Reply-To: <201611201838.04296.kde@carewolf.com> References: <616401a8-5e41-bf4b-e5eb-a4deed27ff6c@gmail.com> <201611201838.04296.kde@carewolf.com> Message-ID: <201611211340.48516.kde@carewolf.com> Here is a proof of concept: https://codereview.qt-project.org/#/c/177325/ Note, we need a FreeType API for getting to the module-name from the face, or a direct getter of the stem-darkening on the face. Best regards `Allan From oswald.buddenhagen at qt.io Mon Nov 21 13:50:43 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 21 Nov 2016 13:50:43 +0100 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: <20161109150119.GD12761@troll08> <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> <20161110112912.GB9877@troll08> <20161121115831.GC22079@troll08> Message-ID: <20161121125043.GF22079@troll08> On Mon, Nov 21, 2016 at 01:37:50PM +0100, Marco Bubke wrote: > On November 21, 2016 12:58:59 Oswald Buddenhagen wrote: > > how about taking the existing processes seriously and exercising social > > pressure on those who think they are above them? > > Sorry, not everybody likes to use social pressure (mobbing). > the thing is that there there is no tooling which is absolutely foolproof. people will always come up with creative ways to circumvent it, and the only way to deal with that is showing them that doing so is not acceptable. it's a bit of a stretch to call that mobbing, and i gladly laugh it off when it happens. From Marco.Bubke at qt.io Mon Nov 21 14:19:57 2016 From: Marco.Bubke at qt.io (Marco Bubke) Date: Mon, 21 Nov 2016 13:19:57 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <20161121125043.GF22079@troll08> References: <20161109150119.GD12761@troll08> <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> <20161110112912.GB9877@troll08> <20161121115831.GC22079@troll08> <20161121125043.GF22079@troll08> Message-ID: On November 21, 2016 13:51:10 Oswald Buddenhagen wrote: > On Mon, Nov 21, 2016 at 01:37:50PM +0100, Marco Bubke wrote: >> On November 21, 2016 12:58:59 Oswald Buddenhagen wrote: >> > how about taking the existing processes seriously and exercising social >> > pressure on those who think they are above them? >> >> Sorry, not everybody likes to use social pressure (mobbing). >> > the thing is that there there is no tooling which is absolutely > foolproof. people will always come up with creative ways to > circumvent it, and the only way to deal with that is showing them that > doing so is not acceptable. it's a bit of a stretch to call that > mobbing, and i gladly laugh it off when it happens. But you see that a tool who makes it easy to snippet on some argument is maybe more suboptimal than other. It's not about using the perfect tool but using one which is better. Ones that sets 'loud' people at a disadvantage. And it's not only the tool, it's the culture too. A culture which is appreciating new arguments and not loves to repeat arguments again and again, especially to hide some private agenda. If an argumentation is more about individual agendas and less about the common good it is doomed. Especially if people try to sell the first as last. The tool should help to make that transparent but it is only one building stone. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Shawn.Rutledge at qt.io Mon Nov 21 14:28:50 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Mon, 21 Nov 2016 13:28:50 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: <20161108101458.GD22297@troll08> <20161109150119.GD12761@troll08> <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> <20161110112912.GB9877@troll08> Message-ID: <7F11C4CA-9AF2-4552-AD42-96547562EC87@qt.io> > On 21 Nov 2016, at 12:06, Edward Welbourne wrote: > > Giuseppe D'Angelo: >>> I would also like to point out that, despite we have a repository, we >>> still don't have a tool for properly discussing the actual content of >>> QUIPs. >>> >>> * Gerrit does not work because comments cannot be threaded, they >>> don't stick to multiple reviews, and they can be ignored > > [0] https://github.com/jensl/critic > > I would dearly love to replace Gerrit with it - I realise that's hoping > for too much - but, for a new repository on which Gerrit isn't adequate, > maybe we could consider it … Maybe it’s worth a try. But someone has to install it on a server so that we can try it, right? Is that easy enough? From Marco.Bubke at qt.io Mon Nov 21 14:31:47 2016 From: Marco.Bubke at qt.io (Marco Bubke) Date: Mon, 21 Nov 2016 13:31:47 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <7F11C4CA-9AF2-4552-AD42-96547562EC87@qt.io> References: <20161108101458.GD22297@troll08> <20161109150119.GD12761@troll08> <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> <20161110112912.GB9877@troll08> <7F11C4CA-9AF2-4552-AD42-96547562EC87@qt.io> Message-ID: On November 21, 2016 14:29:10 Shawn Rutledge wrote: > >> On 21 Nov 2016, at 12:06, Edward Welbourne wrote: >> >> Giuseppe D'Angelo: >>>> I would also like to point out that, despite we have a repository, we >>>> still don't have a tool for properly discussing the actual content of >>>> QUIPs. >>>> >>>> * Gerrit does not work because comments cannot be threaded, they >>>> don't stick to multiple reviews, and they can be ignored >> >> [0] https://github.com/jensl/critic >> >> I would dearly love to replace Gerrit with it - I realise that's hoping >> for too much - but, for a new repository on which Gerrit isn't adequate, >> maybe we could consider it … > > Maybe it’s worth a try. But someone has to install it on a server so that we can try it, right? Is that easy enough? Yes, some server for evaluation would be nice. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Mon Nov 21 14:50:04 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 21 Nov 2016 13:50:04 +0000 Subject: [Development] HEADS-UP: Branching from '5.8' to '5.8.0' started Message-ID: Hi, We have started branching from '5.8' to '5.8.0'. Please start using '5.8.0' for new changes targeted to Qt 5.8.0 release. There should be enough time to finalize ongoing changes in '5.8'; final downmerge will happen Monday 28th November. br, Jani From madigens at gmail.com Mon Nov 21 16:27:25 2016 From: madigens at gmail.com (Nikolaus Waxweiler) Date: Mon, 21 Nov 2016 16:27:25 +0100 Subject: [Development] Font rendering on X11/Wayland: New FreeType API to toggle LCD filters and stem darkening on a per-font basis, would love a review In-Reply-To: <201611211340.48516.kde@carewolf.com> References: <616401a8-5e41-bf4b-e5eb-a4deed27ff6c@gmail.com> <201611201838.04296.kde@carewolf.com> <201611211340.48516.kde@carewolf.com> Message-ID: > Here is a proof of concept: https://codereview.qt-project.org/#/c/177325/ Oh nice, didn't expect something so soon. Will have a look. > Note, we need a FreeType API for getting to the module-name from the face, or > a direct getter of the stem-darkening on the face. Ah, hm. I only know of a way from within the FT source. Will get back to you. From perezmeyer at gmail.com Mon Nov 21 19:49:49 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Mon, 21 Nov 2016 15:49:49 -0300 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <20161120115311.GA1482@klara.mpi.htwm.de> References: <201611182037.26392.marc.mutz@kdab.com> <20161120115311.GA1482@klara.mpi.htwm.de> Message-ID: <19998848.gqzZj1taFC@tonks> On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote: [snip] > - people using Qt in applications distributed by packaging > systems (read "Linux distributions"). They are not affected > by BC breakages. Users might not notice if we maintainers have to deal with this nightmare. If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt lib break ABI we need to get Qt rebuilt and *everything* building against it. That's the worth nightmare we distro maintainers can dream on. And yes, we would need to adjust Qt's SONAME on each change. -- Yo quiero conocer el pensamiento de Dios, el resto son detalles. Albert Einstein Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From apoenitz at t-online.de Mon Nov 21 21:11:44 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Mon, 21 Nov 2016 21:11:44 +0100 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: <20161109150119.GD12761@troll08> <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> <20161110112912.GB9877@troll08> Message-ID: <20161121201144.GA1681@klara.mpi.htwm.de> On Mon, Nov 21, 2016 at 11:06:52AM +0000, Edward Welbourne wrote: > Giuseppe D'Angelo: > >> I would also like to point out that, despite we have a repository, we > >> still don't have a tool for properly discussing the actual content of > >> QUIPs. > >> > >> * Gerrit does not work because comments cannot be threaded, they > >> don't stick to multiple reviews, and they can be ignored > >> * Email does not work (it may work for the overall direction, but not > >> for the in depth discussion) because a single message may cover > >> multiple discussion points, disrupting the threading, and > >> discussion points can get ignored (*) > > All of which plays into my desire to introduce you all to Critic [0] Guys, the idea of QUIPs was to *fix* a problem, namely the current inability to pinpoint results of mailing list discussion. This *is* a problem for the Project, as lazy consensus on the mailing list is *the* official decision making process in the Qt Governance model, but it works in practice rather accidentally, if at all. Discussions are observed to deteriorate, develop into completely unrelated discussions, and even if something appears like consensus or the discussion dies, it typically turns out that different people think differently about what the consensus actually was, and the discussion re-starts half a year later. You both nicely demonstrate that this problem exist, thank you for that, but beyond that this particular sub-discussion misses the point. QUIPs were not meant to require new or different tooling, and I still believe such will be needed. The rough idea is that a topic is presented as usual on the mailing list, and when someone, usually the original proponent, gets the feeling that the usual rounds of bike-shedding, trolling and name-calling is over, and the occasional sensible arguments all have been heard, writes up what appears like a potential consensus and puts that on Gerrit, where some review process commences. The only difference to a normal review process I'd like to see would be a *much* higher bar for approval, to ensure that QUIPs are really close to consensus and to ensure some consistency within the set of QUIPs. None of this requires new tools, certainly not the bootstrapping of the first QUIP. There's also nothing changing processes, so everybody will be free to continue to present his views on his favourite tools in the future, but for now I'd really like to get this here done. IMNSHO it boils down to the question: Does anybody have any fundamental problem with main idea of having documents summarizing the lazy consensus of certain mailing list discussions? If not I'd call that a lazy consensus and would ask to proceed with reviewing the final wording on Gerrit. Andre' From apoenitz at t-online.de Mon Nov 21 21:32:48 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Mon, 21 Nov 2016 21:32:48 +0100 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <2077421479731341@web9g.yandex.ru> References: <20161109150119.GD12761@troll08> <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> <20161110112912.GB9877@troll08> <20161121115831.GC22079@troll08> <2077421479731341@web9g.yandex.ru> Message-ID: <20161121203248.GB1681@klara.mpi.htwm.de> On Mon, Nov 21, 2016 at 03:29:01PM +0300, Konstantin Tokarev wrote: > > > 21.11.2016, 15:26, "Giuseppe D'Angelo" : > > On Mon, Nov 21, 2016 at 12:58 PM, Oswald Buddenhagen > > wrote: > >>>  Any idea to how to actually make this work? > >>  how about taking the existing processes seriously and exercising social > >>  pressure on those who think they are above them? > > > > May I just say that prefer a tool that mandates a workflow over using > > political and social pressures, which in the long term hurt the > > project? > > Well, tools cannot help with social issues, and ignoring review comments is > more like the latter. Well, right, and wrong, kind of ;-) I think tools can help to *prevent* social issues. As example, I think it easier for people to accept a -1 from the Sanity Bot than to accept exactly the same comment from a human reviewer, specifically when it comes to arbitrary choices like prefering American over British spelling in comments. With the bot I usually just swallow and "fix" the issue, no matter how insane it appears to me. Sounds irrational? It is. It is human. Andre' From Marco.Bubke at qt.io Mon Nov 21 21:47:31 2016 From: Marco.Bubke at qt.io (Marco Bubke) Date: Mon, 21 Nov 2016 20:47:31 +0000 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <19998848.gqzZj1taFC@tonks> References: <201611182037.26392.marc.mutz@kdab.com> <20161120115311.GA1482@klara.mpi.htwm.de> <19998848.gqzZj1taFC@tonks> Message-ID: So how often do you had a BC break in stdlibc++? On November 21, 2016 19:50:23 Lisandro Damián Nicanor Pérez Meyer wrote: > On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote: > [snip] >> - people using Qt in applications distributed by packaging >> systems (read "Linux distributions"). They are not affected >> by BC breakages. > > Users might not notice if we maintainers have to deal with this nightmare. > > If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt lib break > ABI we need to get Qt rebuilt and *everything* building against it. That's the > worth nightmare we distro maintainers can dream on. And yes, we would need to > adjust Qt's SONAME on each change. > > -- > Yo quiero conocer el pensamiento de Dios, el resto son detalles. > Albert Einstein > > Lisandro Damián Nicanor Pérez Meyer > http://perezmeyer.com.ar/ > http://perezmeyer.blogspot.com/ From suy at badopi.org Mon Nov 21 21:57:19 2016 From: suy at badopi.org (Alejandro Exojo) Date: Mon, 21 Nov 2016 21:57:19 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: <52173FDB-219A-429A-A99D-216BAAB1E20E@bitshift-dynamics.de> Message-ID: <2066248.S2BLKDqRZ1@walt> On Saturday 19 November 2016 21:08:00 Kevin Kofler wrote: > I am glad that I am not alone with that feeling. > > And by the way, with my distribution packager hat on, I have to frown upon > the idea of dragging in yet another dependency just to enforce the C++ > language inventor's personal, not uncontroversial stylistic preferences. Have you seen the size of the GSL? I think I skimmed in one go through all the source code when it was published, and I did it while commuting, on a mobile phone. Maybe it's a tad larger now, but according to Mark's comment, stuff like owner could even be bundled/reimplemented. I'm almost always on the side that would not like Qt to change at all if it's to make it similar to the standard library API, but I've always had in the mental to-do list some patch to Qt that would annotate when ownership of QObjects is transferred ("I guess the QNetworkReply returned by QNAM::post has a parent, because the docs don't say it should be deleted... Or should be?"). I though that qdoc would be the tool for this (like we have \threadsafe) but stuff like owner<> and not_null<> are IMHO vastly superior. And at least they chose reasonable names for these. :) -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net From Marco.Bubke at qt.io Mon Nov 21 22:02:32 2016 From: Marco.Bubke at qt.io (Marco Bubke) Date: Mon, 21 Nov 2016 21:02:32 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <20161121201144.GA1681@klara.mpi.htwm.de> References: <20161109150119.GD12761@troll08> <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> <20161110112912.GB9877@troll08> <20161121201144.GA1681@klara.mpi.htwm.de> Message-ID: On November 21, 2016 20:02:54 André Pönitz wrote: > On Mon, Nov 21, 2016 at 11:06:52AM +0000, Edward Welbourne wrote: >> Giuseppe D'Angelo: >> >> I would also like to point out that, despite we have a repository, we >> >> still don't have a tool for properly discussing the actual content of >> >> QUIPs. >> >> >> >> * Gerrit does not work because comments cannot be threaded, they >> >> don't stick to multiple reviews, and they can be ignored >> >> * Email does not work (it may work for the overall direction, but not >> >> for the in depth discussion) because a single message may cover >> >> multiple discussion points, disrupting the threading, and >> >> discussion points can get ignored (*) >> >> All of which plays into my desire to introduce you all to Critic [0] > > Guys, > > the idea of QUIPs was to *fix* a problem, namely the current inability > to pinpoint results of mailing list discussion. This *is* a problem for > the Project, as lazy consensus on the mailing list is *the* official > decision making process in the Qt Governance model, but it works in > practice rather accidentally, if at all. > > Discussions are observed to deteriorate, develop into completely > unrelated discussions, and even if something appears like consensus or > the discussion dies, it typically turns out that different people think > differently about what the consensus actually was, and the discussion > re-starts half a year later. > > You both nicely demonstrate that this problem exist, thank you for that, > but beyond that this particular sub-discussion misses the point. > QUIPs were not meant to require new or different tooling, and I still > believe such will be needed. > > The rough idea is that a topic is presented as usual on the mailing > list, and when someone, usually the original proponent, gets the feeling > that the usual rounds of bike-shedding, trolling and name-calling is > over, and the occasional sensible arguments all have been heard, writes > up what appears like a potential consensus and puts that on Gerrit, > where some review process commences. > > The only difference to a normal review process I'd like to see would be > a *much* higher bar for approval, to ensure that QUIPs are really close > to consensus and to ensure some consistency within the set of QUIPs. > > None of this requires new tools, certainly not the bootstrapping of > the first QUIP. There's also nothing changing processes, so everybody > will be free to continue to present his views on his favourite tools > in the future, but for now I'd really like to get this here done. > > IMNSHO it boils down to the question: Does anybody have any fundamental > problem with main idea of having documents summarizing the lazy consensus > of certain mailing list discussions? If not I'd call that a lazy > consensus and would ask to proceed with reviewing the final wording > on Gerrit. > I think it's modeled after Python PEP and RFCs? Do we have a first QUIP who is describing the process? I think we should copy a successful model like https://www.python.org/dev/peps/pep-0001/ and don't try to be smarter. And yes, I don't think document a random email conversation is the answer. > Andre' > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From perezmeyer at gmail.com Mon Nov 21 23:36:43 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Mon, 21 Nov 2016 19:36:43 -0300 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: <19998848.gqzZj1taFC@tonks> Message-ID: <1696347.cJO6kkTjI8@tonks> On lunes, 21 de noviembre de 2016 20:47:31 ART Marco Bubke wrote: > So how often do you had a BC break in stdlibc++? Last time was with gcc5. We've got a nice big [transition] within Debian due to it. It was related to C++11 stuff, and we've got away precisely because Qt doesn't expose it. And quite messy in some concerns too because they did not increase the SONAME as they should, so the only thing we had is to track which apps/libs got rebuilt. Normally we can track this with a proper SONAME change. [transition] the required work to get stuff rebuilt against a lib changing SONAME (or breaking ABI without changing it) in the whole Debian archive and let the affected packages migrate to testing in the same go. -- The generation of random numbers is too important to be left to chance. http://www.devtopics.com/best-programming-jokes/ Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From perezmeyer at gmail.com Mon Nov 21 23:37:16 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Mon, 21 Nov 2016 19:37:16 -0300 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <1696347.cJO6kkTjI8@tonks> References: <1696347.cJO6kkTjI8@tonks> Message-ID: <2776884.NMS8GbRPdS@tonks> On lunes, 21 de noviembre de 2016 19:36:43 ART Lisandro Damián Nicanor Pérez Meyer wrote: > On lunes, 21 de noviembre de 2016 20:47:31 ART Marco Bubke wrote: > > So how often do you had a BC break in stdlibc++? > > Last time was with gcc5. We've got a nice big [transition] within Debian due > to it. It was related to C++11 stuff, and we've got away precisely because > Qt doesn't expose it. Forgot to mention: begginging of 2016 if I remember correctly. -- La ciencia sin la religión es renga, la religión sin la ciencia es ciega. Albert Einstein Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From apoenitz at t-online.de Tue Nov 22 01:06:00 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Tue, 22 Nov 2016 01:06:00 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <19998848.gqzZj1taFC@tonks> References: <201611182037.26392.marc.mutz@kdab.com> <20161120115311.GA1482@klara.mpi.htwm.de> <19998848.gqzZj1taFC@tonks> Message-ID: <20161122000600.GA2032@klara.mpi.htwm.de> On Mon, Nov 21, 2016 at 03:49:49PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote: > [snip] > > - people using Qt in applications distributed by packaging > > systems (read "Linux distributions"). They are not affected > > by BC breakages. > > Users might not notice if we maintainers have to deal with this nightmare. That's what I said. I also said that packagers (i.e. people like you) *are* affected, but I claimed the way they are affected is not fundamentally different from what happens if the packages in question uses any other library that doesn't guarantee BC, or - in case they have similar BC promises like Qt - what happens when there are jumps in major versions. > If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt > lib break ABI we need to get Qt rebuilt and *everything* building > against it. I understand that. What I do not understand is how rebuilding an application can be considered a significant burden while running a full test cycle (Qt doesn't guarantee behavioural compatibility between versions, any versions for that matter) is not. I fear that the answer is something along the lines of "we might run a smoke test, but no more", isn't it? > That's the worth nightmare we distro maintainers can dream > on. And yes, we would need to adjust Qt's SONAME on each change. That's maybe one per year. With a typical distro running, say, two bigger updates per year replacing most packages anyway, that would ill-affect a distro user... how? I am not here trying to make your life harder. I do understand that you would be on the receiving end in case Qt BC guarantees are lowered. I believe I understand the effort packagers invest, and the benefit this has for the Qt ecosystem. But the BC guarantee comes at quite some price like the inability to fix certain mistakes that slipped into some x.0 release, or to use certain features that only became usable a some x.5 time, and this price is payed both by developers and end users. This is not a zero-sum game, there's room for total improvement, and since BC is not the only thing packagers care for a loss of BC could possibly get compensated by something dev can influence. At the very least I see no reason to forbid thinking about it. Andre' From Marco.Bubke at qt.io Tue Nov 22 00:18:08 2016 From: Marco.Bubke at qt.io (Marco Bubke) Date: Mon, 21 Nov 2016 23:18:08 +0000 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <20161122000600.GA2032@klara.mpi.htwm.de> References: <201611182037.26392.marc.mutz@kdab.com> <20161120115311.GA1482@klara.mpi.htwm.de> <19998848.gqzZj1taFC@tonks> <20161122000600.GA2032@klara.mpi.htwm.de> Message-ID: On November 21, 2016 23:57:07 André Pönitz wrote: > On Mon, Nov 21, 2016 at 03:49:49PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: >> On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote: >> [snip] >> > - people using Qt in applications distributed by packaging >> > systems (read "Linux distributions"). They are not affected >> > by BC breakages. >> >> Users might not notice if we maintainers have to deal with this nightmare. > > That's what I said. > > I also said that packagers (i.e. people like you) *are* affected, but I > claimed the way they are affected is not fundamentally different from > what happens if the packages in question uses any other library that > doesn't guarantee BC, or - in case they have similar BC promises like Qt > - what happens when there are jumps in major versions. And how many applications are Qt only and use no standard lib anyway? Are there any numbers? Yes, sometimes they are inlined but sometimes they are not. Is it really a so big burden for you? And what are you doing about GTK? To my knowledge their BC is quite limit. >> If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt >> lib break ABI we need to get Qt rebuilt and *everything* building >> against it. > > I understand that. > > What I do not understand is how rebuilding an application can be > considered a significant burden while running a full test cycle (Qt > doesn't guarantee behavioural compatibility between versions, any > versions for that matter) is not. > > I fear that the answer is something along the lines of "we > might run a smoke test, but no more", isn't it? You can capture behavior changes by unit and integration tests but there is always the possibility that you break something because the complexity is not reasonable testable. It's always a tradeoff. >> That's the worth nightmare we distro maintainers can dream >> on. And yes, we would need to adjust Qt's SONAME on each change. > > That's maybe one per year. With a typical distro running, say, two > bigger updates per year replacing most packages anyway, that would > ill-affect a distro user... how? > > I am not here trying to make your life harder. I do understand that you > would be on the receiving end in case Qt BC guarantees are lowered. I > believe I understand the effort packagers invest, and the benefit this > has for the Qt ecosystem. But the BC guarantee comes at quite some > price like the inability to fix certain mistakes that slipped into some > x.0 release, or to use certain features that only became usable a some > x.5 time, and this price is payed both by developers and end users. > > This is not a zero-sum game, there's room for total improvement, and > since BC is not the only thing packagers care for a loss of BC could > possibly get compensated by something dev can influence. At the very > least I see no reason to forbid thinking about it. I strongly agree with Andre'. And is a BC break in the time of flat pack that bad? As an user I really looking forward to flat pack, so I can update my heavily used Applications and being not dependent on distribution. This package could be much better optimize with LTO and profile guided optimization. Maybe sharing everything is not that smart anymore. > Andre' > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Tue Nov 22 00:42:12 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 21 Nov 2016 15:42:12 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <1696347.cJO6kkTjI8@tonks> References: <1696347.cJO6kkTjI8@tonks> Message-ID: <1607221.47nJ0mp9dn@tjmaciei-mobl1> On segunda-feira, 21 de novembro de 2016 19:36:43 PST Lisandro Damián Nicanor Pérez Meyer wrote: > > So how often do you had a BC break in stdlibc++? > > Last time was with gcc5. In other words, once in 11 years. > And quite messy in some concerns too because they did not increase the > SONAME > as they should, so the only thing we had is to track which apps/libs got > rebuilt. Normally we can track this with a proper SONAME change. Because GCC developers, like the proponents of inline namespaces, forget that libraries use their libraries and thus expose their ABI differences in their ABI. GCC devs invented the "abi_tag" attribute so they could mark methods according to a deveoper-defined tag, and propagate that tag. They provide both sets of ABIs in libstdc++. But unless developers of downstream libraries take the precautions to provide them both in their own libraries, this causes a BC breakage. THAT was the issue. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Nov 22 00:47:09 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 21 Nov 2016 15:47:09 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: <20161122000600.GA2032@klara.mpi.htwm.de> Message-ID: <1573437.LOW8d6lCRL@tjmaciei-mobl1> On segunda-feira, 21 de novembro de 2016 23:18:08 PST Marco Bubke wrote: > I strongly agree with Andre'. And is a BC break in the time of flat pack > that bad? As an user I really looking forward to flat pack, so I can > update my heavily used Applications and being not dependent on > distribution. This package could be much better optimize with LTO and > profile guided optimization. Maybe sharing everything is not that smart > anymore. FlatPaks don't work for Qt. Reasons: /usr/lib64/qt5/plugins/styles/breeze.so /usr/lib64/qt5/plugins/platformthemes/KDEPlasmaPlatformTheme.so If you include Qt in your flatpak or equivalent, then your Qt application will not load the system plugins and will thus not have native look and feel in a Plasma desktop or in LXQt. If you don't include Qt or if the included Qt loads plugins, then BC is required. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Nov 22 00:57:06 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 21 Nov 2016 15:57:06 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <20161122000600.GA2032@klara.mpi.htwm.de> References: <19998848.gqzZj1taFC@tonks> <20161122000600.GA2032@klara.mpi.htwm.de> Message-ID: <6073837.m8i0l8AP7l@tjmaciei-mobl1> On terça-feira, 22 de novembro de 2016 01:06:00 PST André Pönitz wrote: > I also said that packagers (i.e. people like you) *are* affected, but I > claimed the way they are affected is not fundamentally different from > what happens if the packages in question uses any other library that > doesn't guarantee BC, or - in case they have similar BC promises like Qt > - what happens when there are jumps in major versions. Fundamentally, no. But the important difference is the bottleneck. I remember in the MeeGo days when building MeeGo with OBS spent an hour on a very beefy machine compiling Qt, with most of the resources in the OBS farm unused because nothing else could be built yet. With Qt 5 and our split packages, this lessens because only qtbase is the bottleneck. > I understand that. > > What I do not understand is how rebuilding an application can be > considered a significant burden while running a full test cycle (Qt > doesn't guarantee behavioural compatibility between versions, any > versions for that matter) is not. Again, a matter of scale. And note you said "rebuilding an application", not "rebuilding all KF5 and other domain libraries, then the application". In addition, the ability to upgrade just Qt and then retest already-built libraries and applications allows us and distros to detect regressions and other issues. There's no need to rebuild everything in order to see what happens. > > That's the worth nightmare we distro maintainers can dream > > on. And yes, we would need to adjust Qt's SONAME on each change. > > That's maybe one per year. With a typical distro running, say, two > bigger updates per year replacing most packages anyway, that would > ill-affect a distro user... how? End users who don't develop, sure. If they develop something, then their self-built libraries will break and need to be rebuilt. I've since stopped building KDE from sources, but that used to be a problem with libraries that broke ABI. ICU and Boost come to mind: after a system upgrade, many applications would fail to load (to the point of not having a desktop at all) because the older versions of the system packages for those libs got removed in the system upgrade until I rebuilt the world. Granted, this can be fixed by not removing those packages during system upgrade. > This is not a zero-sum game, there's room for total improvement, and > since BC is not the only thing packagers care for a loss of BC could > possibly get compensated by something dev can influence. At the very > least I see no reason to forbid thinking about it. I can't think of anything that would be worth the major headache that breaking BC more often than once every 4 years would cause. And note I'm not talking about breaking SC. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Tue Nov 22 01:21:08 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Mon, 21 Nov 2016 21:21:08 -0300 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <20161122000600.GA2032@klara.mpi.htwm.de> References: <19998848.gqzZj1taFC@tonks> <20161122000600.GA2032@klara.mpi.htwm.de> Message-ID: <2183905.p8M7AFOm8v@tonks> On martes, 22 de noviembre de 2016 01:06:00 ART André Pönitz wrote: > On Mon, Nov 21, 2016 at 03:49:49PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > > On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote: > > [snip] > > > > > - people using Qt in applications distributed by packaging > > > > > > systems (read "Linux distributions"). They are not affected > > > by BC breakages. > > > > Users might not notice if we maintainers have to deal with this nightmare. > > That's what I said. > > I also said that packagers (i.e. people like you) *are* affected, but I > claimed the way they are affected is not fundamentally different from > what happens if the packages in question uses any other library that > doesn't guarantee BC, or - in case they have similar BC promises like Qt > - what happens when there are jumps in major versions. > > > If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt > > lib break ABI we need to get Qt rebuilt and *everything* building > > against it. > > I understand that. > > What I do not understand is how rebuilding an application can be > considered a significant burden Because it's not just a few applications nor a few archs nor a day or two of rebuilding stuff nor Qt alone. Let's take for example the work we Debian maintainers need to do on every minor Qt update due to private symbols. As you all should know Qt ships private headers which should only be used by Qt itself. But there are people out there that need to use those private headers in order to be able to, for example, provide a native theme. Of course Qt will not bump SONAME and that's fine by definition, because they are private headers. But we maintainers need to deal with it somehow. One way to achieve it will mean rebuilding the whole set of apps using Qt, but that's definitely too much. Using something we call "symbols files" we where able to first hack a way to determine which apps uses private symbols (and then thanks to Thiago providing us with tagged symbols we improved it quite a lot). So we get down to something like this: Of course that only shows 2 out of the 11 archs we have. It will seem a pretty easy list, most of it being Qt submodules. That alone on the best case scenario takes us 3 to 5 days. Last time we did it it got tangled with an openssl transition as both of them needed to rebuild the same package: calibre. It took us more than a week to solve the issue, but hey, it's what packagers do :-) (sadly not for a living ;-) ) Now if you break BC at, let's say, libqt5core5 we would need to rename it to something like libqt5core5abi1 and rebuild the whole stack of stuff using Qt. The list of the example above would probably crawl to level 7 with quite some more packages on each level. A transition like that would definitely take like a month, in which no other transition will probably be able to happen because Qt is *so* widely used. > while running a full test cycle (Qt > doesn't guarantee behavioural compatibility between versions, any > versions for that matter) is not. > > I fear that the answer is something along the lines of "we > might run a smoke test, but no more", isn't it? No. > > That's the worth nightmare we distro maintainers can dream > > on. And yes, we would need to adjust Qt's SONAME on each change. > > That's maybe one per year. With a typical distro running, say, two > bigger updates per year replacing most packages anyway, that would > ill-affect a distro user... how? As I described above: by stopping half a distribution to be updated by too much time. > I am not here trying to make your life harder. I do understand that you > would be on the receiving end in case Qt BC guarantees are lowered. I > believe I understand the effort packagers invest, and the benefit this > has for the Qt ecosystem. But the BC guarantee comes at quite some > price like the inability to fix certain mistakes that slipped into some > x.0 release, or to use certain features that only became usable a some > x.5 time, and this price is payed both by developers and end users. We know and do understand this. But the side effects that it ships are not negligible too. We would suffer a lot from them. -- Un viejo proverbio de El.Machi dice que la memoria es como las papas fritas... ¡nunca sobran! Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From perezmeyer at gmail.com Tue Nov 22 01:23:54 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Mon, 21 Nov 2016 21:23:54 -0300 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <1607221.47nJ0mp9dn@tjmaciei-mobl1> References: <1696347.cJO6kkTjI8@tonks> <1607221.47nJ0mp9dn@tjmaciei-mobl1> Message-ID: <1637088.jgCDTdZrsI@tonks> On lunes, 21 de noviembre de 2016 15:42:12 ART Thiago Macieira wrote: > On segunda-feira, 21 de novembro de 2016 19:36:43 PST Lisandro Damián > Nicanor > Pérez Meyer wrote: > > > So how often do you had a BC break in stdlibc++? > > > > Last time was with gcc5. > > In other words, once in 11 years. > > > And quite messy in some concerns too because they did not increase the > > SONAME > > as they should, so the only thing we had is to track which apps/libs got > > rebuilt. Normally we can track this with a proper SONAME change. > > Because GCC developers, like the proponents of inline namespaces, forget > that libraries use their libraries and thus expose their ABI differences in > their ABI. GCC devs invented the "abi_tag" attribute so they could mark > methods according to a deveoper-defined tag, and propagate that tag. They > provide both sets of ABIs in libstdc++. > > But unless developers of downstream libraries take the precautions to > provide them both in their own libraries, this causes a BC breakage. THAT > was the issue. Point taken. If the 3rd party exposed API does not changes that much and the necessary guards are in place then it should not hurt that frequently. Now I have a question: how will the Qt community take that a distro changes the SONAME of a lib from, let's say, 5 to 5abi1 when that kind of changes happen? -- Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it ;) Linus Benedict Torvalds. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From perezmeyer at gmail.com Tue Nov 22 01:30:28 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Mon, 21 Nov 2016 21:30:28 -0300 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: <20161122000600.GA2032@klara.mpi.htwm.de> Message-ID: <6001953.ls6cVEYHrm@tonks> On lunes, 21 de noviembre de 2016 23:18:08 ART Marco Bubke wrote: [snip] > And how many applications are Qt only and use no standard lib anyway? Are > there any numbers? Good question, I wonder if there is a way to dig that. > Yes, sometimes they are inlined but sometimes they are > not. Is it really a so big burden for you? Yes, as I described in a previous mail. Thiago got a nice word there: bottleneck. It's a heck of a bottle neck. > And what are you doing about > GTK? To my knowledge their BC is quite limit. I guess GTK maintainers suffer, specially with the last changes they announced some time ago about breaking API/ABI (sorry, I don't remember exactly which one) in some minor releases. Incindentally the first thing we Qt maintainers though about those changes is how lucky we are to have such a string-minded upstream that guarantess ABI during the life of a major version. -- Bebe a bordo (pero con moderación) Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From perezmeyer at gmail.com Tue Nov 22 01:33:58 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Mon, 21 Nov 2016 21:33:58 -0300 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <6073837.m8i0l8AP7l@tjmaciei-mobl1> References: <20161122000600.GA2032@klara.mpi.htwm.de> <6073837.m8i0l8AP7l@tjmaciei-mobl1> Message-ID: <5027148.9TlP1iZp3V@tonks> On lunes, 21 de noviembre de 2016 15:57:06 ART Thiago Macieira wrote: > On terça-feira, 22 de novembro de 2016 01:06:00 PST André Pönitz wrote: > > I also said that packagers (i.e. people like you) *are* affected, but I > > claimed the way they are affected is not fundamentally different from > > what happens if the packages in question uses any other library that > > doesn't guarantee BC, or - in case they have similar BC promises like Qt > > - what happens when there are jumps in major versions. > > Fundamentally, no. But the important difference is the bottleneck. > > I remember in the MeeGo days when building MeeGo with OBS spent an hour on a > very beefy machine compiling Qt, with most of the resources in the OBS farm > unused because nothing else could be built yet. With Qt 5 and our split > packages, this lessens because only qtbase is the bottleneck. As long as qtbase's private headers do not change. I guess in that case one who knows exactly what would affect will just rebuild the necessary parts, the rest of us need to get all the stuff rebuilt (17 submodules? maybe they are more right now). [snip] > I can't think of anything that would be worth the major headache that > breaking BC more often than once every 4 years would cause. And note I'm > not talking about breaking SC. And if this can be coupled with an upstream-made SONAME like 5 to 5abi1... well, I guess once in 4 years is not that much. -- Never attribute to malice that which is adequately explained by stupidity. http://en.wikipedia.org/wiki/Hanlon's_razor Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From perezmeyer at gmail.com Tue Nov 22 01:36:59 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Mon, 21 Nov 2016 21:36:59 -0300 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <2183905.p8M7AFOm8v@tonks> References: <20161122000600.GA2032@klara.mpi.htwm.de> <2183905.p8M7AFOm8v@tonks> Message-ID: <1576862.dgYvgoAbKU@tonks> On lunes, 21 de noviembre de 2016 21:21:08 ART Lisandro Damián Nicanor Pérez Meyer wrote: [snip] > A transition like that would definitely take like a month, in which no other > transition will probably be able to happen because Qt is *so* widely used. Maybe worth mentioning: in order to improve the speed of a transition no Qt- based apps/libs will be able to be upsdated during the process *except* when they fix bugs in order to achieve the transition. That includes the whole KDE stack, apart from Qt-only things. -- Un viejo proverbio de El.Machi dice que la memoria es como las papas fritas... ¡nunca sobran! Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Tue Nov 22 02:07:08 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 21 Nov 2016 17:07:08 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <5027148.9TlP1iZp3V@tonks> References: <6073837.m8i0l8AP7l@tjmaciei-mobl1> <5027148.9TlP1iZp3V@tonks> Message-ID: <3104963.WLLUXZcUtz@tjmaciei-mobl1> On segunda-feira, 21 de novembro de 2016 21:33:58 PST Lisandro Damián Nicanor Pérez Meyer wrote: > > I remember in the MeeGo days when building MeeGo with OBS spent an hour on > > a very beefy machine compiling Qt, with most of the resources in the OBS > > farm unused because nothing else could be built yet. With Qt 5 and our > > split packages, this lessens because only qtbase is the bottleneck. > > As long as qtbase's private headers do not change. I guess in that case one > who knows exactly what would affect will just rebuild the necessary parts, > the rest of us need to get all the stuff rebuilt (17 submodules? maybe they > are more right now). My point is that there are packages that depend only on qtbase libraries, so they can start rebuilding as soon as qtbase is done, while the system is building qtsvg and qtserialport in another node in the farm. And this scenario was the "rebuild world" case, regardless of whether there were ABI breakages or not. You're right that if you're rebuilding only what needs to be rebuilt, then an update to qtbase should trigger only rebuilding of packages that depended on the private API. With the ELF version marker, that should be easy to detect now. That said, sometimes rebuilding even if there was no dependency on the private API could result in improvements. For example, every time we add overloads there's a chance that the new method is faster and will get selected. > > I can't think of anything that would be worth the major headache that > > breaking BC more often than once every 4 years would cause. And note I'm > > not talking about breaking SC. > > And if this can be coupled with an upstream-made SONAME like 5 to 5abi1... > well, I guess once in 4 years is not that much. And ELF symbol versioning. That allows both libraries to be loaded into memory and not interfere with each other, so long as you don't pass data from one to the other. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Nov 22 02:10:33 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 21 Nov 2016 17:10:33 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <6001953.ls6cVEYHrm@tonks> References: <6001953.ls6cVEYHrm@tonks> Message-ID: <2132262.lNFkZzPzVr@tjmaciei-mobl1> On segunda-feira, 21 de novembro de 2016 21:30:28 PST Lisandro Damián Nicanor Pérez Meyer wrote: > I guess GTK maintainers suffer, specially with the last changes they > announced some time ago about breaking API/ABI (sorry, I don't remember > exactly which one) in some minor releases. Incindentally the first thing we > Qt maintainers though about those changes is how lucky we are to have such > a string-minded upstream that guarantess ABI during the life of a major > version. GTK 2 and GTK 3 do keep their ABI just fine. Lisandro is talking about the GTK 4 plans. See https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/ -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Nov 22 02:20:09 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 21 Nov 2016 17:20:09 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <1637088.jgCDTdZrsI@tonks> References: <1607221.47nJ0mp9dn@tjmaciei-mobl1> <1637088.jgCDTdZrsI@tonks> Message-ID: <3240151.BGy0Pv7jhT@tjmaciei-mobl1> On segunda-feira, 21 de novembro de 2016 21:23:54 PST Lisandro Damián Nicanor Pérez Meyer wrote: > Now I have a question: how will the Qt community take that a distro changes > the SONAME of a lib from, let's say, 5 to 5abi1 when that kind of changes > happen? We prefer to work with downstreams and have those changes in Qt itself. Not because we don't trust Debian, Fedora and OpenSUSE maintainers to do the right thing, but precisely because it's multiple teams. Why should each team redevelop the solution? And don't forget tiny distros and self-built distros (Yocto comes to mind!) whose teams are not aware of those changes. Note that we can do ABI versioning if we wanted to: libQt5Core.so.5 ↑ ↑ ❘ ⌞→ ABI (binary) version ⌞→ API (source) version The ELF symbol version would need to be adapted too. Right now, it marks everything as "Qt_5". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Tue Nov 22 02:29:44 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Mon, 21 Nov 2016 22:29:44 -0300 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <3104963.WLLUXZcUtz@tjmaciei-mobl1> References: <5027148.9TlP1iZp3V@tonks> <3104963.WLLUXZcUtz@tjmaciei-mobl1> Message-ID: <2947030.HE1DYrT872@tonks> On lunes, 21 de noviembre de 2016 17:07:08 ART Thiago Macieira wrote: > On segunda-feira, 21 de novembro de 2016 21:33:58 PST Lisandro Damián > Nicanor > Pérez Meyer wrote: > > > I remember in the MeeGo days when building MeeGo with OBS spent an hour > > > on > > > a very beefy machine compiling Qt, with most of the resources in the OBS > > > farm unused because nothing else could be built yet. With Qt 5 and our > > > split packages, this lessens because only qtbase is the bottleneck. > > > > As long as qtbase's private headers do not change. I guess in that case > > one > > who knows exactly what would affect will just rebuild the necessary parts, > > the rest of us need to get all the stuff rebuilt (17 submodules? maybe > > they > > are more right now). > > My point is that there are packages that depend only on qtbase libraries, so > they can start rebuilding as soon as qtbase is done, while the system is > building qtsvg and qtserialport in another node in the farm. And this > scenario was the "rebuild world" case, regardless of whether there were ABI > breakages or not. > > You're right that if you're rebuilding only what needs to be rebuilt, then > an update to qtbase should trigger only rebuilding of packages that > depended on the private API. With the ELF version marker, that should be > easy to detect now. Just for the record, every time that qtbase's private symbols change we end up requiring a rebuild of almost all the submodules. We might be able to do better with some more hacks, but as we normally require this when we are pushing a new upstream release there is currently not much of a point. > That said, sometimes rebuilding even if there was no dependency on the > private API could result in improvements. For example, every time we add > overloads there's a chance that the new method is faster and will get > selected. Fair point. [snip] > And ELF symbol versioning. That allows both libraries to be loaded into > memory and not interfere with each other, so long as you don't pass data > from one to the other. Indeed, that would really be great. -- Simulations are not data. In God we trust, all the others must supply data. Walter Opyd, "Show Me The Data" IEEE Spectrum's reader's comments, http://www.spectrum.ieee.org/nov04/4004 Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From kevin.kofler at chello.at Tue Nov 22 06:09:01 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 22 Nov 2016 06:09:01 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? References: <20161120232010.4E00.6F0322A@gmail.com> <201611210904.59824.marc.mutz@kdab.com> <20161121093736.7370.6F0322A@gmail.com> <201611211015.24533.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > People make mistakes. The difference is that, in the STL, by way of a > larger target audience, mistakes tend to be fewer than in Qt (looked at > qtimageformats, lately?) That is not a fair comparison. The STL has nothing comparable to qtimageformats. Image decoding and encoding is necessarily a low-level byte crunching task, and performance-critical, even. And thus, things such as buffer overflows can happen. The STL just leaves you in the cold if you need to do any kind of image processing. > If Qt consistently did a better job at implementing such things, the world > might be different. But looking at the Qt containers, and the Qt image > format plugins, I'd much rather use an external library (STL, > lib{jpeg,png,tiff,...) that everyone else also uses, than to reinvent the > wheel and create bugs exclusive to Qt. Several of the decoders already use such external libraries. (The qt5-qtimageformats distribution package I use is linked to libjasper.so.1, libmng.so.2, libtiff.so.5 and libwebp.so.6.) It might make sense to port the others to those libraries. But using an external library does not necessarily fix all problems. Those libraries can have security vulnerabilities (buffer overflows, integer overflows etc.) too. And sometimes, the library you chose is not or poorly maintained. And finally, there can also be bugs in the way the library is called in your code. Still, it is usually a better approach than hardcoding the format directly in Qt. Now, if you are suggesting that all the applications should just use the low-level libraries directly, that is not a reasonable suggestion. Those libraries typically have very low-level C APIs. And most importantly, you need to use a different library for every single format! That is what higher-level abstractions such as qtimageformats are for. Kevin Kofler From kevin.kofler at chello.at Tue Nov 22 06:40:52 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 22 Nov 2016 06:40:52 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? References: <201611182037.26392.marc.mutz@kdab.com> <20161120115311.GA1482@klara.mpi.htwm.de> <19998848.gqzZj1taFC@tonks> <20161122000600.GA2032@klara.mpi.htwm.de> Message-ID: André Pönitz wrote: > I also said that packagers (i.e. people like you) *are* affected, but I > claimed the way they are affected is not fundamentally different from > what happens if the packages in question uses any other library that > doesn't guarantee BC, or - in case they have similar BC promises like Qt > - what happens when there are jumps in major versions. The problem is that Qt is a very widely used library, and that it is also used by many libraries used by other libraries used by other libraries, all of which also use Qt directly (e.g. KF5-*). The "all of which also use Qt directly" part is how this differs from something like libpng which is usually only used through higher-level APIs. Most applications do not link directly to libpng. (In fact, we do this: http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtbase.git/tree/qt5-qtbase.spec#n562 to avoid Qt applications needlessly linking directly to libpng etc. We cannot do this with Qt because its APIs are used both directly and transitively.) >> If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt >> lib break ABI we need to get Qt rebuilt and *everything* building >> against it. > > I understand that. > > What I do not understand is how rebuilding an application can be > considered a significant burden while running a full test cycle (Qt > doesn't guarantee behavioural compatibility between versions, any > versions for that matter) is not. It is not *an* application. It is *many* libraries and applications. > I fear that the answer is something along the lines of "we > might run a smoke test, but no more", isn't it? Well yes, testing is what our users do daily. What we need to take care of is to not have broken dependencies (or worse, symbol lookup failures at runtime because the ABI was changed without a soname bump). Otherwise, the application will not run at all. >> That's the worth nightmare we distro maintainers can dream >> on. And yes, we would need to adjust Qt's SONAME on each change. > > That's maybe one per year. With a typical distro running, say, two > bigger updates per year replacing most packages anyway, that would > ill-affect a distro user... how? In Fedora, the issues this would cause are twofold: 1. In Rawhide, we would have to rebuild all packages using Qt, which are dozens, each time such a thing happens. But, due to the transitive dependency issue I mentioned at the beginning, they would have to be rebuilt in reverse dependency order. So we would first have to compute that. Our tools do not do it for us. The mass rebuilds Fedora release engineering does for some releases are always done in alphabetical order. That will not work if so many libraries have broken dependencies. 2. In Fedora, Qt is often updated to a newer version in a release, as an official update. And even when not, the newer version is typically offered in a Copr repository (a Fedora "PPA"). That would not be reasonably doable anymore if the new version were not binary-compatible. As in Debian's case, the packages (ab)using private APIs are already enough of an issue for us as it stands. But at least we have a list of those, and their interdependencies are limited, whereas rebuilding ALL packages using Qt would be orders of magnitude larger and not suitable for an update nor (realistically) even a Copr at all. Major versions of Qt (i.e., 3, 4, 5, …) are the right place to change the ABI, because there, we just make both versions coexist, and the transition becomes relatively smooth. But also breaking binary compatibility in the minor releases would not really scale. > I am not here trying to make your life harder. I do understand that you > would be on the receiving end in case Qt BC guarantees are lowered. I > believe I understand the effort packagers invest, and the benefit this > has for the Qt ecosystem. But the BC guarantee comes at quite some > price like the inability to fix certain mistakes that slipped into some > x.0 release, or to use certain features that only became usable a some > x.5 time, and this price is payed both by developers and end users. But if our users were to be stuck at, say, Qt 5.8 because 5.9 would be binary-incompatible, they would be losing much more features. > This is not a zero-sum game, there's room for total improvement, and > since BC is not the only thing packagers care for a loss of BC could > possibly get compensated by something dev can influence. At the very > least I see no reason to forbid thinking about it. You can always think about it, but if you do so, you will quickly find that it is not practical at all. Marco Bubke wrote: > I strongly agree with Andre'. And is a BC break in the time of flat pack > that bad? As an user I really looking forward to flat pack, so I can > update my heavily used Applications and being not dependent on > distribution. This package could be much better optimize with LTO and > profile guided optimization. Maybe sharing everything is not that smart > anymore. How does Flatpak solve the issue? Qt is not a leaf package. You cannot offer a Qt Flatpak, none of the applications using Qt would get the improvements from such a Qt. You would have to Flatpak each and every application. We want to offer newer Qt releases as a distro-wide drop-in update for all applications to benefit. Kevin Kofler From Marco.Bubke at qt.io Tue Nov 22 06:54:07 2016 From: Marco.Bubke at qt.io (Marco Bubke) Date: Tue, 22 Nov 2016 05:54:07 +0000 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <2132262.lNFkZzPzVr@tjmaciei-mobl1> References: <6001953.ls6cVEYHrm@tonks> <2132262.lNFkZzPzVr@tjmaciei-mobl1> Message-ID: On November 22, 2016 02:10:50 Thiago Macieira wrote: > On segunda-feira, 21 de novembro de 2016 21:30:28 PST Lisandro Damián Nicanor > Pérez Meyer wrote: >> I guess GTK maintainers suffer, specially with the last changes they >> announced some time ago about breaking API/ABI (sorry, I don't remember >> exactly which one) in some minor releases. Incindentally the first thing we >> Qt maintainers though about those changes is how lucky we are to have such >> a string-minded upstream that guarantess ABI during the life of a major >> version. > > GTK 2 and GTK 3 do keep their ABI just fine. To my understanding GTK 3 gives no guarantees at all. > > Lisandro is talking about the GTK 4 plans. See > https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/ > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Tue Nov 22 07:00:17 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 22 Nov 2016 07:00:17 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <3104963.WLLUXZcUtz@tjmaciei-mobl1> References: <5027148.9TlP1iZp3V@tonks> <3104963.WLLUXZcUtz@tjmaciei-mobl1> Message-ID: <201611220700.17621.marc.mutz@kdab.com> On Tuesday 22 November 2016 02:07:08 Thiago Macieira wrote: > That said, sometimes rebuilding even if there was no dependency on the > private API could result in improvements. For example, every time we add > overloads there's a chance that the new method is faster and will get > selected. Its even worse: if Qt fixes a bug in an inline function, no application will benefit unless recompiled, either. So for any Qt user, and esp. distros, not recompiling all users of Qt when Qt changes runs the risk of not getting some of the bug fixes, leading to users seeing those bugs together with Qt versions in which they're officially fixed. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From Marco.Bubke at qt.io Tue Nov 22 06:59:24 2016 From: Marco.Bubke at qt.io (Marco Bubke) Date: Tue, 22 Nov 2016 05:59:24 +0000 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <6001953.ls6cVEYHrm@tonks> References: <20161122000600.GA2032@klara.mpi.htwm.de> <6001953.ls6cVEYHrm@tonks> Message-ID: On November 22, 2016 01:30:47 Lisandro Damián Nicanor Pérez Meyer wrote: > On lunes, 21 de noviembre de 2016 23:18:08 ART Marco Bubke wrote: > [snip] >> And how many applications are Qt only and use no standard lib anyway? Are >> there any numbers? > > Good question, I wonder if there is a way to dig that. > >> Yes, sometimes they are inlined but sometimes they are >> not. Is it really a so big burden for you? > > Yes, as I described in a previous mail. Thiago got a nice word there: > bottleneck. It's a heck of a bottle neck. > >> And what are you doing about >> GTK? To my knowledge their BC is quite limit. > > I guess GTK maintainers suffer, specially with the last changes they announced > some time ago about breaking API/ABI (sorry, I don't remember exactly which > one) in some minor releases. Incindentally the first thing we Qt maintainers > though about those changes is how lucky we are to have such a string-minded > upstream that guarantess ABI during the life of a major version. So GTK maintainers can do it. There are much more applications on my Linux Desktop so it is possible. And like Linus Torvalds has said, it is questionable to provide a package for every application on Earth. Flatpack is a much more reasonable choise for the developer and the user. > -- > Bebe a bordo (pero con moderación) > > Lisandro Damián Nicanor Pérez Meyer > http://perezmeyer.com.ar/ > http://perezmeyer.blogspot.com/ From Marco.Bubke at qt.io Tue Nov 22 07:13:44 2016 From: Marco.Bubke at qt.io (Marco Bubke) Date: Tue, 22 Nov 2016 06:13:44 +0000 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <1573437.LOW8d6lCRL@tjmaciei-mobl1> References: <20161122000600.GA2032@klara.mpi.htwm.de> <1573437.LOW8d6lCRL@tjmaciei-mobl1> Message-ID: On November 22, 2016 00:47:26 Thiago Macieira wrote: > On segunda-feira, 21 de novembro de 2016 23:18:08 PST Marco Bubke wrote: >> I strongly agree with Andre'. And is a BC break in the time of flat pack >> that bad? As an user I really looking forward to flat pack, so I can >> update my heavily used Applications and being not dependent on >> distribution. This package could be much better optimize with LTO and >> profile guided optimization. Maybe sharing everything is not that smart >> anymore. > > FlatPaks don't work for Qt. > > Reasons: > > /usr/lib64/qt5/plugins/styles/breeze.so > /usr/lib64/qt5/plugins/platformthemes/KDEPlasmaPlatformTheme.so > > If you include Qt in your flatpak or equivalent, then your Qt application will > not load the system plugins and will thus not have native look and feel in a > Plasma desktop or in LXQt. So you say it it does not work because of themeing support? Isn't Qt Controls 2 not anymore providing them too. And is there no technical solutions for that? Like propagating the values to the Flatpack themeing engine. This could be improve the interoperability between different desktop libraries too. The implementation which is based on GTK or Qt is suboptimal anyway. It shows visually why Linux Desktop was never widely adopted. I mean the lack of cooperation and the hesitancy to try to understand the context of the other. I use Linux all the day, but honestly many things are broken, especially where Unix wasn't copied. > If you don't include Qt or if the included Qt loads plugins, then BC is > required. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From kevin.kofler at chello.at Tue Nov 22 07:31:27 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 22 Nov 2016 07:31:27 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? References: <6001953.ls6cVEYHrm@tonks> <2132262.lNFkZzPzVr@tjmaciei-mobl1> Message-ID: Marco Bubke wrote: > On November 22, 2016 02:10:50 Thiago Macieira wrote: >> GTK 2 and GTK 3 do keep their ABI just fine. > > To my understanding GTK 3 gives no guarantees at all. That is not true. GTK+ 3 is backwards ABI-compatible with previous versions all the way down to 3.0. There are some private APIs whose ABI is not guaranteed, such as styling (where custom theme engines do not work anymore at all, you have to use CSS instead of C/C++ code now), but Qt also has such private APIs (and in fact Qt styling is also private, though I hope Qt will never break all existing styles the way GTK+ did!). This will change with GTK+ 4 and their new way is going to be a nightmare, but I will draw a "Not My Problem" card and leave the Fedora GTK+ and GNOME packagers to deal with that. ;-) Kevin Kofler From tony.sarajarvi at qt.io Tue Nov 22 08:12:26 2016 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Tue, 22 Nov 2016 07:12:26 +0000 Subject: [Development] CI suffering from an unknown problem Message-ID: Hi There's something off in the CI currently and we're investigating. -Tony Tony Sarajärvi CI Tech Lead The Qt Company Elektroniikkatie 10 90590, Oulu Finland tony.sarajarvi at qt.io +358 50 4821416 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7132 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 940 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 869 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 832 bytes Desc: image004.png URL: From thiago.macieira at intel.com Tue Nov 22 08:14:53 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 21 Nov 2016 23:14:53 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <201611220700.17621.marc.mutz@kdab.com> References: <3104963.WLLUXZcUtz@tjmaciei-mobl1> <201611220700.17621.marc.mutz@kdab.com> Message-ID: <5201472.m4a6yv7SDW@tjmaciei-mobl1> On terça-feira, 22 de novembro de 2016 07:00:17 PST Marc Mutz wrote: > On Tuesday 22 November 2016 02:07:08 Thiago Macieira wrote: > > That said, sometimes rebuilding even if there was no dependency on the > > private API could result in improvements. For example, every time we add > > overloads there's a chance that the new method is faster and will get > > selected. > > Its even worse: if Qt fixes a bug in an inline function, no application will > benefit unless recompiled, either. So for any Qt user, and esp. distros, > not recompiling all users of Qt when Qt changes runs the risk of not > getting some of the bug fixes, leading to users seeing those bugs together > with Qt versions in which they're officially fixed. True, but there are two important factors in this: 1) those bugfixes and overload additions are not so common 2) application rebuilding can happen at a leisure pace, when resources are available or when the application would have been updated anyway -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Nov 22 08:11:00 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 21 Nov 2016 23:11:00 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: <1573437.LOW8d6lCRL@tjmaciei-mobl1> Message-ID: <6860115.ORWOTKtl0j@tjmaciei-mobl1> On terça-feira, 22 de novembro de 2016 06:13:44 PST Marco Bubke wrote: > So you say it it does not work because of themeing support? Isn't Qt > Controls 2 not anymore providing them too. And is there no technical > solutions for that? Like propagating the values to the Flatpack themeing > engine. This could be improve the interoperability between different > desktop libraries too. The implementation which is based on GTK or Qt is > suboptimal anyway. It shows visually why Linux Desktop was never widely > adopted. I mean the lack of cooperation and the hesitancy to try to > understand the context of the other. I use Linux all the day, but honestly > many things are broken, especially where Unix wasn't copied. So you're saying we need to develop another GUI toolkit for Linux desktops so that we can share some common things between the existing toolkits? This comes to mind: https://xkcd.com/927/ Theming and styling is a complex operation. It's not just "propagating values". Reading config files will at best get you the right font, correct icon set, and somewhat correct colours. But gradients, shapes, complex dialogs will not work. And I don't see anyone volunteering for a major overhaul of QtWidget's styling system. I don't even think a volunteer would be *accepted* by the Qt Project. So, no, there is no solution. Qt applications in a flatpak or similar will not look or feel native, therefore it is not an acceptable solution for an application of regular use. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Nov 22 08:04:56 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 21 Nov 2016 23:04:56 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: <6001953.ls6cVEYHrm@tonks> Message-ID: <5390280.UgN76rMxMY@tjmaciei-mobl1> On terça-feira, 22 de novembro de 2016 05:59:24 PST Marco Bubke wrote: > > I guess GTK maintainers suffer, specially with the last changes they > > announced some time ago about breaking API/ABI (sorry, I don't remember > > exactly which one) in some minor releases. Incindentally the first thing > > we Qt maintainers though about those changes is how lucky we are to have > > such a string-minded upstream that guarantess ABI during the life of a > > major version. > > So GTK maintainers can do it. There are much more applications on my Linux > Desktop so it is possible. And like Linus Torvalds has said, it is > questionable to provide a package for every application on Earth. Flatpack > is a much more reasonable choise for the developer and the user. First of all, GTK maintainers haven't started doing their weird dance of ABI breakage. We don't know if they'll actually go through with it and, if they do, for how long they'll keep doing it. It's very likely that distributions (aside from GTK-centric Fedora) will not keep the unstable versions updated, so they'll get less testing. I find it highly likely the GTK developers abandon this weird dance before or during GTK 5 because of the mess they created. I don't agree on the philosophy of the flatpaks and similar because they're based on a shifting foundation. Oh, it's ok to have a random app here and there that I barely ever use not follow the system L&F -- for example, the Intel Parallel Studio installer (a Qt 5.6 application). But the everyday applications must be native. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Shawn.Rutledge at qt.io Tue Nov 22 10:20:58 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 22 Nov 2016 09:20:58 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <20161121201144.GA1681@klara.mpi.htwm.de> References: <20161109150119.GD12761@troll08> <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> <20161110112912.GB9877@troll08> <20161121201144.GA1681@klara.mpi.htwm.de> Message-ID: > On 21 Nov 2016, at 21:11, André Pönitz wrote: > > QUIPs were not meant to require new or different tooling, and I still > believe such will be needed. Me too. See? we have consensus. ;-) From Marco.Bubke at qt.io Tue Nov 22 12:25:45 2016 From: Marco.Bubke at qt.io (Marco Bubke) Date: Tue, 22 Nov 2016 11:25:45 +0000 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <6860115.ORWOTKtl0j@tjmaciei-mobl1> References: <1573437.LOW8d6lCRL@tjmaciei-mobl1> <6860115.ORWOTKtl0j@tjmaciei-mobl1> Message-ID: On November 22, 2016 08:17:57 Thiago Macieira wrote: > On terça-feira, 22 de novembro de 2016 06:13:44 PST Marco Bubke wrote: >> So you say it it does not work because of themeing support? Isn't Qt >> Controls 2 not anymore providing them too. And is there no technical >> solutions for that? Like propagating the values to the Flatpack themeing >> engine. This could be improve the interoperability between different >> desktop libraries too. The implementation which is based on GTK or Qt is >> suboptimal anyway. It shows visually why Linux Desktop was never widely >> adopted. I mean the lack of cooperation and the hesitancy to try to >> understand the context of the other. I use Linux all the day, but honestly >> many things are broken, especially where Unix wasn't copied. > > So you're saying we need to develop another GUI toolkit for Linux desktops so > that we can share some common things between the existing toolkits? > > This comes to mind: https://xkcd.com/927/ > > Theming and styling is a complex operation. It's not just "propagating > values". Reading config files will at best get you the right font, correct icon > set, and somewhat correct colours. But gradients, shapes, complex dialogs will > not work. I don't see the problem to describe it in text, like CSS is doing. Actually it has the advantage to be independent of drawing systems. If you code it in C++ it is hard to translate that to OpenGL etc. > And I don't see anyone volunteering for a major overhaul of QtWidget's styling > system. I don't even think a volunteer would be *accepted* by the Qt Project. Why do you can not write a QStyle whicj is bridging it? > So, no, there is no solution. Qt applications in a flatpak or similar will not > look or feel native, therefore it is not an acceptable solution for an > application of regular use. Come on, it is mostly broken for me already today. If you mix different toolkits it is not working that well. Mix High DPI in it and it gets worse. Linux Desktop is already in a ugly shape, I don't see how it get worse with it. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Marco.Bubke at qt.io Tue Nov 22 12:33:55 2016 From: Marco.Bubke at qt.io (Marco Bubke) Date: Tue, 22 Nov 2016 11:33:55 +0000 Subject: [Development] Summary ABI compabilty Message-ID: Hi I try to gather all arguments so they don't get lost: Short Term ABI compability(1-2 years): * better bug fixing * faster development * faster adoption of standards - con: we don't want to adapt them because our solution is better Long Term ABI compability(5-10 years): * easier life of Linux packager - con: you can use Flatpack in many case (disputed) I think I miss some but feel free to extend the list -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Tue Nov 22 12:42:52 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 22 Nov 2016 11:42:52 +0000 Subject: [Development] Qt 5.9 In-Reply-To: References: Message-ID: Hi all, We need to start preparations for Qt5.9 release even Qt 5.8.0 isn't out yet :) There are some things to be agreed already now: - Qt 5.9.0 Feature Freeze - Changes in supported platforms/configurations So first of all let's agree the feature freeze date: I propose to have the FF 1.2.2017. From the history we can see that time needed from FF to final release is (even more than) 17 weeks. I know it is too long time but at the moment that is the fact and there is no evidence that we can do it within shorter schedule. We are trying to find ways to make it shorter but at the moment there isn't any big improvements coming and so on that 17 weeks is the best base for our plans. So if we want to get Qt 5.9.0 release out before summer holidays we need to have ff at the beginning of February. And note: At this time we want to keep the FF date to be able to keep the schedule. That means there won't be any exceptions: If feature isn't ready and in at FF date then it won't be in Qt 5.9 release. So please make sure all new features are in early enough & those are fulfilling the ff requirements: https://wiki.qt.io/Qt_5_Feature_Freeze Then I propose following changes in supported platforms/configurations: - We have earlier agreed that for Apple we will support three latest versions. So this means * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 * For iOS we drop 7.x and support 8.x, 9.x, 10.x - I propose to drop standalone macOS Android installer; One having iOS & Android should be enough - For MinGW I propose to start delivering 64 bit binary packages instead of 32 bit one & start using MinGW 6.x (6.2?) - For Windows Android I propose to start doing Android Windows build with MinGW53 (if we are able to build it. Otherwise MinGW49 will be used as with 5.8) - For WinRT/WinPhone I propose to drop WinRT 8.1 and WinPhone 8.1 support & start using term UWP (Universal Windows platform). It means also dropping msvc 2013 from WinRT/WinPhone; UWP only supports msvc2015 - Start supporting QNX 7.0 br, Jani Heikkinen Release Manager From lars.knoll at qt.io Tue Nov 22 12:54:46 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 22 Nov 2016 11:54:46 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <20161121201144.GA1681@klara.mpi.htwm.de> References: <20161109150119.GD12761@troll08> <00921B8F-BBC8-47F9-B438-2F1B741255AA@qt.io> <20161110112912.GB9877@troll08> <20161121201144.GA1681@klara.mpi.htwm.de> Message-ID: <7FC51B63-F83C-4F66-9E29-0E79F6087235@qt.io> +1 to this. First and foremost we're looking for a way to summarize and document the outcome of discussions and decisions made. That's what QUIPs are for. Arguing about whether gerrit is the perfect tool for reviewing QUIPs is besides the point. It is a tool that'll work better than email discussions (as we're also seeing in this thread), and it's a tool we all are using daily and that we know. And btw, it's being used for documentation changes and review as well. And I'd rather work with gerrit (with all it's deficiencies) than introduce yet another separate tool that doesn't fit into our workflow. Cheers, Lars On 21/11/16 21:11, "Development on behalf of André Pönitz" wrote: On Mon, Nov 21, 2016 at 11:06:52AM +0000, Edward Welbourne wrote: > Giuseppe D'Angelo: > >> I would also like to point out that, despite we have a repository, we > >> still don't have a tool for properly discussing the actual content of > >> QUIPs. > >> > >> * Gerrit does not work because comments cannot be threaded, they > >> don't stick to multiple reviews, and they can be ignored > >> * Email does not work (it may work for the overall direction, but not > >> for the in depth discussion) because a single message may cover > >> multiple discussion points, disrupting the threading, and > >> discussion points can get ignored (*) > > All of which plays into my desire to introduce you all to Critic [0] Guys, the idea of QUIPs was to *fix* a problem, namely the current inability to pinpoint results of mailing list discussion. This *is* a problem for the Project, as lazy consensus on the mailing list is *the* official decision making process in the Qt Governance model, but it works in practice rather accidentally, if at all. Discussions are observed to deteriorate, develop into completely unrelated discussions, and even if something appears like consensus or the discussion dies, it typically turns out that different people think differently about what the consensus actually was, and the discussion re-starts half a year later. You both nicely demonstrate that this problem exist, thank you for that, but beyond that this particular sub-discussion misses the point. QUIPs were not meant to require new or different tooling, and I still believe such will be needed. The rough idea is that a topic is presented as usual on the mailing list, and when someone, usually the original proponent, gets the feeling that the usual rounds of bike-shedding, trolling and name-calling is over, and the occasional sensible arguments all have been heard, writes up what appears like a potential consensus and puts that on Gerrit, where some review process commences. The only difference to a normal review process I'd like to see would be a *much* higher bar for approval, to ensure that QUIPs are really close to consensus and to ensure some consistency within the set of QUIPs. None of this requires new tools, certainly not the bootstrapping of the first QUIP. There's also nothing changing processes, so everybody will be free to continue to present his views on his favourite tools in the future, but for now I'd really like to get this here done. IMNSHO it boils down to the question: Does anybody have any fundamental problem with main idea of having documents summarizing the lazy consensus of certain mailing list discussions? If not I'd call that a lazy consensus and would ask to proceed with reviewing the final wording on Gerrit. Andre' _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From rafael.roquetto at kdab.com Tue Nov 22 13:08:58 2016 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Tue, 22 Nov 2016 10:08:58 -0200 Subject: [Development] Nominating James McDonnell for approver status In-Reply-To: <3CE23C32-5971-4D09-8CFD-9B03019FD765@qt.io> References: <20161031175759.GA19662@polaris.localdomain> <2600534.btVR8lGgpv@tjmaciei-mobl1> <3CE23C32-5971-4D09-8CFD-9B03019FD765@qt.io> Message-ID: <20161122120857.GB994@polaris.localdomain> Hello, Since there were no objections, could we please grant the appropriate rights to James? Thanks, Rafael On Tue, Nov 01, 2016 at 08:14:19AM +0000, Lars Knoll wrote: > +1 from my side. Another hand on QNX will be very welcome :) > > Cheers, > Lars > > > > > On 01/11/16 00:01, "Development on behalf of Thiago Macieira" wrote: > > >On segunda-feira, 31 de outubro de 2016 15:58:00 PDT Rafael Roquetto wrote: > >> Hello, > >> > >> I would like to propose the nomination of James McDonnell for approver > >> status. James works at QNX and has been actively contributing with the > >> maintenance of Qt on QNX. Apart from all the patches he submitted and > >> general bugfixing, he has also been a very good helping hand when it comes > >> to testing pre-release versions of Qt on QNX. > > > >+1 > > > >He's very knowledgeable and it would be very good to have more people with QNX > >knowledge with the right to approve changes. > > > >-- > >Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel Open Source Technology Center > > > >_______________________________________________ > >Development mailing list > >Development at qt-project.org > >http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3599 bytes Desc: not available URL: From lars.knoll at qt.io Tue Nov 22 13:13:44 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 22 Nov 2016 12:13:44 +0000 Subject: [Development] Nominating James McDonnell for approver status In-Reply-To: <20161122120857.GB994@polaris.localdomain> References: <20161031175759.GA19662@polaris.localdomain> <2600534.btVR8lGgpv@tjmaciei-mobl1> <3CE23C32-5971-4D09-8CFD-9B03019FD765@qt.io> <20161122120857.GB994@polaris.localdomain> Message-ID: <5237F5B1-0E34-451A-B09B-2A0220E4661A@qt.io> Hi, I added him to the gerrit Approver group. Alex can do any adjustments to Jira that are required. Congratulations, James! Cheers, Lars On 22/11/16 13:08, "Rafael Roquetto" wrote: Hello, Since there were no objections, could we please grant the appropriate rights to James? Thanks, Rafael On Tue, Nov 01, 2016 at 08:14:19AM +0000, Lars Knoll wrote: > +1 from my side. Another hand on QNX will be very welcome :) > > Cheers, > Lars > > > > > On 01/11/16 00:01, "Development on behalf of Thiago Macieira" wrote: > > >On segunda-feira, 31 de outubro de 2016 15:58:00 PDT Rafael Roquetto wrote: > >> Hello, > >> > >> I would like to propose the nomination of James McDonnell for approver > >> status. James works at QNX and has been actively contributing with the > >> maintenance of Qt on QNX. Apart from all the patches he submitted and > >> general bugfixing, he has also been a very good helping hand when it comes > >> to testing pre-release versions of Qt on QNX. > > > >+1 > > > >He's very knowledgeable and it would be very good to have more people with QNX > >knowledge with the right to approve changes. > > > >-- > >Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel Open Source Technology Center > > > >_______________________________________________ > >Development mailing list > >Development at qt-project.org > >http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From cavendish.qi at gmail.com Tue Nov 22 13:40:44 2016 From: cavendish.qi at gmail.com (Liang Qi) Date: Tue, 22 Nov 2016 13:40:44 +0100 Subject: [Development] HEADS-UP: Branching from '5.8' to '5.8.0' started In-Reply-To: References: Message-ID: Then there will be batches of merges 5.6->5.7->5.8 before the final down merge 5.8->5.8.0. If your changes are after those merges, it will miss the 5.8.0 release normally. (cherry-pick only for the critical things after the final down merge.) And I plan to do the merges during weekends, if CI/COIN works fine. Or if you want your changes not missing this chance, please send some notification to me, for example, reply this email to me(not all). Best Regards, Liang On 21 November 2016 at 14:50, Jani Heikkinen wrote: > Hi, > We have started branching from '5.8' to '5.8.0'. Please start using > '5.8.0' for new changes targeted to Qt 5.8.0 release. There should be > enough time to finalize ongoing changes in '5.8'; final downmerge will > happen Monday 28th November. > > br, > Jani > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Tue Nov 22 14:34:54 2016 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Tue, 22 Nov 2016 13:34:54 +0000 Subject: [Development] CI suffering from an unknown problem In-Reply-To: References: Message-ID: Hi again The CI seemed to suffer from the same problem as our personal instances of the CI did: hardware was not allocated per request, nor did cleaning up of VMs work. So my best bet is that something went bad on vSphere's side. What exactly, we don't know, but a restart of the CI seemed to do the trick. So stage ahead :) -Tony From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Tony Sarajärvi Sent: 22. marraskuuta 2016 9:12 To: development at qt-project.org Subject: [Development] CI suffering from an unknown problem Hi There's something off in the CI currently and we're investigating. -Tony Tony Sarajärvi CI Tech Lead The Qt Company Elektroniikkatie 10 90590, Oulu Finland tony.sarajarvi at qt.io +358 50 4821416 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7132 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 940 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 869 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 832 bytes Desc: image004.png URL: From Morten.Sorvig at qt.io Tue Nov 22 14:45:11 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Tue, 22 Nov 2016 13:45:11 +0000 Subject: [Development] [HiDPI] Rethinking the scaling algorithm In-Reply-To: References: Message-ID: > On 16 Nov 2016, at 17:22, Niccolò Belli wrote: > > Hi Morten, > I'm sorry, I missed your reply. > >> RoundPreferFloor Round up for .75 and higher >> RoundPreferFloor is the new default. Do you think this is sufficient? > > qFloor would help for my monitor, of course. > > Unfortunately the default (RoundPreferFloor) wouldn't be enough, because my monitor is 282.42 PPI and 282.42/96=2.94 > Also RoundPreferFloor would break the 4K 27" monitor previously mentioned, because 161.18/96=1.6998 In this case it might be better to adjust the logical DPI for the monitor to something that would give you a (rounded) scale factor of 2x. So the rounding policy gives you options for handling the rounding only, not overall DPI configuration. (I’m assuming that fonts look OK on the monitor when configured for something like 192 DPI) Morten From oswald.buddenhagen at qt.io Tue Nov 22 15:24:52 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 22 Nov 2016 15:24:52 +0100 Subject: [Development] HEADS-UP: Branching from '5.8' to '5.8.0' started In-Reply-To: References: Message-ID: <20161122142452.GC14942@troll08> On Tue, Nov 22, 2016 at 01:40:44PM +0100, Liang Qi wrote: > Then there will be batches of merges 5.6->5.7->5.8 before the final down > merge 5.8->5.8.0. If your changes are after those merges, it will miss the > 5.8.0 release normally. > (cherry-pick only for the critical things after the final down merge.) > as this cherry-picking is kinda getting out of control, i propose the following upgrade to the branching process: - initial situation: 5.6.2 (previous lts release) is done and we want to release 5.8.0 - right after the last forward merges 5.6=>5.7=>5.8 before finishing branching 5.8.0 (that is *now*), we already create 5.6.3 - this appears obviously premature, as we just released 5.6.2, and the final downmerge from 5.6 to 5.6.3 is months away - however, this gives us a place to integrate all critical lts fixes which we can forward-merge to 5.8.0 - weird twist: after 5.8.0 gets released and 5.6.3 is forward-merged to 5.6, the branch can be temporarily closed again, until it is re-activated for the actual 5.6.3 release (or again temporarily for the 5.8.1 release) the 5.6.3 branch would be hard-branched right away and owned by RM (i.e, staging is restricted). developers need to decide between 5.6 and 5.6.3 based on whether they are targeting 5.8 or 5.8.0 when merged up. > And I plan to do the merges during weekends, if CI/COIN works fine. Or if > you want your changes not missing this chance, please send some > notification to me, for example, reply this email to me(not all). > > Best Regards, > Liang > > > On 21 November 2016 at 14:50, Jani Heikkinen wrote: > > > Hi, > > We have started branching from '5.8' to '5.8.0'. Please start using > > '5.8.0' for new changes targeted to Qt 5.8.0 release. There should be > > enough time to finalize ongoing changes in '5.8'; final downmerge will > > happen Monday 28th November. > > > > br, > > Jani > > > > > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From lars.knoll at qt.io Tue Nov 22 15:42:15 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 22 Nov 2016 14:42:15 +0000 Subject: [Development] HEADS-UP: Branching from '5.8' to '5.8.0' started In-Reply-To: <20161122142452.GC14942@troll08> References: <20161122142452.GC14942@troll08> Message-ID: <5E18F0E9-00C8-4A40-95BB-E0B533721224@qt.io> As long as we're still merging from 5.6 to 5.8, this is probably a good way to handle things. But since we're now having this on the table, I still believe that we need to consider when to stop doing merges from 5.6 to newer versions. This has been discussed in length at the contributor summit, and the continued merges place a rather large burden (and potential for errors) on a few people. It also tends to lead to more changes going into 5.6 than we strictly should have according to our policy. A mode where we at some point stop doing any merges from 5.6, and instead backport bug fixes into that branch will then help us distribute the 'merge' load and validation of the change in the older branch to all of us. Cheers, Lars On 22/11/16 15:24, "Development on behalf of Oswald Buddenhagen" wrote: On Tue, Nov 22, 2016 at 01:40:44PM +0100, Liang Qi wrote: > Then there will be batches of merges 5.6->5.7->5.8 before the final down > merge 5.8->5.8.0. If your changes are after those merges, it will miss the > 5.8.0 release normally. > (cherry-pick only for the critical things after the final down merge.) > as this cherry-picking is kinda getting out of control, i propose the following upgrade to the branching process: - initial situation: 5.6.2 (previous lts release) is done and we want to release 5.8.0 - right after the last forward merges 5.6=>5.7=>5.8 before finishing branching 5.8.0 (that is *now*), we already create 5.6.3 - this appears obviously premature, as we just released 5.6.2, and the final downmerge from 5.6 to 5.6.3 is months away - however, this gives us a place to integrate all critical lts fixes which we can forward-merge to 5.8.0 - weird twist: after 5.8.0 gets released and 5.6.3 is forward-merged to 5.6, the branch can be temporarily closed again, until it is re-activated for the actual 5.6.3 release (or again temporarily for the 5.8.1 release) the 5.6.3 branch would be hard-branched right away and owned by RM (i.e, staging is restricted). developers need to decide between 5.6 and 5.6.3 based on whether they are targeting 5.8 or 5.8.0 when merged up. > And I plan to do the merges during weekends, if CI/COIN works fine. Or if > you want your changes not missing this chance, please send some > notification to me, for example, reply this email to me(not all). > > Best Regards, > Liang > > > On 21 November 2016 at 14:50, Jani Heikkinen wrote: > > > Hi, > > We have started branching from '5.8' to '5.8.0'. Please start using > > '5.8.0' for new changes targeted to Qt 5.8.0 release. There should be > > enough time to finalize ongoing changes in '5.8'; final downmerge will > > happen Monday 28th November. > > > > br, > > Jani > > > > > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From alexander.blasche at qt.io Tue Nov 22 16:46:07 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Tue, 22 Nov 2016 15:46:07 +0000 Subject: [Development] Nominating James McDonnell for approver status In-Reply-To: <5237F5B1-0E34-451A-B09B-2A0220E4661A@qt.io> References: <20161031175759.GA19662@polaris.localdomain> <2600534.btVR8lGgpv@tjmaciei-mobl1> <3CE23C32-5971-4D09-8CFD-9B03019FD765@qt.io> <20161122120857.GB994@polaris.localdomain> <5237F5B1-0E34-451A-B09B-2A0220E4661A@qt.io> Message-ID: > -----Original Message----- > From: Lars Knoll > I added him to the gerrit Approver group. Alex can do any adjustments to Jira > that are required. Done. -- Alex From kossebau at kde.org Tue Nov 22 18:05:20 2016 From: kossebau at kde.org (Friedrich W. H. Kossebau) Date: Tue, 22 Nov 2016 18:05:20 +0100 Subject: [Development] Recommendations for 3rd-party QCH file installation folder for easy discovery? Message-ID: <2244793.ZbTD6rx2HE@klux.site> Hi, (resending here instead of qt-creator@, as hinted to by Eike) two questions to anyone working on/with QCH files: Q1: what would be a good system path pattern (on *nixoid systems) for Qt-based libraries to install their QCH files to? Q2: And would/could there be some way to have 3rd-party QCH files automatically added to Qt Assistant, Creator & Co. on installation, to spare the user the additional manual step? For Q1, I see all the Qt ones are on my system at /usr/share/doc/packages/qt5/*.qch So far I would have guessed /usr/share/doc/$lib/$lib.qch might be a good location. So what patterns do people use for their QCH files when delivering to others as part of an install? For Q2, having to manually add all QCH files one-by-one to Qt Assistant & Co. does not nicely scale if there are a dozen and more 3rd-party QCH files (think e.g. all the non-KF5 and KF5 libs created in the KDE community). Would it perhaps make sense to have some registration system, so QCH files can register themselves somewhere, so Qt Assistant/Creator & other documentation viewers know what is present on the system? Would some simple sym-linking into some generic dir make sense for a start? The /usr/share/doc/packages/qt5 perhaps should be reserved to original Qt ones, but perhaps some separate generic dir like /usr/share/doc/qch would work? Or something based on ENV vars, which would avoid hardcoding such dirs into Qt Assistant & Co.? Actually it would be nice if an installed QCH file would be automatically added to Qt Assistant & Co., after all one installed it for a purpose. Are there any plans with regard to that? Background: I am currently working on adding QCH support to the buildsystem for all the libraries of the KDE Frameworks (and other (KDE) library products), for the generation of QCH files during builds (https://phabricator.kde.org/D2854). This is done with the goals that the API documentation of KDE Frameworks libraries can be viewed/used offline with e.g. Qt Assistant, Qt Creator or KDevelop, and that packagers/distributors of those libraries automatically from the build also have a QCH file matching the very API version of the library for packaging (& inclusion into in any package update mechanism). The implementation of this support is done by new CMake macros which for now make use of the QCH generation feature of doxygen. The macros even support the automatic qthelp:// linking to documentation of base libraries, like the Qt ones. So once that support works, there will be dozens of QCH files which currently would each need manual work by the user to have them added to Qt Assistant & Co. Not perfect! Cheers Friedrich From thiago.macieira at intel.com Tue Nov 22 18:06:07 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 22 Nov 2016 09:06:07 -0800 Subject: [Development] Summary ABI compabilty In-Reply-To: References: Message-ID: <2690055.14q0T3OOkW@tjmaciei-mobl1> On terça-feira, 22 de novembro de 2016 11:33:55 PST Marco Bubke wrote: > Short Term ABI compability(1-2 years): > > > * better bug fixing By a very small margin. We've got 20 years of experience fixing bugs without breaking ABI. > * faster development Unproven. > * faster adoption of standards > - con: we don't want to adapt them because our solution is better Unrelated. The standard libraries *do* keep their ABI, mostly. We can choose to use libstdc++ and libc++ in our ABI and still keep our ABI, though with some restrictions. We'd be subject to breakages in those libraries if they did that, accidentally or no, but in those cases the problems would affect almost all C++ programs anyway. > > > Long Term ABI compability(5-10 years): > > > * easier life of Linux packager > > - con: you can use Flatpack in many case (disputed) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Nov 22 18:18:13 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 22 Nov 2016 09:18:13 -0800 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: <6860115.ORWOTKtl0j@tjmaciei-mobl1> Message-ID: <1698505.QJdCbLj3JT@tjmaciei-mobl1> On terça-feira, 22 de novembro de 2016 11:25:45 PST Marco Bubke wrote: > I don't see the problem to describe it in text, like CSS is doing. Actually > it has the advantage to be independent of drawing systems. If you code it > in C++ it is hard to translate that to OpenGL etc. For 20 years we have had code do it. Doing it with text files is not tested, not a tried alternative. > > And I don't see anyone volunteering for a major overhaul of QtWidget's > > styling system. I don't even think a volunteer would be *accepted* by the > > Qt Project. > Why do you can not write a QStyle whicj is bridging it? Yeah, I stand corrected. Maybe a style would be accepted by the Qt Project. But I retain the statement that no one has tried to do a style as complex as Breeze or a platform integration without plugins. When we created the solution for platform themes in Qt 5.0, we went straight to the plugin solution. So we simply don't know how far we can get. > Come on, it is mostly broken for me already today. If you mix different > toolkits it is not working that well. Mix High DPI in it and it gets worse. > Linux Desktop is already in a ugly shape, I don't see how it get worse > with it. That doesn't mean we should throw up our hands and make things even worse. We have the GTK3 theme, there's a Qt theme for GTK; Firefox, Chromium and OpenOffice have Qt/KDE integration too. For example, all of the applications[*] I use on a daily basis use a KDE file dialog for opening and saving files. [*] the only exception is my self-built Qt Creator because it uses my self- built, binary-incompatible Qt 5, but then I almost never use Ctrl+O, I just rely on Ctrl+K f to open files. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Tue Nov 22 18:31:05 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Tue, 22 Nov 2016 14:31:05 -0300 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <3240151.BGy0Pv7jhT@tjmaciei-mobl1> References: <1637088.jgCDTdZrsI@tonks> <3240151.BGy0Pv7jhT@tjmaciei-mobl1> Message-ID: <3313891.LnOHoqHdpN@tonks> On lunes, 21 de noviembre de 2016 17:20:09 ART Thiago Macieira wrote: > On segunda-feira, 21 de novembro de 2016 21:23:54 PST Lisandro Damián > Nicanor > Pérez Meyer wrote: > > Now I have a question: how will the Qt community take that a distro > > changes > > the SONAME of a lib from, let's say, 5 to 5abi1 when that kind of changes > > happen? > > We prefer to work with downstreams and have those changes in Qt itself. Not > because we don't trust Debian, Fedora and OpenSUSE maintainers to do the > right thing, but precisely because it's multiple teams. Why should each > team redevelop the solution? Ah, I was not clear enough, I was actually meaning this: having a solution pre-thought right from Qt itself. And yes, what you describe seems an excellent way to deal with this. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From perezmeyer at gmail.com Tue Nov 22 18:35:40 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Tue, 22 Nov 2016 14:35:40 -0300 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: <20161122000600.GA2032@klara.mpi.htwm.de> Message-ID: <2185946.6tChRWiiuN@tonks> On lunes, 21 de noviembre de 2016 23:18:08 ART Marco Bubke wrote: [snip] > I strongly agree with Andre'. And is a BC break in the time of flat pack > that bad? As an user I really looking forward to flat pack, so I can > update my heavily used Applications and being not dependent on > distribution. Well, what about all the rest of applications? Your heavily used apps (and *libs*, don't forget them) are not necessarily other user's. For what it's worth you can see in [qtbase.txt] a list of packages that would get removed from Debian if we where to remove qtbase right now. In other words, the list of apps and libs that would be affected by an ABI breackage. You can also think on the amount of flatpacks you would need to make. [qtbase.txt] -- lo cual parece incompatible. lógica, esa tendrá particiones dentro, si se transforma la extendida a tiene particiones lógicas, luego extendida. Una extendida estar dentro de una partición Una partición lógica necesita Diga NO al topposting. Matias Silva Bustos Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From perezmeyer at gmail.com Tue Nov 22 18:37:10 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Tue, 22 Nov 2016 14:37:10 -0300 Subject: [Development] Summary ABI compabilty In-Reply-To: References: Message-ID: <5423942.Ez7BSq6Gop@tonks> On martes, 22 de noviembre de 2016 11:33:55 ART Marco Bubke wrote: [snip] > Long Term ABI compability(5-10 years): > > > * easier life of Linux packager > > - con: you can use Flatpack in many case (disputed) The amount of flatpacks needed would easily become also a problem (see my mail with the qtbase.txt link in it a few minutes ago). -- Hacer algo siempre te llevará más tiempo del que esperabas, incluso si tienes en cuenta la ley de Hofstadter. Douglas Hofstadter http://mundogeek.net/archivos/2009/09/05/la-ley-de-hofstadter/ Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From dangelog at gmail.com Tue Nov 22 19:21:40 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Tue, 22 Nov 2016 19:21:40 +0100 Subject: [Development] Summary ABI compabilty In-Reply-To: References: Message-ID: On Tue, Nov 22, 2016 at 12:33 PM, Marco Bubke wrote: > I think I miss some but feel free to extend the list Does Qt need to keep BC across incompatible standard C++ library implementations? (Independently from the long term/short term ABI breaks) This does not mean "is Qt affected by a BC break in the standard C++ library that you used to compile Qt", the answer to that is yes (Qt uses the standard library internally). * pros: ** You can use Qt compiled against either libc++ or libstdc++, with "the other one", without recompiling Qt. * cons: ** End users applications using anything coming from the standard library still need to be recompiled; what's the problem at recompiling Qt too? (If the end user application is NOT using the standard library then this whole discussion is void) ** We can't expose std:: datatypes in our ABI, only in inline functions, losing significant functionality (and possibly performance) * subjective cons: ** apart from Qt, noone does that, why should Qt be special in that regard? ** is there anyone really using this feature? Cheers, -- Giuseppe D'Angelo From thiago.macieira at intel.com Tue Nov 22 21:24:03 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 22 Nov 2016 12:24:03 -0800 Subject: [Development] Summary ABI compabilty In-Reply-To: References: Message-ID: <4008780.ms3XMRHI2B@tjmaciei-mobl1> On terça-feira, 22 de novembro de 2016 19:21:40 PST Giuseppe D'Angelo wrote: > * pros: > ** You can use Qt compiled against either libc++ or libstdc++, with > "the other one", without recompiling Qt. > * subjective cons: > ** apart from Qt, noone does that, why should Qt be special in that regard? > ** is there anyone really using this feature? And that's why we couldn't make the decision: we don't know. macOS seems to have settled on libc++, but now many Linux distributions are providing it too. The question is whether long-term people will want this on Linux or not (Android included). Right now, since none of the distributions shipping libc++ are doing it right, you cannot use "the other one" without recompiling Qt anyway. If this way of building will remain, then we don't have a problem. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kde at carewolf.com Wed Nov 23 00:07:35 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Wed, 23 Nov 2016 00:07:35 +0100 Subject: [Development] Summary ABI compabilty In-Reply-To: <4008780.ms3XMRHI2B@tjmaciei-mobl1> References: <4008780.ms3XMRHI2B@tjmaciei-mobl1> Message-ID: <201611230007.35685.kde@carewolf.com> On Tuesday 22 November 2016, Thiago Macieira wrote: > On terça-feira, 22 de novembro de 2016 19:21:40 PST Giuseppe D'Angelo wrote: > > * pros: > > ** You can use Qt compiled against either libc++ or libstdc++, with > > "the other one", without recompiling Qt. > > > > * subjective cons: > > ** apart from Qt, noone does that, why should Qt be special in that > > regard? ** is there anyone really using this feature? > > And that's why we couldn't make the decision: we don't know. > > macOS seems to have settled on libc++, but now many Linux distributions are > providing it too. The question is whether long-term people will want this > on Linux or not (Android included). > > Right now, since none of the distributions shipping libc++ are doing it > right, you cannot use "the other one" without recompiling Qt anyway. If > this way of building will remain, then we don't have a problem. Can't we statically link to it, so that it doesn't matter which version the application is using? `Allan From Jake.Petroules at qt.io Wed Nov 23 00:46:32 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 22 Nov 2016 23:46:32 +0000 Subject: [Development] Qt 5.9 In-Reply-To: References: Message-ID: > On Nov 22, 2016, at 3:42 AM, Jani Heikkinen wrote: > > Hi all, > We need to start preparations for Qt5.9 release even Qt 5.8.0 isn't out yet :) There are some things to be agreed already now: > > - Qt 5.9.0 Feature Freeze > - Changes in supported platforms/configurations > > So first of all let's agree the feature freeze date: I propose to have the FF 1.2.2017. From the history we can see that time needed from FF to final release is (even more than) 17 weeks. I know it is too long time but at the moment that is the fact and there is no evidence that we can do it within shorter schedule. We are trying to find ways to make it shorter but at the moment there isn't any big improvements coming and so on that 17 weeks is the best base for our plans. So if we want to get Qt 5.9.0 release out before summer holidays we need to have ff at the beginning of February. > > And note: At this time we want to keep the FF date to be able to keep the schedule. That means there won't be any exceptions: If feature isn't ready and in at FF date then it won't be in Qt 5.9 release. So please make sure all new features are in early enough & those are fulfilling the ff requirements: https://wiki.qt.io/Qt_5_Feature_Freeze > > Then I propose following changes in supported platforms/configurations: > > - We have earlier agreed that for Apple we will support three latest versions. So this means > * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 > * For iOS we drop 7.x and support 8.x, 9.x, 10.x Sounds good to me. Already got https://codereview.qt-project.org/#/c/171940/ and https://codereview.qt-project.org/#/c/171941/ ready. Also propose to "drop" tvOS 9 and watchOS 2 which were the minimums set for the technology previews introduced in 5.8. New supported versions will be tvOS 10 and watchOS 3. > - I propose to drop standalone macOS Android installer; One having iOS & Android should be enough I have a slightly different proposal: remove macOS and Android from the macOS+iOS+Android installer so that we actually *have* a standalone iOS installer. The current situation is confusing for users, and no one wants a THREE GIGABYTE installer when they possibly don't care about the other two platforms in it. > - For MinGW I propose to start delivering 64 bit binary packages instead of 32 bit one & start using MinGW 6.x (6.2?) Does this make sense when we're still delivering 32-bit MSVC packages? I'd opt to keep 32-bit or have both. > - For Windows Android I propose to start doing Android Windows build with MinGW53 (if we are able to build it. Otherwise MinGW49 will be used as with 5.8) > > - For WinRT/WinPhone I propose to drop WinRT 8.1 and WinPhone 8.1 support & start using term UWP (Universal Windows platform). It means also dropping msvc 2013 from WinRT/WinPhone; UWP only supports msvc2015 Absolutely agree. > - Start supporting QNX 7.0 > > br, > > Jani Heikkinen > Release Manager > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From thiago.macieira at intel.com Wed Nov 23 01:05:50 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 22 Nov 2016 16:05:50 -0800 Subject: [Development] Summary ABI compabilty In-Reply-To: <201611230007.35685.kde@carewolf.com> References: <4008780.ms3XMRHI2B@tjmaciei-mobl1> <201611230007.35685.kde@carewolf.com> Message-ID: <1788418.bxUOh4kfcA@tjmaciei-mobl1> On quarta-feira, 23 de novembro de 2016 00:07:35 PST Allan Sandfeld Jensen wrote: > Can't we statically link to it, so that it doesn't matter which version the > application is using? No, same problem, which is exactly what the Linux distros are doing wrong. C++ requires certain symbols to be shared and obey ODR: the typeinfo for the base types and the virtual tables for some classes (notably, std::exception). If we statically link one of the libraries that contains those, then applications may or may not link to them at runtime. Breaking ODR for those is problematic. The solution is simple: we need to dynamically link to a library that provides those and just those. Both libc++ and libstdc++ have such a library: respectively, libc++abi and libsupc++. Linux distros need to make sure that only one of those exists and that both libc++ and libstdc++ link to it. But even if we do that, it doesn't solve the problem of using the std types in our ABI, like std::function which we desperately want to use. If our objective is to do that, then you can't replace. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Nov 23 01:07:25 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 22 Nov 2016 16:07:25 -0800 Subject: [Development] Qt 5.9 In-Reply-To: References: Message-ID: <2199330.PnWvMaGU1S@tjmaciei-mobl1> On terça-feira, 22 de novembro de 2016 23:46:32 PST Jake Petroules wrote: > > - For MinGW I propose to start delivering 64 bit binary packages instead > > of 32 bit one & start using MinGW 6.x (6.2?) > Does this make sense when we're still delivering 32-bit MSVC packages? I'd > opt to keep 32-bit or have both. I agree with Jake: replacing one with the other is not a good idea. We should provide both for a time, before dropping 32-bit. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Nov 23 02:58:55 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 22 Nov 2016 17:58:55 -0800 Subject: [Development] Qt 5.9 In-Reply-To: <2199330.PnWvMaGU1S@tjmaciei-mobl1> References: <2199330.PnWvMaGU1S@tjmaciei-mobl1> Message-ID: <2897390.EYxDb8PMXa@tjmaciei-mobl1> On terça-feira, 22 de novembro de 2016 16:07:25 PST Thiago Macieira wrote: > On terça-feira, 22 de novembro de 2016 23:46:32 PST Jake Petroules wrote: > > > - For MinGW I propose to start delivering 64 bit binary packages instead > > > of 32 bit one & start using MinGW 6.x (6.2?) > > > > Does this make sense when we're still delivering 32-bit MSVC packages? I'd > > opt to keep 32-bit or have both. > > I agree with Jake: replacing one with the other is not a good idea. We > should provide both for a time, before dropping 32-bit. If we still have time, I'd like to see MinGW 64-bit for 5.8, so we can drop the 32-bit binary build in time for 5.9. Otherwise, if we have to wait for 5.9 to bring MinGW 64-bit, then we can't drop 32-bit until 5.10. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Jake.Petroules at qt.io Wed Nov 23 03:06:14 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 23 Nov 2016 02:06:14 +0000 Subject: [Development] Qt 5.9 In-Reply-To: <2897390.EYxDb8PMXa@tjmaciei-mobl1> References: <2199330.PnWvMaGU1S@tjmaciei-mobl1> <2897390.EYxDb8PMXa@tjmaciei-mobl1> Message-ID: <9959662B-7314-4F53-AA32-8FBB76504173@qt.io> > On Nov 22, 2016, at 5:58 PM, Thiago Macieira wrote: > > On terça-feira, 22 de novembro de 2016 16:07:25 PST Thiago Macieira wrote: >> On terça-feira, 22 de novembro de 2016 23:46:32 PST Jake Petroules wrote: >>>> - For MinGW I propose to start delivering 64 bit binary packages instead >>>> of 32 bit one & start using MinGW 6.x (6.2?) >>> >>> Does this make sense when we're still delivering 32-bit MSVC packages? I'd >>> opt to keep 32-bit or have both. >> >> I agree with Jake: replacing one with the other is not a good idea. We >> should provide both for a time, before dropping 32-bit. > > If we still have time, I'd like to see MinGW 64-bit for 5.8, so we can drop > the 32-bit binary build in time for 5.9. > > Otherwise, if we have to wait for 5.9 to bring MinGW 64-bit, then we can't > drop 32-bit until 5.10. Agreed. We should also consider dropping 32-bit MSVC since we've had both for a while and we only support Windows 7 and above now, which should mean adoption is good enough to do so. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From thiago.macieira at intel.com Wed Nov 23 03:32:29 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 22 Nov 2016 18:32:29 -0800 Subject: [Development] Qt 5.9 In-Reply-To: <9959662B-7314-4F53-AA32-8FBB76504173@qt.io> References: <2897390.EYxDb8PMXa@tjmaciei-mobl1> <9959662B-7314-4F53-AA32-8FBB76504173@qt.io> Message-ID: <2457783.ZkubCd0Csk@tjmaciei-mobl1> On quarta-feira, 23 de novembro de 2016 02:06:14 PST Jake Petroules wrote: > > If we still have time, I'd like to see MinGW 64-bit for 5.8, so we can > > drop > > the 32-bit binary build in time for 5.9. > > > > Otherwise, if we have to wait for 5.9 to bring MinGW 64-bit, then we can't > > drop 32-bit until 5.10. > > Agreed. We should also consider dropping 32-bit MSVC since we've had both > for a while and we only support Windows 7 and above now, which should mean > adoption is good enough to do so. Good point. Considering that MSVC 2017 is coming (RC is already out), I'd also be prepared to have it available for 5.9, so I propose: 5.7 (for comparison, no change): 32-bit 64-bit MSVC 2013 Y Y MSVC 2015 Y Y MSVC 2017 N N MinGW Y N (5 packages) 5.8: 32-bit 64-bit MSVC 2013 Y Y MSVC 2015 N Y MSVC 2017 N N MinGW Y Y (5 packages) 5.9: 32-bit 64-bit MSVC 2013 N Y MSVC 2015 N Y MSVC 2017 N Y MinGW N Y (4 packages) This also allows us to pick one compiler to provide 32-bit support with if we need to. I just think it's time to let it die and get people who need it to compile from source. There are no current Intel 32-bit only CPUs that regular Windows runs on, only legacy. I don't know AMD's product line, but I'd be surprised if it is different. Intel does have new 32-bit only SoCs like [1], but whether Windows 10 IoT Core will run on them, I don't know. Even if it does, I doubt users will use our desktop binaries. [1] http://ark.intel.com/products/79084/Intel-Quark-SoC-X1000-16K-Cache-400-MHz -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Wed Nov 23 08:55:44 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 23 Nov 2016 10:55:44 +0300 Subject: [Development] Qt 5.9 In-Reply-To: <2457783.ZkubCd0Csk@tjmaciei-mobl1> References: <2897390.EYxDb8PMXa@tjmaciei-mobl1> <9959662B-7314-4F53-AA32-8FBB76504173@qt.io> <2457783.ZkubCd0Csk@tjmaciei-mobl1> Message-ID: <1628741479887744@web23m.yandex.ru> 23.11.2016, 05:32, "Thiago Macieira" : > On quarta-feira, 23 de novembro de 2016 02:06:14 PST Jake Petroules wrote: >>  > If we still have time, I'd like to see MinGW 64-bit for 5.8, so we can >>  > drop >>  > the 32-bit binary build in time for 5.9. >>  > >>  > Otherwise, if we have to wait for 5.9 to bring MinGW 64-bit, then we can't >>  > drop 32-bit until 5.10. >> >>  Agreed. We should also consider dropping 32-bit MSVC since we've had both >>  for a while and we only support Windows 7 and above now, which should mean >>  adoption is good enough to do so. > > Good point. Considering that MSVC 2017 is coming (RC is already out), I'd also > be prepared to have it available for 5.9, so I propose: > > 5.7 (for comparison, no change): >                 32-bit 64-bit > MSVC 2013 Y Y > MSVC 2015 Y Y > MSVC 2017 N N > MinGW Y N > (5 packages) > > 5.8: >                 32-bit 64-bit > MSVC 2013 Y Y > MSVC 2015 N Y > MSVC 2017 N N > MinGW Y Y > (5 packages) Why drop 32-bit builds with newer compiler and keep with older? > > 5.9: >                 32-bit 64-bit > MSVC 2013 N Y > MSVC 2015 N Y > MSVC 2017 N Y > MinGW N Y > (4 packages) > > This also allows us to pick one compiler to provide 32-bit support with if we > need to. I just think it's time to let it die and get people who need it to > compile from source. > > There are no current Intel 32-bit only CPUs that regular Windows runs on, only > legacy. I don't know AMD's product line, but I'd be surprised if it is > different. > > Intel does have new 32-bit only SoCs like [1], but whether Windows 10 IoT Core > will run on them, I don't know. Even if it does, I doubt users will use our > desktop binaries. > > [1] http://ark.intel.com/products/79084/Intel-Quark-SoC-X1000-16K-Cache-400-MHz > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From alexander.blasche at qt.io Wed Nov 23 08:56:00 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Wed, 23 Nov 2016 07:56:00 +0000 Subject: [Development] Qt 5.9 In-Reply-To: <2457783.ZkubCd0Csk@tjmaciei-mobl1> References: <2897390.EYxDb8PMXa@tjmaciei-mobl1> <9959662B-7314-4F53-AA32-8FBB76504173@qt.io> <2457783.ZkubCd0Csk@tjmaciei-mobl1> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Thiago > Macieira > Good point. Considering that MSVC 2017 is coming (RC is already out), I'd also > be prepared to have it available for 5.9, so I propose: > > 5.7 (for comparison, no change): > 32-bit 64-bit > MSVC 2013 Y Y > MSVC 2015 Y Y > MSVC 2017 N N > MinGW Y N > (5 packages) > > 5.8: > 32-bit 64-bit > MSVC 2013 Y Y > MSVC 2015 N Y I am not aware that we are dropping 2015 32bit support in 5.8. I thought the platform/compiler definition for 5.8 was set in stone a long time ago. > MSVC 2017 N N > MinGW Y Y > (5 packages) > > 5.9: > 32-bit 64-bit > MSVC 2013 N Y > MSVC 2015 N Y > MSVC 2017 N Y > MinGW N Y > (4 packages) I don't think we can drop all 32bit support. I do believe MSVC 2017 should be part of the deal though. That's a good suggestion. Keeping these two options in mind, I suggest to drop MSVC 2013 32 bit against MSVC 2017 64bit. This keeps the number of packages the same. > This also allows us to pick one compiler to provide 32-bit support with if we > need to. I just think it's time to let it die and get people who need it to compile > from source. Compiling Qt from source (especially on Windows) is still a major headache for our customers. > > There are no current Intel 32-bit only CPUs that regular Windows runs on, only > legacy. I don't know AMD's product line, but I'd be surprised if it is different. The currently sold CPU's are not really the measurement stick here. The measurement stick is actually installed Win 32 systems. -- Alex From alexander.blasche at qt.io Wed Nov 23 08:59:15 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Wed, 23 Nov 2016 07:59:15 +0000 Subject: [Development] Qt 5.9 In-Reply-To: References: <2897390.EYxDb8PMXa@tjmaciei-mobl1> <9959662B-7314-4F53-AA32-8FBB76504173@qt.io> <2457783.ZkubCd0Csk@tjmaciei-mobl1> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Alexander > Blasche > I don't think we can drop all 32bit support. I do believe MSVC 2017 should be > part of the deal though. That's a good suggestion. Keeping these two options in > mind, I suggest to drop MSVC 2013 32 bit against MSVC 2017 64bit. This keeps > the number of packages the same. To make it more obvious here is my suggestion: 5.9: 32-bit 64-bit MSVC 2013 N Y MSVC 2015 Y Y MSVC 2017 N Y MinGW N Y -- [Alexander Blasche] Alex From lars.knoll at qt.io Wed Nov 23 09:02:18 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 23 Nov 2016 08:02:18 +0000 Subject: [Development] Qt 5.9 In-Reply-To: References: <2897390.EYxDb8PMXa@tjmaciei-mobl1> <9959662B-7314-4F53-AA32-8FBB76504173@qt.io> <2457783.ZkubCd0Csk@tjmaciei-mobl1> Message-ID: I'm fine with this one as well, but as Thiago said in that case it would be good if we could provide 64bit MingW for 5.8 (maybe 5.8.1) to give people a little more time to migrate. Cheers, Lars On 23/11/16 08:59, "Development on behalf of Alexander Blasche" wrote: > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Alexander > Blasche > I don't think we can drop all 32bit support. I do believe MSVC 2017 should be > part of the deal though. That's a good suggestion. Keeping these two options in > mind, I suggest to drop MSVC 2013 32 bit against MSVC 2017 64bit. This keeps > the number of packages the same. To make it more obvious here is my suggestion: 5.9: 32-bit 64-bit MSVC 2013 N Y MSVC 2015 Y Y MSVC 2017 N Y MinGW N Y -- [Alexander Blasche] Alex _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Jake.Petroules at qt.io Wed Nov 23 09:10:36 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 23 Nov 2016 08:10:36 +0000 Subject: [Development] Qt 5.9 In-Reply-To: References: <2897390.EYxDb8PMXa@tjmaciei-mobl1> <9959662B-7314-4F53-AA32-8FBB76504173@qt.io> <2457783.ZkubCd0Csk@tjmaciei-mobl1> Message-ID: > On Nov 22, 2016, at 11:56 PM, Alexander Blasche wrote: > > > >> -----Original Message----- >> From: Development [mailto:development- >> bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Thiago >> Macieira > > > >> Good point. Considering that MSVC 2017 is coming (RC is already out), I'd also >> be prepared to have it available for 5.9, so I propose: >> >> 5.7 (for comparison, no change): >> 32-bit 64-bit >> MSVC 2013 Y Y >> MSVC 2015 Y Y >> MSVC 2017 N N >> MinGW Y N >> (5 packages) >> >> 5.8: >> 32-bit 64-bit >> MSVC 2013 Y Y >> MSVC 2015 N Y > I am not aware that we are dropping 2015 32bit support in 5.8. I thought the platform/compiler definition for 5.8 was set in stone a long time ago. > >> MSVC 2017 N N >> MinGW Y Y >> (5 packages) >> >> 5.9: >> 32-bit 64-bit >> MSVC 2013 N Y >> MSVC 2015 N Y >> MSVC 2017 N Y >> MinGW N Y >> (4 packages) > > I don't think we can drop all 32bit support. I do believe MSVC 2017 should be part of the deal though. That's a good suggestion. Keeping these two options in mind, I suggest to drop MSVC 2013 32 bit against MSVC 2017 64bit. This keeps the number of packages the same. No one suggested dropping *all* 32-bit support just now, but I think we should reduce the number of 32-bit packages now and move towards eliminating them entirely within the next few releases. > >> This also allows us to pick one compiler to provide 32-bit support with if we >> need to. I just think it's time to let it die and get people who need it to compile >> from source. > > Compiling Qt from source (especially on Windows) is still a major headache for our customers. s/customers/users/; this applies to all license types. Also, I don't think this is a relevant counterargument. Compiling Qt from source statically is a major headache for our users as well, yet we don't provide binary packages for Qt built statically. Let's instead focus on the question of whether 32-bit support is actually relevant to enough of our users to bother spending resources on it. >> >> There are no current Intel 32-bit only CPUs that regular Windows runs on, only >> legacy. I don't know AMD's product line, but I'd be surprised if it is different. > > The currently sold CPU's are not really the measurement stick here. The measurement stick is actually installed Win 32 systems. Yes, but what's the 32-bit Windows install base which is capable of running Qt? We only support Windows 7 and above now, so I can't imagine it's very many. Perhaps we should try to find some metrics to base our decision on. > > > -- > Alex > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From lars.knoll at qt.io Wed Nov 23 09:17:01 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 23 Nov 2016 08:17:01 +0000 Subject: [Development] Summary ABI compabilty In-Reply-To: <1788418.bxUOh4kfcA@tjmaciei-mobl1> References: <4008780.ms3XMRHI2B@tjmaciei-mobl1> <201611230007.35685.kde@carewolf.com> <1788418.bxUOh4kfcA@tjmaciei-mobl1> Message-ID: I think we are mixing two problems that should be handled separately in this whole thread. The first one is the question how much of libstdc++ we want to use and expose in our APIs. The second question is about our BC promise between minor and patch level releases. Let's keep these two questions separated and don't mix those in the discussions. There are a lot of good arguments towards using the STL and libstdc++ more, as it will allow us to interoperate better with the C++ standard, and provides a couple of things that we really want to use. So I can see many good arguments towards going down that route. Doing so will bind the compiled Qt binary to a certain version of that library (ie, it will require a recompile of Qt to switch from libc++ to libstdc++). To a large extent that is no different than the situation we're facing with e.g. different VC++ runtimes. It also doesn't create impossible challenges for the Linux packagers/distributors (or at least the challenges won't be caused by us). So I'm positive towards using more of the standard functionality and APIs (and also exposing them in our APIs). Breaking BC in Qt minor or patch level releases is a totally different question. So far I have not convincing arguments as to why we would gain a lot here. We've managed for years to fix our bugs and introduce new features without breaking BC, I don't see why this should be different now. We will have a well defined point where we can break BC with Qt 6 and I think it's beneficial to have these breakages only at well defined points. Let's also not forget that breaking BC in minor releases would come at a severe cost for the Linux ecosystem, an ecosystem we want to support as good as we can. Cheers, Lars I think this is something we probably just need to do, as we see more As we all know there are quite a few things we really would like to use On 23/11/16 01:05, "Development on behalf of Thiago Macieira" wrote: On quarta-feira, 23 de novembro de 2016 00:07:35 PST Allan Sandfeld Jensen wrote: > Can't we statically link to it, so that it doesn't matter which version the > application is using? No, same problem, which is exactly what the Linux distros are doing wrong. C++ requires certain symbols to be shared and obey ODR: the typeinfo for the base types and the virtual tables for some classes (notably, std::exception). If we statically link one of the libraries that contains those, then applications may or may not link to them at runtime. Breaking ODR for those is problematic. The solution is simple: we need to dynamically link to a library that provides those and just those. Both libc++ and libstdc++ have such a library: respectively, libc++abi and libsupc++. Linux distros need to make sure that only one of those exists and that both libc++ and libstdc++ link to it. But even if we do that, it doesn't solve the problem of using the std types in our ABI, like std::function which we desperately want to use. If our objective is to do that, then you can't replace. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Wed Nov 23 09:22:09 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 23 Nov 2016 00:22:09 -0800 Subject: [Development] Qt 5.9 In-Reply-To: References: Message-ID: <8182754.2IByElXpg7@tjmaciei-mobl1> On quarta-feira, 23 de novembro de 2016 08:10:36 PST Jake Petroules wrote: > > The currently sold CPU's are not really the measurement stick here. The > > measurement stick is actually installed Win 32 systems. > Yes, but what's the 32-bit Windows install base which is capable of running > Qt? We only support Windows 7 and above now, so I can't imagine it's very > many. Perhaps we should try to find some metrics to base our decision on. That's an important point: since Qt 5.7, we no longer support anything older than Windows 7. That was the first Windows with decent 64-bit support and computers with Windows 7, 8, 8.1 and now 10 tended to come with the 64-bit version pre-installed. So the chances of users running 64-bit Windows are much higher now. We only have to contend with pre-2007 computers that have been upgraded since. And netbooks, since many of the first and second generation Atom came with their 64-bit capabilities fused off. (Ultrabooks are always 64-bit and actually use Core processors, not Atom) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Nov 23 09:15:29 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 23 Nov 2016 00:15:29 -0800 Subject: [Development] Qt 5.9 In-Reply-To: References: <2457783.ZkubCd0Csk@tjmaciei-mobl1> Message-ID: <6902831.PO4QU8eVLd@tjmaciei-mobl1> On quarta-feira, 23 de novembro de 2016 07:56:00 PST Alexander Blasche wrote: > > 5.8: > > 32-bit 64-bit > > MSVC 2013 Y Y > > MSVC 2015 N Y > > I am not aware that we are dropping 2015 32bit support in 5.8. I thought the > platform/compiler definition for 5.8 was set in stone a long time ago. This is a proposal. In order to keep the work the same, I decided to drop one MSVC 32-bit to make room for MinGW 64-bit. To answer Konstantin: I thought it was more likely people were still using 32-bit when they hadn't yet upgraded their compilers. This is an unproven guess. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Maurice.Kalinowski at qt.io Wed Nov 23 09:44:30 2016 From: Maurice.Kalinowski at qt.io (Maurice Kalinowski) Date: Wed, 23 Nov 2016 08:44:30 +0000 Subject: [Development] Qt 5.9 In-Reply-To: <8182754.2IByElXpg7@tjmaciei-mobl1> References: <8182754.2IByElXpg7@tjmaciei-mobl1> Message-ID: > On quarta-feira, 23 de novembro de 2016 08:10:36 PST Jake Petroules wrote: > > > The currently sold CPU's are not really the measurement stick here. > > > The measurement stick is actually installed Win 32 systems. > > Yes, but what's the 32-bit Windows install base which is capable of > > running Qt? We only support Windows 7 and above now, so I can't > > imagine it's very many. Perhaps we should try to find some metrics to base > our decision on. > > That's an important point: since Qt 5.7, we no longer support anything older > than Windows 7. That was the first Windows with decent 64-bit support and > computers with Windows 7, 8, 8.1 and now 10 tended to come with the 64- > bit version pre-installed. So the chances of users running 64-bit Windows are > much higher now. > [Kalinowski Maurice] This is only true for the desktop case. Especially those cheap tablets with Windows 10 in the ~100Euro area still have Windows 10 32bit included. That touches a pretty big consumer area. Also note, that those is only for classic app development. For WinRT we still need x86 packages, because first x86 packages should be part of the bundle, and secondly the x86 build can be (and actually is) used for the Windows 10 (Mobile) emulators in addition . BR, Maurice From Maurice.Kalinowski at qt.io Wed Nov 23 09:48:02 2016 From: Maurice.Kalinowski at qt.io (Maurice Kalinowski) Date: Wed, 23 Nov 2016 08:48:02 +0000 Subject: [Development] Qt 5.9 In-Reply-To: References: Message-ID: > > - For WinRT/WinPhone I propose to drop WinRT 8.1 and WinPhone 8.1 > support & start using term UWP (Universal Windows platform). It means also > dropping msvc 2013 from WinRT/WinPhone; UWP only supports msvc2015 > > Absolutely agree. [Kalinowski Maurice] Start using the term UWP in our website etc. WinRT is still a technical correct term for the API. So we should not start simply renaming mkspecs or such. In addition this causes a couple of changes to our CI system. My proposal would be: - Have winrt-x86-msvc2015 (or winrt-x64-msvc2015) replace the winphone-arm-msvc2013 test target on CI. Right now this would be the same build test, but I still hope that CI resources will allow regular CI auto tests at one point - Have winrt-arm-msvc2015 replace winrt-x86-msvc2015 replace to be tested during qt5.git integration. Currently Windows 10 (UWP) is only tested for the integration due to resource constraints. It should not get worse when we are removing platforms. BR, Maurice From tim at klingt.org Wed Nov 23 10:49:51 2016 From: tim at klingt.org (Tim Blechmann) Date: Wed, 23 Nov 2016 10:49:51 +0100 Subject: [Development] Qt 5.9 In-Reply-To: <8182754.2IByElXpg7@tjmaciei-mobl1> References: <8182754.2IByElXpg7@tjmaciei-mobl1> Message-ID: hi all, >>> The currently sold CPU's are not really the measurement stick here. The >>> measurement stick is actually installed Win 32 systems. >> Yes, but what's the 32-bit Windows install base which is capable of running >> Qt? We only support Windows 7 and above now, so I can't imagine it's very >> many. Perhaps we should try to find some metrics to base our decision on. > > That's an important point: since Qt 5.7, we no longer support anything older > than Windows 7. That was the first Windows with decent 64-bit support and > computers with Windows 7, 8, 8.1 and now 10 tended to come with the 64-bit > version pre-installed. So the chances of users running 64-bit Windows are much > higher now. when using qt inside a plugin it is not necessarily a question how many users are on 64-bit windows, but how many are on 64-bit hosts, as 32-bit host can run on 64-bit windows. i don't care about the binary packages, though. as long as i can still build from sources, i'm fine ... but please don't completely drop support for 32-bit windows. cheers, tim From Jake.Petroules at qt.io Wed Nov 23 11:11:22 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 23 Nov 2016 10:11:22 +0000 Subject: [Development] Qt 5.9 In-Reply-To: References: <8182754.2IByElXpg7@tjmaciei-mobl1> Message-ID: > On Nov 23, 2016, at 1:49 AM, Tim Blechmann wrote: > > hi all, > >>>> The currently sold CPU's are not really the measurement stick here. The >>>> measurement stick is actually installed Win 32 systems. >>> Yes, but what's the 32-bit Windows install base which is capable of running >>> Qt? We only support Windows 7 and above now, so I can't imagine it's very >>> many. Perhaps we should try to find some metrics to base our decision on. >> >> That's an important point: since Qt 5.7, we no longer support anything older >> than Windows 7. That was the first Windows with decent 64-bit support and >> computers with Windows 7, 8, 8.1 and now 10 tended to come with the 64-bit >> version pre-installed. So the chances of users running 64-bit Windows are much >> higher now. > > when using qt inside a plugin it is not necessarily a question how many > users are on 64-bit windows, but how many are on 64-bit hosts, as 32-bit > host can run on 64-bit windows. True, and this is a good point. Many Windows applications are still 32-bit. > > i don't care about the binary packages, though. as long as i can still > build from sources, i'm fine ... but please don't completely drop > support for 32-bit windows. Of course this is out of the question (and would be of little to no benefit to Qt). We're talking ONLY about binary packages here, not to worry. :) > > cheers, > tim > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From massimocallegari at yahoo.it Wed Nov 23 11:24:58 2016 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Wed, 23 Nov 2016 10:24:58 +0000 (UTC) Subject: [Development] Qt 5.9 In-Reply-To: References: Message-ID: <1102843838.360155.1479896698820@mail.yahoo.com> Hi, is there any chance Qt 5.9 can support MSYS2 out of the box ? For us Linux users, MSYS2 feels like home, and it's the most convenient environment to work with external dependencies simply by using pkg-config. At the moment, the MSYS2 project is stuck on Qt 5.6.2, I believe mainly cause of QtWebEngine, which AFAIK can't still be built on MSYS2. I contributed with some updated patches to build Qt 5.7 but still QtWebEngine is excluded from the build. Supporting MSYS2 would mean 2 things: 1) evaluate the patches that are currently in the GH repo [1] and [2] and check if they're worth to be merged upstream 2) possibly add MSYS2 to the Qt CI system, to deliver a pre-built Qt package in the pkg.tar.xz format suitable for PacMan Would be nice to finally have QtWebEngine to build on MSYS2 as well. I can give my assistance in the process, but the content of some patches targeting qtbase is beyond my knowledge of the Qt build files. Plus, a lot of work has been done on Qt 5.8.0 in that sense, so probably some things have already been addressed or just need to be lightly adjusted. Regards, Massimo [1] https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-qt5 (Qt 5.6.2) [2] https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-qt5-git (Qt 5.7.0) ________________________________ Da: Jani Heikkinen A: "development at qt-project.org" Cc: "releasing at qt-project.org" Inviato: Martedì 22 Novembre 2016 12:42 Oggetto: [Development] Qt 5.9 Hi all, We need to start preparations for Qt5.9 release even Qt 5.8.0 isn't out yet :) There are some things to be agreed already now: - Qt 5.9.0 Feature Freeze - Changes in supported platforms/configurations So first of all let's agree the feature freeze date: I propose to have the FF 1.2.2017. From the history we can see that time needed from FF to final release is (even more than) 17 weeks. I know it is too long time but at the moment that is the fact and there is no evidence that we can do it within shorter schedule. We are trying to find ways to make it shorter but at the moment there isn't any big improvements coming and so on that 17 weeks is the best base for our plans. So if we want to get Qt 5.9.0 release out before summer holidays we need to have ff at the beginning of February. And note: At this time we want to keep the FF date to be able to keep the schedule. That means there won't be any exceptions: If feature isn't ready and in at FF date then it won't be in Qt 5.9 release. So please make sure all new features are in early enough & those are fulfilling the ff requirements: https://wiki.qt.io/Qt_5_Feature_Freeze Then I propose following changes in supported platforms/configurations: - We have earlier agreed that for Apple we will support three latest versions. So this means * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 * For iOS we drop 7.x and support 8.x, 9.x, 10.x - I propose to drop standalone macOS Android installer; One having iOS & Android should be enough - For MinGW I propose to start delivering 64 bit binary packages instead of 32 bit one & start using MinGW 6.x (6.2?) - For Windows Android I propose to start doing Android Windows build with MinGW53 (if we are able to build it. Otherwise MinGW49 will be used as with 5.8) - For WinRT/WinPhone I propose to drop WinRT 8.1 and WinPhone 8.1 support & start using term UWP (Universal Windows platform). It means also dropping msvc 2013 from WinRT/WinPhone; UWP only supports msvc2015 - Start supporting QNX 7.0 br, Jani Heikkinen Release Manager _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From akseli.salovaara at qt.io Wed Nov 23 11:40:53 2016 From: akseli.salovaara at qt.io (Akseli Salovaara) Date: Wed, 23 Nov 2016 10:40:53 +0000 Subject: [Development] Qt 5.7.1 packages available Message-ID: Hi all, We have most likely final Qt 5.7.1 snapshot available Linux: http://download.qt.io/snapshots/qt/5.7/5.7.1/579/ Mac: http://download.qt.io/snapshots/qt/5.7/5.7.1/617/ Windows: http://download.qt.io/snapshots/qt/5.7/5.7.1/664/ Src: http://download.qt.io/snapshots/qt/5.7/5.7.1/latest_src/ According to RTA smoke testing packages seems to be OK so please test the packages as soon as possible. All known blockers should be fixed, please verify fixes for open ones ( https://bugreports.qt.io/issues/?filter=17833 ). We will release these packages as Qt 5.7.1 later (maybe next Tuesday) if nothing really serious found during testing. Please update the known issues page when needed: https://wiki.qt.io/Qt_5.7.1_Known_Issues Known issues in the packages: https://bugreports.qt.io/issues/?filter=18129 Br, Akseli From helmut.muelner at gmail.com Wed Nov 23 11:45:12 2016 From: helmut.muelner at gmail.com (=?iso-8859-1?Q?Helmut_M=FClner?=) Date: Wed, 23 Nov 2016 11:45:12 +0100 Subject: [Development] Qt 5.9 In-Reply-To: <8182754.2IByElXpg7@tjmaciei-mobl1> References: <8182754.2IByElXpg7@tjmaciei-mobl1> Message-ID: <004f01d24576$ab541ec0$01fc5c40$@gmail.com> > Von: Development [mailto:development-bounces+helmut.muelner=gmail.com at qt-project.org] Im Auftrag von Thiago Macieira > Gesendet: Mittwoch, 23. November 2016 09:22 > On quarta-feira, 23 de novembro de 2016 08:10:36 PST Jake Petroules wrote: > > > The currently sold CPU's are not really the measurement stick here. > > > The measurement stick is actually installed Win 32 systems. > > Yes, but what's the 32-bit Windows install base which is capable of > > running Qt? We only support Windows 7 and above now, so I can't > > imagine it's very many. Perhaps we should try to find some metrics to base our decision on. > That's an important point: since Qt 5.7, we no longer support anything older than Windows 7. > That was the first Windows with decent 64-bit support and computers with Windows 7, 8, 8.1 and now 10 tended > to come with the 64-bit version pre-installed. > So the chances of users running 64-bit Windows are much higher now. > We only have to contend with pre-2007 computers that have been upgraded since. > And netbooks, since many of the first and second generation Atom came with their 64-bit capabilities fused off. > (Ultrabooks are always 64-bit and actually use Core processors, not Atom) That is not relevant here. I am using Windows 10 (64-bit) but I am still forced (because of 3rt-party-libraries) to develop 32-bit-Qt-applications. Even if the operating system is 64-bit there can be a lot of 32-bit application, e.g. VS 2013 and VS 2015 are still 32-bit applications. Helmut Mülner From annulen at yandex.ru Wed Nov 23 12:02:02 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 23 Nov 2016 14:02:02 +0300 Subject: [Development] Qt 5.9 In-Reply-To: <1102843838.360155.1479896698820@mail.yahoo.com> References: <1102843838.360155.1479896698820@mail.yahoo.com> Message-ID: <367141479898922@web30o.yandex.ru> 23.11.2016, 13:26, "Massimo Callegari via Development" : > Hi, > is there any chance Qt 5.9 can support MSYS2 out of the box ? > > For us Linux users, MSYS2 feels like home, and it's the most convenient environment to work with external dependencies simply by using pkg-config. > > At the moment, the MSYS2 project is stuck on Qt 5.6.2, I believe mainly cause of QtWebEngine, which AFAIK can't still be built on MSYS2. > I contributed with some updated patches to build Qt 5.7 but still QtWebEngine is excluded from the build. > > Supporting MSYS2 would mean 2 things: > 1) evaluate the patches that are currently in the GH repo [1] and [2] and check if they're worth to be merged upstream I'm afraid it does not work in this way. The following process is more likely to get desired result: 1. Patch authors who own copyright on the code and understand why each piece is needed should contribute patches to codereview.qt-project.org. 2. When you end up with sane amount of local patches (maybe 3-5) which you cannot handle in a step (1), we can discuss it again. > > 2) possibly add MSYS2 to the Qt CI system, to deliver a pre-built Qt package in the pkg.tar.xz format suitable for PacMan > > Would be nice to finally have QtWebEngine to build on MSYS2 as well. Revived QtWebKit[1] supports MinGW[2], you can use instead of QtWebEngine for some applications [1] http://qtwebkit.blogspot.ru/2016/08/qtwebkit-im-back.html [2]actually, it's in a one patch distance from it, will be fixed soon > > I can give my assistance in the process, but the content of some patches targeting qtbase is beyond my knowledge of the Qt build files. > Plus, a lot of work has been done on Qt 5.8.0 in that sense, so probably some things have already been addressed or just need to be lightly adjusted. > > Regards, > Massimo > [1] https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-qt5 (Qt 5.6.2) > [2] https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-qt5-git (Qt 5.7.0) > > ________________________________ > Da: Jani Heikkinen > A: "development at qt-project.org" > Cc: "releasing at qt-project.org" > Inviato: Martedì 22 Novembre 2016 12:42 > Oggetto: [Development] Qt 5.9 > > Hi all, > We need to start preparations for Qt5.9 release even Qt 5.8.0 isn't out yet :) There are some things to be agreed already now: > > - Qt 5.9.0 Feature Freeze > - Changes in supported platforms/configurations > > So first of all let's agree the feature freeze date: I propose to have the FF 1.2.2017. From the history we can see that time needed from FF to final release is (even more than) 17 weeks. I know it is too long time but at the moment that is the fact and there is no evidence that we can do it within shorter schedule. We are trying to find ways to make it shorter but at the moment there isn't any big improvements coming and so on that 17 weeks is the best base for our plans. So if we want to get Qt 5.9.0 release out before summer holidays we need to have ff at the beginning of February. > > And note: At this time we want to keep the FF date to be able to keep the schedule. That means there won't be any exceptions: If feature isn't ready and in at FF date then it won't be in Qt 5.9 release. So please make sure all new features are in early enough & those are fulfilling the ff requirements: https://wiki.qt.io/Qt_5_Feature_Freeze > > Then I propose following changes in supported platforms/configurations: > > - We have earlier agreed that for Apple we will support three latest versions. So this means >    * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 >    * For iOS we drop 7.x and support 8.x, 9.x, 10.x > > - I propose to drop standalone macOS Android installer; One having iOS & Android should be enough > > - For MinGW I propose to start delivering 64 bit binary packages instead of 32 bit one & start using MinGW 6.x (6.2?) > > - For Windows Android I propose to start doing Android Windows build with MinGW53 (if we are able to build it. Otherwise MinGW49 will be used as with 5.8) > > - For WinRT/WinPhone I propose to drop WinRT 8.1 and WinPhone 8.1 support & start using term UWP (Universal Windows platform). It means also dropping msvc 2013 from WinRT/WinPhone; UWP only supports msvc2015 > > - Start supporting QNX 7.0 > > br, > > Jani Heikkinen > Release Manager > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From rafael.roquetto at kdab.com Wed Nov 23 12:36:32 2016 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Wed, 23 Nov 2016 09:36:32 -0200 Subject: [Development] Qt 5.9 In-Reply-To: References: Message-ID: <20161123113630.GA10086@polaris.localdomain> Hello, On Tue, Nov 22, 2016 at 11:42:52AM +0000, Jani Heikkinen wrote: > Hi all, > - Start supporting QNX 7.0 Has the QtC already laid out a plan for what needs to be considered for this? I intend to start looking into it soon, but it would be best if we coordinated this together in order to avoid duplicated efforts. In particular, we also want to properly support QNX 7 on QtCreator, which is orthogonal to having QNX 7 support on Qt 5.9, timing wise it makes sense. Thanks, Rafael -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3599 bytes Desc: not available URL: From simoneverts at gmail.com Wed Nov 23 22:14:52 2016 From: simoneverts at gmail.com (Simon Everts) Date: Wed, 23 Nov 2016 21:14:52 +0000 Subject: [Development] Qt 5.9 In-Reply-To: <004f01d24576$ab541ec0$01fc5c40$@gmail.com> References: <8182754.2IByElXpg7@tjmaciei-mobl1> <004f01d24576$ab541ec0$01fc5c40$@gmail.com> Message-ID: Op wo 23 nov. 2016 om 11:45 schreef Helmut Mülner : > > > That is not relevant here. I am using Windows 10 (64-bit) but I am still > forced (because of 3rt-party-libraries) to develop 32-bit-Qt-applications. > Even if the operating system is 64-bit there can be a lot of 32-bit > application, e.g. VS 2013 and VS 2015 are still 32-bit applications. > +1 As a machine manufacturer we are still deploying 32bit windows systems because of this reason. We'll be on 64bit windows soon, but need to support the 32bit systems for at least 5 years. A lot of industrial computer suppliers still install 32bit images on computers because there aren't any 64bit drivers available for the hardware. We have no need to create 64bit apps, so its easier to just only create 32bit apps so it's compatible with all systems we need to maintain. Best regards, Simon Everts -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Nov 23 23:10:31 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 23 Nov 2016 14:10:31 -0800 Subject: [Development] Qt 5.9 In-Reply-To: References: <004f01d24576$ab541ec0$01fc5c40$@gmail.com> Message-ID: <2374789.4RfaRo27MI@tjmaciei-mobl1> On quarta-feira, 23 de novembro de 2016 21:14:52 PST Simon Everts wrote: > > That is not relevant here. I am using Windows 10 (64-bit) but I am still > > forced (because of 3rt-party-libraries) to develop 32-bit-Qt-applications. > > Even if the operating system is 64-bit there can be a lot of 32-bit > > application, e.g. VS 2013 and VS 2015 are still 32-bit applications. > > +1 > > As a machine manufacturer we are still deploying 32bit windows systems > because of this reason. We'll be on 64bit windows soon, but need to support > the 32bit systems for at least 5 years. A lot of industrial computer > suppliers still install 32bit images on computers because there aren't any > 64bit drivers available for the hardware. Good, thanks for the information, Simon and Helmut. I know the sample size here is horrible, but in your opinion what compiler should we keep offering a 32-bit binary build for? MSVC 2013 MSVC 2015 MinGW -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tuukka.turunen at qt.io Thu Nov 24 06:40:12 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 24 Nov 2016 05:40:12 +0000 Subject: [Development] Qt 5.9 In-Reply-To: <20161123113630.GA10086@polaris.localdomain> References: <20161123113630.GA10086@polaris.localdomain> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Rafael > Roquetto > Sent: keskiviikkona 23. marraskuuta 2016 13.37 > To: Jani Heikkinen > Cc: development at qt-project.org; releasing at qt-project.org > Subject: Re: [Development] Qt 5.9 > > Hello, > > On Tue, Nov 22, 2016 at 11:42:52AM +0000, Jani Heikkinen wrote: > > Hi all, > > > - Start supporting QNX 7.0 > > Has the QtC already laid out a plan for what needs to be considered for this? I > intend to start looking into it soon, but it would be best if we coordinated this > together in order to avoid duplicated efforts. In particular, we also want to > properly support QNX 7 on QtCreator, which is orthogonal to having QNX 7 > support on Qt 5.9, timing wise it makes sense. > To some extent, yes. Having proper c++11 support QNX 7 actually makes some things easier, while of course we still need to support QNX 6.6 as well. One of the first steps is to add QNX 7 to Qt CI system for dev and 5.9 - at least for build testing. There will be many items to tweak and polish, and hope is that you and James will participate actively, as discussed at QtCon. I am well aware the Qt release cycle is a bit quick to keep up with, but hope is we will be able to have good support for new QNX 7 already with Qt 5.9. Yours, Tuukka > Thanks, > Rafael > > -- > Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46- > 563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL > Experts From Uwe.Rathmann at tigertal.de Thu Nov 24 08:38:20 2016 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Thu, 24 Nov 2016 07:38:20 +0000 (UTC) Subject: [Development] Recommendations for 3rd-party QCH file installation folder for easy discovery? References: <2244793.ZbTD6rx2HE@klux.site> Message-ID: On Tue, 22 Nov 2016 18:05:20 +0100, Friedrich W. H. Kossebau wrote: > Q1: what would be a good system path pattern (on *nixoid systems) for > Qt-based libraries to install their QCH files to? Qwt ( http://qwt.sf.net ) offers a qch file and is available for quite some time. So you could check, what is common practice among distro packagers. F.e. on my box ( OpenSusSE 12.2 ) it is simply not part of qwt6-devel- doc. But the OpenSuSE package maintainer seems in general not being aware of these Qt specific files as the installation of the feature files is also broken. But the rest of the docs can be found below /usr/share/doc/packages/qwt6- devel-doc and IMO this is where I would expect to find qwt.qch as well. Maybe other distros can give you a better hint. > Q2: And would/could there be some way to have 3rd-party QCH files > automatically added to Qt Assistant, Creator & Co. on installation, to > spare the user the additional manual step? To me one of the most error prone things is loading 3rd party plugins to the creator. This has mostly to do with binary incompatibilities between the libraries used for development and the one used by the Creator ( Assistant is less bad as being built together with Qt libs ) , but the fact, that plugins are loaded "automatically" from some directories is part of the problem. Coming from having experienced maximal user frustration with this approach I wouldn't recommend to establish such an automatism. Uwe From simoneverts at gmail.com Thu Nov 24 10:01:40 2016 From: simoneverts at gmail.com (Simon Everts) Date: Thu, 24 Nov 2016 09:01:40 +0000 Subject: [Development] Qt 5.9 In-Reply-To: <2374789.4RfaRo27MI@tjmaciei-mobl1> References: <004f01d24576$ab541ec0$01fc5c40$@gmail.com> <2374789.4RfaRo27MI@tjmaciei-mobl1> Message-ID: Op wo 23 nov. 2016 om 23:10 schreef Thiago Macieira < thiago.macieira at intel.com>: > > I know the sample size here is horrible, but in your opinion what compiler > should we keep offering a 32-bit binary build for? > > MSVC 2013 > MSVC 2015 > MinGW > > Currently we're using Qt5.5 with MSVC2010 and Qt5.7 with MSVC 2013. I have no problem updating the compiler when updating to a new minor Qt release since we use windeployqt. If Qt is installed in the PATH, then I would only update the compiler on a major Qt release or compile it using a infix. I'm not considering using MinGW professionally. We had issues with it in the past and also use tools like Intel Parallel Studio and Resharper-c++ that integrate with MSVC. Best regards, Simon Everts -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at qt.io Thu Nov 24 11:59:31 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Thu, 24 Nov 2016 10:59:31 +0000 Subject: [Development] Qt 5.9 In-Reply-To: <2374789.4RfaRo27MI@tjmaciei-mobl1> References: <004f01d24576$ab541ec0$01fc5c40$@gmail.com> <2374789.4RfaRo27MI@tjmaciei-mobl1> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Thiago > Macieira > I know the sample size here is horrible, but in your opinion what compiler should > we keep offering a 32-bit binary build for? > > MSVC 2013 > MSVC 2015 > MinGW I can offer one more pointer for this question. Looking at our Visual Studio Addon 2.0 release: MSVC2013 https://marketplace.visualstudio.com/items?itemName=TheQtCompany.QtVisualStudioTools MSVC2015 https://marketplace.visualstudio.com/items?itemName=TheQtCompany.QtVisualStudioTools2015 We can see a strong preference for MSVC2015 in the download figures (370 vs 1620 as of just now). MSVC2015 32bit would live much longer as a supported compiler option for the Qt project as well. -- Alex From Gatis.Paeglis at qt.io Thu Nov 24 14:00:32 2016 From: Gatis.Paeglis at qt.io (Gatis Paeglis) Date: Thu, 24 Nov 2016 13:00:32 +0000 Subject: [Development] Nominating Teemu Holappa for Approver and Maintainer status. Message-ID: Hi, I'd like to nominate Teemu Holappa for the Approver status. He joined Digia (now The Qt Company) 3+ years ago as a Qt consultant. Teemu has contributed to meta-boot2qt and anything else that needs fixing to get Qt for Device Creation releases out the door. Here is his gerrit dashboard: https://codereview.qt-project.org/#/q/owner:%22Teemu+Holappa+%253Cteemu.holappa%2540qt.io%253E%22+status:merged,n,z Teemu also has done a good job at reviewing changes for meta-{boot2qt, qt5, mingw} among other projects: https://codereview.qt-project.org/#/q/reviewer:%22Teemu+Holappa+%253Cteemu.holappa%2540qt.io%253E%22+status:merged,n,z I'd also like to nominate him as the Maintainer of the qtdeviceutilities module (http://code.qt.io/cgit/qt/qtdeviceutilities.git/). Teemu has heavily refactored this module and added significant amount of new features. He is the go-to guy in the team when qtdeviceutilities is the topic. Gatis Paeglis. -------------- next part -------------- An HTML attachment was scrubbed... URL: From perezmeyer at gmail.com Thu Nov 24 15:08:56 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Thu, 24 Nov 2016 11:08:56 -0300 Subject: [Development] Recommendations for 3rd-party QCH file installation folder for easy discovery? In-Reply-To: References: <2244793.ZbTD6rx2HE@klux.site> Message-ID: <92504770.cgoorlbV0K@tonks> On jueves, 24 de noviembre de 2016 07:38:20 ART Uwe Rathmann wrote: > On Tue, 22 Nov 2016 18:05:20 +0100, Friedrich W. H. Kossebau wrote: > > Q1: what would be a good system path pattern (on *nixoid systems) for > > Qt-based libraries to install their QCH files to? > > Qwt ( http://qwt.sf.net ) offers a qch file and is available for quite > some time. So you could check, what is common practice among distro > packagers. > > F.e. on my box ( OpenSusSE 12.2 ) it is simply not part of qwt6-devel- > doc. But the OpenSuSE package maintainer seems in general not being aware > of these Qt specific files as the installation of the feature files is > also broken. > > But the rest of the docs can be found below /usr/share/doc/packages/qwt6- > devel-doc and IMO this is where I would expect to find qwt.qch as well. > > Maybe other distros can give you a better hint. At least on Debian I would push them to /usr/share//doc/ > > Q2: And would/could there be some way to have 3rd-party QCH files > > automatically added to Qt Assistant, Creator & Co. on installation, to > > spare the user the additional manual step? > > To me one of the most error prone things is loading 3rd party plugins to > the creator. This has mostly to do with binary incompatibilities between > the libraries used for development and the one used by the Creator > ( Assistant is less bad as being built together with Qt libs ) , but the > fact, that plugins are loaded "automatically" from some directories is > part of the problem. > > Coming from having experienced maximal user frustration with this > approach I wouldn't recommend to establish such an automatism. Note he says qch. I don't think it uses plugins for that. -- Must it be assumed that because we are engineers beauty is not our concern, and that while we make our constructions robust and durable we do not also strive to make them elegant? Is it not true that the genuine conditions of strength always comply with the secret conditions of harmony? Gustave Eiffel, 1887 Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From Marco.Bubke at qt.io Thu Nov 24 17:48:11 2016 From: Marco.Bubke at qt.io (Marco Bubke) Date: Thu, 24 Nov 2016 16:48:11 +0000 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <583716F4.2070407@gmail.com> References: <1573437.LOW8d6lCRL@tjmaciei-mobl1> <6860115.ORWOTKtl0j@tjmaciei-mobl1> , <583716F4.2070407@gmail.com> Message-ID: So you are writing a style for the QPaintEngine. What if you have a OpenGL back end or some other back ends where your descriptions does not fit that well any more? I have seen much more complicated things written in an abstract way, so it should be possible. And I haven't said that you should use CSS. Some custom DSL would quite handy. Actually I don't care about that fancy styles, they looks too baroque to me but I want something like Flatpak so I don't have work with outdated packages! But that are my priorities. [?] ________________________________ From: Matthew Woehlke Sent: Thursday, November 24, 2016 5:36:04 PM To: development at qt-project.org Cc: Marco Bubke Subject: Re: Basing Qt Creator Coding Style on C++ Core Guidelines? On 2016-11-22 06:25, Marco Bubke wrote: > On November 22, 2016 08:17:57 Thiago Macieira wrote: >> Theming and styling is a complex operation. It's not just "propagating >> values". Reading config files will at best get you the right font, correct icon >> set, and somewhat correct colours. But gradients, shapes, complex dialogs will >> not work. > > I don't see the problem to describe it in text, like CSS is doing. Clearly you have never actually written a QStyle. Something like Oxygen involves *multiple* gradients just for the window background. Don't forget inline SVG's for elements like the tree expanders and the 'icons' on scroll bar buttons, combo boxes, spin boxes... and that's not even the *hard* stuff. Try specifying a tab bar in CSS. You have text margins, margins between the tabs, possible complex shapes of the tabs themselves (all of which need complicated gradients for shading)... The current version of the Oxygen style (well, the KDE4 version anyway) represents *years* of work, and even then I would not say it is perfect. Take a look at http://pcdesktops.emuunlim.com/pictures/skins/wb/macosx-aqua-bjb.gif and explain to me how to replicate that in CSS. Start with the scroll bar handle. *Then* I will believe you when you say there is no problem describing widget style in CSS. That said, there *is* a textual language that can be used to adequately describe a style. That language is commonly known as "C++". -- Matthew -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwoehlke.floss at gmail.com Thu Nov 24 17:48:48 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Thu, 24 Nov 2016 11:48:48 -0500 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: <1573437.LOW8d6lCRL@tjmaciei-mobl1> <6860115.ORWOTKtl0j@tjmaciei-mobl1> Message-ID: <583719F0.5050301@gmail.com> On 2016-11-22 06:25, Marco Bubke wrote: > On November 22, 2016 08:17:57 Thiago Macieira wrote: >> Theming and styling is a complex operation. It's not just "propagating >> values". Reading config files will at best get you the right font, correct icon >> set, and somewhat correct colours. But gradients, shapes, complex dialogs will >> not work. > > I don't see the problem to describe it in text, like CSS is doing. Clearly you have never actually written a QStyle. Something like Oxygen involves *multiple* gradients just for the window background. Don't forget inline SVG's for elements like the tree expanders and the 'icons' on scroll bar buttons, combo boxes, spin boxes... and that's not even the *hard* stuff. Try specifying a tab bar in CSS. You have text margins, margins between the tabs, possible complex shapes of the tabs themselves (all of which need complicated gradients for shading)... The current version of the Oxygen style (well, the KDE4 version anyway) represents *years* of work, and even then I would not say it is perfect. Take a look at http://pcdesktops.emuunlim.com/pictures/skins/wb/macosx-aqua-bjb.gif and explain to me how to replicate that in CSS. Start with the scroll bar handle. *Then* I will believe you when you say there is no problem describing widget style in CSS. That said, there *is* a textual language that can be used to adequately describe a style. That language is commonly known as "C++". -- Matthew From kossebau at kde.org Thu Nov 24 19:23:39 2016 From: kossebau at kde.org (Friedrich W. H. Kossebau) Date: Thu, 24 Nov 2016 19:23:39 +0100 Subject: [Development] Recommendations for 3rd-party QCH file installation folder for easy discovery? In-Reply-To: References: <2244793.ZbTD6rx2HE@klux.site> Message-ID: <2153799.nZ78KMU9ou@klux.site> Hi Uwe, Am Donnerstag, 24. November 2016, 07:38:20 CET schrieb Uwe Rathmann: > On Tue, 22 Nov 2016 18:05:20 +0100, Friedrich W. H. Kossebau wrote: > > Q1: what would be a good system path pattern (on *nixoid systems) for > > Qt-based libraries to install their QCH files to? > > Qwt ( http://qwt.sf.net ) offers a qch file and is available for quite > some time. So you could check, what is common practice among distro > packagers. > > F.e. on my box ( OpenSusSE 12.2 ) it is simply not part of qwt6-devel- > doc. But the OpenSuSE package maintainer seems in general not being aware > of these Qt specific files as the installation of the feature files is > also broken. >From a quick look I would guess the reason for no qwt.qch being part of any package with openSUSE is that it is only available as a separate download, so not part of the sourcecode tarball. Best file a bug about this, most packagers do not eat all their dog food, at least not until the last bit(e), and if no- one has told them they will not know. Been there, done that :) That is also why I started this thread, to make sure that those QCH files for all the KDE Framework libs and the other libs from KDE also can make it all the way to the end-user, and are not lost on the track or end up unseen in the corner. So let's join forces here as creators of 3rd-party QCH files and form an interest group :) BTW, seeing you have used doxygen 1.8.11 for creating the latest qwt-6.1.3.qch, you might be interested in this patch to doxygen perhaps: https://github.com/doxygen/doxygen/pull/541 "Fix: Add missing jquery.js, dynsections.js & optional svgpan.js to QCH file" And this bug report about the hardcoded JavaScript in QCH files from doxygen: https://bugzilla.gnome.org/show_bug.cgi?id=773715 Seems things have regressed a little since https://blog.qt.io/blog/2009/01/15/ creating-qch-files-from-doxygen-revisited/ :( > But the rest of the docs can be found below /usr/share/doc/packages/qwt6- > devel-doc and IMO this is where I would expect to find qwt.qch as well. > > Maybe other distros can give you a better hint. Okay, thanks for this info. > > Q2: And would/could there be some way to have 3rd-party QCH files > > automatically added to Qt Assistant, Creator & Co. on installation, to > > spare the user the additional manual step? > > To me one of the most error prone things is loading 3rd party plugins to > the creator. This has mostly to do with binary incompatibilities between > the libraries used for development and the one used by the Creator > ( Assistant is less bad as being built together with Qt libs ) , but the > fact, that plugins are loaded "automatically" from some directories is > part of the problem. > > Coming from having experienced maximal user frustration with this > approach I wouldn't recommend to establish such an automatism. ? I was talking about the QCH files only, so no code/binaries involved :) Though your comment points to the issue of multiple versions of some libs being installed at the same time: if their respective QCH files are all being automatically added in Qt Assistant & Co., this will result in some confusion, especially when it comes to resolving version-less qthelp:// urls. That needs more thinking. One wild idea I had was to have IDEs know which QCH files belong to which libraries, and using the info they can get from the buildsystem about the used libs in the current project automatically activate the respective QCH files in the API documentation viewer module, or at least have them available as proposals. Might be handy when starting or joining a project :) Some long-term idea for now. Cheers Friedrich From kossebau at kde.org Thu Nov 24 19:51:13 2016 From: kossebau at kde.org (Friedrich W. H. Kossebau) Date: Thu, 24 Nov 2016 19:51:13 +0100 Subject: [Development] Recommendations for 3rd-party QCH file installation folder for easy discovery? In-Reply-To: <92504770.cgoorlbV0K@tonks> References: <2244793.ZbTD6rx2HE@klux.site> <92504770.cgoorlbV0K@tonks> Message-ID: <3543322.SOzbhoDrlK@klux.site> Hi, Am Donnerstag, 24. November 2016, 11:08:56 CET schrieb Lisandro Damián Nicanor Pérez Meyer: > On jueves, 24 de noviembre de 2016 07:38:20 ART Uwe Rathmann wrote: > > On Tue, 22 Nov 2016 18:05:20 +0100, Friedrich W. H. Kossebau wrote: > > > Q1: what would be a good system path pattern (on *nixoid systems) for > > > Qt-based libraries to install their QCH files to? > > > > Qwt ( http://qwt.sf.net ) offers a qch file and is available for quite > > some time. So you could check, what is common practice among distro > > packagers. > > > > F.e. on my box ( OpenSusSE 12.2 ) it is simply not part of qwt6-devel- > > doc. But the OpenSuSE package maintainer seems in general not being aware > > of these Qt specific files as the installation of the feature files is > > also broken. > > > > But the rest of the docs can be found below /usr/share/doc/packages/qwt6- > > devel-doc and IMO this is where I would expect to find qwt.qch as well. > > > > Maybe other distros can give you a better hint. > > At least on Debian I would push them to /usr/share//doc/ I see, thanks for the info. Even more, "find /usr/share/ -name doc" tells me on my openSUSE Tumbleweed that indeed /usr/share//doc/ is more popular than /usr/share/doc/packages/ And I see that GammaRay puts their QCH file here directly to /usr/share/gammaray/gammaray-api.qch Meh. There are better places for variety and personality :) Hm. Currently I am tempted to solve this issue for now by defaulting the install of the 3rd-party QCH files directly to the Qt system folder with the Qt QCH files (the one of the Qt linked against). Seems at least Qt Assistant automatically adds any new QCH file placed there, so this would solve the discoverability issue. After all if someone installed a package with the QCH file, they do want to use it usually... Cheers Friedrich From kevin.kofler at chello.at Fri Nov 25 01:26:56 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 25 Nov 2016 01:26:56 +0100 Subject: [Development] Summary ABI compabilty References: Message-ID: Marco Bubke wrote: > * easier life of Linux packager Where what you call "easier life" is really a question about whether distributions can continue shipping Qt at all (at least current versions of Qt, as opposed to sticking to an LTS version forever, even beyond its EOL and even ignoring future LTS versions) or not. Kevin Kofler From kevin.kofler at chello.at Fri Nov 25 01:37:32 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 25 Nov 2016 01:37:32 +0100 Subject: [Development] Summary ABI compabilty References: <4008780.ms3XMRHI2B@tjmaciei-mobl1> <201611230007.35685.kde@carewolf.com> <1788418.bxUOh4kfcA@tjmaciei-mobl1> Message-ID: Lars Knoll wrote: > There are a lot of good arguments towards using the STL and libstdc++ > more, as it will allow us to interoperate better with the C++ standard, > and provides a couple of things that we really want to use. So I can see > many good arguments towards going down that route. Doing so will bind the > compiled Qt binary to a certain version of that library (ie, it will > require a recompile of Qt to switch from libc++ to libstdc++). To a large > extent that is no different than the situation we're facing with e.g. > different VC++ runtimes. It also doesn't create impossible challenges for > the Linux packagers/distributors (or at least the challenges won't be > caused by us). So I'm positive towards using more of the standard > functionality and APIs (and also exposing them in our APIs). libstdc++ now has a sub-ABI-version that was already bumped recently for better C++11 compliance. It can be bumped again, without even changing the soname, and all libraries using the std:: types in their APIs will have a broken ABI. That would leave us distributors only with very unpleasant solutions: (a) rebuild everything using Qt in reverse dependency order, which has to be computed first. Alphabetic order, as normally used by the Fedora mass rebuild scripts, will almost certainly not work, due to symbol lookup failures. (b) pin libstc++ to an old version forever. (c) patch libstdc++ to stick to the old ABI forever. (d) tweak the build flags of Qt, everything using Qt, all C++ libraries it uses, everything using those libraries, etc., propagating back and forth, to stick to the old ABI forever. That is likely all or almost all C++ stuff in the distribution. So (d) is probably just a very complicated way to implement (c). (e) hack things up so that Qt uses the old ABI types for its own APIs (forever), but the new ABI types for libraries it uses that have already been rebuilt. That requires patching Qt with libstdc++-specific hacks and maintaining those patches forever. Neither of those is really acceptable. Kevin Kofler From kevin.kofler at chello.at Fri Nov 25 02:28:43 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 25 Nov 2016 02:28:43 +0100 Subject: [Development] Recommendations for 3rd-party QCH file installation folder for easy discovery? References: <2244793.ZbTD6rx2HE@klux.site> <2153799.nZ78KMU9ou@klux.site> Message-ID: Friedrich W. H. Kossebau wrote: > Though your comment points to the issue of multiple versions of some libs > being installed at the same time: if their respective QCH files are all > being automatically added in Qt Assistant & Co., this will result in some > confusion, especially when it comes to resolving version-less qthelp:// > urls. That needs more thinking. Distros will typically only allow one version of the QCH to be installed at the same time to begin with. Kevin Kofler From bo at vikingsoft.eu Fri Nov 25 08:02:46 2016 From: bo at vikingsoft.eu (Bo Thorsen) Date: Fri, 25 Nov 2016 08:02:46 +0100 Subject: [Development] Qt 5.9 In-Reply-To: <2374789.4RfaRo27MI@tjmaciei-mobl1> References: <004f01d24576$ab541ec0$01fc5c40$@gmail.com> <2374789.4RfaRo27MI@tjmaciei-mobl1> Message-ID: Den 23-11-2016 kl. 23:10 skrev Thiago Macieira: > On quarta-feira, 23 de novembro de 2016 21:14:52 PST Simon Everts wrote: >>> That is not relevant here. I am using Windows 10 (64-bit) but I am still >>> forced (because of 3rt-party-libraries) to develop 32-bit-Qt-applications. >>> Even if the operating system is 64-bit there can be a lot of 32-bit >>> application, e.g. VS 2013 and VS 2015 are still 32-bit applications. >> >> +1 >> >> As a machine manufacturer we are still deploying 32bit windows systems >> because of this reason. We'll be on 64bit windows soon, but need to support >> the 32bit systems for at least 5 years. A lot of industrial computer >> suppliers still install 32bit images on computers because there aren't any >> 64bit drivers available for the hardware. > > Good, thanks for the information, Simon and Helmut. > > I know the sample size here is horrible, but in your opinion what compiler > should we keep offering a 32-bit binary build for? > > MSVC 2013 > MSVC 2015 > MinGW The reason for doing 32 bit MSVC releasees is 3rd party libraries. Is that a valid reason for MinGW? I would have thought that the guys using it pretty much have to compile everything themselves anyway. I don't know, though. I won't ever use MinGW myself unless a customer forces me to. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From annulen at yandex.ru Fri Nov 25 08:46:05 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 25 Nov 2016 10:46:05 +0300 Subject: [Development] Summary ABI compabilty In-Reply-To: References: <4008780.ms3XMRHI2B@tjmaciei-mobl1> <201611230007.35685.kde@carewolf.com> <1788418.bxUOh4kfcA@tjmaciei-mobl1> Message-ID: <1340091480059965@web11g.yandex.ru> 25.11.2016, 03:38, "Kevin Kofler" : > Lars Knoll wrote: >>  There are a lot of good arguments towards using the STL and libstdc++ >>  more, as it will allow us to interoperate better with the C++ standard, >>  and provides a couple of things that we really want to use. So I can see >>  many good arguments towards going down that route. Doing so will bind the >>  compiled Qt binary to a certain version of that library (ie, it will >>  require a recompile of Qt to switch from libc++ to libstdc++). To a large >>  extent that is no different than the situation we're facing with e.g. >>  different VC++ runtimes. It also doesn't create impossible challenges for >>  the Linux packagers/distributors (or at least the challenges won't be >>  caused by us). So I'm positive towards using more of the standard >>  functionality and APIs (and also exposing them in our APIs). > > libstdc++ now has a sub-ABI-version that was already bumped recently for > better C++11 compliance. It can be bumped again, without even changing the > soname, and all libraries using the std:: types in their APIs will have a > broken ABI. > > That would leave us distributors only with very unpleasant solutions: > (a) rebuild everything using Qt in reverse dependency order, which has to be >     computed first. Alphabetic order, as normally used by the Fedora mass >     rebuild scripts, will almost certainly not work, due to symbol lookup >     failures. Gentoo provides revdep-rebuild for ages. Looks like you guys are stuck with crappy tooling. > (b) pin libstc++ to an old version forever. > (c) patch libstdc++ to stick to the old ABI forever. > (d) tweak the build flags of Qt, everything using Qt, all C++ libraries it >     uses, everything using those libraries, etc., propagating back and >     forth, to stick to the old ABI forever. That is likely all or almost all >     C++ stuff in the distribution. So (d) is probably just a very >     complicated way to implement (c). > (e) hack things up so that Qt uses the old ABI types for its own APIs >     (forever), but the new ABI types for libraries it uses that have already >     been rebuilt. That requires patching Qt with libstdc++-specific hacks >     and maintaining those patches forever. > > Neither of those is really acceptable. > >         Kevin Kofler > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From eric.lemanissier at gmail.com Fri Nov 25 09:39:06 2016 From: eric.lemanissier at gmail.com (Eric Lemanisser) Date: Fri, 25 Nov 2016 08:39:06 +0000 Subject: [Development] Qt 5.9 In-Reply-To: References: <004f01d24576$ab541ec0$01fc5c40$@gmail.com> <2374789.4RfaRo27MI@tjmaciei-mobl1> Message-ID: We have been using the MinGW binaries of Qt for years in production without problems. Until now 64bit has not been required, so we only used 32bit which is able to run on all windows platforms. A non-negligible part of users are using 32bit windows (on tablets for example), so it does not seem a very good move to stop offering MinGW 32bits. That said we would definitely make use of MinGW 64bits binaries ! Eric Lemanissier Le ven. 25 nov. 2016 à 08:03, Bo Thorsen a écrit : > Den 23-11-2016 kl. 23:10 skrev Thiago Macieira: > > On quarta-feira, 23 de novembro de 2016 21:14:52 PST Simon Everts wrote: > >>> That is not relevant here. I am using Windows 10 (64-bit) but I am > still > >>> forced (because of 3rt-party-libraries) to develop > 32-bit-Qt-applications. > >>> Even if the operating system is 64-bit there can be a lot of 32-bit > >>> application, e.g. VS 2013 and VS 2015 are still 32-bit applications. > >> > >> +1 > >> > >> As a machine manufacturer we are still deploying 32bit windows systems > >> because of this reason. We'll be on 64bit windows soon, but need to > support > >> the 32bit systems for at least 5 years. A lot of industrial computer > >> suppliers still install 32bit images on computers because there aren't > any > >> 64bit drivers available for the hardware. > > > > Good, thanks for the information, Simon and Helmut. > > > > I know the sample size here is horrible, but in your opinion what > compiler > > should we keep offering a 32-bit binary build for? > > > > MSVC 2013 > > MSVC 2015 > > MinGW > > The reason for doing 32 bit MSVC releasees is 3rd party libraries. Is > that a valid reason for MinGW? I would have thought that the guys using > it pretty much have to compile everything themselves anyway. > > I don't know, though. I won't ever use MinGW myself unless a customer > forces me to. > > Bo Thorsen, > Director, Viking Software. > > -- > Viking Software > Qt and C++ developers for hire > http://www.vikingsoft.eu > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.harmer at kdab.com Fri Nov 25 10:15:59 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Fri, 25 Nov 2016 09:15:59 +0000 Subject: [Development] Very slow incremental builds with 5.8 Message-ID: <2387283.G2dgGJT2N3@cartman> Hi all, what is the reason that when doing incremental builds with the 5.8 branch that qmake gets run in each and every subdir please? It *really* slows down doing incremental builds. Is there any way to avoid this or can we go back to the 5.7 behaviour please? Cheers, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From mitch.curtis at qt.io Fri Nov 25 10:36:19 2016 From: mitch.curtis at qt.io (Mitch Curtis) Date: Fri, 25 Nov 2016 09:36:19 +0000 Subject: [Development] Very slow incremental builds with 5.8 In-Reply-To: <2387283.G2dgGJT2N3@cartman> References: <2387283.G2dgGJT2N3@cartman> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt- > project.org] On Behalf Of Sean Harmer > Sent: Friday, 25 November 2016 10:16 AM > To: development at qt-project.org > Subject: [Development] Very slow incremental builds with 5.8 > > Hi all, > > what is the reason that when doing incremental builds with the 5.8 branch > that qmake gets run in each and every subdir please? It *really* slows down > doing incremental builds. Is there any way to avoid this or can we go back to > the > 5.7 behaviour please? I had a similar problem with Creator: https://bugreports.qt.io/browse/QTCREATORBUG-16807 Apparently it's better (or fixed?) in 4.2, but I haven't tested it properly yet. > Cheers, > > Sean > -- > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB > (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46- > 563-540090 > Mobile: +44 (0)7545 140604 > KDAB - Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From dangelog at gmail.com Fri Nov 25 10:51:06 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Fri, 25 Nov 2016 10:51:06 +0100 Subject: [Development] Summary ABI compabilty In-Reply-To: References: <4008780.ms3XMRHI2B@tjmaciei-mobl1> <201611230007.35685.kde@carewolf.com> <1788418.bxUOh4kfcA@tjmaciei-mobl1> Message-ID: On Fri, Nov 25, 2016 at 1:37 AM, Kevin Kofler wrote: > libstdc++ now has a sub-ABI-version that was already bumped recently for > better C++11 compliance. It can be bumped again, without even changing the > soname, and all libraries using the std:: types in their APIs will have a > broken ABI. Out of curiosity, why does a ABI break not incur in a soname change? Cheers, -- Giuseppe D'Angelo From sh at theharmers.co.uk Fri Nov 25 10:59:31 2016 From: sh at theharmers.co.uk (Sean Harmer) Date: Fri, 25 Nov 2016 09:59:31 +0000 Subject: [Development] Very slow incremental builds with 5.8 In-Reply-To: References: <2387283.G2dgGJT2N3@cartman> Message-ID: <2168654.0CE17Gdo6N@cartman> On Friday 25 November 2016 09:36:19 Mitch Curtis wrote: > > -----Original Message----- > > From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt- > > project.org] On Behalf Of Sean Harmer > > Sent: Friday, 25 November 2016 10:16 AM > > To: development at qt-project.org > > Subject: [Development] Very slow incremental builds with 5.8 > > > > Hi all, > > > > what is the reason that when doing incremental builds with the 5.8 branch > > that qmake gets run in each and every subdir please? It *really* slows > > down > > doing incremental builds. Is there any way to avoid this or can we go back > > to the > > 5.7 behaviour please? > > I had a similar problem with Creator: > https://bugreports.qt.io/browse/QTCREATORBUG-16807 > > Apparently it's better (or fixed?) in 4.2, but I haven't tested it properly > yet. Thanks. I'm using he work around of removing the call to qmake in the build settings and manually running qmake when necessary for now. Building Qt 5.7 modules in creator doesn't suffer from this problem so something must have changed in qmake or related files that triggered this behaviour in creator. Cheers, Sean From edward.welbourne at qt.io Fri Nov 25 12:43:54 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 25 Nov 2016 11:43:54 +0000 Subject: [Development] Very slow incremental builds with 5.8 In-Reply-To: <2168654.0CE17Gdo6N@cartman> References: <2387283.G2dgGJT2N3@cartman> , <2168654.0CE17Gdo6N@cartman> Message-ID: Sean Harmer: >>> what is the reason that when doing incremental builds with the 5.8 >>> branch that qmake gets run in each and every subdir please? It >>> *really* slows down doing incremental builds. Is there any way to >>> avoid this or can we go back to the 5.7 behaviour please? I can confirm this is just the make files - Creator is not the culprit - as I'm building purely using make and seeing the same. Eddy. From olivier at woboq.com Fri Nov 25 13:03:21 2016 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 25 Nov 2016 13:03:21 +0100 Subject: [Development] Summary ABI compabilty In-Reply-To: References: Message-ID: <2348504.HcQ2fXuXpI@maurice> On Freitag, 25. November 2016 10:51:06 CET Giuseppe D'Angelo wrote: > On Fri, Nov 25, 2016 at 1:37 AM, Kevin Kofler wrote: > > libstdc++ now has a sub-ABI-version that was already bumped recently for > > better C++11 compliance. It can be bumped again, without even changing the > > soname, and all libraries using the std:: types in their APIs will have a > > broken ABI. > > Out of curiosity, why does a ABI break not incur in a soname change? Because they would use a new abi tag or new inline namespace and so they would technically not break their ABI. (As the symbols in the old namespace or without the abi tag would still be present in the binary) However, if a library (such as Qt) made use of the standard library in their interface, they would only contain one set of symbols (with the new or the old tag, but not both). Therefore, the applications have to be build with the same standard library abi tag than all libraries. It's a bit unfortunate that this happens like that. But, we should ask: - How often will it happen in the future? They only change the binary compatibility if they have a very good reason to do so. Last time it was required in the GNU's libstdc++ because of a change in C++11 (which specified things that were left unspecified before). The standard committee is not easily accepting changes that force implementer to break binary compatibility. So perhaps not more than once every 6 years. (conservative estimate) - Why would Qt be different than all the other libraries that uses the standard library? I mean, when the gcc break happened last year, most C++ applications and libraries had to be rebuilt anyway. Should Qt ABI depends on the stl, how big is the set of dependencies that would not need to be rebuilt compared to the amount of package that anyway need to be rebuilt? So considering these two points, it should not happen often and most packages would anyway need to be recompiled. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From oswald.buddenhagen at qt.io Fri Nov 25 13:40:15 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 25 Nov 2016 13:40:15 +0100 Subject: [Development] [HEADS-UP] Updates to branching scheme Message-ID: <20161125124015.GD21393@troll08> hello, as discussed at the QtCS and these lists, forward-merging from the LTS branch 5.6 is becoming a significant burden. therefore, 5.6 is switching to a cherry-pick based model: - 5.6 is *NOT* going to be forward-merged any more, *ever* (also not to merge tags) - you may integrate only changes which have been already integrated into a stable mainline - use cherry-pick -x. don't forget to refresh the change if you create it before the source change integrates (new sha1!). - within the 5.6 "realm", there will be forward-merging from the release branch (next: 5.6.3) to 5.6 itself, so cherry-pick to only one of the 5.6.x branches. - this model is actually the same as what we employed for 4.8, our last LTS branch. - if you find that your changes recently integrated on 5.6 don't show up on 5.7 until monday, it means that you missed the last merge. in this case you'll need to _forward_-cherry-pick them. this is an exceptional case. to prevent this from happening from this point on, staging in 5.6 is temporarily locked down until we open it up again for the cherry-picks. second item: with the 5.8.0 release approaching, 5.7 is now reaching end of life. only critical fixes should go to 5.7 at this point. staging in 5.7 has been restricted to the release team, so we will be able to forward-merge 5.7 directly into 5.8.0, and we could in principle do a 5.7.2 release directly from that branch. all non-critical fixes should go to 5.8 now. i'm expecting a flurry of retargeting requests of changes from 5.6 and 5.7 to 5.8 now. regards, lars & ossi From giuseppe.dangelo at kdab.com Fri Nov 25 17:09:30 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Fri, 25 Nov 2016 17:09:30 +0100 Subject: [Development] [HEADS-UP] Updates to branching scheme In-Reply-To: <20161125124015.GD21393@troll08> References: <20161125124015.GD21393@troll08> Message-ID: <43dbdc1b-c80d-8e6f-bbc0-6e7dc6874ca0@kdab.com> Il 25/11/2016 13:40, Oswald Buddenhagen ha scritto: > - 5.6 is *NOT* going to be forward-merged any more, *ever* (also not to > merge tags) > - you may integrate only changes which have been already integrated into > a stable mainline Sorry, but need to raise an objection against this strategy, or at least ask for many more clarifications about this process. To me this looks like asking all contributors to at least double the effort necessary to fix bugs that are (also) present in 5.6: patch 5.x, get it merged, cherry-pick to 5.6, get it merged there. On average, the cherry-pick to 5.6 will mean rewrite the patch, because: 1) The whole motivation for stop doing merges from 5.6 forward is the high number of conflicts between the branches. Therefore, I can assume that conflicts will be also be hit when cherry-picking back. 2) I am happily going to -1 any patch aimed at 5.7+ which does not use C++11 features if it can (and should, according to the coding policy). Any such patch will require modifications. We even kept our code base in a certain "shape" (still using Q_FOO macros for C++11 features, etc.) because we wanted to minimize the chance of conflicts when merging from 5.6; now that motivation is not there any more, right? So, while on one hand this new branching scheme distributes the burden from the current merge masters onto the bigger community, in practice I'm very afraid (read: almost certain) that this will mean that very few people will be willing to do the extra work, hence leaving 5.6 unpatched for ordinary, non-critical bug fixes. This makes using a LTS quite less attractive to me. Are we sure there isn't a better way? My 2 cents, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From andre.hartmann at iseg-hv.de Fri Nov 25 16:33:01 2016 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Fri, 25 Nov 2016 16:33:01 +0100 Subject: [Development] Qt 5.9 In-Reply-To: References: <004f01d24576$ab541ec0$01fc5c40$@gmail.com> <2374789.4RfaRo27MI@tjmaciei-mobl1> Message-ID: <931339ea-1705-81fd-b511-7bda93f4b4ff@iseg-hv.de> Hi, This nice thing about the MinGW package is, that you get Qt, Creator, the compiler and the debugger in one package. I already recommended this package to people that wanted to start Windows development and this always worked fine. So another +1 for MinGW 32bit build from my side. Andre PS: And I never want to got back to early Creator 2.x times, when you had to put all this together your own, and the requirements changed for every new Creator version... Am 25.11.2016 um 09:39 schrieb Eric Lemanisser: > We have been using the MinGW binaries of Qt for years in production > without problems. Until now 64bit has not been required, so we only used > 32bit which is able to run on all windows platforms. A non-negligible > part of users are using 32bit windows (on tablets for example), so it > does not seem a very good move to stop offering MinGW 32bits. That said > we would definitely make use of MinGW 64bits binaries ! > > Eric Lemanissier > > Le ven. 25 nov. 2016 à 08:03, Bo Thorsen > a écrit : > > Den 23-11-2016 kl. 23:10 skrev Thiago Macieira: > > On quarta-feira, 23 de novembro de 2016 21:14:52 PST Simon Everts > wrote: > >>> That is not relevant here. I am using Windows 10 (64-bit) but I > am still > >>> forced (because of 3rt-party-libraries) to develop > 32-bit-Qt-applications. > >>> Even if the operating system is 64-bit there can be a lot of 32-bit > >>> application, e.g. VS 2013 and VS 2015 are still 32-bit applications. > >> > >> +1 > >> > >> As a machine manufacturer we are still deploying 32bit windows > systems > >> because of this reason. We'll be on 64bit windows soon, but need > to support > >> the 32bit systems for at least 5 years. A lot of industrial computer > >> suppliers still install 32bit images on computers because there > aren't any > >> 64bit drivers available for the hardware. > > > > Good, thanks for the information, Simon and Helmut. > > > > I know the sample size here is horrible, but in your opinion what > compiler > > should we keep offering a 32-bit binary build for? > > > > MSVC 2013 > > MSVC 2015 > > MinGW > > The reason for doing 32 bit MSVC releasees is 3rd party libraries. Is > that a valid reason for MinGW? I would have thought that the guys using > it pretty much have to compile everything themselves anyway. > > I don't know, though. I won't ever use MinGW myself unless a customer > forces me to. > > Bo Thorsen, > Director, Viking Software. > > -- > Viking Software > Qt and C++ developers for hire > http://www.vikingsoft.eu > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Best regards / Mit freundlichen Grüßen André Hartmann, Dipl.-Ing. (FH) Software Project Manager iseg Spezialelektronik GmbH | phone: ++49 (0)351 26996-43 Bautzner Landstr. 23 | fax: ++49 (0)351 26996-21 D-01454 Radeberg / Rossendorf | web: www.iseg-hv.com Geschäftsführer / Managing director: Dr. F. Gleisberg, Dr. J. Pöthig Amtsgericht / Lower district court: Dresden HRB 16250 Ust.-Id.-Nr. / VAT-ID: DE812508942 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From oswald.buddenhagen at qt.io Fri Nov 25 18:45:20 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 25 Nov 2016 18:45:20 +0100 Subject: [Development] [HEADS-UP] Updates to branching scheme In-Reply-To: <43dbdc1b-c80d-8e6f-bbc0-6e7dc6874ca0@kdab.com> References: <20161125124015.GD21393@troll08> <43dbdc1b-c80d-8e6f-bbc0-6e7dc6874ca0@kdab.com> Message-ID: <20161125174520.GG5187@troll08> On Fri, Nov 25, 2016 at 05:09:30PM +0100, Giuseppe D'Angelo wrote: > So, while on one hand this new branching scheme distributes the burden > from the current merge masters onto the bigger community, in practice > I'm very afraid (read: almost certain) that this will mean that very > few people will be willing to do the extra work, hence leaving 5.6 > unpatched for ordinary, non-critical bug fixes. > i said that much myself previously. > Are we sure there isn't a better way? > maybe you should have raised that concern when the topic was discussed previously on this list (about two or three times) or at the contributor summit. as an immediate measure, you may step up and _commit to_ being the merge monkey (at least for the 5.6 -> 5.8 merges). if you do that quick enough (like, monday), we may reconsider. and for everyone else this uncertainty means that they should hold off their bugfix integrations on 5.8, to avoid the cherry-picks they were prepared to do. From kevin.kofler at chello.at Fri Nov 25 19:29:53 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 25 Nov 2016 19:29:53 +0100 Subject: [Development] Qt 5.9 References: <004f01d24576$ab541ec0$01fc5c40$@gmail.com> <2374789.4RfaRo27MI@tjmaciei-mobl1> Message-ID: Bo Thorsen wrote: > The reason for doing 32 bit MSVC releasees is 3rd party libraries. Is > that a valid reason for MinGW? I would have thought that the guys using > it pretty much have to compile everything themselves anyway. C libraries are normally interoperable between VC and MinGW. Even C++ libraries with a purely extern "C" API should work with both compilers. Only the C++ ABI is incompatible. So you can have a 32-bit binary-only DLL that works with MinGW32, but of course not with MinGW64. Kevin Kofler From apoenitz at t-online.de Fri Nov 25 20:41:42 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Fri, 25 Nov 2016 20:41:42 +0100 Subject: [Development] [HEADS-UP] Updates to branching scheme In-Reply-To: <43dbdc1b-c80d-8e6f-bbc0-6e7dc6874ca0@kdab.com> References: <20161125124015.GD21393@troll08> <43dbdc1b-c80d-8e6f-bbc0-6e7dc6874ca0@kdab.com> Message-ID: <20161125194142.GB1882@klara.mpi.htwm.de> On Fri, Nov 25, 2016 at 05:09:30PM +0100, Giuseppe D'Angelo wrote: > Il 25/11/2016 13:40, Oswald Buddenhagen ha scritto: > > - 5.6 is *NOT* going to be forward-merged any more, *ever* (also not to > > merge tags) > > - you may integrate only changes which have been already integrated into > > a stable mainline > > Sorry, but need to raise an objection against this strategy, or at least > ask for many more clarifications about this process. > > To me this looks like asking all contributors to at least double the > effort necessary to fix bugs that are (also) present in 5.6: patch 5.x, > get it merged, cherry-pick to 5.6, get it merged there. > > On average, the cherry-pick to 5.6 will mean rewrite the patch, because: > > 1) The whole motivation for stop doing merges from 5.6 forward is the > high number of conflicts between the branches. That's not true, it's also about the time it takes for a patch to trickle down from 5.6 to dev to enable dependent work there. > Therefore, I can assume > that conflicts will be also be hit when cherry-picking back. E.f.s.q. > So, while on one hand this new branching scheme distributes the burden > from the current merge masters onto the bigger community, in practice > I'm very afraid (read: almost certain) that this will mean that very few > people will be willing to do the extra work, hence leaving 5.6 unpatched > for ordinary, non-critical bug fixes. Being more and more restrictive as the patch levels increase does not really sound like a problem for LTS release. > This makes using a LTS quite less attractive to me. Using with what hat on? People with a "end user programmer hat" want something stable there, no new features. People with a "Qt developer hat" do not want to wait weeks for dependendecies to trickle down. > Are we sure there isn't a better way? I am not sure there isn't, I am just not aware of such either. Andre' From ernst.maurer at gmail.com Fri Nov 25 20:12:06 2016 From: ernst.maurer at gmail.com (Ernst Maurer) Date: Fri, 25 Nov 2016 19:12:06 +0000 Subject: [Development] build [any] qt-based project ising cmake , outside of qtcreator Message-ID: hello just faced with a requirement to build qt/cmake based project from command line or another IDE, and could not. what is a qtcreator magic which helps to do this successfully? tried to build simplest sample project from actual documentation here ( http://doc.qt.io/qt-5/cmake-manual.html) , the same problem. it looks like cmake can't find all required .cmake scripts, I don't see the instructions to set the paths to all .cmake scripts for required modules. I suppose qtcreator does some "tuning" the project implicitly?? this is the output for sample cmakelists from doc page sample above: cmake.exe -DCMAKE_BUILD_TYPE=Debug -G "CodeBlocks - MinGW Makefiles" C:\dev\workspace\algolist.v2 CMake Warning at CMakeLists.txt:13 (find_package): By not providing "FindQt5Widgets.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "Qt5Widgets", but CMake did not find one. Could not find a package configuration file provided by "Qt5Widgets" with any of the following names: Qt5WidgetsConfig.cmake qt5widgets-config.cmake Add the installation prefix of "Qt5Widgets" to CMAKE_PREFIX_PATH or set "Qt5Widgets_DIR" to a directory containing one of the above files. If "Qt5Widgets" provides a separate development package or SDK, be sure it has been installed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Nov 25 20:30:40 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 25 Nov 2016 11:30:40 -0800 Subject: [Development] Summary ABI compabilty In-Reply-To: References: Message-ID: <4404735.lUbY5pB2Wv@tjmaciei-mobl1> On sexta-feira, 25 de novembro de 2016 10:51:06 PST Giuseppe D'Angelo wrote: > Out of curiosity, why does a ABI break not incur in a soname change? Because they technically did not break BC. Programs that were compiled and linked against an older version will continue to run exactly as before. They've only added new symbols to the library. It's also not an SC break: programs that used to compile with the old library will still compile again with the new one. Like with glibc with ELF version, the newly-linked program will call the new symbols, not the old ones. This is a domain of breakage that isn't very well explored because it happens not in the library that made the source code change, but in a second library that used the first one. It happens almost exclusively in C++, though if you try hard enough you can do it in C with some macros too. It happens because C++ has two "features" that allow it to happen: 1) default parameters (including default template parameters) 2) extensive mangling of symbols The most likely case of this breakage was that of adding new defaulted template parameers to template classes. Fortunately, it was one of the cases caught in the C++ Binary Compatibility guideline on KDE websites. Inline namespaces actually make it easy to cause this breakage. So we should not use them in Qt public headers. GCC ABI tags are like inline namespaces, but looking from another angle. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Nov 25 20:17:54 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 25 Nov 2016 11:17:54 -0800 Subject: [Development] Summary ABI compabilty In-Reply-To: References: Message-ID: <3485604.UsZSM6ntKs@tjmaciei-mobl1> On sexta-feira, 25 de novembro de 2016 01:37:32 PST Kevin Kofler wrote: > libstdc++ now has a sub-ABI-version that was already bumped recently for > better C++11 compliance. It can be bumped again, without even changing the > soname, and all libraries using the std:: types in their APIs will have a > broken ABI. > > That would leave us distributors only with very unpleasant solutions: [cut] What option are you choosing for the other packages that do use the libstdc++ API? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oswald.buddenhagen at qt.io Fri Nov 25 21:11:13 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 25 Nov 2016 21:11:13 +0100 Subject: [Development] [HEADS-UP] Updates to branching scheme In-Reply-To: <20161125194142.GB1882@klara.mpi.htwm.de> References: <20161125124015.GD21393@troll08> <43dbdc1b-c80d-8e6f-bbc0-6e7dc6874ca0@kdab.com> <20161125194142.GB1882@klara.mpi.htwm.de> Message-ID: <20161125201113.GA18789@troll08> On Fri, Nov 25, 2016 at 08:41:42PM +0100, André Pönitz wrote: > On Fri, Nov 25, 2016 at 05:09:30PM +0100, Giuseppe D'Angelo wrote: > > 1) The whole motivation for stop doing merges from 5.6 forward is the > > high number of conflicts between the branches. > > That's not true, it's also about the time it takes for a patch to > trickle down from 5.6 to dev to enable dependent work there. > that only makes sense when you add the word "integrating" here. because nothing is stopping you from having said changes cherry-picked locally. this even extends to whole teams, if the involved people are capable of using git beyond the three basic commands. > > This makes using a LTS quite less attractive to me. > > Using with what hat on? People with a "end user programmer hat" want > something stable there, no new features. > who's talking about features? and if you don't want _any_ changes, then you obviosly don't need to update. > People with a "Qt developer hat" do not want to wait weeks for > dependendecies to trickle down. > only those who appear to be constantly chased by the devil himself. i have no problem whatsoever to do followup work while earlier changes wait for integration. From nassian at bitshift-dynamics.de Fri Nov 25 21:15:39 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Fri, 25 Nov 2016 21:15:39 +0100 Subject: [Development] Qt 5.9 In-Reply-To: References: <004f01d24576$ab541ec0$01fc5c40$@gmail.com> <2374789.4RfaRo27MI@tjmaciei-mobl1> Message-ID: <52644688-575B-4A41-9A18-B18C735F4EFE@bitshift-dynamics.de> Also a +1 from me. Its simply the easiest and most hassle free way for newcomers to start on Windows and it runs everywhere. In my opinion 32bit should have been completely stopped 10 years ago, but sadly the reality is ugly. Beste Grüße / Best regards, Alexander Nassian > Am 25.11.2016 um 19:29 schrieb Kevin Kofler : > > Bo Thorsen wrote: >> The reason for doing 32 bit MSVC releasees is 3rd party libraries. Is >> that a valid reason for MinGW? I would have thought that the guys using >> it pretty much have to compile everything themselves anyway. > > C libraries are normally interoperable between VC and MinGW. Even C++ > libraries with a purely extern "C" API should work with both compilers. Only > the C++ ABI is incompatible. > > So you can have a 32-bit binary-only DLL that works with MinGW32, but of > course not with MinGW64. > > Kevin Kofler > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From apoenitz at t-online.de Fri Nov 25 23:05:31 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Fri, 25 Nov 2016 23:05:31 +0100 Subject: [Development] [HEADS-UP] Updates to branching scheme In-Reply-To: <20161125201113.GA18789@troll08> References: <20161125124015.GD21393@troll08> <43dbdc1b-c80d-8e6f-bbc0-6e7dc6874ca0@kdab.com> <20161125194142.GB1882@klara.mpi.htwm.de> <20161125201113.GA18789@troll08> Message-ID: <20161125220531.GA4296@klara.mpi.htwm.de> On Fri, Nov 25, 2016 at 09:11:13PM +0100, Oswald Buddenhagen wrote: > On Fri, Nov 25, 2016 at 08:41:42PM +0100, André Pönitz wrote: > > On Fri, Nov 25, 2016 at 05:09:30PM +0100, Giuseppe D'Angelo wrote: > > > 1) The whole motivation for stop doing merges from 5.6 forward is the > > > high number of conflicts between the branches. > > > > That's not true, it's also about the time it takes for a patch to > > trickle down from 5.6 to dev to enable dependent work there. > > > that only makes sense when you add the word "integrating" here. > because nothing is stopping you from having said changes cherry-picked > locally. Yes, integrations. but that's what matters. Not many people will seriously review patches that require more than a trivial amount of patches in other branches. I even doubt that most people have builds of all active configurations around, not to mention something else than the standard configuration. > this even extends to whole teams, if the involved people are > capable of using git beyond the three basic commands. That's already a lots of assumptions... > > > This makes using a LTS quite less attractive to me. > > > > Using with what hat on? People with a "end user programmer hat" want > > something stable there, no new features. > > who's talking about features? and if you don't want _any_ changes, > then you obviosly don't need to update. > > > People with a "Qt developer hat" do not want to wait weeks for > > dependendecies to trickle down. > > > only those who appear to be constantly chased by the devil himself. Also the ones that would be completely fine with doing their work in dev, but are kindly asked to use the "right" branch, where "right" tends to depend on the person of the reviewer and circumstances unrelated to the patch. > i have no problem whatsoever to do followup work while earlier changes > wait for integration. I know. Andre' From kevin.kofler at chello.at Fri Nov 25 22:00:39 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 25 Nov 2016 22:00:39 +0100 Subject: [Development] Summary ABI compabilty References: <3485604.UsZSM6ntKs@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > What option are you choosing for the other packages that do use the > libstdc++ API? Rebuilding them all, and everything that does not work when building in random (basically alphabetical, though the order is not guaranteed) order (with the mass rebuild script) has to be fixed manually. Kevin Kofler From kevin.kofler at chello.at Fri Nov 25 22:08:04 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 25 Nov 2016 22:08:04 +0100 Subject: [Development] build [any] qt-based project ising cmake , outside of qtcreator References: Message-ID: Ernst Maurer wrote: > just faced with a requirement to build qt/cmake based project from command > line or another IDE, and could not. what is a qtcreator magic which helps > to do this successfully? This is really a question for qt-interest (about developing WITH Qt), not qt-devel (about developing FOR Qt). > it looks like cmake can't find all required .cmake scripts, I don't see > the instructions to set the paths to all .cmake scripts for required > modules. It is clear from your output: > cmake.exe -DCMAKE_BUILD_TYPE=Debug -G "CodeBlocks - MinGW Makefiles" > C:\dev\workspace\algolist.v2 that you are using Windows, which does not use a standardized path hierarchy. This problem does not occur on operating systems using the Filesystem Hierarchy Standard (FHS). On Windows, you have to tell CMake where to find the *Config.cmake files, and the error message tells you how to do it: > Could not find a package configuration file provided by "Qt5Widgets" > with any of the following names: > > Qt5WidgetsConfig.cmake > qt5widgets-config.cmake > > Add the installation prefix of "Qt5Widgets" to CMAKE_PREFIX_PATH or set > "Qt5Widgets_DIR" to a directory containing one of the above files. If > "Qt5Widgets" provides a separate development package or SDK, be sure it has > been installed. so why are you even asking here? Your post contains the answer. Kevin Kofler From annulen at yandex.ru Fri Nov 25 22:12:50 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sat, 26 Nov 2016 00:12:50 +0300 Subject: [Development] build [any] qt-based project ising cmake , outside of qtcreator In-Reply-To: References: Message-ID: <7672391480108370@web10j.yandex.ru> 25.11.2016, 22:12, "Ernst Maurer" : > hello > > just faced with a requirement to build qt/cmake based project from command line or another IDE, and could not. what is a qtcreator magic which helps to do this successfully? > > tried to build simplest sample project from actual documentation here (http://doc.qt.io/qt-5/cmake-manual.html) , the same problem. > > it looks like cmake can't find all required .cmake scripts, I don't see the instructions to set the paths to all .cmake scripts for required modules. > > I suppose qtcreator does some "tuning" the project implicitly?? > > this is the output for sample cmakelists from doc page sample above: > > cmake.exe -DCMAKE_BUILD_TYPE=Debug -G "CodeBlocks - MinGW Makefiles" C:\dev\workspace\algolist.v2 > CMake Warning at CMakeLists.txt:13 (find_package): >   By not providing "FindQt5Widgets.cmake" in CMAKE_MODULE_PATH this project >   has asked CMake to find a package configuration file provided by >   "Qt5Widgets", but CMake did not find one. > >   Could not find a package configuration file provided by "Qt5Widgets" with >   any of the following names: > >     Qt5WidgetsConfig.cmake >     qt5widgets-config.cmake > >   Add the installation prefix of "Qt5Widgets" to CMAKE_PREFIX_PATH or set >   "Qt5Widgets_DIR" to a directory containing one of the above files.  If >   "Qt5Widgets" provides a separate development package or SDK, be sure it has >   been installed. Hi, The above message means that you need to add -DCMAKE_PREFIX_PATH=$QTDIR to your cmake arguments, where $QTDIR is a path to your Qt installation > > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From lars.knoll at qt.io Fri Nov 25 22:24:17 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 25 Nov 2016 21:24:17 +0000 Subject: [Development] [HEADS-UP] Updates to branching scheme In-Reply-To: <20161125201113.GA18789@troll08> References: <20161125124015.GD21393@troll08> <43dbdc1b-c80d-8e6f-bbc0-6e7dc6874ca0@kdab.com> <20161125194142.GB1882@klara.mpi.htwm.de> <20161125201113.GA18789@troll08> Message-ID: <6CDAA8A1-0A32-4F58-8584-8C029EE7B819@qt.io> The merging has become a huge burden on more than one person. Distributing it over every developer has a couple of positive side effects: * The code bases have deviated quite a bit in certain areas (c++11 usage, configuration system, removal of WinCE to name just some examples) to make merges difficult and prone to errors. I've seen at least one merge where the merge was actually resolving things the wrong way. And you can't blame the merge masters for it, it's simply too easy to make mistakes there, especially if you don't know the code in question very well * Developers can usually back port their changes very quickly. They know the code in question, and as it's a single (usually small/localized) change, resolving any conflicts is in almost all cases straight forward. This is not the case when merging 50 unrelated commits * We will not continuously get C++98 idioms merged back into our development code line * 5.6 is a stable LTS branch. This does not means that we should fix every possible bug in there. It also doesn't mean we will automatically add support for any new OS version that comes out in there. The most important objective of the branch is to give our customers a stable base for longer lived projects. This means we need to be very careful to avoid regressions. And that means limiting changes in the branch. Mainly have critical and security fixes in there, and little else. The new branching scheme will support this nicely. It'll focus our R&D efforts onto 5.8/dev, back-porting critical fixes when required. > On 25 Nov 2016, at 21:11, Oswald Buddenhagen wrote: > > On Fri, Nov 25, 2016 at 08:41:42PM +0100, André Pönitz wrote: >> On Fri, Nov 25, 2016 at 05:09:30PM +0100, Giuseppe D'Angelo wrote: >>> 1) The whole motivation for stop doing merges from 5.6 forward is the >>> high number of conflicts between the branches. >> >> That's not true, it's also about the time it takes for a patch to >> trickle down from 5.6 to dev to enable dependent work there. >> > that only makes sense when you add the word "integrating" here. because > nothing is stopping you from having said changes cherry-picked locally. > this even extends to whole teams, if the involved people are capable of > using git beyond the three basic commands. True, but it still keeps some part of your mindshare distracted, as you wait for the feature to trickle down. The long merge chain also causes additional overhead and potential delays when trying to get releases out, so it does have a cost for the project as a whole. Cheers, Lars > >>> This makes using a LTS quite less attractive to me. >> >> Using with what hat on? People with a "end user programmer hat" want >> something stable there, no new features. >> > who's talking about features? > and if you don't want _any_ changes, then you obviosly don't need to > update. > >> People with a "Qt developer hat" do not want to wait weeks for >> dependendecies to trickle down. >> > only those who appear to be constantly chased by the devil himself. i > have no problem whatsoever to do followup work while earlier changes > wait for integration. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From samuel.gaist at edeltech.ch Sat Nov 26 00:51:06 2016 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Sat, 26 Nov 2016 00:51:06 +0100 Subject: [Development] New library in qtbase Message-ID: Hi, As requested by Thiago in https://codereview.qt-project.org/#/c/166456/ I’d like to open a discussion about adding a new library in qtbase. Why this discussion ? Currently in work a pluggable notification system developed in its own library in qtbase. Why add a new library ? Originally the submission was integrated in QPA however after some thoughts and discussion, it was reworked to avoid that so that developers of non-GUI application could also take advantage of notifications without the need of a QGuiApplication. One of my motivation to move the code in its own library was that the second implementation provided a run-time plugin selection mechanism much like the QtSql module. After further discussion, the plugin selection has been moved to build-time. The library as it is currently could even be in its own repository however the goal in the long run is to replace the code used in QSystemTrayIcon by calls to this module which at this time duplicates the showMessage logic for macOS. Therefore having it as a separated repo would mean that qtbase would depend on it to be build which IMHO is not an option. So basically we are at this point: 1) Keep the new notifications module 2) Move the code in the gui module since QImage might be used In any case, the outcome of this discussion should likely be written in a QUIP so we have a clear set of rules about adding new libraries in existing Qt modules. Thank you for your attention Samuel From Jake.Petroules at qt.io Sat Nov 26 06:36:16 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Sat, 26 Nov 2016 05:36:16 +0000 Subject: [Development] New library in qtbase In-Reply-To: References: Message-ID: <9418F6B3-FA3B-48CD-B4CB-D968E1174529@qt.io> > On Nov 25, 2016, at 3:51 PM, Samuel Gaist wrote: > > Hi, > > As requested by Thiago in https://codereview.qt-project.org/#/c/166456/ I’d like to open a discussion about adding a new library in qtbase. > > Why this discussion ? > > Currently in work a pluggable notification system developed in its own library in qtbase. > > Why add a new library ? > > Originally the submission was integrated in QPA however after some thoughts and discussion, it was reworked to avoid that so that developers of non-GUI application could also take advantage of notifications without the need of a QGuiApplication. > > One of my motivation to move the code in its own library was that the second implementation provided a run-time plugin selection mechanism much like the QtSql module. After further discussion, the plugin selection has been moved to build-time. > > The library as it is currently could even be in its own repository however the goal in the long run is to replace the code used in QSystemTrayIcon by calls to this module which at this time duplicates the showMessage logic for macOS. Therefore having it as a separated repo would mean that qtbase would depend on it to be build which IMHO is not an option. > > So basically we are at this point: > > 1) Keep the new notifications module I would rather it be a separate module, QtGui is becoming large. > 2) Move the code in the gui module since QImage might be used Maybe we can have two modules - QtNotifications and QtGraphicalNotifications, only the latter of which depends on QtGui. For Qt 6 I'd like to separate QtGui into two modules, one which handles just general graphics and imaging (QtGraphics), and another which handles the windowing system abstraction and user interface primitives (QtUi or QtGui). Of course that's a separate discussion but it would help situations like this... > In any case, the outcome of this discussion should likely be written in a QUIP so we have a clear set of rules about adding new libraries in existing Qt modules. > > Thank you for your attention > > Samuel > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Anyways, +1 overall. -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From thiago.macieira at intel.com Sat Nov 26 07:50:11 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 25 Nov 2016 22:50:11 -0800 Subject: [Development] New library in qtbase In-Reply-To: References: Message-ID: <13507339.QtWAKzEl5T@tjmaciei-mobl1> On sábado, 26 de novembro de 2016 00:51:06 PST Samuel Gaist wrote: > The library as it is currently could even be in its own repository however > the goal in the long run is to replace the code used in QSystemTrayIcon by > calls to this module which at this time duplicates the showMessage logic > for macOS. Therefore having it as a separated repo would mean that qtbase > would depend on it to be build which IMHO is not an option. What platforms are you targetting, besides macOS? Which ones have you already developed? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kde at carewolf.com Sat Nov 26 11:18:24 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Sat, 26 Nov 2016 11:18:24 +0100 Subject: [Development] New library in qtbase In-Reply-To: References: Message-ID: <201611261118.24816.kde@carewolf.com> I would prefer putting the interface in gui or core and the implementation in platformsupport and QPA. It is not going to be more than a few kilobytes, and if we split core at some point it would fit with other system services. Note the Linux version will need the dbus and the dbustray code in platformsupport themes. `Allan From mike.krus at kdab.com Sat Nov 26 18:10:30 2016 From: mike.krus at kdab.com (Mike Krus) Date: Sat, 26 Nov 2016 17:10:30 +0000 Subject: [Development] Qt 5.9 In-Reply-To: References: Message-ID: <071EBD52-2967-43FE-8E94-22BB52549255@kdab.com> > On 22 Nov 2016, at 23:46, Jake Petroules wrote: >> On Nov 22, 2016, at 3:42 AM, Jani Heikkinen wrote: >> - We have earlier agreed that for Apple we will support three latest versions. So this means >> * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 >> * For iOS we drop 7.x and support 8.x, 9.x, 10.x > > Sounds good to me. Already got https://codereview.qt-project.org/#/c/171940/ and https://codereview.qt-project.org/#/c/171941/ ready. sounds reasonable. > Also propose to "drop" tvOS 9 and watchOS 2 which were the minimums set for the technology previews introduced in 5.8. New supported versions will be tvOS 10 and watchOS 3. +1, makes sense. Any opinion, or specific requirements, for either of these to come out of tech preview? >> - I propose to drop standalone macOS Android installer; One having iOS & Android should be enough > > I have a slightly different proposal: remove macOS and Android from the macOS+iOS+Android installer so that we actually *have* a standalone iOS installer. The current situation is confusing for users, and no one wants a THREE GIGABYTE installer when they possibly don't care about the other two platforms in it. I’m not sure why you would want iOS or Android without macOS but I guess the simplest would to provide the 3 separate installers. Mike -- Mike Krus | mike.krus at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44 1625 809908 Mobile +44 7833 491941 KDAB - The Qt Experts From thiago.macieira at intel.com Sat Nov 26 19:33:18 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 26 Nov 2016 10:33:18 -0800 Subject: [Development] New library in qtbase In-Reply-To: <201611261118.24816.kde@carewolf.com> References: <201611261118.24816.kde@carewolf.com> Message-ID: <1762690.pXvRYFjCRz@tjmaciei-mobl1> On sábado, 26 de novembro de 2016 11:18:24 PST Allan Sandfeld Jensen wrote: > I would prefer putting the interface in gui or core and the implementation > in platformsupport and QPA. It is not going to be more than a few > kilobytes, and if we split core at some point it would fit with other > system services. Or if we split QtGui along the lines that Jake proposed in his email. Not to mention that on some systems you will need a graphical connection to send notifications. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sersver00 at gmail.com Sat Nov 26 19:59:26 2016 From: sersver00 at gmail.com (ser00) Date: Sat, 26 Nov 2016 20:59:26 +0200 Subject: [Development] tag in QTextEdit In-Reply-To: <5839D89B.9020403@i.ua> References: <5839D89B.9020403@i.ua> Message-ID: <5839DB8E.5030709@i.ua> I create topic in Forum https://forum.qt.io/topic/73709/when-qtextedit-will-understand-tag-strike May you add support of tag to QTextEdit and other classes? It is useful for paste rich text from browsers. If no and never, please tell it and I will write support manually to my application. What about add some other not supported tags? It may be or never? P.S. I correct my program code for support the tag manually in my child class , so the problem is not relevant for me now. But for other users may be. Sergey From nassian at bitshift-dynamics.de Sat Nov 26 20:15:08 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Sat, 26 Nov 2016 20:15:08 +0100 Subject: [Development] tag in QTextEdit In-Reply-To: <5839DB8E.5030709@i.ua> References: <5839D89B.9020403@i.ua> <5839DB8E.5030709@i.ua> Message-ID: Instead of begging on a maillist and otherwise implementing it proprietary in your application, wouldn't it be an option to contribute the support of these tags to the Qt project? Beste Grüße / Best regards, Alexander Nassian > Am 26.11.2016 um 19:59 schrieb ser00 : > > I create topic in Forum https://forum.qt.io/topic/73709/when-qtextedit-will-understand-tag-strike May you add support of tag to QTextEdit and other classes? It is useful for paste rich text from browsers. If no and never, please tell it and I will write support manually to my application. What about add some other not supported tags? It may be or never? > > P.S. I correct my program code for support the tag manually in my child class , so the problem is not relevant for me now. But for other users may be. > > Sergey > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From kde at carewolf.com Sat Nov 26 22:37:01 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Sat, 26 Nov 2016 22:37:01 +0100 Subject: [Development] New library in qtbase In-Reply-To: <1762690.pXvRYFjCRz@tjmaciei-mobl1> References: <201611261118.24816.kde@carewolf.com> <1762690.pXvRYFjCRz@tjmaciei-mobl1> Message-ID: <201611262237.02005.kde@carewolf.com> On Saturday 26 November 2016, Thiago Macieira wrote: > On sábado, 26 de novembro de 2016 11:18:24 PST Allan Sandfeld Jensen wrote: > > I would prefer putting the interface in gui or core and the > > implementation in platformsupport and QPA. It is not going to be more > > than a few kilobytes, and if we split core at some point it would fit > > with other system services. > > Or if we split QtGui along the lines that Jake proposed in his email. > > Not to mention that on some systems you will need a graphical connection to > send notifications. Why not split both? ;) But yes, notifications in QtGui probably makes more since. It includes icons - avoiding an unnecessary split of notifications, and on some platforms notifications are tied to the graphical API and will need it. `Allan From madigens at gmail.com Sun Nov 27 15:13:40 2016 From: madigens at gmail.com (Nikolaus Waxweiler) Date: Sun, 27 Nov 2016 15:13:40 +0100 Subject: [Development] Font rendering on X11/Wayland: New FreeType API to toggle LCD filters and stem darkening on a per-font basis, would love a review In-Reply-To: <201611211340.48516.kde@carewolf.com> References: <616401a8-5e41-bf4b-e5eb-a4deed27ff6c@gmail.com> <201611201838.04296.kde@carewolf.com> <201611211340.48516.kde@carewolf.com> Message-ID: <39987191-a7d2-3faf-7ce5-dee8129d2c15@gmail.com> > Note, we need a FreeType API for getting to the module-name from the face, or > a direct getter of the stem-darkening on the face. Werner had this to say: > Get the font format with `FT_Get_Font_Format'; the returned string can > then be mapped to the corresponding module name. > > CFF -> cff > TrueType -> truetype > > For the auto-hinter this doesn't work, of course, since it is > completely agnostic of the font format. From samuel.gaist at edeltech.ch Sun Nov 27 20:22:25 2016 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Sun, 27 Nov 2016 20:22:25 +0100 Subject: [Development] New library in qtbase In-Reply-To: <13507339.QtWAKzEl5T@tjmaciei-mobl1> References: <13507339.QtWAKzEl5T@tjmaciei-mobl1> Message-ID: <00277C8A-FA69-44DF-85A3-CA224DE8B688@edeltech.ch> > On 26 Nov 2016, at 07:50, Thiago Macieira wrote: > > On sábado, 26 de novembro de 2016 00:51:06 PST Samuel Gaist wrote: >> The library as it is currently could even be in its own repository however >> the goal in the long run is to replace the code used in QSystemTrayIcon by >> calls to this module which at this time duplicates the showMessage logic >> for macOS. Therefore having it as a separated repo would mean that qtbase >> would depend on it to be build which IMHO is not an option. > > What platforms are you targetting, besides macOS? Which ones have you already > developed? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > Currently there’s macOS and iOS already working. The plan is to add - Android - Linux through DBus - Win10 (there will be some constraints if I understood their documentation correctly) From thiago.macieira at intel.com Sun Nov 27 20:44:09 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 27 Nov 2016 11:44:09 -0800 Subject: [Development] New library in qtbase In-Reply-To: <00277C8A-FA69-44DF-85A3-CA224DE8B688@edeltech.ch> References: <13507339.QtWAKzEl5T@tjmaciei-mobl1> <00277C8A-FA69-44DF-85A3-CA224DE8B688@edeltech.ch> Message-ID: <2976940.gPpOHW8DdO@tjmaciei-mobl1> On domingo, 27 de novembro de 2016 20:22:25 PST Samuel Gaist wrote: > Currently there’s macOS and iOS already working. > > The plan is to add > - Android > - Linux through DBus > - Win10 (there will be some constraints if I understood their documentation > correctly) How about the older X11 / XEmbed way? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From aleixpol at kde.org Mon Nov 28 01:05:10 2016 From: aleixpol at kde.org (Aleix Pol) Date: Mon, 28 Nov 2016 01:05:10 +0100 Subject: [Development] New library in qtbase In-Reply-To: References: Message-ID: On Sat, Nov 26, 2016 at 12:51 AM, Samuel Gaist wrote: > Hi, > > As requested by Thiago in https://codereview.qt-project.org/#/c/166456/ I’d like to open a discussion about adding a new library in qtbase. > > Why this discussion ? > > Currently in work a pluggable notification system developed in its own library in qtbase. > > Why add a new library ? > > Originally the submission was integrated in QPA however after some thoughts and discussion, it was reworked to avoid that so that developers of non-GUI application could also take advantage of notifications without the need of a QGuiApplication. > > One of my motivation to move the code in its own library was that the second implementation provided a run-time plugin selection mechanism much like the QtSql module. After further discussion, the plugin selection has been moved to build-time. > > The library as it is currently could even be in its own repository however the goal in the long run is to replace the code used in QSystemTrayIcon by calls to this module which at this time duplicates the showMessage logic for macOS. Therefore having it as a separated repo would mean that qtbase would depend on it to be build which IMHO is not an option. > > So basically we are at this point: > > 1) Keep the new notifications module > 2) Move the code in the gui module since QImage might be used > > In any case, the outcome of this discussion should likely be written in a QUIP so we have a clear set of rules about adding new libraries in existing Qt modules. > > Thank you for your attention This is very interesting! We've missed this in several occasions and at the moment it's a bit of a stopper for some KDE applications to flourish on some platforms (thinking of KDE Connect at the moment but I'm sure that others too). IMHO the inflection point it's whether it's going to require QCoreApplication or QGuiApplication. Without having sat down into details, not only QImage but QIcon should also be part of the API. I'd say that QtGui will end up being required. Aleix From thiago.macieira at intel.com Mon Nov 28 06:40:39 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 27 Nov 2016 21:40:39 -0800 Subject: [Development] Whoever is responsible for QtGamepad Message-ID: <3333781.M8cARef2nB@tjmaciei-mobl1> Please have a component created for you in JIRA and take ownership of https://bugreports.qt.io/browse/QTBUG-57338 I've made the bug report unassigned meanwhile. If you don't do that, it'll be in the limbo forever. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From alexander.blasche at qt.io Mon Nov 28 08:23:48 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Mon, 28 Nov 2016 07:23:48 +0000 Subject: [Development] Whoever is responsible for QtGamepad In-Reply-To: <3333781.M8cARef2nB@tjmaciei-mobl1> References: <3333781.M8cARef2nB@tjmaciei-mobl1> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Thiago > Macieira > Please have a component created for you in JIRA and take ownership of > https://bugreports.qt.io/browse/QTBUG-57338 Done and assigned to Andy. I also took the liberty of updating https://wiki.qt.io/Maintainers. -- Alex From sean.harmer at kdab.com Mon Nov 28 10:12:21 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 28 Nov 2016 09:12:21 +0000 Subject: [Development] Retargeting Requests: 5.8 -> 5.8.0 Message-ID: <2164605.2UNX5e4pXI@cartman> Hi Ossi/Friedeman, could you retarget the following to the 5.8.0 branch please? Thanks in advance! https://codereview.qt-project.org/#/c/170339/ https://codereview.qt-project.org/#/c/170431/ https://codereview.qt-project.org/#/c/170432/ https://codereview.qt-project.org/#/c/170433/ https://codereview.qt-project.org/#/c/170434/ https://codereview.qt-project.org/#/c/170439/ https://codereview.qt-project.org/#/c/170440/ https://codereview.qt-project.org/#/c/170441/ https://codereview.qt-project.org/#/c/170442/ https://codereview.qt-project.org/#/c/170443/ https://codereview.qt-project.org/#/c/170444/ https://codereview.qt-project.org/#/c/170445/ https://codereview.qt-project.org/#/c/170493/ https://codereview.qt-project.org/#/c/170494/ https://codereview.qt-project.org/#/c/170495/ https://codereview.qt-project.org/#/c/170496/ https://codereview.qt-project.org/#/c/170578/ https://codereview.qt-project.org/#/c/170579/ https://codereview.qt-project.org/#/c/170580/ https://codereview.qt-project.org/#/c/170581/ https://codereview.qt-project.org/#/c/170621/ https://codereview.qt-project.org/#/c/170622/ https://codereview.qt-project.org/#/c/170623/ https://codereview.qt-project.org/#/c/170690/ https://codereview.qt-project.org/#/c/170691/ https://codereview.qt-project.org/#/c/170692/ https://codereview.qt-project.org/#/c/170693/ https://codereview.qt-project.org/#/c/170694/ https://codereview.qt-project.org/#/c/172659/ https://codereview.qt-project.org/#/c/172660/ https://codereview.qt-project.org/#/c/172661/ https://codereview.qt-project.org/#/c/172662/ https://codereview.qt-project.org/#/c/172663/ https://codereview.qt-project.org/#/c/172664/ https://codereview.qt-project.org/#/c/172665/ https://codereview.qt-project.org/#/c/172666/ https://codereview.qt-project.org/#/c/172666/ https://codereview.qt-project.org/#/c/173077/ https://codereview.qt-project.org/#/c/173078/ https://codereview.qt-project.org/#/c/173079/ https://codereview.qt-project.org/#/c/173167/ https://codereview.qt-project.org/#/c/178047/ https://codereview.qt-project.org/#/c/177976/ https://codereview.qt-project.org/#/c/177977/ https://codereview.qt-project.org/#/c/177978/ https://codereview.qt-project.org/#/c/177979/ Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From marc.mutz at kdab.com Mon Nov 28 13:39:46 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 28 Nov 2016 13:39:46 +0100 Subject: [Development] [HEADS-UP] Updates to branching scheme In-Reply-To: <20161125124015.GD21393@troll08> References: <20161125124015.GD21393@troll08> Message-ID: <201611281339.46912.marc.mutz@kdab.com> On Friday 25 November 2016 13:40:15 Oswald Buddenhagen wrote: > hello, > > as discussed at the QtCS and these lists, forward-merging from the LTS > branch 5.6 is becoming a significant burden. > therefore, 5.6 is switching to a cherry-pick based model: > - 5.6 is *NOT* going to be forward-merged any more, *ever* (also not to > merge tags) How about some advance notice to finish integrating existing stuff into 5.6?!? > - you may integrate only changes which have been already integrated into > a stable mainline > - use cherry-pick -x. don't forget to refresh the change if you create > it before the source change integrates (new sha1!). > - within the 5.6 "realm", there will be forward-merging from the release > branch (next: 5.6.3) to 5.6 itself, so cherry-pick to only one of the > 5.6.x branches. > - this model is actually the same as what we employed for 4.8, our last > LTS branch. > - if you find that your changes recently integrated on 5.6 don't show up > on 5.7 until monday, it means that you missed the last merge. in this > case you'll need to _forward_-cherry-pick them. this is an exceptional > case. to prevent this from happening from this point on, staging in > 5.6 is temporarily locked down until we open it up again for the > cherry-picks. > > second item: with the 5.8.0 release approaching, 5.7 is now reaching end > of life. only critical fixes should go to 5.7 at this point. staging in > 5.7 has been restricted to the release team, so we will be able to > forward-merge 5.7 directly into 5.8.0, and we could in principle do a > 5.7.2 release directly from that branch. all non-critical fixes should > go to 5.8 now. > > i'm expecting a flurry of retargeting requests of changes from 5.6 and > 5.7 to 5.8 now. > > regards, > lars & ossi > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From giuseppe.dangelo at kdab.com Mon Nov 28 14:18:23 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 28 Nov 2016 14:18:23 +0100 Subject: [Development] [HEADS-UP] Updates to branching scheme In-Reply-To: <20161125174520.GG5187@troll08> References: <20161125124015.GD21393@troll08> <43dbdc1b-c80d-8e6f-bbc0-6e7dc6874ca0@kdab.com> <20161125174520.GG5187@troll08> Message-ID: <09ad0685-dc43-466b-c91f-e9c73b0131bc@kdab.com> Il 25/11/2016 18:45, Oswald Buddenhagen ha scritto: > as an immediate measure, you may step up and _commit to_ being the merge > monkey (at least for the 5.6 -> 5.8 merges). if you do that quick enough > (like, monday), we may reconsider. Nice straw man in there. :P I put "merge masters burden" in the pros. The cons are not getting discussed at all. See, this is why we need tools for structured discussions... Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From annulen at yandex.ru Mon Nov 28 15:11:19 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 28 Nov 2016 17:11:19 +0300 Subject: [Development] Proposal: Use -qt-zlib configuration in official MinGW builds Message-ID: <1760001480342279@web16m.yandex.ru> Hello, Currently, MinGW builds in Coin use -system-zlib configuration. It happens because MinGW is shipped with zlib headers and libz.a. However, linking zlib to several Qt modules (at least, QtCore, QtGui, QtNetwork, and QtSvg) is suboptimal, while with -system-zlib one copy in QtCore is shared between all modules. Also this would be consistent with MSVC builds. -- Regards, Konstantin From marc.mutz at kdab.com Mon Nov 28 15:33:17 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 28 Nov 2016 15:33:17 +0100 Subject: [Development] =?utf-8?q?Basing_Qt_Creator_Coding_Style_on_C++_Co?= =?utf-8?q?re_Guidelines=3F?= In-Reply-To: <201611182037.26392.marc.mutz@kdab.com> References: <3180741.cRJAskENCj@tjmaciei-mobl1> <05EB4094-933F-4B45-AFA2-A389F978E275@qt.io> <201611182037.26392.marc.mutz@kdab.com> Message-ID: <7856b53df583fc7dd2de58906b33c14b@kdab.com> On 2016-11-18 20:37, Marc Mutz wrote: > On Friday 18 November 2016 09:30:03 Lars Knoll wrote: >> On 17/11/16 23:03, Thiago Macieira wrote: [...] >> > But GSL is another story. If it is sensibly developed, with a promise >> > to binary compatibility for extended periods of time and no nonsense >> > stuff like inline namespaces, we could accept it. Especially the >> > header-only parts of it. [...] >> Let's wait a bit how this develops, and whether they are even >> interested in >> keeping compatibility between versions. But it would be another >> dependency, something I don't want to introduce without getting enough >> benefit out of it. > > The GSL is header-only. There are no BC guarantees, and, "worse", there > are > different implementations. All the compiler, or a static checker, cares > about > is the name of type: ::gsl::owner, ::gsl::non_null, ::gsl::string_span. > It > does not care about the implementation. To see how simple gsl::owner markup is to incorporate into Qt, I sat down, added it to QtGlobal and marked up QScopedPointer (incl. docs) with gsl::owner. https://codereview.qt-project.org/178107 Anything other than gsl::owner is hitting the incompatibility wall, but, given some form of reliable detection of GSL alternatives, could be used with a Qt implementation as a fallback. In that case, Qt would only give BC guarantees for the version compiled with its own version of the GSL. This is a stop-gap measure to enable the use of more of GSL in Qt while still being bound by the current restrictive API rules. Personally, I wouldn't bother with anything but gsl::owner until those rules are relaxed to allow upstream GSL's types in the ABI. The use of gsl::owner now also marks places where we might want to use unique_ptr in the future, reducing this amount of conceptual work when moving to Qt 6. Thanks, Marc From alexander.blasche at qt.io Mon Nov 28 16:40:56 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Mon, 28 Nov 2016 15:40:56 +0000 Subject: [Development] Qt 5.9 In-Reply-To: References: , Message-ID: Ok, let's summarize and restate the package list for Qt 5.9 based on the comments provided on this mail thread. The list describes the delta to Qt 5.8 packages: * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 * For iOS we drop 7.x and support 8.x, 9.x, 10.x * MinGW remains 5.3 using 32 bit * Add MSVC 2017 64bit desktop * Add MSVC 2017 UWP (x64, x86, armv7) * Drop MSVC 2013 x86 * Drop MSVC 2013 for WinRT/WinPhone & MSVC 2013 for WinRT 8.1 and WinPhone 8.1 * Drop standalone macOS Android installer; One having iOS & Android * For Windows Android start doing Android Windows build with MinGW53 * Start supporting QNX 7.0 -- Alex From Jake.Petroules at qt.io Mon Nov 28 19:23:02 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Mon, 28 Nov 2016 18:23:02 +0000 Subject: [Development] Qt 5.9 In-Reply-To: References: Message-ID: <2107A1D2-A516-4248-8A98-4E636E894673@qt.io> > On Nov 28, 2016, at 7:40 AM, Alexander Blasche wrote: > > Ok, let's summarize and restate the package list for Qt 5.9 based on the comments provided on this mail thread. The list describes the delta to Qt 5.8 packages: > > * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 > * For iOS we drop 7.x and support 8.x, 9.x, 10.x * For tvOS we drop 9.x and support 10.x * For watchOS we drop 2.x and support 3.x > * MinGW remains 5.3 using 32 bit > * Add MSVC 2017 64bit desktop > * Add MSVC 2017 UWP (x64, x86, armv7) > * Drop MSVC 2013 x86 > * Drop MSVC 2013 for WinRT/WinPhone & MSVC 2013 for WinRT 8.1 and WinPhone 8.1 > * Drop standalone macOS Android installer; One having iOS & Android As I said, let's not, and instead drop the massive macOS+iOS+Android installer in favor of an iOS-only installer. > * For Windows Android start doing Android Windows build with MinGW53 > * Start supporting QNX 7.0 > > -- > Alex > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From jani.heikkinen at qt.io Tue Nov 29 08:24:41 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 29 Nov 2016 07:24:41 +0000 Subject: [Development] Qt 5.9 In-Reply-To: <2107A1D2-A516-4248-8A98-4E636E894673@qt.io> References: <2107A1D2-A516-4248-8A98-4E636E894673@qt.io> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+jani.heikkinen=qt.io at qt-project.org] On Behalf Of Jake Petroules > Sent: maanantaina 28. marraskuuta 2016 20.23 > To: Alexander Blasche > Cc: development at qt-project.org; releasing at qt-project.org > Subject: Re: [Development] Qt 5.9 > > > > On Nov 28, 2016, at 7:40 AM, Alexander Blasche > wrote: > > > > Ok, let's summarize and restate the package list for Qt 5.9 based on the > comments provided on this mail thread. The list describes the delta to Qt 5.8 > packages: > > > > * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 > > * For iOS we drop 7.x and support 8.x, 9.x, 10.x > > * For tvOS we drop 9.x and support 10.x > * For watchOS we drop 2.x and support 3.x > > > * MinGW remains 5.3 using 32 bit > > * Add MSVC 2017 64bit desktop > > * Add MSVC 2017 UWP (x64, x86, armv7) > > * Drop MSVC 2013 x86 > > * Drop MSVC 2013 for WinRT/WinPhone & MSVC 2013 for WinRT 8.1 and > WinPhone 8.1 > > * Drop standalone macOS Android installer; One having iOS & Android > > As I said, let's not, and instead drop the massive macOS+iOS+Android > installer in favor of an iOS-only installer. Is it really so that users of iOS installer needs only iOS binaries and nothing for desktop side? In this case I agree this might be the optimal solution but this doesn't decrease amount of our installers and that's why I prefer just dropping that one & keep those two old ones: - one just for macOS + another one for macOS, iOS & Android br, Jani > > > * For Windows Android start doing Android Windows build with MinGW53 > > * Start supporting QNX 7.0 > > > > -- > > Alex > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Jake Petroules - jake.petroules at qt.io > The Qt Company - Silicon Valley > Qbs build tool evangelist - qbs.io > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Jake.Petroules at qt.io Tue Nov 29 08:32:31 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 29 Nov 2016 07:32:31 +0000 Subject: [Development] Qt 5.9 In-Reply-To: References: <2107A1D2-A516-4248-8A98-4E636E894673@qt.io> Message-ID: > On Nov 28, 2016, at 11:24 PM, Jani Heikkinen wrote: > >> -----Original Message----- >> From: Development [mailto:development- >> bounces+jani.heikkinen=qt.io at qt-project.org] On Behalf Of Jake Petroules >> Sent: maanantaina 28. marraskuuta 2016 20.23 >> To: Alexander Blasche >> Cc: development at qt-project.org; releasing at qt-project.org >> Subject: Re: [Development] Qt 5.9 >> >> >>> On Nov 28, 2016, at 7:40 AM, Alexander Blasche >> wrote: >>> >>> Ok, let's summarize and restate the package list for Qt 5.9 based on the >> comments provided on this mail thread. The list describes the delta to Qt 5.8 >> packages: >>> >>> * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 >>> * For iOS we drop 7.x and support 8.x, 9.x, 10.x >> >> * For tvOS we drop 9.x and support 10.x >> * For watchOS we drop 2.x and support 3.x >> >>> * MinGW remains 5.3 using 32 bit >>> * Add MSVC 2017 64bit desktop >>> * Add MSVC 2017 UWP (x64, x86, armv7) >>> * Drop MSVC 2013 x86 >>> * Drop MSVC 2013 for WinRT/WinPhone & MSVC 2013 for WinRT 8.1 and >> WinPhone 8.1 >>> * Drop standalone macOS Android installer; One having iOS & Android >> >> As I said, let's not, and instead drop the massive macOS+iOS+Android >> installer in favor of an iOS-only installer. > > Is it really so that users of iOS installer needs only iOS binaries and nothing for desktop side? > > In this case I agree this might be the optimal solution but this doesn't decrease amount of our installers and that's why I prefer just dropping that one & keep those two old ones: > - one just for macOS + another one for macOS, iOS & Android I have no idea what I'm getting when I download these packages. Why do we maintain an inconsistency for macOS versus the other two host platforms? I don't see why we can't simplify this process and have ONE platform per installer... Let's focus on delivering a better experience to our users and customers instead of dropping packages just because it makes our job a little bit easier. ;) > > br, > Jani > >> >>> * For Windows Android start doing Android Windows build with MinGW53 >>> * Start supporting QNX 7.0 >>> >>> -- >>> Alex >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> >> -- >> Jake Petroules - jake.petroules at qt.io >> The Qt Company - Silicon Valley >> Qbs build tool evangelist - qbs.io >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From nassian at bitshift-dynamics.de Tue Nov 29 08:37:36 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Tue, 29 Nov 2016 08:37:36 +0100 Subject: [Development] Qt 5.9 In-Reply-To: References: <2107A1D2-A516-4248-8A98-4E636E894673@qt.io> Message-ID: I don’t get the use case for having *only* iOS installed on my system. As well as for example only a cross Qt for an embedded device (iOS is practically the same thing). The normal development cycle should be (at least in my opinion) mainly develop on the desktop and check on the target in a regular manner. The cross build and deployment is enormously slower than on the desktop (which is ok with a cycle as I described), so why would I ever *only* use the cross build and deployment? Same thing for Android. Same thing for any embedded Linux target, but in contrast to Android and iOS we don’t deliver prebuilt binaries for them. Beste Grüße / Best regards, Alexander Nassian > Am 29.11.2016 um 08:24 schrieb Jani Heikkinen : > >> -----Original Message----- >> From: Development [mailto:development- >> bounces+jani.heikkinen=qt.io at qt-project.org ] On Behalf Of Jake Petroules >> Sent: maanantaina 28. marraskuuta 2016 20.23 >> To: Alexander Blasche > >> Cc: development at qt-project.org ; releasing at qt-project.org >> Subject: Re: [Development] Qt 5.9 >> >> >>> On Nov 28, 2016, at 7:40 AM, Alexander Blasche >> wrote: >>> >>> Ok, let's summarize and restate the package list for Qt 5.9 based on the >> comments provided on this mail thread. The list describes the delta to Qt 5.8 >> packages: >>> >>> * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 >>> * For iOS we drop 7.x and support 8.x, 9.x, 10.x >> >> * For tvOS we drop 9.x and support 10.x >> * For watchOS we drop 2.x and support 3.x >> >>> * MinGW remains 5.3 using 32 bit >>> * Add MSVC 2017 64bit desktop >>> * Add MSVC 2017 UWP (x64, x86, armv7) >>> * Drop MSVC 2013 x86 >>> * Drop MSVC 2013 for WinRT/WinPhone & MSVC 2013 for WinRT 8.1 and >> WinPhone 8.1 >>> * Drop standalone macOS Android installer; One having iOS & Android >> >> As I said, let's not, and instead drop the massive macOS+iOS+Android >> installer in favor of an iOS-only installer. > > Is it really so that users of iOS installer needs only iOS binaries and nothing for desktop side? > > In this case I agree this might be the optimal solution but this doesn't decrease amount of our installers and that's why I prefer just dropping that one & keep those two old ones: > - one just for macOS + another one for macOS, iOS & Android > > br, > Jani > >> >>> * For Windows Android start doing Android Windows build with MinGW53 >>> * Start supporting QNX 7.0 >>> >>> -- >>> Alex >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> >> -- >> Jake Petroules - jake.petroules at qt.io >> The Qt Company - Silicon Valley >> Qbs build tool evangelist - qbs.io >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Petroules at qt.io Tue Nov 29 08:42:53 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 29 Nov 2016 07:42:53 +0000 Subject: [Development] Qt 5.9 In-Reply-To: References: <2107A1D2-A516-4248-8A98-4E636E894673@qt.io> Message-ID: I don't know what sort of cross build and deployment environment you've set up, but I've worked with Qt Creator developing on actual embedded Linux hardware and the code-deploy-test cycle is lightning fast; no slower than desktop at all. iOS may be slower in particular due to our suboptimal build process implementation on that platform (and thus recommending that you use the iOS Simulator instead might not be a viable alternative), but I at least have never noticed any problems with slowness here so I'm not sure what you're referring to. Android, I'm not sure. Again, possibly due to the suboptimal build process implementation, but at least the emulators are blazing fast these days compared to the original SDK back in 2010 or so. > On Nov 28, 2016, at 11:37 PM, Alexander Nassian wrote: > > I don’t get the use case for having *only* iOS installed on my system. As well as for example only a cross Qt for an embedded device (iOS is practically the same thing). The normal development cycle should be (at least in my opinion) mainly develop on the desktop and check on the target in a regular manner. The cross build and deployment is enormously slower than on the desktop (which is ok with a cycle as I described), so why would I ever *only* use the cross build and deployment? Same thing for Android. Same thing for any embedded Linux target, but in contrast to Android and iOS we don’t deliver prebuilt binaries for them. > > Beste Grüße / Best regards, > Alexander Nassian > >> Am 29.11.2016 um 08:24 schrieb Jani Heikkinen : >> >>> -----Original Message----- >>> From: Development [mailto:development- >>> bounces+jani.heikkinen=qt.io at qt-project.org] On Behalf Of Jake Petroules >>> Sent: maanantaina 28. marraskuuta 2016 20.23 >>> To: Alexander Blasche >>> Cc: development at qt-project.org; releasing at qt-project.org >>> Subject: Re: [Development] Qt 5.9 >>> >>> >>>> On Nov 28, 2016, at 7:40 AM, Alexander Blasche >>> wrote: >>>> >>>> Ok, let's summarize and restate the package list for Qt 5.9 based on the >>> comments provided on this mail thread. The list describes the delta to Qt 5.8 >>> packages: >>>> >>>> * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 >>>> * For iOS we drop 7.x and support 8.x, 9.x, 10.x >>> >>> * For tvOS we drop 9.x and support 10.x >>> * For watchOS we drop 2.x and support 3.x >>> >>>> * MinGW remains 5.3 using 32 bit >>>> * Add MSVC 2017 64bit desktop >>>> * Add MSVC 2017 UWP (x64, x86, armv7) >>>> * Drop MSVC 2013 x86 >>>> * Drop MSVC 2013 for WinRT/WinPhone & MSVC 2013 for WinRT 8.1 and >>> WinPhone 8.1 >>>> * Drop standalone macOS Android installer; One having iOS & Android >>> >>> As I said, let's not, and instead drop the massive macOS+iOS+Android >>> installer in favor of an iOS-only installer. >> >> Is it really so that users of iOS installer needs only iOS binaries and nothing for desktop side? >> >> In this case I agree this might be the optimal solution but this doesn't decrease amount of our installers and that's why I prefer just dropping that one & keep those two old ones: >> - one just for macOS + another one for macOS, iOS & Android >> >> br, >> Jani >> >>> >>>> * For Windows Android start doing Android Windows build with MinGW53 >>>> * Start supporting QNX 7.0 >>>> >>>> -- >>>> Alex >>>> >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> -- >>> Jake Petroules - jake.petroules at qt.io >>> The Qt Company - Silicon Valley >>> Qbs build tool evangelist - qbs.io >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From nassian at bitshift-dynamics.de Tue Nov 29 08:46:46 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Tue, 29 Nov 2016 08:46:46 +0100 Subject: [Development] Qt 5.9 In-Reply-To: References: <2107A1D2-A516-4248-8A98-4E636E894673@qt.io> Message-ID: As for embedded Linux it’s not only the build and deployment itself (I usually have a separate VM for each customer and board), but much more the nature of the device itself. On the target all „real“ interfaces and features are enabled. On the desktop I disable them to speed things up and/or to compensate missing hardware - which is also really useful for automated tests. Beste Grüße / Best regards, Alexander Nassian > Am 29.11.2016 um 08:42 schrieb Jake Petroules : > > I don't know what sort of cross build and deployment environment you've set up, but I've worked with Qt Creator developing on actual embedded Linux hardware and the code-deploy-test cycle is lightning fast; no slower than desktop at all. > > iOS may be slower in particular due to our suboptimal build process implementation on that platform (and thus recommending that you use the iOS Simulator instead might not be a viable alternative), but I at least have never noticed any problems with slowness here so I'm not sure what you're referring to. > > Android, I'm not sure. Again, possibly due to the suboptimal build process implementation, but at least the emulators are blazing fast these days compared to the original SDK back in 2010 or so. > >> On Nov 28, 2016, at 11:37 PM, Alexander Nassian wrote: >> >> I don’t get the use case for having *only* iOS installed on my system. As well as for example only a cross Qt for an embedded device (iOS is practically the same thing). The normal development cycle should be (at least in my opinion) mainly develop on the desktop and check on the target in a regular manner. The cross build and deployment is enormously slower than on the desktop (which is ok with a cycle as I described), so why would I ever *only* use the cross build and deployment? Same thing for Android. Same thing for any embedded Linux target, but in contrast to Android and iOS we don’t deliver prebuilt binaries for them. >> >> Beste Grüße / Best regards, >> Alexander Nassian >> >>> Am 29.11.2016 um 08:24 schrieb Jani Heikkinen : >>> >>>> -----Original Message----- >>>> From: Development [mailto:development- >>>> bounces+jani.heikkinen=qt.io at qt-project.org] On Behalf Of Jake Petroules >>>> Sent: maanantaina 28. marraskuuta 2016 20.23 >>>> To: Alexander Blasche >>>> Cc: development at qt-project.org; releasing at qt-project.org >>>> Subject: Re: [Development] Qt 5.9 >>>> >>>> >>>>> On Nov 28, 2016, at 7:40 AM, Alexander Blasche >>>> wrote: >>>>> >>>>> Ok, let's summarize and restate the package list for Qt 5.9 based on the >>>> comments provided on this mail thread. The list describes the delta to Qt 5.8 >>>> packages: >>>>> >>>>> * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 >>>>> * For iOS we drop 7.x and support 8.x, 9.x, 10.x >>>> >>>> * For tvOS we drop 9.x and support 10.x >>>> * For watchOS we drop 2.x and support 3.x >>>> >>>>> * MinGW remains 5.3 using 32 bit >>>>> * Add MSVC 2017 64bit desktop >>>>> * Add MSVC 2017 UWP (x64, x86, armv7) >>>>> * Drop MSVC 2013 x86 >>>>> * Drop MSVC 2013 for WinRT/WinPhone & MSVC 2013 for WinRT 8.1 and >>>> WinPhone 8.1 >>>>> * Drop standalone macOS Android installer; One having iOS & Android >>>> >>>> As I said, let's not, and instead drop the massive macOS+iOS+Android >>>> installer in favor of an iOS-only installer. >>> >>> Is it really so that users of iOS installer needs only iOS binaries and nothing for desktop side? >>> >>> In this case I agree this might be the optimal solution but this doesn't decrease amount of our installers and that's why I prefer just dropping that one & keep those two old ones: >>> - one just for macOS + another one for macOS, iOS & Android >>> >>> br, >>> Jani >>> >>>> >>>>> * For Windows Android start doing Android Windows build with MinGW53 >>>>> * Start supporting QNX 7.0 >>>>> >>>>> -- >>>>> Alex >>>>> >>>>> _______________________________________________ >>>>> Development mailing list >>>>> Development at qt-project.org >>>>> http://lists.qt-project.org/mailman/listinfo/development >>>> >>>> -- >>>> Jake Petroules - jake.petroules at qt.io >>>> The Qt Company - Silicon Valley >>>> Qbs build tool evangelist - qbs.io >>>> >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> > > -- > Jake Petroules - jake.petroules at qt.io > The Qt Company - Silicon Valley > Qbs build tool evangelist - qbs.io > -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Tue Nov 29 08:47:13 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 29 Nov 2016 10:47:13 +0300 Subject: [Development] Qt 5.9 In-Reply-To: References: <2107A1D2-A516-4248-8A98-4E636E894673@qt.io> Message-ID: <2073421480405633@web23g.yandex.ru> 29.11.2016, 10:43, "Jake Petroules" : > I don't know what sort of cross build and deployment environment you've set up, but I've worked with Qt Creator developing on actual embedded Linux hardware and the code-deploy-test cycle is lightning fast; no slower than desktop at all. Indeed. Testing changes on device maybe somewhat slower, but there are lots of things that are not possible to check properly on desktop. > > iOS may be slower in particular due to our suboptimal build process implementation on that platform (and thus recommending that you use the iOS Simulator instead might not be a viable alternative), but I at least have never noticed any problems with slowness here so I'm not sure what you're referring to. > > Android, I'm not sure. Again, possibly due to the suboptimal build process implementation, but at least the emulators are blazing fast these days compared to the original SDK back in 2010 or so. > >>  On Nov 28, 2016, at 11:37 PM, Alexander Nassian wrote: >> >>  I don’t get the use case for having *only* iOS installed on my system. As well as for example only a cross Qt for an embedded device (iOS is practically the same thing). The normal development cycle should be (at least in my opinion) mainly develop on the desktop and check on the target in a regular manner. The cross build and deployment is enormously slower than on the desktop (which is ok with a cycle as I described), so why would I ever *only* use the cross build and deployment? Same thing for Android. Same thing for any embedded Linux target, but in contrast to Android and iOS we don’t deliver prebuilt binaries for them. >> >>  Beste Grüße / Best regards, >>  Alexander Nassian >> >>>  Am 29.11.2016 um 08:24 schrieb Jani Heikkinen : >>> >>>>  -----Original Message----- >>>>  From: Development [mailto:development- >>>>  bounces+jani.heikkinen=qt.io at qt-project.org] On Behalf Of Jake Petroules >>>>  Sent: maanantaina 28. marraskuuta 2016 20.23 >>>>  To: Alexander Blasche >>>>  Cc: development at qt-project.org; releasing at qt-project.org >>>>  Subject: Re: [Development] Qt 5.9 >>>> >>>>>  On Nov 28, 2016, at 7:40 AM, Alexander Blasche >>>>   wrote: >>>>>  Ok, let's summarize and restate the package list for Qt 5.9 based on the >>>>  comments provided on this mail thread. The list describes the delta to Qt 5.8 >>>>  packages: >>>>>  * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 >>>>>  * For iOS we drop 7.x and support 8.x, 9.x, 10.x >>>> >>>>  * For tvOS we drop 9.x and support 10.x >>>>  * For watchOS we drop 2.x and support 3.x >>>> >>>>>  * MinGW remains 5.3 using 32 bit >>>>>  * Add MSVC 2017 64bit desktop >>>>>  * Add MSVC 2017 UWP (x64, x86, armv7) >>>>>  * Drop MSVC 2013 x86 >>>>>  * Drop MSVC 2013 for WinRT/WinPhone & MSVC 2013 for WinRT 8.1 and >>>>  WinPhone 8.1 >>>>>  * Drop standalone macOS Android installer; One having iOS & Android >>>> >>>>  As I said, let's not, and instead drop the massive macOS+iOS+Android >>>>  installer in favor of an iOS-only installer. >>> >>>  Is it really so that users of iOS installer needs only iOS binaries and nothing for desktop side? >>> >>>  In this case I agree this might be the optimal solution but this doesn't decrease amount of our installers and that's why I prefer just dropping that one & keep those two old ones: >>>  - one just for macOS + another one for macOS, iOS & Android >>> >>>  br, >>>  Jani >>> >>>>>  * For Windows Android start doing Android Windows build with MinGW53 >>>>>  * Start supporting QNX 7.0 >>>>> >>>>>  -- >>>>>  Alex >>>>> >>>>>  _______________________________________________ >>>>>  Development mailing list >>>>>  Development at qt-project.org >>>>>  http://lists.qt-project.org/mailman/listinfo/development >>>> >>>>  -- >>>>  Jake Petroules - jake.petroules at qt.io >>>>  The Qt Company - Silicon Valley >>>>  Qbs build tool evangelist - qbs.io >>>> >>>>  _______________________________________________ >>>>  Development mailing list >>>>  Development at qt-project.org >>>>  http://lists.qt-project.org/mailman/listinfo/development >>>  _______________________________________________ >>>  Development mailing list >>>  Development at qt-project.org >>>  http://lists.qt-project.org/mailman/listinfo/development > > -- > Jake Petroules - jake.petroules at qt.io > The Qt Company - Silicon Valley > Qbs build tool evangelist - qbs.io > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From samuel.gaist at edeltech.ch Tue Nov 29 09:07:47 2016 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Tue, 29 Nov 2016 09:07:47 +0100 Subject: [Development] New library in qtbase In-Reply-To: <2976940.gPpOHW8DdO@tjmaciei-mobl1> References: <13507339.QtWAKzEl5T@tjmaciei-mobl1> <00277C8A-FA69-44DF-85A3-CA224DE8B688@edeltech.ch> <2976940.gPpOHW8DdO@tjmaciei-mobl1> Message-ID: <9D014B0F-982B-4A5E-AC85-91B5A85F7170@edeltech.ch> > On 27 Nov 2016, at 20:44, Thiago Macieira wrote: > > On domingo, 27 de novembro de 2016 20:22:25 PST Samuel Gaist wrote: >> Currently there’s macOS and iOS already working. >> >> The plan is to add >> - Android >> - Linux through DBus >> - Win10 (there will be some constraints if I understood their documentation >> correctly) > > How about the older X11 / XEmbed way? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > I was writing the list from memory and I forgot that one. I haven’t took a deep look yet at it but I don’t see any reason to not have it. From samuel.gaist at edeltech.ch Tue Nov 29 09:22:47 2016 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Tue, 29 Nov 2016 09:22:47 +0100 Subject: [Development] New library in qtbase In-Reply-To: References: Message-ID: <2E63EAFE-3E6A-4DCE-87E6-2A06EF96422C@edeltech.ch> > On 28 Nov 2016, at 01:05, Aleix Pol wrote: > > On Sat, Nov 26, 2016 at 12:51 AM, Samuel Gaist wrote: >> Hi, >> >> As requested by Thiago in https://codereview.qt-project.org/#/c/166456/ I’d like to open a discussion about adding a new library in qtbase. >> >> Why this discussion ? >> >> Currently in work a pluggable notification system developed in its own library in qtbase. >> >> Why add a new library ? >> >> Originally the submission was integrated in QPA however after some thoughts and discussion, it was reworked to avoid that so that developers of non-GUI application could also take advantage of notifications without the need of a QGuiApplication. >> >> One of my motivation to move the code in its own library was that the second implementation provided a run-time plugin selection mechanism much like the QtSql module. After further discussion, the plugin selection has been moved to build-time. >> >> The library as it is currently could even be in its own repository however the goal in the long run is to replace the code used in QSystemTrayIcon by calls to this module which at this time duplicates the showMessage logic for macOS. Therefore having it as a separated repo would mean that qtbase would depend on it to be build which IMHO is not an option. >> >> So basically we are at this point: >> >> 1) Keep the new notifications module >> 2) Move the code in the gui module since QImage might be used >> >> In any case, the outcome of this discussion should likely be written in a QUIP so we have a clear set of rules about adding new libraries in existing Qt modules. >> >> Thank you for your attention > > This is very interesting! We've missed this in several occasions and > at the moment it's a bit of a stopper for some KDE applications to > flourish on some platforms (thinking of KDE Connect at the moment but > I'm sure that others too). > > IMHO the inflection point it's whether it's going to require > QCoreApplication or QGuiApplication. Without having sat down into > details, not only QImage but QIcon should also be part of the API. I'd > say that QtGui will end up being required. > > Aleix That’s one of the “trick" I used, I didn’t put the QIcon interface on purpose. Without it you don’t need a QGuiApplication. One possibility might be to do like Jake suggested and have one non-gui and one gui library provide by the module. If we go with Allan's suggestion, putting it in QPA (which corresponds a bit like my first implementation), then there would be no way around a QGuiApplication. Samuel From thiago.macieira at intel.com Tue Nov 29 09:31:50 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 29 Nov 2016 00:31:50 -0800 Subject: [Development] New library in qtbase In-Reply-To: <9D014B0F-982B-4A5E-AC85-91B5A85F7170@edeltech.ch> References: <2976940.gPpOHW8DdO@tjmaciei-mobl1> <9D014B0F-982B-4A5E-AC85-91B5A85F7170@edeltech.ch> Message-ID: <3150359.ivMQHeSVmh@tjmaciei-mobl1> On terça-feira, 29 de novembro de 2016 09:07:47 PST Samuel Gaist wrote: > > On 27 Nov 2016, at 20:44, Thiago Macieira > > wrote:> > > On domingo, 27 de novembro de 2016 20:22:25 PST Samuel Gaist wrote: > >> Currently there’s macOS and iOS already working. > >> > >> The plan is to add > >> - Android > >> - Linux through DBus > >> - Win10 (there will be some constraints if I understood their > >> documentation > >> correctly) > > > > How about the older X11 / XEmbed way? > > I was writing the list from memory and I forgot that one. > > I haven’t took a deep look yet at it but I don’t see any reason to not have > it. So it really looks like this should be part of QtGui with implementation in each QPA plugin. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Nov 29 09:33:26 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 29 Nov 2016 00:33:26 -0800 Subject: [Development] Qt 5.9 In-Reply-To: References: Message-ID: <1730010.M5yXzDyc6Q@tjmaciei-mobl1> On terça-feira, 29 de novembro de 2016 07:32:31 PST Jake Petroules wrote: > I have no idea what I'm getting when I download these packages. Why do we > maintain an inconsistency for macOS versus the other two host platforms? I > don't see why we can't simplify this process and have ONE platform per > installer... I agree with Jake. People download the one they need first (now!). If they need something else later, they can just run the maintenance tool and have it install the rest. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Tue Nov 29 09:53:59 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 29 Nov 2016 09:53:59 +0100 Subject: [Development] CI error: "creation of work items failed" Message-ID: <201611290954.00015.marc.mutz@kdab.com> Hi, I'm seeing Continuous Integration: Cancelled Creation of work items failed: The module (qt/qtbase) sha1 needs to be known if it is not part of product (qt/qt5) Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444 errors on the CI for 5.8 recently (since yesterday?). Would appreciate if someone looked into it. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- An embedded message was scrubbed... From: "Qt CI Bot (Code Review)" Subject: Change in qt/qtbase[5.8]: QListViewItem: add constexpr Date: Tue, 29 Nov 2016 08:17:31 +0000 Size: 3507 URL: From samuel.gaist at edeltech.ch Tue Nov 29 09:54:16 2016 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Tue, 29 Nov 2016 09:54:16 +0100 Subject: [Development] CI error: "creation of work items failed" In-Reply-To: <201611290954.00015.marc.mutz@kdab.com> References: <201611290954.00015.marc.mutz@kdab.com> Message-ID: <7B7C668B-3AE8-4E19-9415-D5EF05C40435@edeltech.ch> > On 29 Nov 2016, at 09:53, Marc Mutz wrote: > > Hi, > > I'm seeing > > Continuous Integration: Cancelled > > Creation of work items failed: The module (qt/qtbase) sha1 needs to be known > if it is not part of product (qt/qt5) > > Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444 > > errors on the CI for 5.8 recently (since yesterday?). > > Would appreciate if someone looked into it. > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt, C++ and OpenGL Experts > > From: "Qt CI Bot (Code Review)" > Subject: Change in qt/qtbase[5.8]: QListViewItem: add constexpr > Date: 29 November 2016 at 09:17:31 GMT+1 > To: Marc Mutz > Cc: Friedemann Kleint , Qt Sanity Bot , "Olivier Goffart (Woboq GmbH)" , Thiago Macieira , Sérgio Martins , Giuseppe D'Angelo > Reply-To: qt_ci_bot at qt-project.org > > > Qt CI Bot has posted comments on this change. > > Change subject: QListViewItem: add constexpr > ...................................................................... > > > Continuous Integration: Cancelled > > Creation of work items failed: The module (qt/qtbase) sha1 needs to be known if it is not part of product (qt/qt5) > > Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444 > > Tested changes (refs/builds/qtci/5.8/1480407442): > https://codereview.qt-project.org/#/q/baf6e39ab16de581e4f836226af0156694e43a88,n,z QListViewItem: add constexpr > > -- > To view, visit https://codereview.qt-project.org/173313 > To unsubscribe, visit https://codereview.qt-project.org/settings > > Gerrit-MessageType: comment > Gerrit-Change-Id: Ibae16792d822ff183a0c542380501978f2108d93 > Gerrit-PatchSet: 2 > Gerrit-Project: qt/qtbase > Gerrit-Branch: 5.8 > Gerrit-Owner: Marc Mutz > Gerrit-Reviewer: Friedemann Kleint > Gerrit-Reviewer: Giuseppe D'Angelo > Gerrit-Reviewer: Marc Mutz > Gerrit-Reviewer: Olivier Goffart (Woboq GmbH) > Gerrit-Reviewer: Qt Sanity Bot > Gerrit-Reviewer: Sérgio Martins > Gerrit-Reviewer: Thiago Macieira > Gerrit-HasComments: No > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Hi, I just noticed that the same happened to dev Regards Samuel Qt CI Bot has posted comments on this change. Change subject: Add configurable connect timeout for QAbstractSocket ...................................................................... Continuous Integration: Cancelled Creation of work items failed: The module (qt/qtbase) sha1 needs to be known if it is not part of product (qt/qt5) Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480349268 Tested changes (refs/builds/qtci/dev/1480349266): https://codereview.qt-project.org/#/q/f580628a219f5b588e3f9c221f2f016213bfa085,n,z Add configurable connect timeout for QAbstractSocket -- To view, visit https://codereview.qt-project.org/141210 To unsubscribe, visit https://codereview.qt-project.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I1dc4051be2c74f925f7a9e0a9ccef332efc2e370 Gerrit-PatchSet: 8 Gerrit-Project: qt/qtbase Gerrit-Branch: dev Gerrit-Owner: Samuel Gaist Gerrit-Reviewer: Alex Blasche Gerrit-Reviewer: Giuseppe D'Angelo Gerrit-Reviewer: Lorn Potter Gerrit-Reviewer: Markus Goetz (Woboq GmbH) Gerrit-Reviewer: Qt Sanity Bot Gerrit-Reviewer: Richard J. Moore Gerrit-Reviewer: Samuel Gaist Gerrit-Reviewer: Thiago Macieira Gerrit-HasComments: No From dominik.holland at pelagicore.com Tue Nov 29 10:50:20 2016 From: dominik.holland at pelagicore.com (Dominik Holland) Date: Tue, 29 Nov 2016 10:50:20 +0100 Subject: [Development] CI error: "creation of work items failed" In-Reply-To: <7B7C668B-3AE8-4E19-9415-D5EF05C40435@edeltech.ch> References: <201611290954.00015.marc.mutz@kdab.com> <7B7C668B-3AE8-4E19-9415-D5EF05C40435@edeltech.ch> Message-ID: <1e280f21-a7bb-936d-0e9b-31a64a7cb6c2@pelagicore.com> Am 11/29/2016 um 09:54 AM schrieb Samuel Gaist: > >> On 29 Nov 2016, at 09:53, Marc Mutz wrote: >> >> Hi, >> >> I'm seeing >> >> Continuous Integration: Cancelled >> >> Creation of work items failed: The module (qt/qtbase) sha1 needs to be known >> if it is not part of product (qt/qt5) >> >> Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444 >> >> errors on the CI for 5.8 recently (since yesterday?). >> >> Would appreciate if someone looked into it. >> >> Thanks, >> Marc >> >> -- >> Marc Mutz | Senior Software Engineer >> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company >> Tel: +49-30-521325470 >> KDAB - The Qt, C++ and OpenGL Experts >> >> From: "Qt CI Bot (Code Review)" >> Subject: Change in qt/qtbase[5.8]: QListViewItem: add constexpr >> Date: 29 November 2016 at 09:17:31 GMT+1 >> To: Marc Mutz >> Cc: Friedemann Kleint , Qt Sanity Bot , "Olivier Goffart (Woboq GmbH)" , Thiago Macieira , Sérgio Martins , Giuseppe D'Angelo >> Reply-To: qt_ci_bot at qt-project.org >> >> >> Qt CI Bot has posted comments on this change. >> >> Change subject: QListViewItem: add constexpr >> ...................................................................... >> >> >> Continuous Integration: Cancelled >> >> Creation of work items failed: The module (qt/qtbase) sha1 needs to be known if it is not part of product (qt/qt5) >> >> Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444 >> >> Tested changes (refs/builds/qtci/5.8/1480407442): >> https://codereview.qt-project.org/#/q/baf6e39ab16de581e4f836226af0156694e43a88,n,z QListViewItem: add constexpr >> >> -- >> To view, visit https://codereview.qt-project.org/173313 >> To unsubscribe, visit https://codereview.qt-project.org/settings >> >> Gerrit-MessageType: comment >> Gerrit-Change-Id: Ibae16792d822ff183a0c542380501978f2108d93 >> Gerrit-PatchSet: 2 >> Gerrit-Project: qt/qtbase >> Gerrit-Branch: 5.8 >> Gerrit-Owner: Marc Mutz >> Gerrit-Reviewer: Friedemann Kleint >> Gerrit-Reviewer: Giuseppe D'Angelo >> Gerrit-Reviewer: Marc Mutz >> Gerrit-Reviewer: Olivier Goffart (Woboq GmbH) >> Gerrit-Reviewer: Qt Sanity Bot >> Gerrit-Reviewer: Sérgio Martins >> Gerrit-Reviewer: Thiago Macieira >> Gerrit-HasComments: No >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > Hi, > > I just noticed that the same happened to dev > > Regards > > Samuel > > > Qt CI Bot has posted comments on this change. > > Change subject: Add configurable connect timeout for QAbstractSocket > ...................................................................... > > > Continuous Integration: Cancelled > > Creation of work items failed: The module (qt/qtbase) sha1 needs to be known if it is not part of product (qt/qt5) > > Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480349268 > > Tested changes (refs/builds/qtci/dev/1480349266): > https://codereview.qt-project.org/#/q/f580628a219f5b588e3f9c221f2f016213bfa085,n,z Add configurable connect timeout for QAbstractSocket > It seems to happen to all projects in the CI, regardless whether they are part of qt5.git or not. Dominik -- Dominik Holland SENIOR SOFTWARE ENGINEER Pelagicore AG Balanstr. 55, 81541 Munich, Germany +49 (0)171 760 25 96 dominik.holland at pelagicore.com www.pelagicore.com From konrad at silmor.de Tue Nov 29 11:02:32 2016 From: konrad at silmor.de (Konrad Rosenbaum) Date: Tue, 29 Nov 2016 11:02:32 +0100 Subject: [Development] Proposal: Use -qt-zlib configuration in official MinGW builds In-Reply-To: <1760001480342279@web16m.yandex.ru> References: <1760001480342279@web16m.yandex.ru> Message-ID: <5532043.OJhSBTsZdJ@gandalf> Hi, On Monday 28 November 2016 17:11:19 Konstantin Tokarev wrote: > Currently, MinGW builds in Coin use -system-zlib configuration. It happens > because MinGW is shipped with zlib headers and libz.a. However, linking zlib > to several Qt modules (at least, QtCore, QtGui, QtNetwork, and QtSvg) is > suboptimal, while with -system-zlib one copy in QtCore is shared between > all modules. Please be aware that there are quite a few Applications out there that use zlib independently of Qt - e.g. to encode/decode ZIP files. Unfortunately Qt does not expose its internal zlib headers, nor does it wrap all functionality of zlib. So at the very least qt-zlib needs to be linked in a way that allows an additional version of zlib to be linked. Konrad From Kai.Koehne at qt.io Tue Nov 29 11:12:06 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Tue, 29 Nov 2016 10:12:06 +0000 Subject: [Development] Proposal: Use -qt-zlib configuration in official MinGW builds In-Reply-To: <5532043.OJhSBTsZdJ@gandalf> References: <1760001480342279@web16m.yandex.ru> <5532043.OJhSBTsZdJ@gandalf> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Konrad Rosenbaum > Sent: Tuesday, November 29, 2016 11:03 AM > To: development at qt-project.org > Subject: Re: [Development] Proposal: Use -qt-zlib configuration in official > MinGW builds > > Hi, > > On Monday 28 November 2016 17:11:19 Konstantin Tokarev wrote: > > Currently, MinGW builds in Coin use -system-zlib configuration. It > > happens because MinGW is shipped with zlib headers and libz.a. > > However, linking zlib to several Qt modules (at least, QtCore, QtGui, > > QtNetwork, and QtSvg) is suboptimal, while with -system-zlib one copy > > in QtCore is shared between all modules. > > Please be aware that there are quite a few Applications out there that use > zlib independently of Qt - e.g. to encode/decode ZIP files. Unfortunately Qt > does not expose its internal zlib headers, nor does it wrap all functionality of > zlib. So at the very least qt-zlib needs to be linked in a way that allows an > additional version of zlib to be linked. This shouldn't be a problem, because the symbol ones from the internal version are prefixed with "z_". See change 1f461ac45bf in qtbase. Regards Kai From annulen at yandex.ru Tue Nov 29 11:14:19 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 29 Nov 2016 13:14:19 +0300 Subject: [Development] Proposal: Use -qt-zlib configuration in official MinGW builds In-Reply-To: <5532043.OJhSBTsZdJ@gandalf> References: <1760001480342279@web16m.yandex.ru> <5532043.OJhSBTsZdJ@gandalf> Message-ID: <327351480414459@web42j.yandex.ru> 29.11.2016, 13:02, "Konrad Rosenbaum" : > Hi, > > On Monday 28 November 2016 17:11:19 Konstantin Tokarev wrote: >>  Currently, MinGW builds in Coin use -system-zlib configuration. It happens >>  because MinGW is shipped with zlib headers and libz.a. However, linking zlib >>  to several Qt modules (at least, QtCore, QtGui, QtNetwork, and QtSvg) is >>  suboptimal, while with -system-zlib one copy in QtCore is shared between >>  all modules. > > Please be aware that there are quite a few Applications out there that use > zlib independently of Qt - e.g. to encode/decode ZIP files. Unfortunately Qt > does not expose its internal zlib headers, nor does it wrap all functionality > of zlib. qt-zlib builds provide zlib headers in include/QtZlib > So at the very least qt-zlib needs to be linked in a way that allows > an additional version of zlib to be linked. zlib in QtCore is built with prefixed symbols. > >         Konrad > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From Kai.Koehne at qt.io Tue Nov 29 11:19:38 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Tue, 29 Nov 2016 10:19:38 +0000 Subject: [Development] Proposal: Use -qt-zlib configuration in official MinGW builds In-Reply-To: <1760001480342279@web16m.yandex.ru> References: <1760001480342279@web16m.yandex.ru> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Konstantin Tokarev > Sent: Monday, November 28, 2016 3:11 PM > To: development at qt-project.org > Subject: [Development] Proposal: Use -qt-zlib configuration in official > MinGW builds > > Hello, > > Currently, MinGW builds in Coin use -system-zlib configuration. It happens > because MinGW is shipped with zlib headers and libz.a. However, linking zlib > to several Qt modules (at least, QtCore, QtGui, QtNetwork, and QtSvg) is > suboptimal, while with -system-zlib one copy in QtCore is shared between all > modules. I think this is a good idea. Could you create a suggestion for this on bugreports.qt.io, component "Packaging & Installer" (https://bugreports.qt.io/browse/QTBUG/component/19211) ? Thanks Kai From annulen at yandex.ru Tue Nov 29 11:32:13 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 29 Nov 2016 13:32:13 +0300 Subject: [Development] Proposal: Use -qt-zlib configuration in official MinGW builds In-Reply-To: References: <1760001480342279@web16m.yandex.ru> Message-ID: <795171480415533@web2g.yandex.ru> 29.11.2016, 13:19, "Kai Koehne" : >>  -----Original Message----- >>  From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- >>  project.org] On Behalf Of Konstantin Tokarev >>  Sent: Monday, November 28, 2016 3:11 PM >>  To: development at qt-project.org >>  Subject: [Development] Proposal: Use -qt-zlib configuration in official >>  MinGW builds >> >>  Hello, >> >>  Currently, MinGW builds in Coin use -system-zlib configuration. It happens >>  because MinGW is shipped with zlib headers and libz.a. However, linking zlib >>  to several Qt modules (at least, QtCore, QtGui, QtNetwork, and QtSvg) is >>  suboptimal, while with -system-zlib one copy in QtCore is shared between all >>  modules. > > I think this is a good idea. > > Could you create a suggestion for this on bugreports.qt.io, component "Packaging & Installer" (https://bugreports.qt.io/browse/QTBUG/component/19211) ? Done: https://bugreports.qt.io/browse/QTBUG-57376 > > Thanks > > Kai -- Regards, Konstantin From Simon.Hausmann at qt.io Tue Nov 29 11:35:43 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 29 Nov 2016 10:35:43 +0000 Subject: [Development] CI error: "creation of work items failed" In-Reply-To: <1e280f21-a7bb-936d-0e9b-31a64a7cb6c2@pelagicore.com> References: <201611290954.00015.marc.mutz@kdab.com> <7B7C668B-3AE8-4E19-9415-D5EF05C40435@edeltech.ch>, <1e280f21-a7bb-936d-0e9b-31a64a7cb6c2@pelagicore.com> Message-ID: Hi, The bug was a file descriptor memory leak in coin, which was caused by a new upstream version of the python sh module. We didn't pin the version, so we "accidentally" got a new version that had the leak. I've reverted to a non-leaking sh version and am working on a test-case for an upstream bug report. Simon ________________________________ From: Development on behalf of Dominik Holland Sent: Tuesday, November 29, 2016 10:50:20 AM To: development at qt-project.org Subject: Re: [Development] CI error: "creation of work items failed" Am 11/29/2016 um 09:54 AM schrieb Samuel Gaist: > >> On 29 Nov 2016, at 09:53, Marc Mutz wrote: >> >> Hi, >> >> I'm seeing >> >> Continuous Integration: Cancelled >> >> Creation of work items failed: The module (qt/qtbase) sha1 needs to be known >> if it is not part of product (qt/qt5) >> >> Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444 >> >> errors on the CI for 5.8 recently (since yesterday?). >> >> Would appreciate if someone looked into it. >> >> Thanks, >> Marc >> >> -- >> Marc Mutz | Senior Software Engineer >> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company >> Tel: +49-30-521325470 >> KDAB - The Qt, C++ and OpenGL Experts >> >> From: "Qt CI Bot (Code Review)" >> Subject: Change in qt/qtbase[5.8]: QListViewItem: add constexpr >> Date: 29 November 2016 at 09:17:31 GMT+1 >> To: Marc Mutz >> Cc: Friedemann Kleint , Qt Sanity Bot , "Olivier Goffart (Woboq GmbH)" , Thiago Macieira , Sérgio Martins , Giuseppe D'Angelo >> Reply-To: qt_ci_bot at qt-project.org >> >> >> Qt CI Bot has posted comments on this change. >> >> Change subject: QListViewItem: add constexpr >> ...................................................................... >> >> >> Continuous Integration: Cancelled >> >> Creation of work items failed: The module (qt/qtbase) sha1 needs to be known if it is not part of product (qt/qt5) >> >> Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444 >> >> Tested changes (refs/builds/qtci/5.8/1480407442): >> https://codereview.qt-project.org/#/q/baf6e39ab16de581e4f836226af0156694e43a88,n,z QListViewItem: add constexpr >> >> -- >> To view, visit https://codereview.qt-project.org/173313 >> To unsubscribe, visit https://codereview.qt-project.org/settings >> >> Gerrit-MessageType: comment >> Gerrit-Change-Id: Ibae16792d822ff183a0c542380501978f2108d93 >> Gerrit-PatchSet: 2 >> Gerrit-Project: qt/qtbase >> Gerrit-Branch: 5.8 >> Gerrit-Owner: Marc Mutz >> Gerrit-Reviewer: Friedemann Kleint >> Gerrit-Reviewer: Giuseppe D'Angelo >> Gerrit-Reviewer: Marc Mutz >> Gerrit-Reviewer: Olivier Goffart (Woboq GmbH) >> Gerrit-Reviewer: Qt Sanity Bot >> Gerrit-Reviewer: Sérgio Martins >> Gerrit-Reviewer: Thiago Macieira >> Gerrit-HasComments: No >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > Hi, > > I just noticed that the same happened to dev > > Regards > > Samuel > > > Qt CI Bot has posted comments on this change. > > Change subject: Add configurable connect timeout for QAbstractSocket > ...................................................................... > > > Continuous Integration: Cancelled > > Creation of work items failed: The module (qt/qtbase) sha1 needs to be known if it is not part of product (qt/qt5) > > Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480349268 > > Tested changes (refs/builds/qtci/dev/1480349266): > https://codereview.qt-project.org/#/q/f580628a219f5b588e3f9c221f2f016213bfa085,n,z Add configurable connect timeout for QAbstractSocket > It seems to happen to all projects in the CI, regardless whether they are part of qt5.git or not. Dominik -- Dominik Holland SENIOR SOFTWARE ENGINEER Pelagicore AG Balanstr. 55, 81541 Munich, Germany +49 (0)171 760 25 96 dominik.holland at pelagicore.com www.pelagicore.com _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From kalle.viironen at qt.io Tue Nov 29 11:47:24 2016 From: kalle.viironen at qt.io (Kalle Viironen) Date: Tue, 29 Nov 2016 10:47:24 +0000 Subject: [Development] Nominating Teemu Holappa for Approver and Maintainer status. Message-ID: +1 from me. -Kalle From: Development > on behalf of Gatis Paeglis > Date: Thursday 24 November 2016 15:00 To: "development at qt-project.org" > Subject: [Development] Nominating Teemu Holappa for Approver and Maintainer status. Hi, I'd like to nominate Teemu Holappa for the Approver status. He joined Digia (now The Qt Company) 3+ years ago as a Qt consultant. Teemu has contributed to meta-boot2qt and anything else that needs fixing to get Qt for Device Creation releases out the door. Here is his gerrit dashboard: https://codereview.qt-project.org/#/q/owner:%22Teemu+Holappa+%253Cteemu.holappa%2540qt.io%253E%22+status:merged,n,z Teemu also has done a good job at reviewing changes for meta-{boot2qt, qt5, mingw} among other projects: https://codereview.qt-project.org/#/q/reviewer:%22Teemu+Holappa+%253Cteemu.holappa%2540qt.io%253E%22+status:merged,n,z I'd also like to nominate him as the Maintainer of the qtdeviceutilities module (http://code.qt.io/cgit/qt/qtdeviceutilities.git/). Teemu has heavily refactored this module and added significant amount of new features. He is the go-to guy in the team when qtdeviceutilities is the topic. Gatis Paeglis. -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuli.piippo at gmail.com Tue Nov 29 11:52:12 2016 From: samuli.piippo at gmail.com (Samuli Piippo) Date: Tue, 29 Nov 2016 12:52:12 +0200 Subject: [Development] Nominating Teemu Holappa for Approver and Maintainer status. In-Reply-To: References: Message-ID: On 24.11.2016 15:00, Gatis Paeglis wrote: > Hi, > > I'd like to nominate Teemu Holappa for the Approver status. He joined > Digia (now The Qt Company) 3+ years ago as a Qt consultant. Teemu has > contributed to meta-boot2qt and anything else that needs fixing to get > Qt for Device Creation releases out the door. > > Here is his gerrit dashboard: > > https://codereview.qt-project.org/#/q/owner:%22Teemu+Holappa+%253Cteemu.holappa%2540qt.io%253E%22+status:merged,n,z > > Teemu also has done a good job at reviewing changes for meta-{boot2qt, > qt5, mingw} among other projects: > > https://codereview.qt-project.org/#/q/reviewer:%22Teemu+Holappa+%253Cteemu.holappa%2540qt.io%253E%22+status:merged,n,z > > I'd also like to nominate him as the Maintainer of the qtdeviceutilities > module (http://code.qt.io/cgit/qt/qtdeviceutilities.git/). Teemu has > heavily refactored this module and added significant amount of new > features. He is the go-to guy in the team when qtdeviceutilities is the > topic. +1 for both, Teemu is now doing most of the work on qtdeviceutilities and makes sense to have him there as a Maintainer. -samuli From marco.a.piccolino at gmail.com Tue Nov 29 11:54:11 2016 From: marco.a.piccolino at gmail.com (Marco Piccolino) Date: Tue, 29 Nov 2016 11:54:11 +0100 Subject: [Development] Qt 5.9 Message-ID: We just had a little discussion about this on QtMob ( http://slackin.qtmob.org) where everybody does iOS/Android, and most people do it on a macOS host. It looks like people tend to use the online installer. When it comes to the offline installers (which in our case are mainly used for checking out betas, it seems) an installer for each platform seems to be the preferred option. This said, it seems that the main concern for our mobile devs is actually the size of the Qt for iOS distribution per se and people would like to have the option to not install simulator builds. Br, Marco Piccolino - QtMob community manager -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Tue Nov 29 12:08:15 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 29 Nov 2016 11:08:15 +0000 Subject: [Development] Qt 5.9 In-Reply-To: <1730010.M5yXzDyc6Q@tjmaciei-mobl1> References: , <1730010.M5yXzDyc6Q@tjmaciei-mobl1> Message-ID: >>________________________________________ >>From: Development on behalf of Thiago Macieira >>Sent: Tuesday, November 29, 2016 10:33 AM >>To: development at qt-project.org >>Subject: Re: [Development] Qt 5.9 >> >>On terça-feira, 29 de novembro de 2016 07:32:31 PST Jake Petroules wrote: >>> I have no idea what I'm getting when I download these packages. Why do we >>> maintain an inconsistency for macOS versus the other two host platforms? I >>> don't see why we can't simplify this process and have ONE platform per >>> installer... >> >>I agree with Jake. >> >>People download the one they need first (now!). If they need something else >>later, they can just run the maintenance tool and have it install the rest. That is the case with online installation. With offline installer they cannot update new stuff by using maintenance tool :( So users should prefer to online installers; with that they got biggest flexibility & smallest package size (online installer users are able to install just the stuff they need). But there is still users who need offline installers and that's why combined installer (macOS, iOS + Android) is best for their purposes: If they don't need mobile platforms at all they can just use pure desktop one. But if they are doing mobile as well then they need to use that all-in-one offline solution. That's why I still think we should proceed as I proposed: Keep online offering as it is but drop separate macos + android offline installer (have macOS and macOS + mobile targets for macOS offline offering). Decreasing our offline installer offering is essential; needed testing effort at the moment is really huge & it is increasing all the time because of these parallel releases. That's why we need to decrease stuff to be tested to make our live easier. And how to encourage users to use online installers instead of offline ones? One solution could be that we start using online ones at first & bring offline ones later. Earlier we have released beta with offline only so should we do this differently with Qt 5.9: Qt 5.9 alpha: src only Qt 5.9 beta: online only Qt 5.9 rc & final: online + offline br, Jani From samuel.gaist at edeltech.ch Tue Nov 29 12:13:14 2016 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Tue, 29 Nov 2016 12:13:14 +0100 Subject: [Development] CI error: "creation of work items failed" In-Reply-To: References: <201611290954.00015.marc.mutz@kdab.com> <7B7C668B-3AE8-4E19-9415-D5EF05C40435@edeltech.ch> <1e280f21-a7bb-936d-0e9b-31a64a7cb6c2@pelagicore.com> Message-ID: <267B9019-F3B8-4B9C-8213-B67B9E7BAC46@edeltech.ch> > On 29 Nov 2016, at 11:35, Simon Hausmann wrote: > > Hi, > > The bug was a file descriptor memory leak in coin, which was caused by a new upstream version of the python sh module. We > didn't pin the version, so we "accidentally" got a new version that had the leak. I've reverted to a non-leaking sh version and > am working on a test-case for an upstream bug report. > > > Simon Thanks ! Samuel > From: Development on behalf of Dominik Holland > Sent: Tuesday, November 29, 2016 10:50:20 AM > To: development at qt-project.org > Subject: Re: [Development] CI error: "creation of work items failed" > > Am 11/29/2016 um 09:54 AM schrieb Samuel Gaist: > > > >> On 29 Nov 2016, at 09:53, Marc Mutz wrote: > >> > >> Hi, > >> > >> I'm seeing > >> > >> Continuous Integration: Cancelled > >> > >> Creation of work items failed: The module (qt/qtbase) sha1 needs to be known > >> if it is not part of product (qt/qt5) > >> > >> Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444 > >> > >> errors on the CI for 5.8 recently (since yesterday?). > >> > >> Would appreciate if someone looked into it. > >> > >> Thanks, > >> Marc > >> > >> -- > >> Marc Mutz | Senior Software Engineer > >> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > >> Tel: +49-30-521325470 > >> KDAB - The Qt, C++ and OpenGL Experts > >> > >> From: "Qt CI Bot (Code Review)" > >> Subject: Change in qt/qtbase[5.8]: QListViewItem: add constexpr > >> Date: 29 November 2016 at 09:17:31 GMT+1 > >> To: Marc Mutz > >> Cc: Friedemann Kleint , Qt Sanity Bot , "Olivier Goffart (Woboq GmbH)" , Thiago Macieira , Sérgio Martins , Giuseppe D'Angelo > >> Reply-To: qt_ci_bot at qt-project.org > >> > >> > >> Qt CI Bot has posted comments on this change. > >> > >> Change subject: QListViewItem: add constexpr > >> ...................................................................... > >> > >> > >> Continuous Integration: Cancelled > >> > >> Creation of work items failed: The module (qt/qtbase) sha1 needs to be known if it is not part of product (qt/qt5) > >> > >> Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444 > >> > >> Tested changes (refs/builds/qtci/5.8/1480407442): > >> https://codereview.qt-project.org/#/q/baf6e39ab16de581e4f836226af0156694e43a88,n,z QListViewItem: add constexpr > >> > >> -- > >> To view, visit https://codereview.qt-project.org/173313 > >> To unsubscribe, visit https://codereview.qt-project.org/settings > >> > >> Gerrit-MessageType: comment > >> Gerrit-Change-Id: Ibae16792d822ff183a0c542380501978f2108d93 > >> Gerrit-PatchSet: 2 > >> Gerrit-Project: qt/qtbase > >> Gerrit-Branch: 5.8 > >> Gerrit-Owner: Marc Mutz > >> Gerrit-Reviewer: Friedemann Kleint > >> Gerrit-Reviewer: Giuseppe D'Angelo > >> Gerrit-Reviewer: Marc Mutz > >> Gerrit-Reviewer: Olivier Goffart (Woboq GmbH) > >> Gerrit-Reviewer: Qt Sanity Bot > >> Gerrit-Reviewer: Sérgio Martins > >> Gerrit-Reviewer: Thiago Macieira > >> Gerrit-HasComments: No > >> > >> > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > > > > Hi, > > > > I just noticed that the same happened to dev > > > > Regards > > > > Samuel > > > > > > Qt CI Bot has posted comments on this change. > > > > Change subject: Add configurable connect timeout for QAbstractSocket > > ...................................................................... > > > > > > Continuous Integration: Cancelled > > > > Creation of work items failed: The module (qt/qtbase) sha1 needs to be known if it is not part of product (qt/qt5) > > > > Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480349268 > > > > Tested changes (refs/builds/qtci/dev/1480349266): > > https://codereview.qt-project.org/#/q/f580628a219f5b588e3f9c221f2f016213bfa085,n,z Add configurable connect timeout for QAbstractSocket > > > > It seems to happen to all projects in the CI, regardless whether they > are part of qt5.git or not. > > Dominik > > -- > Dominik Holland > SENIOR SOFTWARE ENGINEER > > Pelagicore AG > Balanstr. 55, 81541 Munich, Germany > +49 (0)171 760 25 96 > dominik.holland at pelagicore.com > www.pelagicore.com > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From oswald.buddenhagen at qt.io Tue Nov 29 12:41:17 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 29 Nov 2016 12:41:17 +0100 Subject: [Development] HEADS-UP: Branching from '5.8' to '5.8.0' complete Message-ID: <20161129114117.GB3951@troll08> On Mon, Nov 21, 2016 at 01:50:04PM +0000, Jani Heikkinen wrote: > We have started branching from '5.8' to '5.8.0'. Please start using > '5.8.0' for new changes targeted to Qt 5.8.0 release. There should be > enough time to finalize ongoing changes in '5.8'; final downmerge will > happen Monday 28th November. > with just one day of delay, this has happened now. changes on 5.8 are 5.8.1 material now. have your release-critical 5.8 changes retargeted to 5.8.0 before you integrate them. cherry-picks only in extraordinary circumstances, as usual. From mardy at users.sourceforge.net Tue Nov 29 12:59:23 2016 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Tue, 29 Nov 2016 14:59:23 +0300 Subject: [Development] [HEADS-UP] Updates to branching scheme In-Reply-To: <20161125124015.GD21393@troll08> References: <20161125124015.GD21393@troll08> Message-ID: <92530f71-1e14-933a-020c-94955907b980@users.sourceforge.net> On 11/25/2016 03:40 PM, Oswald Buddenhagen wrote: > i'm expecting a flurry of retargeting requests of changes from 5.6 and > 5.7 to 5.8 now. I have a few changes targeting 5.6 which are waiting for review: https://codereview.qt-project.org/#/q/owner:%22Alberto+Mardegan%22+branch:5.6+status:open,n,z Eventually I hope to find the time to propose them on the 5.8 branch, but given that these are changes I've already proposed and they are just waiting for a +2, and that I'm myself interested in 5.6 only at the moment, it would be sooo nice if someone would take care of cherry-picking them to 5.8. :-) Ciao, Alberto From Shawn.Rutledge at qt.io Tue Nov 29 13:39:34 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 29 Nov 2016 12:39:34 +0000 Subject: [Development] New library in qtbase In-Reply-To: <9D014B0F-982B-4A5E-AC85-91B5A85F7170@edeltech.ch> References: <13507339.QtWAKzEl5T@tjmaciei-mobl1> <00277C8A-FA69-44DF-85A3-CA224DE8B688@edeltech.ch> <2976940.gPpOHW8DdO@tjmaciei-mobl1> <9D014B0F-982B-4A5E-AC85-91B5A85F7170@edeltech.ch> Message-ID: <5C427FD9-5003-41CD-9B43-91F5D34DCC39@qt.io> > On 29 Nov 2016, at 09:07, Samuel Gaist wrote: > >> On 27 Nov 2016, at 20:44, Thiago Macieira wrote: >> >> On domingo, 27 de novembro de 2016 20:22:25 PST Samuel Gaist wrote: >>> Currently there’s macOS and iOS already working. >>> >>> The plan is to add >>> - Android >>> - Linux through DBus >>> - Win10 (there will be some constraints if I understood their documentation >>> correctly) >> >> How about the older X11 / XEmbed way? > > I was writing the list from memory and I forgot that one. > > I haven’t took a deep look yet at it but I don’t see any reason to not have it. A system tray icon can emit notifications, but you aren’t putting the whole tray icon implementation into this library, are you? XEmbed is a way of rendering tray icons, whereas we don’t need it for notifications themselves, right? because they are shown as separate windows. In some cases we render them; in others, the rendering is done in another desktop-wide process. From Shawn.Rutledge at qt.io Tue Nov 29 13:44:33 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 29 Nov 2016 12:44:33 +0000 Subject: [Development] New library in qtbase In-Reply-To: References: Message-ID: <07638D4D-2F81-456F-B7B4-6E96D5B64E83@qt.io> > On 28 Nov 2016, at 01:05, Aleix Pol wrote: > > This is very interesting! We've missed this in several occasions and > at the moment it's a bit of a stopper for some KDE applications to > flourish on some platforms (thinking of KDE Connect at the moment but > I'm sure that others too). By which you mean you want to develop an alternative plugin to send desktop notifications to a remote device? Or something else? I just tried KDE Connect for the first time last night, and was wondering why it won’t run outside of a Plasma session. Is that related? From samuel.gaist at edeltech.ch Tue Nov 29 14:31:24 2016 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Tue, 29 Nov 2016 14:31:24 +0100 Subject: [Development] New library in qtbase In-Reply-To: <5C427FD9-5003-41CD-9B43-91F5D34DCC39@qt.io> References: <13507339.QtWAKzEl5T@tjmaciei-mobl1> <00277C8A-FA69-44DF-85A3-CA224DE8B688@edeltech.ch> <2976940.gPpOHW8DdO@tjmaciei-mobl1> <9D014B0F-982B-4A5E-AC85-91B5A85F7170@edeltech.ch> <5C427FD9-5003-41CD-9B43-91F5D34DCC39@qt.io> Message-ID: <938B8FC5-626C-47B1-BB12-6017C475490A@edeltech.ch> > On 29 Nov 2016, at 13:39, Shawn Rutledge wrote: > >> >> On 29 Nov 2016, at 09:07, Samuel Gaist wrote: >> >>> On 27 Nov 2016, at 20:44, Thiago Macieira wrote: >>> >>> On domingo, 27 de novembro de 2016 20:22:25 PST Samuel Gaist wrote: >>>> Currently there’s macOS and iOS already working. >>>> >>>> The plan is to add >>>> - Android >>>> - Linux through DBus >>>> - Win10 (there will be some constraints if I understood their documentation >>>> correctly) >>> >>> How about the older X11 / XEmbed way? >> >> I was writing the list from memory and I forgot that one. >> >> I haven’t took a deep look yet at it but I don’t see any reason to not have it. > > A system tray icon can emit notifications, but you aren’t putting the whole tray icon implementation into this library, are you? > > XEmbed is a way of rendering tray icons, whereas we don’t need it for notifications themselves, right? because they are shown as separate windows. In some cases we render them; in others, the rendering is done in another desktop-wide process. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development No, I’m not. The idea is to implement the notification part which would be then used by QSystemTrayIcon. From thiago.macieira at intel.com Tue Nov 29 16:55:47 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 29 Nov 2016 07:55:47 -0800 Subject: [Development] Qt 5.9 In-Reply-To: References: <1730010.M5yXzDyc6Q@tjmaciei-mobl1> Message-ID: <5178841.U4LaUdPk4B@tjmaciei-mobl1> On terça-feira, 29 de novembro de 2016 11:08:15 PST Jani Heikkinen wrote: > With offline installer they cannot update new stuff by using maintenance > tool Say what? Why not? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Jake.Petroules at qt.io Tue Nov 29 18:19:30 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 29 Nov 2016 17:19:30 +0000 Subject: [Development] Qt 5.9 In-Reply-To: References: <1730010.M5yXzDyc6Q@tjmaciei-mobl1> Message-ID: > On Nov 29, 2016, at 3:08 AM, Jani Heikkinen wrote: > >>> ________________________________________ >>> From: Development on behalf of Thiago Macieira >>> Sent: Tuesday, November 29, 2016 10:33 AM >>> To: development at qt-project.org >>> Subject: Re: [Development] Qt 5.9 >>> >>> On terça-feira, 29 de novembro de 2016 07:32:31 PST Jake Petroules wrote: >>>> I have no idea what I'm getting when I download these packages. Why do we >>>> maintain an inconsistency for macOS versus the other two host platforms? I >>>> don't see why we can't simplify this process and have ONE platform per >>>> installer... >>> >>> I agree with Jake. >>> >>> People download the one they need first (now!). If they need something else >>> later, they can just run the maintenance tool and have it install the rest. > > That is the case with online installation. With offline installer they cannot update new stuff by using maintenance tool :( So users should prefer to online installers; with that they got biggest flexibility & smallest package size (online installer users are able to install just the stuff they need). > > But there is still users who need offline installers and that's why combined installer (macOS, iOS + Android) is best for their purposes: If they don't need mobile platforms at all they can just use pure desktop one. But if they are doing mobile as well then they need to use that all-in-one offline solution. > > That's why I still think we should proceed as I proposed: Keep online offering as it is but drop separate macos + android offline installer (have macOS and macOS + mobile targets for macOS offline offering). Decreasing our offline installer offering is essential; needed testing effort at the moment is really huge & it is increasing all the time because of these parallel releases. That's why we need to decrease stuff to be tested to make our live easier. So don't test them. I'm not joking. There should be no reason to test every possible combination; just test each platform through the online installer and that should implicitly test that the offline one works. Our process shouldn't be so flimsy and untrustworthy that we're testing every possible combination. Let the community do it, and if there's a problem, we'll surely know soon enough. > And how to encourage users to use online installers instead of offline ones? One solution could be that we start using online ones at first & bring offline ones later. Earlier we have released beta with offline only so should we do this differently with Qt 5.9: > > Qt 5.9 alpha: src only > Qt 5.9 beta: online only > Qt 5.9 rc & final: online + offline > > br, > Jani > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From Jake.Petroules at qt.io Tue Nov 29 18:22:15 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 29 Nov 2016 17:22:15 +0000 Subject: [Development] Qt 5.9 In-Reply-To: References: Message-ID: <2006A9C4-123F-4317-AD21-BC3913B6DA15@qt.io> > On Nov 29, 2016, at 2:54 AM, Marco Piccolino wrote: > > We just had a little discussion about this on QtMob (http://slackin.qtmob.org) where everybody does iOS/Android, and most people do it on a macOS host. > It looks like people tend to use the online installer. > When it comes to the offline installers (which in our case are mainly used for checking out betas, it seems) an installer for each platform seems to be the preferred option. > This said, it seems that the main concern for our mobile devs is actually the size of the Qt for iOS distribution per se and people would like to have the option to not install simulator builds. I guarantee you we'll never do that while qmake remains the Qt build system. But in Qt 5.9 when Qt is built as shared libraries for iOS, a lot of the excess size should be moved out into external dSYM (debug symbol) files which can be made an optional component in the online installer. Also, 32-bit iOS is not long for this world, so we may be able to halve the size within the next few years when Apple removes all 32-bit support (even for applications) from iOS. > Br, > Marco Piccolino - QtMob community manager > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From nassian at bitshift-dynamics.de Tue Nov 29 18:39:34 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Tue, 29 Nov 2016 18:39:34 +0100 Subject: [Development] Qt 5.9 In-Reply-To: <2006A9C4-123F-4317-AD21-BC3913B6DA15@qt.io> References: <2006A9C4-123F-4317-AD21-BC3913B6DA15@qt.io> Message-ID: <1BEFA2C3-EC23-4831-9186-56970F52EF01@bitshift-dynamics.de> Installing additional versions is broken and, more annoyingly (but I personally only have limited need for that) using the online installer behind a proxy is also broken (can't download meta). Beste Grüße / Best regards, Alexander Nassian > Am 29.11.2016 um 18:22 schrieb Jake Petroules : > > >> On Nov 29, 2016, at 2:54 AM, Marco Piccolino wrote: >> >> We just had a little discussion about this on QtMob (http://slackin.qtmob.org) where everybody does iOS/Android, and most people do it on a macOS host. >> It looks like people tend to use the online installer. >> When it comes to the offline installers (which in our case are mainly used for checking out betas, it seems) an installer for each platform seems to be the preferred option. >> This said, it seems that the main concern for our mobile devs is actually the size of the Qt for iOS distribution per se and people would like to have the option to not install simulator builds. > > I guarantee you we'll never do that while qmake remains the Qt build system. But in Qt 5.9 when Qt is built as shared libraries for iOS, a lot of the excess size should be moved out into external dSYM (debug symbol) files which can be made an optional component in the online installer. > > Also, 32-bit iOS is not long for this world, so we may be able to halve the size within the next few years when Apple removes all 32-bit support (even for applications) from iOS. > >> Br, >> Marco Piccolino - QtMob community manager >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Jake Petroules - jake.petroules at qt.io > The Qt Company - Silicon Valley > Qbs build tool evangelist - qbs.io > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From roland.m.winklmeier at gmail.com Tue Nov 29 18:49:51 2016 From: roland.m.winklmeier at gmail.com (Roland Winklmeier) Date: Tue, 29 Nov 2016 18:49:51 +0100 Subject: [Development] Qt 5.9 In-Reply-To: References: Message-ID: <51AB351C-8AC4-4E6C-9DA3-E54CECA2843D@gmail.com> > On 28 Nov 2016, at 16:40, Alexander Blasche wrote: > > Ok, let's summarize and restate the package list for Qt 5.9 based on the comments provided on this mail thread. The list describes the delta to Qt 5.8 packages: > > * MinGW remains 5.3 using 32 bit Since I'm using MinGW binaries in 32 bit and 64 bit mode (as plugins for flight simulator applications which exist in 32 and 64 bit), I would be very happy to have both as official MinGW installers. Especially since the MinGW debug binaries are huge compared to the MSVC ones. So I tend to use 64 bit ones (up to now self compiled from source) whenever possible. Would it be an option to add the MinGW 64 bit installer and keep the 32 bit one? Roland From cpbezemer at gmail.com Tue Nov 29 19:53:41 2016 From: cpbezemer at gmail.com (Cor-Paul Bezemer) Date: Tue, 29 Nov 2016 13:53:41 -0500 Subject: [Development] two questions about the build system of Qt Message-ID: Hi, I am a researcher in a team that is working on build systems and we are doing a case study on missing dependencies in the Qt 5.3.0 build system. I know that Qt 5.3.0 is an old version but the case study is part of a paper that has been under review for more than a year now. We found two things that we cannot explain.. Could anyone confirm/clarify to me whether these are bugs in the build system or features? 1. In the Makefile in qtbase/tests/auto/other/qaccessibilitylinux, the target cache_adaptor.h has no dependencies on the header files (e.g. Qtcore/QObject) that it uses. Hence, if those header files change, cache_adaptor.h (and therefore cache_adaptor.cpp) are never rebuilt, which will leave .obj/cache_adaptor.o outdated. Or am I overlooking something? 2. The target for .obj/qgrayraster.o in the Makefile in qtbase/src/gui has a dependency on .pch/Qt5Gui.gch/c, but we noticed that during the build, the .pch/Qt5Gui.gch/c++ file is also read. Is there a reason why gcc would read the c++ file during the build? E.g. because c and c++ code is being mixed? We do not observe similar behaviour (i.e., the c file being read by g++) for targets that are compiled from .cpp files. Thank you! Cor-Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From sahumada at texla.cl Tue Nov 29 20:17:23 2016 From: sahumada at texla.cl (Sergio Ahumada) Date: Tue, 29 Nov 2016 20:17:23 +0100 Subject: [Development] Qt 5.9 In-Reply-To: <5178841.U4LaUdPk4B@tjmaciei-mobl1> References: <1730010.M5yXzDyc6Q@tjmaciei-mobl1> <5178841.U4LaUdPk4B@tjmaciei-mobl1> Message-ID: <0acc37d9-99a7-92e7-575f-378966c9e1d8@texla.cl> On 29.11.2016 16:55, Thiago Macieira wrote: > On terça-feira, 29 de novembro de 2016 11:08:15 PST Jani Heikkinen wrote: >> With offline installer they cannot update new stuff by using maintenance >> tool > > Say what? Why not? > I think he meant that you can't add new stuff .. say if you have a iOS-only offline installer, then you can't use that maintenance tool to install the android stuff .. you would need to download the android-only offline installer to install android (which, if it hasn't been fixed, will install a second instance of QtCreator) that's why (AFAIR) the offline installer has everything (desktop+ios+android), if you only want iOS, then you unselect Android and problem solved -- Sergio Ahumada sahumada at texla.cl From thiago.macieira at intel.com Tue Nov 29 21:03:12 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 29 Nov 2016 12:03:12 -0800 Subject: [Development] Qt 5.9 In-Reply-To: <0acc37d9-99a7-92e7-575f-378966c9e1d8@texla.cl> References: <5178841.U4LaUdPk4B@tjmaciei-mobl1> <0acc37d9-99a7-92e7-575f-378966c9e1d8@texla.cl> Message-ID: <2045771.ykAkeBLFFx@tjmaciei-mobl1> On terça-feira, 29 de novembro de 2016 20:17:23 PST Sergio Ahumada wrote: > > Say what? Why not? > > I think he meant that you can't add new stuff .. say if you have a > iOS-only offline installer, then you can't use that maintenance tool to > install the android stuff .. you would need to download the android-only > offline installer to install android (which, if it hasn't been fixed, > will install a second instance of QtCreator) I got it that you can't do it today. The question is why we haven't fixed that. Sounds like a reasonable feature: you download the offline once and you only use the maintenance tool to update. And if you can't even share the same Qt Creator installation, then it's an important bug. > that's why (AFAIR) the offline installer has everything > (desktop+ios+android), if you only want iOS, then you unselect Android > and problem solved Right, but that's upside down. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Nov 29 21:04:38 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 29 Nov 2016 12:04:38 -0800 Subject: [Development] Qt 5.9 In-Reply-To: <51AB351C-8AC4-4E6C-9DA3-E54CECA2843D@gmail.com> References: <51AB351C-8AC4-4E6C-9DA3-E54CECA2843D@gmail.com> Message-ID: <2359315.7OoQPyVVht@tjmaciei-mobl1> On terça-feira, 29 de novembro de 2016 18:49:51 PST Roland Winklmeier wrote: > > On 28 Nov 2016, at 16:40, Alexander Blasche > > wrote: > > > > Ok, let's summarize and restate the package list for Qt 5.9 based on the > > comments provided on this mail thread. The list describes the delta to Qt > > 5.8 packages: > > > > * MinGW remains 5.3 using 32 bit > > Since I'm using MinGW binaries in 32 bit and 64 bit mode (as plugins for > flight simulator applications which exist in 32 and 64 bit), I would be > very happy to have both as official MinGW installers. Especially since the > MinGW debug binaries are huge compared to the MSVC ones. So I tend to use > 64 bit ones (up to now self compiled from source) whenever possible. Would > it be an option to add the MinGW 64 bit installer and keep the 32 bit one? Agreed with Roland. I thought one of the major conclusions from this thread is that we would provide 64-bit MinGW with Qt 5.9. I don't see that in Alex's conclusion email. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Nov 29 21:14:55 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 29 Nov 2016 12:14:55 -0800 Subject: [Development] two questions about the build system of Qt In-Reply-To: References: Message-ID: <2873037.lCvWRlJxxu@tjmaciei-mobl1> On terça-feira, 29 de novembro de 2016 13:53:41 PST Cor-Paul Bezemer wrote: > 1. In the Makefile in qtbase/tests/auto/other/qaccessibilitylinux, the > target cache_adaptor.h has no dependencies on the header files (e.g. > Qtcore/QObject) that it uses. Hence, if those header files change, > cache_adaptor.h (and therefore cache_adaptor.cpp) are never rebuilt, which > will leave .obj/cache_adaptor.o outdated. Or am I overlooking something? That file is generated during the build. It's created by qdbusxml2cpp by parsing src/3rdparty/atspi2/xml/Cache.xml. Since it's generated, it doesn't exist yet when qmake scans the source files for the dependencies. And we don't update that when compiling or when updating the Makefile. > 2. The target for .obj/qgrayraster.o in the Makefile in qtbase/src/gui has > a dependency on .pch/Qt5Gui.gch/c, but we noticed that during the build, > the .pch/Qt5Gui.gch/c++ file is also read. Is there a reason why gcc would > read the c++ file during the build? E.g. because c and c++ code is being > mixed? We do not observe similar behaviour (i.e., the c file being read by > g++) for targets that are compiled from .cpp files. I can confirm it with strace. Seems like a bug because there is no C++ code mixed in for that particular compilation. You should check with GCC folks. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Nov 29 21:37:56 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 29 Nov 2016 12:37:56 -0800 Subject: [Development] two questions about the build system of Qt In-Reply-To: <2873037.lCvWRlJxxu@tjmaciei-mobl1> References: <2873037.lCvWRlJxxu@tjmaciei-mobl1> Message-ID: <4324171.8AMOGE067J@tjmaciei-mobl1> On terça-feira, 29 de novembro de 2016 12:14:55 PST Thiago Macieira wrote: > > 2. The target for .obj/qgrayraster.o in the Makefile in qtbase/src/gui has > > a dependency on .pch/Qt5Gui.gch/c, but we noticed that during the build, > > the .pch/Qt5Gui.gch/c++ file is also read. Is there a reason why gcc would > > read the c++ file during the build? E.g. because c and c++ code is being > > mixed? We do not observe similar behaviour (i.e., the c file being read by > > g++) for targets that are compiled from .cpp files. > > I can confirm it with strace. Seems like a bug because there is no C++ code > mixed in for that particular compilation. You should check with GCC folks. Looks like it's normal behaviour. Strace shows: open("./.pch/Qt5Gui.t.gch", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 open("./.pch/Qt5Gui.t.gch/c++", O_RDONLY|O_NOCTTY) = 4 open("./.pch/Qt5Gui.t.gch/c", O_RDONLY|O_NOCTTY) = 4 So it's actually reading from the directory and opening all files it finds there until it finds one that is a valid GCC preprocessor output for the current language. Since the buildsystem creates the C++ preprocessed header first (more files depend on it), it's first in the directory listing. This is confirmed by running gcc with -H option. It prints: x ./.pch/Qt5Gui.t.gch/c++ ! ./.pch/Qt5Gui.t.gch/c Its documentation says: '-H' Print the name of each header file used, in addition to other normal activities. Each name is indented to show how deep in the '#include' stack it is. Precompiled header files are also printed, even if they are found to be invalid; an invalid precompiled header file is printed with '...x' and a valid one with '...!' . -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From cpbezemer at gmail.com Tue Nov 29 21:41:04 2016 From: cpbezemer at gmail.com (Cor-Paul Bezemer) Date: Tue, 29 Nov 2016 15:41:04 -0500 Subject: [Development] two questions about the build system of Qt In-Reply-To: <4324171.8AMOGE067J@tjmaciei-mobl1> References: <2873037.lCvWRlJxxu@tjmaciei-mobl1> <4324171.8AMOGE067J@tjmaciei-mobl1> Message-ID: Thanks Thiago! On Tue, Nov 29, 2016 at 3:37 PM, Thiago Macieira wrote: > On terça-feira, 29 de novembro de 2016 12:14:55 PST Thiago Macieira wrote: > > > 2. The target for .obj/qgrayraster.o in the Makefile in qtbase/src/gui > has > > > a dependency on .pch/Qt5Gui.gch/c, but we noticed that during the > build, > > > the .pch/Qt5Gui.gch/c++ file is also read. Is there a reason why gcc > would > > > read the c++ file during the build? E.g. because c and c++ code is > being > > > mixed? We do not observe similar behaviour (i.e., the c file being > read by > > > g++) for targets that are compiled from .cpp files. > > > > I can confirm it with strace. Seems like a bug because there is no C++ > code > > mixed in for that particular compilation. You should check with GCC > folks. > > Looks like it's normal behaviour. Strace shows: > > open("./.pch/Qt5Gui.t.gch", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 > open("./.pch/Qt5Gui.t.gch/c++", O_RDONLY|O_NOCTTY) = 4 > open("./.pch/Qt5Gui.t.gch/c", O_RDONLY|O_NOCTTY) = 4 > > So it's actually reading from the directory and opening all files it finds > there > until it finds one that is a valid GCC preprocessor output for the current > language. Since the buildsystem creates the C++ preprocessed header first > (more > files depend on it), it's first in the directory listing. > > This is confirmed by running gcc with -H option. It prints: > > x ./.pch/Qt5Gui.t.gch/c++ > ! ./.pch/Qt5Gui.t.gch/c > > Its documentation says: > > '-H' > Print the name of each header file used, in addition to other > normal activities. Each name is indented to show how deep in the > '#include' stack it is. Precompiled header files are also printed, > even if they are found to be invalid; an invalid precompiled header > file is printed with '...x' and a valid one with '...!' . > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From szehowe.koh at gmail.com Tue Nov 29 23:25:49 2016 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Wed, 30 Nov 2016 06:25:49 +0800 Subject: [Development] Qt 5.9 In-Reply-To: <2045771.ykAkeBLFFx@tjmaciei-mobl1> References: <5178841.U4LaUdPk4B@tjmaciei-mobl1> <0acc37d9-99a7-92e7-575f-378966c9e1d8@texla.cl> <2045771.ykAkeBLFFx@tjmaciei-mobl1> Message-ID: On 30 Nov. 2016 04:04, "Thiago Macieira" wrote: > > On terça-feira, 29 de novembro de 2016 20:17:23 PST Sergio Ahumada wrote: > > > Say what? Why not? > > > > I think he meant that you can't add new stuff .. say if you have a > > iOS-only offline installer, then you can't use that maintenance tool to > > install the android stuff .. you would need to download the android-only > > offline installer to install android (which, if it hasn't been fixed, > > will install a second instance of QtCreator) > > I got it that you can't do it today. > > The question is why we haven't fixed that. Sounds like a reasonable feature: > you download the offline once and you only use the maintenance tool to update. There's a related discussion at https://bugreports.qt.io/browse/QTBUG-32122 > And if you can't even share the same Qt Creator installation, then it's an > important bug. Yep, we can't even share the same Qt Creator installation: https://forum.qt.io/topic/36275/how-to-install-multiple-qt-5-2-versions-on-windows-using-offline-installers > > that's why (AFAIR) the offline installer has everything > > (desktop+ios+android), if you only want iOS, then you unselect Android > > and problem solved > > Right, but that's upside down. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center Regards, Sze-Howe -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at qt.io Wed Nov 30 08:15:31 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Wed, 30 Nov 2016 07:15:31 +0000 Subject: [Development] Qt 5.9 In-Reply-To: <2359315.7OoQPyVVht@tjmaciei-mobl1> References: <51AB351C-8AC4-4E6C-9DA3-E54CECA2843D@gmail.com> <2359315.7OoQPyVVht@tjmaciei-mobl1> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Thiago > Macieira > Sent: Tuesday, 29 November 2016 21:05 > To: development at qt-project.org > Subject: Re: [Development] Qt 5.9 > > On terça-feira, 29 de novembro de 2016 18:49:51 PST Roland Winklmeier wrote: > > > On 28 Nov 2016, at 16:40, Alexander Blasche > > > > > > wrote: > > > > > > Ok, let's summarize and restate the package list for Qt 5.9 based on > > > the comments provided on this mail thread. The list describes the > > > delta to Qt > > > 5.8 packages: > > > > > > * MinGW remains 5.3 using 32 bit > > > > Since I'm using MinGW binaries in 32 bit and 64 bit mode (as plugins > > for flight simulator applications which exist in 32 and 64 bit), I > > would be very happy to have both as official MinGW installers. > > Especially since the MinGW debug binaries are huge compared to the > > MSVC ones. So I tend to use > > 64 bit ones (up to now self compiled from source) whenever possible. > > Would it be an option to add the MinGW 64 bit installer and keep the 32 bit > one? > > Agreed with Roland. I thought one of the major conclusions from this thread is > that we would provide 64-bit MinGW with Qt 5.9. I don't see that in Alex's > conclusion email. The big problem is that there are still plenty of 32bit users because they truly use 32bit platforms or 3rdparty software forces them to do so. Moving to 64 bit excludes users without alternatives. 32 bit does not exclude. Yes, I know this is a chicken and egg problem but right now we have reduced the 32bit package count for 5.9 already. Let's not rush too much. > > 64 bit ones (up to now self compiled from source) whenever possible. Mind you, Roland himself stated the continued need for 32 bit. > > Would it be an option to add the MinGW 64 bit installer and keep the 32 bit > one? There are already 11 windows binary types/packages in the current setup and that's too many. I see some opportunity when 2013 drops out in the future. -- Alex From alexander.blasche at qt.io Wed Nov 30 08:28:09 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Wed, 30 Nov 2016 07:28:09 +0000 Subject: [Development] Qt 5.9 In-Reply-To: References: <1730010.M5yXzDyc6Q@tjmaciei-mobl1> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Jake Petroules > > That's why I still think we should proceed as I proposed: Keep online offering > as it is but drop separate macos + android offline installer (have macOS and > macOS + mobile targets for macOS offline offering). Decreasing our offline > installer offering is essential; needed testing effort at the moment is really huge > & it is increasing all the time because of these parallel releases. That's why we > need to decrease stuff to be tested to make our live easier. > > So don't test them. I'm not joking. There should be no reason to test every > possible combination; just test each platform through the online installer and > that should implicitly test that the offline one works. Sorry but that's not going to fly. > Our process shouldn't be so flimsy and untrustworthy that we're testing every > possible combination. Let the community do it, and if there's a problem, we'll > surely know soon enough. Software is a living and breathing thing. Its nature is such that it evolves changes each time. Not testing is not an option. We could have more confidence if history wouldn't proof us constantly wrong. Jake, even you had your fair share of breaks during release time. Stop breaking other platforms with your iOS changes and we can talk again ;) You can use the online installer if you want only one mobile platform but not the other. Sure there is more MBs to download with offline but the releasing and testing effort is an even greater concern. Dropping 32bit once Apple says so is a much more rewarding and likely opportunity. > One solution could be that we start using online ones at first & bring offline ones > later. Earlier we have released beta with offline only so should we do this > differently with Qt 5.9: > > > > Qt 5.9 alpha: src only > > Qt 5.9 beta: online only I am against this. Online installers are much harder to handle when you have to continuously install competing Qt versions. Testing requires to install 4 different builds of Qt during for example beta time. Both types of builds have their advantage and testing/trialing is not one where the online installer shines. -- Alex From thiago.macieira at intel.com Wed Nov 30 08:28:51 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 29 Nov 2016 23:28:51 -0800 Subject: [Development] Qt 5.9 In-Reply-To: References: <2359315.7OoQPyVVht@tjmaciei-mobl1> Message-ID: <9103298.SF329cE0Bt@tjmaciei-mobl1> On quarta-feira, 30 de novembro de 2016 07:15:31 PST Alexander Blasche wrote: > The big problem is that there are still plenty of 32bit users because they > truly use 32bit platforms or 3rdparty software forces them to do so. Moving > to 64 bit excludes users without alternatives. 32 bit does not exclude. > Yes, I know this is a chicken and egg problem but right now we have reduced > the 32bit package count for 5.9 already. Let's not rush too much. Then let's not drop the 32-bit mingw. But we should add the 64-bit one, and if possible to 5.8 too. > There are already 11 windows binary types/packages in the current setup and > that's too many. I see some opportunity when 2013 drops out in the future. How are there 11? There are currently 3 compilers and 2 architectures for desktop Windows, so the maximum number possible is 6. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Jake.Petroules at qt.io Wed Nov 30 08:35:25 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 30 Nov 2016 07:35:25 +0000 Subject: [Development] Qt 5.9 In-Reply-To: <9103298.SF329cE0Bt@tjmaciei-mobl1> References: <2359315.7OoQPyVVht@tjmaciei-mobl1> <9103298.SF329cE0Bt@tjmaciei-mobl1> Message-ID: > On Nov 29, 2016, at 11:28 PM, Thiago Macieira wrote: > > On quarta-feira, 30 de novembro de 2016 07:15:31 PST Alexander Blasche wrote: >> The big problem is that there are still plenty of 32bit users because they >> truly use 32bit platforms or 3rdparty software forces them to do so. Moving >> to 64 bit excludes users without alternatives. 32 bit does not exclude. >> Yes, I know this is a chicken and egg problem but right now we have reduced >> the 32bit package count for 5.9 already. Let's not rush too much. > > Then let's not drop the 32-bit mingw. But we should add the 64-bit one, and if > possible to 5.8 too. > >> There are already 11 windows binary types/packages in the current setup and >> that's too many. I see some opportunity when 2013 drops out in the future. > > How are there 11? There are currently 3 compilers and 2 architectures for > desktop Windows, so the maximum number possible is 6. I think you're forgetting WinRT? Also 2015 x86+x86_64+armv7 + 2013 x86 + armv7(phone), making 11. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From Jake.Petroules at qt.io Wed Nov 30 08:53:40 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 30 Nov 2016 07:53:40 +0000 Subject: [Development] Qt 5.9 In-Reply-To: References: <1730010.M5yXzDyc6Q@tjmaciei-mobl1> Message-ID: <76A7D197-150E-485A-AC7F-69BAE5DDD479@qt.io> > On Nov 29, 2016, at 11:28 PM, Alexander Blasche wrote: > >> -----Original Message----- >> From: Development [mailto:development- >> bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Jake Petroules > >>> That's why I still think we should proceed as I proposed: Keep online offering >> as it is but drop separate macos + android offline installer (have macOS and >> macOS + mobile targets for macOS offline offering). Decreasing our offline >> installer offering is essential; needed testing effort at the moment is really huge >> & it is increasing all the time because of these parallel releases. That's why we >> need to decrease stuff to be tested to make our live easier. >> >> So don't test them. I'm not joking. There should be no reason to test every >> possible combination; just test each platform through the online installer and >> that should implicitly test that the offline one works. > > Sorry but that's not going to fly. > >> Our process shouldn't be so flimsy and untrustworthy that we're testing every >> possible combination. Let the community do it, and if there's a problem, we'll >> surely know soon enough. > > Software is a living and breathing thing. Its nature is such that it evolves changes each time. Not testing is not an option. We could have more confidence if history wouldn't proof us constantly wrong. Jake, even you had your fair share of breaks during release time. Stop breaking other platforms with your iOS changes and we can talk again ;) > > You can use the online installer if you want only one mobile platform but not the other. Sure there is more MBs to download with offline but the releasing and testing effort is an even greater concern. > > Dropping 32bit once Apple says so is a much more rewarding and likely opportunity. How about we have one package per host platform which includes all possible hosts and targets compatible with it? Then we have 3 packages, ever. If our releasing and testing effort is the #1 concern over anything else, then having multi-gigabyte packages should not be a problem. We can then have: Windows host: includes Windows (i386-2015,x86_64-2015,i386-2015-winrt,x86_64-2015-winrt,armv7-2015-winrt) + Android (armv7,x86) macOS host: includes macOS (x86_64) + iOS (armv7,arm64,i386,x86_64) + Android (armv7,x86) Linux host: includes Linux (x86_64) + Android (armv7,x86) + QNX (armv7,x86)? By this estimation the Windows one would be around 3.5 GB (maybe less), about the same as the combined macOS+iOS+Android installer. In fact, because the WinRT and desktop binaries should be identical or very similar in many cases, they might compress even better than that (and/or we can look into the possibility of creating a unified Windows build whose DLLs work in either a classic desktop OR WinRT environment, and switch on the platform plugin. not sure to what degree that's possible) We could add the two 2013 builds (2013 WinRT is dead, so 2, not 4 or 5) and the MinGW to the Windows installer, ballooning it to around 6 GB or so (again, this may be totally fine), or we could separate those into 1 or 2 extra installers. Then we have between 3 and 5 rather than 13 like the 5.8 beta has currently. I don't know how useful the offline installers really are, so having the few users suffer a bit over longer download times should be OK given the nice tradeoff in testing. 90% of users should be on the online installer anyways. So, any good reasons we shouldn't do this? > >> One solution could be that we start using online ones at first & bring offline ones >> later. Earlier we have released beta with offline only so should we do this >> differently with Qt 5.9: >>> >>> Qt 5.9 alpha: src only >>> Qt 5.9 beta: online only > > I am against this. Online installers are much harder to handle when you have to continuously install competing Qt versions. Testing requires to install 4 different builds of Qt during for example beta time. Both types of builds have their advantage and testing/trialing is not one where the online installer shines. > > -- > Alex -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From Kai.Koehne at qt.io Wed Nov 30 09:05:32 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Wed, 30 Nov 2016 08:05:32 +0000 Subject: [Development] Qt 5.9 In-Reply-To: <9103298.SF329cE0Bt@tjmaciei-mobl1> References: <2359315.7OoQPyVVht@tjmaciei-mobl1> , <9103298.SF329cE0Bt@tjmaciei-mobl1> Message-ID: > Then let's not drop the 32-bit mingw. But we should add the 64-bit one, and if > possible to 5.8 too. The deal is that we don't want to increase the number of packages in total. Personally, I don't see the qualms with switching to 64 bit for MinGW instantly. For MinGW, there are hardly any binary-only libraries that you can't recompile, and the use case where you ship a 32 bit MinGW plugin for an executable that is compiled with MSVC sounds a border case to me. Also, I doubt that MinGW is popular on the embedded devices that still might be 32 bit only. Finally, the MinGW community is very active in shipping latest Qt in their installers, so if you really need 32 bit you could still use binary packages from the MSYS2 repositories. Anyhow, the argument also goes the other way round: If we don't like to drop 32 bit, we can advise people to use MSYS2 packages. I don't have strong opinions about which one to prefer, but I do think that not adding more packages is a good restriction. My two cents Kai ________________________________ From: Development on behalf of Thiago Macieira Sent: Wednesday, November 30, 2016 8:28:51 AM To: development at qt-project.org Subject: Re: [Development] Qt 5.9 On quarta-feira, 30 de novembro de 2016 07:15:31 PST Alexander Blasche wrote: > The big problem is that there are still plenty of 32bit users because they > truly use 32bit platforms or 3rdparty software forces them to do so. Moving > to 64 bit excludes users without alternatives. 32 bit does not exclude. > Yes, I know this is a chicken and egg problem but right now we have reduced > the 32bit package count for 5.9 already. Let's not rush too much. Then let's not drop the 32-bit mingw. But we should add the 64-bit one, and if possible to 5.8 too. > There are already 11 windows binary types/packages in the current setup and > that's too many. I see some opportunity when 2013 drops out in the future. How are there 11? There are currently 3 compilers and 2 architectures for desktop Windows, so the maximum number possible is 6. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development Development Info Page - Qt lists.qt-project.org To see the collection of prior postings to the list, visit the Development Archives. Using Development: To post a message to all the list members ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From announce at qt-project.org Wed Nov 30 15:11:57 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Wed, 30 Nov 2016 14:11:57 +0000 Subject: [Development] [Announce] Qt Creator 4.2 RC1 released Message-ID: We are happy to announce the release of Qt Creator 4.2 RC1: https://blog.qt.io/blog/2016/11/30/qt-creator-4-2-rc1-released/ Br, -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From thiago.macieira at intel.com Wed Nov 30 16:02:17 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 30 Nov 2016 07:02:17 -0800 Subject: [Development] Qt 5.9 In-Reply-To: References: <9103298.SF329cE0Bt@tjmaciei-mobl1> Message-ID: <1553159.JRX9lEQCOJ@tjmaciei-mobl1> On quarta-feira, 30 de novembro de 2016 07:35:25 PST Jake Petroules wrote: > I think you're forgetting WinRT? Also 2015 x86+x86_64+armv7 + 2013 x86 + > armv7(phone), making 11. Right, I was. Can anyone find out from the traffic stats if people actually download those things? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Nov 30 16:05:35 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 30 Nov 2016 07:05:35 -0800 Subject: [Development] Qt 5.9 In-Reply-To: <76A7D197-150E-485A-AC7F-69BAE5DDD479@qt.io> References: <76A7D197-150E-485A-AC7F-69BAE5DDD479@qt.io> Message-ID: <5895604.KNhrVNCRLl@tjmaciei-mobl1> On quarta-feira, 30 de novembro de 2016 07:53:40 PST Jake Petroules wrote: > How about we have one package per host platform which includes all possible > hosts and targets compatible with it? Then we have 3 packages, ever. Or, at least, one binary per platform + compiler combination. So that's 1 Linux package, 1 macOS package, 3 Windows packages today, with a 4th Windows (MSVC 2017) coming for 5.9. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kossebau at kde.org Wed Nov 30 17:14:39 2016 From: kossebau at kde.org (Friedrich W. H. Kossebau) Date: Wed, 30 Nov 2016 17:14:39 +0100 Subject: [Development] Recommendations for 3rd-party QCH file installation folder for easy discovery? In-Reply-To: <2244793.ZbTD6rx2HE@klux.site> References: <2244793.ZbTD6rx2HE@klux.site> Message-ID: <1771536.9ryNEon5mP@klux.site> Thanks for all the replies so far. Seems this is not a topic where people working on Qt have (already) opinions or ideas about or at least some to share :) Guess this needs to wait until there are more 3rd-party QCH files in the wild obviously, so the issues get more important and there is some base to discuss & plan any possible/needed improvements to Assistant, Creator and the qthelp system. Will try now also the interest mailing list for any experiences/ideas. For the record here my current conclusions: Am Dienstag, 22. November 2016, 18:05:20 CET schrieb Friedrich W. H. Kossebau: > two questions to anyone working on/with QCH files: > > Q1: what would be a good system path pattern (on *nixoid systems) for > Qt-based libraries to install their QCH files to? While it was proposed to use some path below the package-owned resource folders (e.g. /usr/share//doc), this does not help with the use case easy discovery of QCH files and with the use case easy mass addition of dozens of them (like one day hopefully the case with the ones for all the KDE Framework libraries), e.g. by selecting them in one go in the file dialog (on the command line "assistant -register" even only takes one file it seems, so only experts with bash & find foo have an easy going ;) ). Looking at other documentation format (systems) I see they have a specific folder, where installing some package specific documentation also automatically works as registration: /usr/share/info/ /usr/share/man/ And seeing that KDE uses /usr/share/doc/HTML for documentation in html/ docbook(?) format I am for now proposing /usr/share/doc/QCH as folder where packages would drop the QCH/qthelp system specific files, namespacing them by proper basenames ".qch" similar to what is needed with ".so". This helps at least with the use-case of looking at the file system to find what QCH files are available, by being a central place to look at and also the use-case to pick multiple files in one go in Assistant's file dialog. > Q2: And would/could there be some way to have 3rd-party QCH files > automatically added to Qt Assistant, Creator & Co. on installation, to spare > the user the additional manual step? Given the concept of user specific collection files in Qt Assistant (no idea about Qt Creator here), automatically adding QCH help files on system install (assuming linux distribution here) to any collection files would not be nice anyway. Still it might be nice to at least add them automatically to the default help file collection IMHO, this might serve the average of people who usually only work on one project where they only install the QCH files to the system the need anyway and also only use the default help file collection. As it seems that Qt Assistant automatically adds (after restart) new QCH files it discovers in the QT_INSTALL_DOCS folder to the default help file collection, simply installing any 3rd-party QCH files into that folder would serve the use-case of automatic addition to Qt Assistant after install. And thus this is what I propose now as well to do. After all installing into the Qt system dirs is also done already for 3rd-party plugins, mkspec files or QML imports. See the above conclusions (and any follow-up ones) being implemented in the new CMake macros proposed to become part of the Extra-CMake-Modules here: https://phabricator.kde.org/D2854 (custom version even already committed to development versions of KDE's KProperty & KReport libs, with more to come). Cheers Friedrich