From tony.sarajarvi at qt.io Thu Jun 1 11:07:05 2017 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Thu, 1 Jun 2017 09:07:05 +0000 Subject: [Development] Hardware failure again, several systems affected Message-ID: Hi We have problems with our hardware again. Investigations are ongoing. At least the CI is down for the moment, and other systems should be affected to some degree as well. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tero.kojo at qt.io Thu Jun 1 14:44:04 2017 From: tero.kojo at qt.io (Tero Kojo) Date: Thu, 1 Jun 2017 12:44:04 +0000 Subject: [Development] Qt World Summit call for presentation extension till Sunday June 4. Message-ID: Hello, We have received an excellent number of talk proposals, thank you to everyone who submitted a topic! Due to the last minute submission rush, we are extending the deadline to this Sunday, 4th June. That is the final deadline when the submission will close. After that you can expect the evaluation panel to take a couple of weeks to go through everything and get back to you with the decisions. Best, Tero -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Fri Jun 2 08:29:17 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 2 Jun 2017 06:29:17 +0000 Subject: [Development] Qt 5.10 Feature Freeze is coming Message-ID: Hi all! Just a kindly reminder: Qt 5.10 Feature Freeze date is 8.8.2017 so there isn't really more than 2 months time left to get new features in (see https://wiki.qt.io/Qt_5.10_Release ). We kept final schedule with Qt 5.9.0 and we need to continue that with Qt 5.10. So if you already now see that some feature won't be ready early enough please postpone it to 5.11 instead. Please make sure all new features are visible in new feature page (https://wiki.qt.io/New_Features_in_Qt_5.10) as soon as possible. Please also make sure new features are fulfilling ff criteria (https://wiki.qt.io/Qt_5_Feature_Freeze). And make sure all new modules are in qt5.git early enough, at this time latest at the end of June (also possible new Technology Preview ones): FF is immediately after summer holiday period and we need to create configurations etc for those as well before FF. That's why we need to get new modules in qt5.git as early as possible. At the moment I don't know any new module for Qt 5.10. If there will be some please inform me immediately with details(we can start preparations for those already now): - Module name & repository - Officially supported/TP - Description for installer - Supported platforms - etc And also inform me if some already existing module change it's state (e.g TP->officially supported, deprecated etc) br, Jani Heikkinen Release Manager From tuukka.turunen at qt.io Fri Jun 2 09:04:02 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Fri, 2 Jun 2017 07:04:02 +0000 Subject: [Development] Qt 5.10 Feature Freeze is coming In-Reply-To: References: Message-ID: Hi, If you are still developing in a feature branch, please merge to dev as soon as possible. Unless you are already aiming to Qt 5.11, that is. We should avoid "last minute" merges as these are likely to cause problems. Yours, Tuukka ________________________________ From: Development on behalf of Jani Heikkinen Sent: Friday, June 2, 2017 9:29:17 AM To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Development] Qt 5.10 Feature Freeze is coming Hi all! Just a kindly reminder: Qt 5.10 Feature Freeze date is 8.8.2017 so there isn't really more than 2 months time left to get new features in (see https://wiki.qt.io/Qt_5.10_Release ). We kept final schedule with Qt 5.9.0 and we need to continue that with Qt 5.10. So if you already now see that some feature won't be ready early enough please postpone it to 5.11 instead. Please make sure all new features are visible in new feature page (https://wiki.qt.io/New_Features_in_Qt_5.10) as soon as possible. Please also make sure new features are fulfilling ff criteria (https://wiki.qt.io/Qt_5_Feature_Freeze). And make sure all new modules are in qt5.git early enough, at this time latest at the end of June (also possible new Technology Preview ones): FF is immediately after summer holiday period and we need to create configurations etc for those as well before FF. That's why we need to get new modules in qt5.git as early as possible. At the moment I don't know any new module for Qt 5.10. If there will be some please inform me immediately with details(we can start preparations for those already now): - Module name & repository - Officially supported/TP - Description for installer - Supported platforms - etc And also inform me if some already existing module change it's state (e.g TP->officially supported, deprecated etc) br, Jani Heikkinen Release Manager _______________________________________________ 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 jhihn at gmx.com Fri Jun 2 18:54:43 2017 From: jhihn at gmx.com (Jason H) Date: Fri, 2 Jun 2017 18:54:43 +0200 Subject: [Development] QNumericVector? Message-ID: I'm just wondering out loud if it would be a good thing to have a numeric vector type that supports math operations (and optionally will SIMD accelerate them). Qt supports some fixed dimensionality vectors (QVecorXD, x={2,3,4}). But this would add flexibility for say, machine learning applications. The only collision that I know of is length() where the existing fixed-dimension classes provide magnitude as length(). Additionally it may be useful to support non-Euclidean spaces, though I wouldn't see much use beyond polar (haversine) distances and bearings. Thoughts? From annulen at yandex.ru Fri Jun 2 18:58:18 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 02 Jun 2017 19:58:18 +0300 Subject: [Development] QNumericVector? In-Reply-To: References: Message-ID: <3859551496422698@web39j.yandex.ru> 02.06.2017, 19:55, "Jason H" : > I'm just wondering out loud if it would be a good thing to have a numeric vector type that supports math operations (and optionally will SIMD accelerate them). Qt supports some fixed dimensionality vectors (QVecorXD, x={2,3,4}). But this would add flexibility for say, machine learning applications. The only collision that I know of is length() where the existing fixed-dimension classes provide magnitude as length(). Additionally it may be useful to support non-Euclidean spaces, though I wouldn't see much use beyond polar (haversine) distances and bearings. > > Thoughts? Use Eigen? > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Fri Jun 2 21:29:17 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 02 Jun 2017 12:29:17 -0700 Subject: [Development] QNumericVector? In-Reply-To: <3859551496422698@web39j.yandex.ru> References: <3859551496422698@web39j.yandex.ru> Message-ID: <2276051.RcZut0AfNO@tjmaciei-mobl1> On Friday, 2 June 2017 09:58:18 PDT Konstantin Tokarev wrote: > 02.06.2017, 19:55, "Jason H" : > > I'm just wondering out loud if it would be a good thing to have a numeric > > vector type that supports math operations (and optionally will SIMD > > accelerate them). Qt supports some fixed dimensionality vectors > > (QVecorXD, x={2,3,4}). But this would add flexibility for say, machine > > learning applications. The only collision that I know of is length() > > where the existing fixed-dimension classes provide magnitude as length(). > > Additionally it may be useful to support non-Euclidean spaces, though I > > wouldn't see much use beyond polar (haversine) distances and bearings. > > > > Thoughts? > > Use Eigen? There's a couple of classes in Qt3D that do 3D and 4D vectors with SSE2 and AVX2 acceleration, but I would really like you to use Eigen instead. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ewleaver at comcast.net Sat Jun 3 02:33:53 2017 From: ewleaver at comcast.net (Ed Leaver) Date: Fri, 2 Jun 2017 20:33:53 -0400 Subject: [Development] QNumericVector? In-Reply-To: <2276051.RcZut0AfNO@tjmaciei-mobl1> References: <3859551496422698@web39j.yandex.ru> <2276051.RcZut0AfNO@tjmaciei-mobl1> Message-ID: <5f20b16f-cff1-a01f-b727-0f639d2fb032@comcast.net> Agree. I've used Eigen a fair bit. At least as much as I have Qt. Eigen is one polished wheel I certainly wouldn't want to re-invent. On 06/02/2017 03:29 PM, Thiago Macieira wrote: > On Friday, 2 June 2017 09:58:18 PDT Konstantin Tokarev wrote: >> 02.06.2017, 19:55, "Jason H" : >>> I'm just wondering out loud if it would be a good thing to have a numeric >>> vector type that supports math operations (and optionally will SIMD >>> accelerate them). Qt supports some fixed dimensionality vectors >>> (QVecorXD, x={2,3,4}). But this would add flexibility for say, machine >>> learning applications. The only collision that I know of is length() >>> where the existing fixed-dimension classes provide magnitude as length(). >>> Additionally it may be useful to support non-Euclidean spaces, though I >>> wouldn't see much use beyond polar (haversine) distances and bearings. >>> >>> Thoughts? >> Use Eigen? > There's a couple of classes in Qt3D that do 3D and 4D vectors with SSE2 and > AVX2 acceleration, but I would really like you to use Eigen instead. > From rjvbertin at gmail.com Sat Jun 3 10:11:01 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Sat, 03 Jun 2017 10:11:01 +0200 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) Message-ID: <5875213.LdfPq16Ncl@bola> Hi, I use the "English (Macintosh)" keyboard variant with the standard "English (US)" layout. Like on Mac, this gives me accented characters via deadkeys that associate the most common occurrences: AltGr+e is the deadkey for e-acute, AltGr+i the deadkey for i-circonflex etc. At random intervals I lose the deadkey aspect in the sense that in Qt4 applications, AltGr+e will insert the acute on itself (idem for the other combinations) and Qt5 applications the deadkey does nothing at all. IOW, in Qt4 apps I get the accent followed by the to-be-accented letter (´e) while in Qt5 I just get the letter without the accent. Most of the time I can get out of this by toggling the keyboard layout (to French in my case) and back using the Plasma4 keyboard widget, but every now and then the only thing that seems to work is logging off and back in. This appears to be a Qt issue because it never affects GTk applications. It also only started happening after I upgraded my hardware (cloned the install to a new machine). I've already asked around on KDE MLs but nobody there seems to have an idea. While my main concern is to find a fix that doesn't oblige me to log off I guess it could be useful to figure out exactly what is going on. Thanks, R. From thiago.macieira at intel.com Sat Jun 3 19:23:00 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 03 Jun 2017 10:23:00 -0700 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) In-Reply-To: <5875213.LdfPq16Ncl@bola> References: <5875213.LdfPq16Ncl@bola> Message-ID: <7357771.xnueTRxam7@tjmaciei-mobl1> On Saturday, 3 June 2017 01:11:01 PDT René J.V. Bertin wrote: > I use the "English (Macintosh)" keyboard variant with the standard "English > (US)" layout. Like on Mac, this gives me accented characters via deadkeys > that associate the most common occurrences: AltGr+e is the deadkey for > e-acute, AltGr+i the deadkey for i-circonflex etc. > > At random intervals I lose the deadkey aspect in the sense that in Qt4 > applications, AltGr+e will insert the acute on itself (idem for the other > combinations) and Qt5 applications the deadkey does nothing at all. IOW, in > Qt4 apps I get the accent followed by the to-be-accented letter (´e) while > in Qt5 I just get the letter without the accent. Just to provide a different viewpoint: I've only ever used "English (Alt International)" for the last, oh, 20 years, and I haven't had deadkey problems in the last 3. There was some problem in some early versions of Qt 5 because of the XCB rewrite, along with problems with the compose map, but they haven't shown up in years. I have never had problems with Qt 4. What you're describing isn't exactly a Qt problem, but must be caused by some other application. The deadkeys lose their state if certain (keyboard) events get sent to the application between the deadkey and the modified key. If some other application is playing tricks with your keyboard, it will affect the deadkeys. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jhihn at gmx.com Sun Jun 4 23:00:16 2017 From: jhihn at gmx.com (Jason H) Date: Sun, 4 Jun 2017 23:00:16 +0200 Subject: [Development] Future of Qt on Web? Message-ID: While Qt is not a web framework, over time there have been efforts to use it on the web (outlined below). Given that Chrome is dropping NaCL (http://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly,34583.html) and the WebGL streaming is also not ideal (but better?), I am wondering about the future of Qt on Web? Will there be a WebAssembly version of Qt? As for the various approaches over time, Wt, (2005): I believe that Wt has it pretty close to right*, where the architecture leverages balanced mix of server and client code QMLWeb (2014): Re-implmenentation of QML in browser, including QML parser. Qt 5.10 WebGL (2017?): server issue low-level draw commands It strikes me that the proper* balance would be server-side implementation is light-weight and leans on the client for rendering. In a way, I consider all web frameworks as failed as there is a new one every 3 months. I think the problem comes from treating the web as a platform and not merely a delivery platform. It can't be a platform because it requires a server in a completely different architecture than the client. The client is continually being changed, which means your application code has to be changed to take advantage of those features. This is what Wt gets right: it is a library and you can target new browser features (i.e. websockets) with just relinking to a new library version. There is no application-specific code that has to change. This turns the web into a delivery platform, as how I think it should be treated (aka "proper", imho) The "proper" balance would then be a server-side widget/QML element hierarchy which is synchronized with the browser. The browser uses it's own logic intelligently update. It would seem to me that the next step is to take the WebGL stuff and iterate it to the point that it's not the GL commands being sent, but higher level logic that relies on the browser to issue those commands to itself. Of course a QWidget::paint() call gets complicated, but maybe the compilation output could be a WebAssembly function that is sent to the client. In this approach there's isn't a complete version of Qt for WebAssembly, just the application-specific code that the browser needs to know about. Thoughts? From lorn.potter at gmail.com Mon Jun 5 06:34:48 2017 From: lorn.potter at gmail.com (Lorn Potter) Date: Mon, 5 Jun 2017 14:34:48 +1000 Subject: [Development] Future of Qt on Web? In-Reply-To: References: Message-ID: On 06/05/2017 07:00 AM, Jason H wrote: > While Qt is not a web framework, over time there have been efforts to use it on the web (outlined below). > > Given that Chrome is dropping NaCL (http://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly,34583.html) and the WebGL streaming is also not ideal (but better?), I am wondering about the future of Qt on Web? Will there be a WebAssembly version of Qt? We have been working on Qt5 for webassembly. I was just writing a short blog about this: http://qtandeverything.blogspot.com.au/2017/06/qt-for-web-assembly.html From sam.sgrs at gmail.com Mon Jun 5 12:40:07 2017 From: sam.sgrs at gmail.com (Sam Segers) Date: Mon, 05 Jun 2017 10:40:07 +0000 Subject: [Development] Future of Qt on Web? In-Reply-To: References: Message-ID: Op ma 5 jun. 2017 06:35 schreef Lorn Potter : > > > On 06/05/2017 07:00 AM, Jason H wrote: > > While Qt is not a web framework, over time there have been efforts to > use it on the web (outlined below). > > > > Given that Chrome is dropping NaCL ( > http://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly,34583.html) > and the WebGL streaming is also not ideal (but better?), I am wondering > about the future of Qt on Web? Will there be a WebAssembly version of Qt? > > We have been working on Qt5 for webassembly. > I was just writing a short blog about this: > > http://qtandeverything.blogspot.com.au/2017/06/qt-for-web-assembly.html Good to see this. I also gave it a go at compiling qt with emscripten: https://github.com/labsin/qtbase So I can stop this. I ran in some bugs in emscripten itself (now fixed) and just got the base compiling so it is still far of. I'll give it a go. > _______________________________________________ > 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 olszak.tomasz at gmail.com Mon Jun 5 16:01:46 2017 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Mon, 5 Jun 2017 16:01:46 +0200 Subject: [Development] Fwd: Releasing QVideoFrame inside QDeclarativeVideoRendererBackend In-Reply-To: References: Message-ID: Hello, Few weeks ago I submitted a patch[1]. I hope the commit description is verbose enough. Without this patch custom video devices (e.g. based on v4l2) are unstable (assuming that they are stopped and started again and again). Who should I add as reviewer to get some feedback? Seems like some kind of edge case, but I would expect the video buffer to be released when QAbstractVideoSurface is stopped. [1] https://codereview.qt-project.org/#/c/193529/2 Cheers, Tomasz -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhihn at gmx.com Mon Jun 5 16:20:04 2017 From: jhihn at gmx.com (Jason H) Date: Mon, 5 Jun 2017 16:20:04 +0200 Subject: [Development] Future of Qt on Web? In-Reply-To: References: Message-ID: > Sent: Monday, June 05, 2017 at 12:34 AM > From: "Lorn Potter" > To: development at qt-project.org > Subject: Re: [Development] Future of Qt on Web? > > > > On 06/05/2017 07:00 AM, Jason H wrote: > > While Qt is not a web framework, over time there have been efforts to use it on the web (outlined below). > > > > Given that Chrome is dropping NaCL (http://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly,34583.html) and the WebGL streaming is also not ideal (but better?), I am wondering about the future of Qt on Web? Will there be a WebAssembly version of Qt? > > We have been working on Qt5 for webassembly. > I was just writing a short blog about this: > > http://qtandeverything.blogspot.com.au/2017/06/qt-for-web-assembly.html That is great news! You mention the wasm is smaller? How much smaller? From annulen at yandex.ru Mon Jun 5 16:22:26 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 05 Jun 2017 17:22:26 +0300 Subject: [Development] Future of Qt on Web? In-Reply-To: References: Message-ID: <1459661496672546@web28j.yandex.ru> 05.06.2017, 17:20, "Jason H" : >>  Sent: Monday, June 05, 2017 at 12:34 AM >>  From: "Lorn Potter" >>  To: development at qt-project.org >>  Subject: Re: [Development] Future of Qt on Web? >> >>  On 06/05/2017 07:00 AM, Jason H wrote: >>  > While Qt is not a web framework, over time there have been efforts to use it on the web (outlined below). >>  > >>  > Given that Chrome is dropping NaCL (http://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly,34583.html) and the WebGL streaming is also not ideal (but better?), I am wondering about the future of Qt on Web? Will there be a WebAssembly version of Qt? >> >>  We have been working on Qt5 for webassembly. >>  I was just writing a short blog about this: >> >>  http://qtandeverything.blogspot.com.au/2017/06/qt-for-web-assembly.html > > That is great news! You mention the wasm is smaller? How much smaller? This article says it's smaller than asm.js, not NaCl > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From lorn.potter at gmail.com Mon Jun 5 21:26:53 2017 From: lorn.potter at gmail.com (Lorn Potter) Date: Tue, 6 Jun 2017 05:26:53 +1000 Subject: [Development] Future of Qt on Web? In-Reply-To: References: Message-ID: On 06/06/2017 12:20 AM, Jason H wrote: > > >> Sent: Monday, June 05, 2017 at 12:34 AM >> From: "Lorn Potter" >> To: development at qt-project.org >> Subject: Re: [Development] Future of Qt on Web? >> >> >> >> On 06/05/2017 07:00 AM, Jason H wrote: >>> While Qt is not a web framework, over time there have been efforts to use it on the web (outlined below). >>> >>> Given that Chrome is dropping NaCL (http://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly,34583.html) and the WebGL streaming is also not ideal (but better?), I am wondering about the future of Qt on Web? Will there be a WebAssembly version of Qt? >> >> We have been working on Qt5 for webassembly. >> I was just writing a short blog about this: >> >> http://qtandeverything.blogspot.com.au/2017/06/qt-for-web-assembly.html > > That is great news! You mention the wasm is smaller? How much smaller? For one small example app (standarddialog) the difference between asmjs and wasm is: wasm: 520 k js file and 14 MB wasm file. asmjs: 69 MB js file. From jhihn at gmx.com Mon Jun 5 21:51:53 2017 From: jhihn at gmx.com (Jason H) Date: Mon, 5 Jun 2017 21:51:53 +0200 Subject: [Development] Future of Qt on Web? In-Reply-To: References: Message-ID: > Sent: Monday, June 05, 2017 at 3:26 PM > From: "Lorn Potter" > To: "Jason H" > Cc: development at qt-project.org > Subject: Re: [Development] Future of Qt on Web? > > > > On 06/06/2017 12:20 AM, Jason H wrote: > > > > > >> Sent: Monday, June 05, 2017 at 12:34 AM > >> From: "Lorn Potter" > >> To: development at qt-project.org > >> Subject: Re: [Development] Future of Qt on Web? > >> > >> > >> > >> On 06/05/2017 07:00 AM, Jason H wrote: > >>> While Qt is not a web framework, over time there have been efforts to use it on the web (outlined below). > >>> > >>> Given that Chrome is dropping NaCL (http://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly,34583.html) and the WebGL streaming is also not ideal (but better?), I am wondering about the future of Qt on Web? Will there be a WebAssembly version of Qt? > >> > >> We have been working on Qt5 for webassembly. > >> I was just writing a short blog about this: > >> > >> http://qtandeverything.blogspot.com.au/2017/06/qt-for-web-assembly.html > > > > That is great news! You mention the wasm is smaller? How much smaller? > > For one small example app (standarddialog) the difference between asmjs > and wasm is: > > wasm: 520 k js file and 14 MB wasm file. > asmjs: 69 MB js file. That's encouraging. It's almost reasonable. Maybe a progressive web app would be the way to go? But I don't think that is using the browser in the best way? You're effectively telling it how to redraw everything, rather than letting it do what it already knows how to do. Is that a fair statement? From alexander.blasche at qt.io Tue Jun 6 13:58:08 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Tue, 6 Jun 2017 11:58:08 +0000 Subject: [Development] Nominating Vikas Pachdha for Approver status In-Reply-To: References: Message-ID: Congratulations to Vikas. The rights have been adjusted. -- Alex ________________________________________ From: Development on behalf of Eike Ziller Sent: Monday, 15 May 2017 10:43:57 AM To: Cc: qt-creator Subject: [Development] Nominating Vikas Pachdha for Approver status Hereby I nominate Vikas Pachdha for Approver status. He has been defacto maintaining iOS support in Qt Creator since a year. https://codereview.qt-project.org/#/q/owner:%22Vikas+Pachdha%22+status:merged,n,z 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, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Wed Jun 7 08:57:10 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 7 Jun 2017 06:57:10 +0000 Subject: [Development] Qt 5.10 pre-built bunaries Message-ID: Hi all, There has been discussion ongoing about 5.10 supported platforms and CI configurations. What we haven't agreed yet is Qt 5.10 pre-built binaries. I don't see big need to change anything from 5.9 but there is still couple of things on my mind: - Should we now switch from MinGW32 bit -> MinGW 64bit ones? With 5.9 this was too early but would it be time to do it now? Offering both isn't an option. And 5,9 is LTS so 5.10 could be good release to change that... - Can we start using RHEL 7.4 for linux packaging? Tony is planning to add RHEL 7.4 in CI and so on it would be wise to replace 7.2 with 7.4 in the packaging as well Is there some other change proposals which we should discuss about? br, Jani From lars.knoll at qt.io Wed Jun 7 09:30:15 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 7 Jun 2017 07:30:15 +0000 Subject: [Development] Qt 5.10 pre-built bunaries In-Reply-To: References: Message-ID: Hi Jani, > On 7 Jun 2017, at 08:57, Jani Heikkinen wrote: > > Hi all, > > There has been discussion ongoing about 5.10 supported platforms and CI configurations. What we haven't agreed yet is Qt 5.10 pre-built binaries. I don't see big need to change anything from 5.9 but there is still couple of things on my mind: > > - Should we now switch from MinGW32 bit -> MinGW 64bit ones? With 5.9 this was too early but would it be time to do it now? Offering both isn't an option. And 5,9 is LTS so 5.10 could be good release to change that... We got a lot of questions about 32bit binaries still in the comments to the release blog. But those were pretty much all about VS2017. I'd personally be happy to move more towards 64 bit, but we should somehow find out how much 32bit is still required by our users. > > - Can we start using RHEL 7.4 for linux packaging? Tony is planning to add RHEL 7.4 in CI and so on it would be wise to replace 7.2 with 7.4 in the packaging as well Sounds good to me, unless anybody knows about any reasons why we should stay on 7.2. > > Is there some other change proposals which we should discuss about? I think we should strongly consider dropping 32bit for iOS. Cheers, Lars From Jake.Petroules at qt.io Wed Jun 7 17:46:55 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 7 Jun 2017 15:46:55 +0000 Subject: [Development] Qt 5.10 pre-built bunaries In-Reply-To: References: Message-ID: <9FB9EF89-CBF4-4F3A-91C1-5C66B31AA52D@qt.io> > On Jun 7, 2017, at 12:30 AM, Lars Knoll wrote: > > Hi Jani, > >> On 7 Jun 2017, at 08:57, Jani Heikkinen wrote: >> >> Hi all, >> >> There has been discussion ongoing about 5.10 supported platforms and CI configurations. What we haven't agreed yet is Qt 5.10 pre-built binaries. I don't see big need to change anything from 5.9 but there is still couple of things on my mind: >> >> - Should we now switch from MinGW32 bit -> MinGW 64bit ones? With 5.9 this was too early but would it be time to do it now? Offering both isn't an option. And 5,9 is LTS so 5.10 could be good release to change that... > > We got a lot of questions about 32bit binaries still in the comments to the release blog. But those were pretty much all about VS2017. I'd personally be happy to move more towards 64 bit, but we should somehow find out how much 32bit is still required by our users. >> >> - Can we start using RHEL 7.4 for linux packaging? Tony is planning to add RHEL 7.4 in CI and so on it would be wise to replace 7.2 with 7.4 in the packaging as well > > Sounds good to me, unless anybody knows about any reasons why we should stay on 7.2. >> >> Is there some other change proposals which we should discuss about? > > I think we should strongly consider dropping 32bit for iOS. I thought we already agreed to do this. :) With Apple announcing that iOS 11 will no longer support 32-bit applications, let alone CPUs, there's very little value in us supporting it. 80-90% of iOS devices will likely be on iOS 11 in the first week or month of its release, and of the percentage that aren't, only a minority will be the 32-bit iPhone 5. We probably even support too many iOS versions as it is. Apple's official recommendation is that your deployment target should be "major version one below current, maximum minor version" - i.e. when iOS 11 is out, your deployment target should be 10.3. > Cheers, > Lars > > _______________________________________________ > 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 Jun 7 22:09:36 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 07 Jun 2017 13:09:36 -0700 Subject: [Development] [Releasing] Qt 5.10 pre-built bunaries In-Reply-To: References: Message-ID: <2568778.hfst4LOck6@tjmaciei-mobl1> On Tuesday, 6 June 2017 23:57:10 PDT Jani Heikkinen wrote: > Hi all, > > There has been discussion ongoing about 5.10 supported platforms and CI > configurations. What we haven't agreed yet is Qt 5.10 pre-built binaries. I > don't see big need to change anything from 5.9 but there is still couple of > things on my mind: > > - Should we now switch from MinGW32 bit -> MinGW 64bit ones? With 5.9 this > was too early but would it be time to do it now? Offering both isn't an > option. And 5,9 is LTS so 5.10 could be good release to change that... > > - Can we start using RHEL 7.4 for linux packaging? Tony is planning to add > RHEL 7.4 in CI and so on it would be wise to replace 7.2 with 7.4 in the > packaging as well > > Is there some other change proposals which we should discuss about? I'd like to propose raising the minimum version for GCC to 4.8.1, which is the first C++11 complete version, or higher. The reason for this is actually to drop GCC 4.7 and earlier, which have a few bugs with their C++11 support. GCC 4.7 has been the minimum since Qt 5.7.0 and is now 5 years old. I've just been bitten by one with QRandomGenerator, relating to calling static member functions from a lambda. The workaround suggested in the Coding Convention is not applicable going forward because Clang 5.0 will produce a warning about it (I've updated the wiki), so we have to choose which one we'll support very shortly, as soon as Apple begins shipping Clang based on the current trunk version in XCode. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Wed Jun 7 22:30:30 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 07 Jun 2017 23:30:30 +0300 Subject: [Development] [Releasing] Qt 5.10 pre-built bunaries In-Reply-To: <2568778.hfst4LOck6@tjmaciei-mobl1> References: <2568778.hfst4LOck6@tjmaciei-mobl1> Message-ID: <4677251496867430@web43g.yandex.ru> 07.06.2017, 23:09, "Thiago Macieira" : > On Tuesday, 6 June 2017 23:57:10 PDT Jani Heikkinen wrote: >>  Hi all, >> >>  There has been discussion ongoing about 5.10 supported platforms and CI >>  configurations. What we haven't agreed yet is Qt 5.10 pre-built binaries. I >>  don't see big need to change anything from 5.9 but there is still couple of >>  things on my mind: >> >>  - Should we now switch from MinGW32 bit -> MinGW 64bit ones? With 5.9 this >>  was too early but would it be time to do it now? Offering both isn't an >>  option. And 5,9 is LTS so 5.10 could be good release to change that... >> >>  - Can we start using RHEL 7.4 for linux packaging? Tony is planning to add >>  RHEL 7.4 in CI and so on it would be wise to replace 7.2 with 7.4 in the >>  packaging as well >> >>  Is there some other change proposals which we should discuss about? > > I'd like to propose raising the minimum version for GCC to 4.8.1, which is the > first C++11 complete version, or higher. The reason for this is actually to > drop GCC 4.7 and earlier, which have a few bugs with their C++11 support. GCC > 4.7 has been the minimum since Qt 5.7.0 and is now 5 years old. FWIW, the first really C++11 complete version of GCC is 4.9, 4.8 still has a number of bugs that result in internal compiler errors, compilation errors, or runtime errors in some non-trivial but valid C++11 code. See for example patches in [1, 2] [1] https://trac.webkit.org/search?q=gcc+4.8&noquickjump=1&changeset=on [2] https://trac.webkit.org/search?q=libstdc%2B%2B+4.8&noquickjump=1&changeset=on > > I've just been bitten by one with QRandomGenerator, relating to calling static > member functions from a lambda. The workaround suggested in the Coding > Convention is not applicable going forward because Clang 5.0 will produce a > warning about it (I've updated the wiki), so we have to choose which one we'll > support very shortly, as soon as Apple begins shipping Clang based on the > current trunk version in XCode. > > -- > 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 thiago.macieira at intel.com Thu Jun 8 00:10:57 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 07 Jun 2017 15:10:57 -0700 Subject: [Development] Dropping older compilers for Qt 5.10 (was: Qt 5.10 pre-built bunaries) In-Reply-To: <4677251496867430@web43g.yandex.ru> References: <2568778.hfst4LOck6@tjmaciei-mobl1> <4677251496867430@web43g.yandex.ru> Message-ID: <4163411.lHBuFDpqgs@tjmaciei-mobl1> On quarta-feira, 7 de junho de 2017 13:30:30 PDT Konstantin Tokarev wrote: > FWIW, the first really C++11 complete version of GCC is 4.9, 4.8 still has a > number of bugs that result in internal compiler errors, compilation errors, > or runtime errors in some non-trivial but valid C++11 code. See for example > patches in [1, 2] 4.9 is a 4-year-old compiler today. I'd love to get rid of the buggy 5.3.x, but that's too recent. Quick survey shows: * GCC 4.9 in Ubuntu 14.04 LTS, Debian Jessie, Fedora 21 [*] * GCC 4.8.5 in the latest OpenSUSE Leap, SUSE Linux Enterprise. and CentOS / RHEL. [*] F21 is not supported by Fedora; minimum support at the time of Qt 5.10's release will be F24 So I'm guessing we should require GCC 4.8.5 (all the latest fixes). This will give us full C++11 support in GCC. Clang claims to be fully C++14 compliant in 3.4, which we already require. Then there's MSVC. So... should we begin thinking of dropping MMSVC 2013? We'll gain by doing that: * default and delete members * alignas & alignof * inheriting constructors * noexcept * range for (without having to check if it really works) * ref qualifiers (no more need for #ifdef) * thread_local (QRandomGenerator benefits from this, also obviates the need to introduce Q_THREAD_LOCAL) * user defined literals * Unicode strings * unrestricted unions Another benefit is that MSVC 2017 and 2015 are supposedly binary compatible with each other. With care, we can even use this feature in Qt. If we require MSVC 2015 with the most recent update (which is over a year old now), in addition we get: * attributes * thread-safe statics (finally! could drop the fallback from Q_GLOBAL_STATIC! oh, wait, Apple...) * uniform initialisation (without having to check if it really works) In other words, there'll be exactly one C++11 feature we won't be able to indiscriminately use: * constexpr (plus whatever fails due to issues in the the Standard Libraries) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marco.a.piccolino at gmail.com Thu Jun 8 07:37:09 2017 From: marco.a.piccolino at gmail.com (Marco Piccolino) Date: Thu, 8 Jun 2017 07:37:09 +0200 Subject: [Development] Qt 5.10 pre-built binaries In-Reply-To: References: Message-ID: Hello, Would you also consider creating a smaller macOS offline installer? Current version with Android and iOS is at 3.5 Gb and has been reported to cause persistent timeouts when downloaded on CI like Travis. Is providing android and iOS as add-on installs an option? Marco Piccolino Il 07 giu 2017 9:30 AM, ha scritto: Send Development mailing list submissions to development at qt-project.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.qt-project.org/mailman/listinfo/development or, via email, send a message with subject or body 'help' to development-request at qt-project.org You can reach the person managing the list at development-owner at qt-project.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Development digest..." Today's Topics: 1. Re: Future of Qt on Web? (Konstantin Tokarev) 2. Re: Future of Qt on Web? (Lorn Potter) 3. Re: Future of Qt on Web? (Jason H) 4. Re: Nominating Vikas Pachdha for Approver status (Alex Blasche) 5. Qt 5.10 pre-built bunaries (Jani Heikkinen) 6. Re: Qt 5.10 pre-built bunaries (Lars Knoll) ---------- Messaggio inoltrato ---------- From: Konstantin Tokarev To: Jason H , Lorn Potter Cc: "development at qt-project.org" Bcc: Date: Mon, 05 Jun 2017 17:22:26 +0300 Subject: Re: [Development] Future of Qt on Web? 05.06.2017, 17:20, "Jason H" : >> Sent: Monday, June 05, 2017 at 12:34 AM >> From: "Lorn Potter" >> To: development at qt-project.org >> Subject: Re: [Development] Future of Qt on Web? >> >> On 06/05/2017 07:00 AM, Jason H wrote: >> > While Qt is not a web framework, over time there have been efforts to use it on the web (outlined below). >> > >> > Given that Chrome is dropping NaCL (http://www.tomshardware.com/n ews/chrome-deprecates-pnacl-embraces-webassembly,34583.html) and the WebGL streaming is also not ideal (but better?), I am wondering about the future of Qt on Web? Will there be a WebAssembly version of Qt? >> >> We have been working on Qt5 for webassembly. >> I was just writing a short blog about this: >> >> http://qtandeverything.blogspot.com.au/2017/06/qt-for-web-assembly.html > > That is great news! You mention the wasm is smaller? How much smaller? This article says it's smaller than asm.js, not NaCl > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin ---------- Messaggio inoltrato ---------- From: Lorn Potter To: Jason H Cc: development at qt-project.org Bcc: Date: Tue, 6 Jun 2017 05:26:53 +1000 Subject: Re: [Development] Future of Qt on Web? On 06/06/2017 12:20 AM, Jason H wrote: > > >> Sent: Monday, June 05, 2017 at 12:34 AM >> From: "Lorn Potter" >> To: development at qt-project.org >> Subject: Re: [Development] Future of Qt on Web? >> >> >> >> On 06/05/2017 07:00 AM, Jason H wrote: >>> While Qt is not a web framework, over time there have been efforts to use it on the web (outlined below). >>> >>> Given that Chrome is dropping NaCL (http://www.tomshardware.com/n ews/chrome-deprecates-pnacl-embraces-webassembly,34583.html) and the WebGL streaming is also not ideal (but better?), I am wondering about the future of Qt on Web? Will there be a WebAssembly version of Qt? >> >> We have been working on Qt5 for webassembly. >> I was just writing a short blog about this: >> >> http://qtandeverything.blogspot.com.au/2017/06/qt-for-web-assembly.html > > That is great news! You mention the wasm is smaller? How much smaller? For one small example app (standarddialog) the difference between asmjs and wasm is: wasm: 520 k js file and 14 MB wasm file. asmjs: 69 MB js file. ---------- Messaggio inoltrato ---------- From: Jason H To: Lorn Potter Cc: development at qt-project.org Bcc: Date: Mon, 5 Jun 2017 21:51:53 +0200 Subject: Re: [Development] Future of Qt on Web? > Sent: Monday, June 05, 2017 at 3:26 PM > From: "Lorn Potter" > To: "Jason H" > Cc: development at qt-project.org > Subject: Re: [Development] Future of Qt on Web? > > > > On 06/06/2017 12:20 AM, Jason H wrote: > > > > > >> Sent: Monday, June 05, 2017 at 12:34 AM > >> From: "Lorn Potter" > >> To: development at qt-project.org > >> Subject: Re: [Development] Future of Qt on Web? > >> > >> > >> > >> On 06/05/2017 07:00 AM, Jason H wrote: > >>> While Qt is not a web framework, over time there have been efforts to use it on the web (outlined below). > >>> > >>> Given that Chrome is dropping NaCL (http://www.tomshardware.com/n ews/chrome-deprecates-pnacl-embraces-webassembly,34583.html) and the WebGL streaming is also not ideal (but better?), I am wondering about the future of Qt on Web? Will there be a WebAssembly version of Qt? > >> > >> We have been working on Qt5 for webassembly. > >> I was just writing a short blog about this: > >> > >> http://qtandeverything.blogspot.com.au/2017/06/qt-for-web-assembly.html > > > > That is great news! You mention the wasm is smaller? How much smaller? > > For one small example app (standarddialog) the difference between asmjs > and wasm is: > > wasm: 520 k js file and 14 MB wasm file. > asmjs: 69 MB js file. That's encouraging. It's almost reasonable. Maybe a progressive web app would be the way to go? But I don't think that is using the browser in the best way? You're effectively telling it how to redraw everything, rather than letting it do what it already knows how to do. Is that a fair statement? ---------- Messaggio inoltrato ---------- From: Alex Blasche To: "" Cc: qt-creator Bcc: Date: Tue, 6 Jun 2017 11:58:08 +0000 Subject: Re: [Development] Nominating Vikas Pachdha for Approver status Congratulations to Vikas. The rights have been adjusted. -- Alex ________________________________________ From: Development on behalf of Eike Ziller Sent: Monday, 15 May 2017 10:43:57 AM To: Cc: qt-creator Subject: [Development] Nominating Vikas Pachdha for Approver status Hereby I nominate Vikas Pachdha for Approver status. He has been defacto maintaining iOS support in Qt Creator since a year. https://codereview.qt-project.org/#/q/owner:%22Vikas+Pachdha %22+status:merged,n,z 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, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development ---------- Messaggio inoltrato ---------- From: Jani Heikkinen To: "development at qt-project.org" Cc: "releasing at qt-project.org" Bcc: Date: Wed, 7 Jun 2017 06:57:10 +0000 Subject: [Development] Qt 5.10 pre-built bunaries Hi all, There has been discussion ongoing about 5.10 supported platforms and CI configurations. What we haven't agreed yet is Qt 5.10 pre-built binaries. I don't see big need to change anything from 5.9 but there is still couple of things on my mind: - Should we now switch from MinGW32 bit -> MinGW 64bit ones? With 5.9 this was too early but would it be time to do it now? Offering both isn't an option. And 5,9 is LTS so 5.10 could be good release to change that... - Can we start using RHEL 7.4 for linux packaging? Tony is planning to add RHEL 7.4 in CI and so on it would be wise to replace 7.2 with 7.4 in the packaging as well Is there some other change proposals which we should discuss about? br, Jani ---------- Messaggio inoltrato ---------- From: Lars Knoll To: Jani Heikkinen Cc: Qt development mailing list , " releasing at qt-project.org" Bcc: Date: Wed, 7 Jun 2017 07:30:15 +0000 Subject: Re: [Development] Qt 5.10 pre-built bunaries Hi Jani, > On 7 Jun 2017, at 08:57, Jani Heikkinen wrote: > > Hi all, > > There has been discussion ongoing about 5.10 supported platforms and CI configurations. What we haven't agreed yet is Qt 5.10 pre-built binaries. I don't see big need to change anything from 5.9 but there is still couple of things on my mind: > > - Should we now switch from MinGW32 bit -> MinGW 64bit ones? With 5.9 this was too early but would it be time to do it now? Offering both isn't an option. And 5,9 is LTS so 5.10 could be good release to change that... We got a lot of questions about 32bit binaries still in the comments to the release blog. But those were pretty much all about VS2017. I'd personally be happy to move more towards 64 bit, but we should somehow find out how much 32bit is still required by our users. > > - Can we start using RHEL 7.4 for linux packaging? Tony is planning to add RHEL 7.4 in CI and so on it would be wise to replace 7.2 with 7.4 in the packaging as well Sounds good to me, unless anybody knows about any reasons why we should stay on 7.2. > > Is there some other change proposals which we should discuss about? I think we should strongly consider dropping 32bit for iOS. Cheers, Lars _______________________________________________ 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 tuukka.turunen at qt.io Thu Jun 8 08:02:07 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 8 Jun 2017 06:02:07 +0000 Subject: [Development] Qt 5.10 pre-built binaries In-Reply-To: References: Message-ID: <24F19BE8-8120-4B5F-B361-80AE88DB31AE@qt.io> Hi, Dropping ARMv7 and i386 iOS binaries should help in this. Yours, Tuukka From: Development on behalf of Marco Piccolino Date: Thursday, 8 June 2017 at 8.37 To: "development at qt-project.org" Subject: Re: [Development] Qt 5.10 pre-built binaries Hello, Would you also consider creating a smaller macOS offline installer? Current version with Android and iOS is at 3.5 Gb and has been reported to cause persistent timeouts when downloaded on CI like Travis. Is providing android and iOS as add-on installs an option? Marco Piccolino Il 07 giu 2017 9:30 AM, > ha scritto: Send Development mailing list submissions to development at qt-project.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.qt-project.org/mailman/listinfo/development or, via email, send a message with subject or body 'help' to development-request at qt-project.org You can reach the person managing the list at development-owner at qt-project.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Development digest..." Today's Topics: 1. Re: Future of Qt on Web? (Konstantin Tokarev) 2. Re: Future of Qt on Web? (Lorn Potter) 3. Re: Future of Qt on Web? (Jason H) 4. Re: Nominating Vikas Pachdha for Approver status (Alex Blasche) 5. Qt 5.10 pre-built bunaries (Jani Heikkinen) 6. Re: Qt 5.10 pre-built bunaries (Lars Knoll) ---------- Messaggio inoltrato ---------- From: Konstantin Tokarev > To: Jason H >, Lorn Potter > Cc: "development at qt-project.org" > Bcc: Date: Mon, 05 Jun 2017 17:22:26 +0300 Subject: Re: [Development] Future of Qt on Web? 05.06.2017, 17:20, "Jason H" >: >> Sent: Monday, June 05, 2017 at 12:34 AM >> From: "Lorn Potter" > >> To: development at qt-project.org >> Subject: Re: [Development] Future of Qt on Web? >> >> On 06/05/2017 07:00 AM, Jason H wrote: >> > While Qt is not a web framework, over time there have been efforts to use it on the web (outlined below). >> > >> > Given that Chrome is dropping NaCL (http://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly,34583.html) and the WebGL streaming is also not ideal (but better?), I am wondering about the future of Qt on Web? Will there be a WebAssembly version of Qt? >> >> We have been working on Qt5 for webassembly. >> I was just writing a short blog about this: >> >> http://qtandeverything.blogspot.com.au/2017/06/qt-for-web-assembly.html > > That is great news! You mention the wasm is smaller? How much smaller? This article says it's smaller than asm.js, not NaCl > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin ---------- Messaggio inoltrato ---------- From: Lorn Potter > To: Jason H > Cc: development at qt-project.org Bcc: Date: Tue, 6 Jun 2017 05:26:53 +1000 Subject: Re: [Development] Future of Qt on Web? On 06/06/2017 12:20 AM, Jason H wrote: > > >> Sent: Monday, June 05, 2017 at 12:34 AM >> From: "Lorn Potter" > >> To: development at qt-project.org >> Subject: Re: [Development] Future of Qt on Web? >> >> >> >> On 06/05/2017 07:00 AM, Jason H wrote: >>> While Qt is not a web framework, over time there have been efforts to use it on the web (outlined below). >>> >>> Given that Chrome is dropping NaCL (http://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly,34583.html) and the WebGL streaming is also not ideal (but better?), I am wondering about the future of Qt on Web? Will there be a WebAssembly version of Qt? >> >> We have been working on Qt5 for webassembly. >> I was just writing a short blog about this: >> >> http://qtandeverything.blogspot.com.au/2017/06/qt-for-web-assembly.html > > That is great news! You mention the wasm is smaller? How much smaller? For one small example app (standarddialog) the difference between asmjs and wasm is: wasm: 520 k js file and 14 MB wasm file. asmjs: 69 MB js file. ---------- Messaggio inoltrato ---------- From: Jason H > To: Lorn Potter > Cc: development at qt-project.org Bcc: Date: Mon, 5 Jun 2017 21:51:53 +0200 Subject: Re: [Development] Future of Qt on Web? > Sent: Monday, June 05, 2017 at 3:26 PM > From: "Lorn Potter" > > To: "Jason H" > > Cc: development at qt-project.org > Subject: Re: [Development] Future of Qt on Web? > > > > On 06/06/2017 12:20 AM, Jason H wrote: > > > > > >> Sent: Monday, June 05, 2017 at 12:34 AM > >> From: "Lorn Potter" > > >> To: development at qt-project.org > >> Subject: Re: [Development] Future of Qt on Web? > >> > >> > >> > >> On 06/05/2017 07:00 AM, Jason H wrote: > >>> While Qt is not a web framework, over time there have been efforts to use it on the web (outlined below). > >>> > >>> Given that Chrome is dropping NaCL (http://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly,34583.html) and the WebGL streaming is also not ideal (but better?), I am wondering about the future of Qt on Web? Will there be a WebAssembly version of Qt? > >> > >> We have been working on Qt5 for webassembly. > >> I was just writing a short blog about this: > >> > >> http://qtandeverything.blogspot.com.au/2017/06/qt-for-web-assembly.html > > > > That is great news! You mention the wasm is smaller? How much smaller? > > For one small example app (standarddialog) the difference between asmjs > and wasm is: > > wasm: 520 k js file and 14 MB wasm file. > asmjs: 69 MB js file. That's encouraging. It's almost reasonable. Maybe a progressive web app would be the way to go? But I don't think that is using the browser in the best way? You're effectively telling it how to redraw everything, rather than letting it do what it already knows how to do. Is that a fair statement? ---------- Messaggio inoltrato ---------- From: Alex Blasche > To: ">" > Cc: qt-creator > Bcc: Date: Tue, 6 Jun 2017 11:58:08 +0000 Subject: Re: [Development] Nominating Vikas Pachdha for Approver status Congratulations to Vikas. The rights have been adjusted. -- Alex ________________________________________ From: Development > on behalf of Eike Ziller > Sent: Monday, 15 May 2017 10:43:57 AM To: > Cc: qt-creator Subject: [Development] Nominating Vikas Pachdha for Approver status Hereby I nominate Vikas Pachdha for Approver status. He has been defacto maintaining iOS support in Qt Creator since a year. https://codereview.qt-project.org/#/q/owner:%22Vikas+Pachdha%22+status:merged,n,z 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, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development ---------- Messaggio inoltrato ---------- From: Jani Heikkinen > To: "development at qt-project.org" > Cc: "releasing at qt-project.org" > Bcc: Date: Wed, 7 Jun 2017 06:57:10 +0000 Subject: [Development] Qt 5.10 pre-built bunaries Hi all, There has been discussion ongoing about 5.10 supported platforms and CI configurations. What we haven't agreed yet is Qt 5.10 pre-built binaries. I don't see big need to change anything from 5.9 but there is still couple of things on my mind: - Should we now switch from MinGW32 bit -> MinGW 64bit ones? With 5.9 this was too early but would it be time to do it now? Offering both isn't an option. And 5,9 is LTS so 5.10 could be good release to change that... - Can we start using RHEL 7.4 for linux packaging? Tony is planning to add RHEL 7.4 in CI and so on it would be wise to replace 7.2 with 7.4 in the packaging as well Is there some other change proposals which we should discuss about? br, Jani ---------- Messaggio inoltrato ---------- From: Lars Knoll > To: Jani Heikkinen > Cc: Qt development mailing list >, "releasing at qt-project.org" > Bcc: Date: Wed, 7 Jun 2017 07:30:15 +0000 Subject: Re: [Development] Qt 5.10 pre-built bunaries Hi Jani, > On 7 Jun 2017, at 08:57, Jani Heikkinen > wrote: > > Hi all, > > There has been discussion ongoing about 5.10 supported platforms and CI configurations. What we haven't agreed yet is Qt 5.10 pre-built binaries. I don't see big need to change anything from 5.9 but there is still couple of things on my mind: > > - Should we now switch from MinGW32 bit -> MinGW 64bit ones? With 5.9 this was too early but would it be time to do it now? Offering both isn't an option. And 5,9 is LTS so 5.10 could be good release to change that... We got a lot of questions about 32bit binaries still in the comments to the release blog. But those were pretty much all about VS2017. I'd personally be happy to move more towards 64 bit, but we should somehow find out how much 32bit is still required by our users. > > - Can we start using RHEL 7.4 for linux packaging? Tony is planning to add RHEL 7.4 in CI and so on it would be wise to replace 7.2 with 7.4 in the packaging as well Sounds good to me, unless anybody knows about any reasons why we should stay on 7.2. > > Is there some other change proposals which we should discuss about? I think we should strongly consider dropping 32bit for iOS. Cheers, Lars _______________________________________________ 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 lars.knoll at qt.io Thu Jun 8 08:23:51 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 8 Jun 2017 06:23:51 +0000 Subject: [Development] [Releasing] Qt 5.10 pre-built bunaries In-Reply-To: <2568778.hfst4LOck6@tjmaciei-mobl1> References: <2568778.hfst4LOck6@tjmaciei-mobl1> Message-ID: <17A4B969-B2B7-405E-B746-9D60E404A996@qt.io> On 7 Jun 2017, at 22:09, Thiago Macieira > wrote: On Tuesday, 6 June 2017 23:57:10 PDT Jani Heikkinen wrote: Hi all, There has been discussion ongoing about 5.10 supported platforms and CI configurations. What we haven't agreed yet is Qt 5.10 pre-built binaries. I don't see big need to change anything from 5.9 but there is still couple of things on my mind: - Should we now switch from MinGW32 bit -> MinGW 64bit ones? With 5.9 this was too early but would it be time to do it now? Offering both isn't an option. And 5,9 is LTS so 5.10 could be good release to change that... - Can we start using RHEL 7.4 for linux packaging? Tony is planning to add RHEL 7.4 in CI and so on it would be wise to replace 7.2 with 7.4 in the packaging as well Is there some other change proposals which we should discuss about? I'd like to propose raising the minimum version for GCC to 4.8.1, which is the first C++11 complete version, or higher. The reason for this is actually to drop GCC 4.7 and earlier, which have a few bugs with their C++11 support. GCC 4.7 has been the minimum since Qt 5.7.0 and is now 5 years old. I'm not necessarily against it, as I believe we need to move forward with our compilers. But I am unsure how much sense this makes as long as we're still supporting VC++ 2013. And dropping GCC 4.7 would imply dropping support for QNX 6. Cheers, Lars I've just been bitten by one with QRandomGenerator, relating to calling static member functions from a lambda. The workaround suggested in the Coding Convention is not applicable going forward because Clang 5.0 will produce a warning about it (I've updated the wiki), so we have to choose which one we'll support very shortly, as soon as Apple begins shipping Clang based on the current trunk version in XCode. -- 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 ville.voutilainen at gmail.com Thu Jun 8 08:37:13 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Thu, 8 Jun 2017 09:37:13 +0300 Subject: [Development] [Releasing] Qt 5.10 pre-built bunaries In-Reply-To: <17A4B969-B2B7-405E-B746-9D60E404A996@qt.io> References: <2568778.hfst4LOck6@tjmaciei-mobl1> <17A4B969-B2B7-405E-B746-9D60E404A996@qt.io> Message-ID: On 8 June 2017 at 09:23, Lars Knoll wrote: >> I'd like to propose raising the minimum version for GCC to 4.8.1, which is >> the >> first C++11 complete version, or higher. The reason for this is actually to >> drop GCC 4.7 and earlier, which have a few bugs with their C++11 support. >> GCC >> 4.7 has been the minimum since Qt 5.7.0 and is now 5 years old. > > I'm not necessarily against it, as I believe we need to move forward with > our compilers. But I am unsure how much sense this makes as long as we're > still supporting VC++ 2013. > > And dropping GCC 4.7 would imply dropping support for QNX 6. I'll make the observation that we just released an LTS release that will support QNX 6 until the next LTS comes out. From lars.knoll at qt.io Thu Jun 8 08:45:24 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 8 Jun 2017 06:45:24 +0000 Subject: [Development] [Releasing] Qt 5.10 pre-built bunaries In-Reply-To: References: <2568778.hfst4LOck6@tjmaciei-mobl1> <17A4B969-B2B7-405E-B746-9D60E404A996@qt.io> Message-ID: <1D9E87ED-8CA5-404B-BBD8-5E18E921B51D@qt.io> > On 8 Jun 2017, at 08:37, Ville Voutilainen wrote: > > On 8 June 2017 at 09:23, Lars Knoll wrote: >>> I'd like to propose raising the minimum version for GCC to 4.8.1, which is >>> the >>> first C++11 complete version, or higher. The reason for this is actually to >>> drop GCC 4.7 and earlier, which have a few bugs with their C++11 support. >>> GCC >>> 4.7 has been the minimum since Qt 5.7.0 and is now 5 years old. >> >> I'm not necessarily against it, as I believe we need to move forward with >> our compilers. But I am unsure how much sense this makes as long as we're >> still supporting VC++ 2013. >> >> And dropping GCC 4.7 would imply dropping support for QNX 6. > > I'll make the observation that we just released an LTS release that > will support QNX 6 > until the next LTS comes out. Sure, it's still important that we all know about the possible side effects of dropping a compiler version before making the decision. IMO, keeping VC++ 2013 while dropping gcc 4.7 doesn't make too much sense. We either keep both or drop both. Cheers, Lars From ville.voutilainen at gmail.com Thu Jun 8 08:47:35 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Thu, 8 Jun 2017 09:47:35 +0300 Subject: [Development] [Releasing] Qt 5.10 pre-built bunaries In-Reply-To: <1D9E87ED-8CA5-404B-BBD8-5E18E921B51D@qt.io> References: <2568778.hfst4LOck6@tjmaciei-mobl1> <17A4B969-B2B7-405E-B746-9D60E404A996@qt.io> <1D9E87ED-8CA5-404B-BBD8-5E18E921B51D@qt.io> Message-ID: On 8 June 2017 at 09:45, Lars Knoll wrote: >>> And dropping GCC 4.7 would imply dropping support for QNX 6. >> >> I'll make the observation that we just released an LTS release that >> will support QNX 6 >> until the next LTS comes out. > > > Sure, it's still important that we all know about the possible side effects of dropping a compiler version before making the decision. > > IMO, keeping VC++ 2013 while dropping gcc 4.7 doesn't make too much sense. We either keep both or drop both. Agreed on all points. I would drop both. The vendors of those compilers won't bugfix them any more, either. From marco.a.piccolino at gmail.com Thu Jun 8 10:43:55 2017 From: marco.a.piccolino at gmail.com (Marco Piccolino) Date: Thu, 8 Jun 2017 10:43:55 +0200 Subject: [Development] Qt 5.10 pre-built binaries In-Reply-To: <24F19BE8-8120-4B5F-B361-80AE88DB31AE@qt.io> References: <24F19BE8-8120-4B5F-B361-80AE88DB31AE@qt.io> Message-ID: Thanks Tuukka, that makes sense, I'll have a look at how big they are. Marco Piccolino Il 08 giu 2017 8:02 AM, "Tuukka Turunen" ha scritto: > > > Hi, > > > > Dropping ARMv7 and i386 iOS binaries should help in this. > > > > Yours, > > > > Tuukka > > > > *From: *Development qt.io at qt-project.org> on behalf of Marco Piccolino < > marco.a.piccolino at gmail.com> > *Date: *Thursday, 8 June 2017 at 8.37 > *To: *"development at qt-project.org" > *Subject: *Re: [Development] Qt 5.10 pre-built binaries > > > > Hello, > > Would you also consider creating a smaller macOS offline installer? > Current version with Android and iOS is at 3.5 Gb and has been reported to > cause persistent timeouts when downloaded on CI like Travis. > > Is providing android and iOS as add-on installs an option? > > > > Marco Piccolino > > > > Il 07 giu 2017 9:30 AM, ha scritto: > > Send Development mailing list submissions to > development at qt-project.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.qt-project.org/mailman/listinfo/development > or, via email, send a message with subject or body 'help' to > development-request at qt-project.org > > You can reach the person managing the list at > development-owner at qt-project.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Development digest..." > > Today's Topics: > > 1. Re: Future of Qt on Web? (Konstantin Tokarev) > 2. Re: Future of Qt on Web? (Lorn Potter) > 3. Re: Future of Qt on Web? (Jason H) > 4. Re: Nominating Vikas Pachdha for Approver status (Alex Blasche) > 5. Qt 5.10 pre-built bunaries (Jani Heikkinen) > 6. Re: Qt 5.10 pre-built bunaries (Lars Knoll) > > > ---------- Messaggio inoltrato ---------- > From: Konstantin Tokarev > To: Jason H , Lorn Potter > Cc: "development at qt-project.org" > Bcc: > Date: Mon, 05 Jun 2017 17:22:26 +0300 > Subject: Re: [Development] Future of Qt on Web? > > > 05.06.2017, 17:20, "Jason H" : > >> Sent: Monday, June 05, 2017 at 12:34 AM > >> From: "Lorn Potter" > >> To: development at qt-project.org > >> Subject: Re: [Development] Future of Qt on Web? > >> > >> On 06/05/2017 07:00 AM, Jason H wrote: > >> > While Qt is not a web framework, over time there have been efforts > to use it on the web (outlined below). > >> > > >> > Given that Chrome is dropping NaCL (http://www.tomshardware.com/ > news/chrome-deprecates-pnacl-embraces-webassembly,34583.html) and the > WebGL streaming is also not ideal (but better?), I am wondering about the > future of Qt on Web? Will there be a WebAssembly version of Qt? > >> > >> We have been working on Qt5 for webassembly. > >> I was just writing a short blog about this: > >> > >> http://qtandeverything.blogspot.com.au/2017/06/qt- > for-web-assembly.html > > > > That is great news! You mention the wasm is smaller? How much smaller? > > This article says it's smaller than asm.js, not NaCl > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin > > > > ---------- Messaggio inoltrato ---------- > From: Lorn Potter > To: Jason H > Cc: development at qt-project.org > Bcc: > Date: Tue, 6 Jun 2017 05:26:53 +1000 > Subject: Re: [Development] Future of Qt on Web? > > > On 06/06/2017 12:20 AM, Jason H wrote: > > > > > >> Sent: Monday, June 05, 2017 at 12:34 AM > >> From: "Lorn Potter" > >> To: development at qt-project.org > >> Subject: Re: [Development] Future of Qt on Web? > >> > >> > >> > >> On 06/05/2017 07:00 AM, Jason H wrote: > >>> While Qt is not a web framework, over time there have been efforts to > use it on the web (outlined below). > >>> > >>> Given that Chrome is dropping NaCL (http://www.tomshardware.com/ > news/chrome-deprecates-pnacl-embraces-webassembly,34583.html) and the > WebGL streaming is also not ideal (but better?), I am wondering about the > future of Qt on Web? Will there be a WebAssembly version of Qt? > >> > >> We have been working on Qt5 for webassembly. > >> I was just writing a short blog about this: > >> > >> http://qtandeverything.blogspot.com.au/2017/06/qt-for-web-assembly.html > > > > That is great news! You mention the wasm is smaller? How much smaller? > > For one small example app (standarddialog) the difference between asmjs > and wasm is: > > wasm: 520 k js file and 14 MB wasm file. > asmjs: 69 MB js file. > > > > > ---------- Messaggio inoltrato ---------- > From: Jason H > To: Lorn Potter > Cc: development at qt-project.org > Bcc: > Date: Mon, 5 Jun 2017 21:51:53 +0200 > Subject: Re: [Development] Future of Qt on Web? > > > > Sent: Monday, June 05, 2017 at 3:26 PM > > From: "Lorn Potter" > > To: "Jason H" > > Cc: development at qt-project.org > > Subject: Re: [Development] Future of Qt on Web? > > > > > > > > On 06/06/2017 12:20 AM, Jason H wrote: > > > > > > > > >> Sent: Monday, June 05, 2017 at 12:34 AM > > >> From: "Lorn Potter" > > >> To: development at qt-project.org > > >> Subject: Re: [Development] Future of Qt on Web? > > >> > > >> > > >> > > >> On 06/05/2017 07:00 AM, Jason H wrote: > > >>> While Qt is not a web framework, over time there have been efforts > to use it on the web (outlined below). > > >>> > > >>> Given that Chrome is dropping NaCL (http://www.tomshardware.com/ > news/chrome-deprecates-pnacl-embraces-webassembly,34583.html) and the > WebGL streaming is also not ideal (but better?), I am wondering about the > future of Qt on Web? Will there be a WebAssembly version of Qt? > > >> > > >> We have been working on Qt5 for webassembly. > > >> I was just writing a short blog about this: > > >> > > >> http://qtandeverything.blogspot.com.au/2017/06/qt- > for-web-assembly.html > > > > > > That is great news! You mention the wasm is smaller? How much smaller? > > > > For one small example app (standarddialog) the difference between asmjs > > and wasm is: > > > > wasm: 520 k js file and 14 MB wasm file. > > asmjs: 69 MB js file. > > That's encouraging. It's almost reasonable. Maybe a progressive web app > would be the way to go? > But I don't think that is using the browser in the best way? You're > effectively telling it how to redraw everything, rather than letting it do > what it already knows how to do. Is that a fair statement? > > > > ---------- Messaggio inoltrato ---------- > From: Alex Blasche > To: "" > Cc: qt-creator > Bcc: > Date: Tue, 6 Jun 2017 11:58:08 +0000 > Subject: Re: [Development] Nominating Vikas Pachdha for Approver status > Congratulations to Vikas. The rights have been adjusted. > > -- > Alex > ________________________________________ > From: Development project.org> on behalf of Eike Ziller > Sent: Monday, 15 May 2017 10:43:57 AM > To: > Cc: qt-creator > Subject: [Development] Nominating Vikas Pachdha for Approver status > > Hereby I nominate Vikas Pachdha for Approver status. He has been defacto > maintaining iOS support in Qt Creator since a year. > > https://codereview.qt-project.org/#/q/owner:%22Vikas+ > Pachdha%22+status:merged,n,z > > 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, Mika Harjuaho > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht > Charlottenburg, HRB 144331 B > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > > ---------- Messaggio inoltrato ---------- > From: Jani Heikkinen > To: "development at qt-project.org" > Cc: "releasing at qt-project.org" > Bcc: > Date: Wed, 7 Jun 2017 06:57:10 +0000 > Subject: [Development] Qt 5.10 pre-built bunaries > Hi all, > > There has been discussion ongoing about 5.10 supported platforms and CI > configurations. What we haven't agreed yet is Qt 5.10 pre-built binaries. I > don't see big need to change anything from 5.9 but there is still couple of > things on my mind: > > - Should we now switch from MinGW32 bit -> MinGW 64bit ones? With 5.9 this > was too early but would it be time to do it now? Offering both isn't an > option. And 5,9 is LTS so 5.10 could be good release to change that... > > - Can we start using RHEL 7.4 for linux packaging? Tony is planning to add > RHEL 7.4 in CI and so on it would be wise to replace 7.2 with 7.4 in the > packaging as well > > Is there some other change proposals which we should discuss about? > > br, > Jani > > > > > > ---------- Messaggio inoltrato ---------- > From: Lars Knoll > To: Jani Heikkinen > Cc: Qt development mailing list , " > releasing at qt-project.org" > Bcc: > Date: Wed, 7 Jun 2017 07:30:15 +0000 > Subject: Re: [Development] Qt 5.10 pre-built bunaries > Hi Jani, > > > On 7 Jun 2017, at 08:57, Jani Heikkinen wrote: > > > > Hi all, > > > > There has been discussion ongoing about 5.10 supported platforms and CI > configurations. What we haven't agreed yet is Qt 5.10 pre-built binaries. I > don't see big need to change anything from 5.9 but there is still couple of > things on my mind: > > > > - Should we now switch from MinGW32 bit -> MinGW 64bit ones? With 5.9 > this was too early but would it be time to do it now? Offering both isn't > an option. And 5,9 is LTS so 5.10 could be good release to change that... > > We got a lot of questions about 32bit binaries still in the comments to > the release blog. But those were pretty much all about VS2017. I'd > personally be happy to move more towards 64 bit, but we should somehow find > out how much 32bit is still required by our users. > > > > - Can we start using RHEL 7.4 for linux packaging? Tony is planning to > add RHEL 7.4 in CI and so on it would be wise to replace 7.2 with 7.4 in > the packaging as well > > Sounds good to me, unless anybody knows about any reasons why we should > stay on 7.2. > > > > Is there some other change proposals which we should discuss about? > > I think we should strongly consider dropping 32bit for iOS. > > Cheers, > Lars > > > > _______________________________________________ > 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 marc.mutz at kdab.com Thu Jun 8 12:00:02 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 8 Jun 2017 12:00:02 +0200 Subject: [Development] [Releasing] Qt 5.10 pre-built bunaries In-Reply-To: <1D9E87ED-8CA5-404B-BBD8-5E18E921B51D@qt.io> References: <1D9E87ED-8CA5-404B-BBD8-5E18E921B51D@qt.io> Message-ID: <201706081200.02583.marc.mutz@kdab.com> On Thursday 08 June 2017 08:45:24 Lars Knoll wrote: > Sure, it's still important that we all know about the possible side effects > of dropping a compiler version before making the decision. > > IMO, keeping VC++ 2013 while dropping gcc 4.7 doesn't make too much sense. > We either keep both or drop both. This thread seems pertinent: http://lists.qt- project.org/pipermail/development/2017-March/029325.html TL;DR: - Marc proposed to drop GCC 4.7 and MSVC 2013 - Ville in favour - Peppe cautioned about slow migration away from MSVC 2013 - Rafael strongly opposed to dropping GCC 4.7: * QNX 7 just released * Very slow migration away from QNX 6 * suggests to drop QNX 6 support not before Qt 6 - Alex said still 30% of downloads are for MSVC 2013 * no-go for 5.10 from him * 5.11 "realistic chance" - Olivier suggesting to require min. GCC 4.8.1 iff we drop GCC 4.7 - Marc linking to https://msdn.microsoft.com/en-us/library/hh567368.aspx for how much feature dropping 2013 would unlock Thread ended inconclusive, but with two strong oppositions to drooping GCC 4.7 and MSVC 2013 each. 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 olivier at woboq.com Thu Jun 8 12:39:51 2017 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 08 Jun 2017 12:39:51 +0200 Subject: [Development] [Releasing] Qt 5.10 pre-built bunaries In-Reply-To: <201706081200.02583.marc.mutz@kdab.com> References: <1D9E87ED-8CA5-404B-BBD8-5E18E921B51D@qt.io> <201706081200.02583.marc.mutz@kdab.com> Message-ID: <2646168.nV5c6qFIJZ@maurice> Am Donnerstag, 8. Juni 2017, 12:00:02 CEST schrieb Marc Mutz: [...] > Thread ended inconclusive, but with two strong oppositions to drooping GCC > 4.7 and MSVC 2013 each. Note that this was before we knew that Qt 5.9 would be a LTS. From rjvbertin at gmail.com Thu Jun 8 15:23:48 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 08 Jun 2017 15:23:48 +0200 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) (and sometimes the entire keyboard in Konsole) References: <5875213.LdfPq16Ncl@bola> <7357771.xnueTRxam7@tjmaciei-mobl1> Message-ID: <2317342.6SXUxKMd2A@patux.local> Thiago Macieira wrote: > Just to provide a different viewpoint: I've only ever used "English (Alt > International)" for the last, oh, 20 years, and I haven't had deadkey problems > in the last 3. I've been using the "English (Macintosh)" layout for a bit over 3 years now, without any issue until I upgraded my hardware a year ago. I don't see how that would be related, but as far as I can tell this still doesn't happen on the old computer. > What you're describing isn't exactly a Qt problem, but must be caused by some > other application. Do you have an idea why only Qt applications would be affected? > The deadkeys lose their state if certain (keyboard) events > get sent to the application between the deadkey and the modified key. I've suspected KDE's kglobalacceld but restarting that one doesn't make any difference. The only other global interference I can think of would come from the screensaver, possibly through the X server itself. I *think* the deadkey issue only happens after the screensaver has kicked in but am not 100% certain. Anyway, changing the screensaving engine from the one in KWin to xscreensaver didn't > If some > other application is playing tricks with your keyboard, it will affect the > deadkeys. I guess it'll be very nontrivial figuring out who might be responsible? FWIW, I have another keyboard issue which I realise could somehow be related because it too never occurred on my old notebook. It affects Konsole only, both the Qt4 and Qt5 versions. In this case I lose keyboard input completely (the paste menu action continues to work). That's either in a single tab or application wide; in the former case I can usually just clone the tab and keep working, in the latter case I have to restart the entire application. And this issue can strike at any moment; I've never been able to reproduce it at will or even figure out a pattern in what I was doing when it triggered. From kde at carewolf.com Thu Jun 8 15:43:07 2017 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Thu, 08 Jun 2017 15:43:07 +0200 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) In-Reply-To: <5875213.LdfPq16Ncl@bola> References: <5875213.LdfPq16Ncl@bola> Message-ID: <39395012.2OI0CL8vqR@twilight> On Samstag, 3. Jun 2017 10:11:01 CEST René J.V. Bertin wrote: > Hi, > > I use the "English (Macintosh)" keyboard variant with the standard "English > (US)" layout. Like on Mac, this gives me accented characters via deadkeys > that associate the most common occurrences: AltGr+e is the deadkey for > e-acute, AltGr+i the deadkey for i-circonflex etc. > > At random intervals I lose the deadkey aspect in the sense that in Qt4 > applications, AltGr+e will insert the acute on itself (idem for the other > combinations) and Qt5 applications the deadkey does nothing at all. IOW, in > Qt4 apps I get the accent followed by the to-be-accented letter (´e) while > in Qt5 I just get the letter without the accent. > I just ran into the same thing today not an hour ago. No idea what triggered it, but I haven't seen it before. I solved it by starting ibus, but I guess that just adds another layer of interpretting keys. Also newly started qt5 applications had working dead-keys too, it was just all running qt5 applications that broke. 'Allan From rjvbertin at gmail.com Thu Jun 8 16:04:19 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 08 Jun 2017 16:04:19 +0200 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) In-Reply-To: <39395012.2OI0CL8vqR@twilight> References: <5875213.LdfPq16Ncl@bola> <39395012.2OI0CL8vqR@twilight> Message-ID: <2905997.UJ0fNaHWCn@portia.local> On Thursday June 08 2017 15:43:07 Allan Sandfeld Jensen wrote: > I just ran into the same thing today not an hour ago. No idea what triggered > it, but I haven't seen it before. I solved it by starting ibus, but I guess > that just adds another layer of interpretting keys. Also newly started qt5 > applications had working dead-keys too, it was just all running qt5 > applications that broke. Wow, at least now I know "it's not just me" ... What DE are you using? I installed ibus a while back to have another mechanism for swapping and restoring keyboard layouts. Hasn't helped me at all until now (and it's been running ever since I installed it). Next time I'll see if newly started Qt applications are still affected. I think I must already have tried restarting the application I get this most often in (KDE4/Qt4 based KMail) without much success. Maybe you ran into the version that can be cured by cycling keyboard layouts. R. From thiago.macieira at intel.com Thu Jun 8 18:02:07 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 08 Jun 2017 09:02:07 -0700 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) (and sometimes the entire keyboard in Konsole) In-Reply-To: <2317342.6SXUxKMd2A@patux.local> References: <5875213.LdfPq16Ncl@bola> <7357771.xnueTRxam7@tjmaciei-mobl1> <2317342.6SXUxKMd2A@patux.local> Message-ID: <3609962.4OYlFpake6@tjmaciei-mobl1> On quinta-feira, 8 de junho de 2017 06:23:48 PDT René J. V. Bertin wrote: > > If some > > other application is playing tricks with your keyboard, it will affect the > > deadkeys. > > I guess it'll be very nontrivial figuring out who might be responsible? Try using xev and see if any events are sent between the deadkey and the key. Here's my output for : KeyPress event, serial 40, synthetic NO, window 0x800001, root 0xdb, subw 0x0, time 444468201, (-1603,615), root:(217,676), state 0x0, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XmbLookupString gives 0 bytes: XFilterEvent returns: True KeyRelease event, serial 40, synthetic NO, window 0x800001, root 0xdb, subw 0x0, time 444468270, (-1603,615), root:(217,676), state 0x0, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyPress event, serial 40, synthetic NO, window 0x800001, root 0xdb, subw 0x0, time 444470041, (-1603,615), root:(217,676), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XmbLookupString gives 1 bytes: (65) "e" XFilterEvent returns: True KeyPress event, serial 40, synthetic NO, window 0x800001, root 0xdb, subw 0x0, time 444470041, (-1603,615), root:(217,676), state 0x0, keycode 0 (keysym 0xe9, eacute), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 2 bytes: (c3 a9) "é" XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x800001, root 0xdb, subw 0x0, time 444470098, (-1603,615), root:(217,676), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XFilterEvent returns: False (note how there's an extra KeyPress I had never noticed before) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Jun 8 18:06:08 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 08 Jun 2017 09:06:08 -0700 Subject: [Development] [Releasing] Qt 5.10 pre-built bunaries In-Reply-To: References: <1D9E87ED-8CA5-404B-BBD8-5E18E921B51D@qt.io> Message-ID: <3609963.0E5pOqEV3L@tjmaciei-mobl1> On quarta-feira, 7 de junho de 2017 23:47:35 PDT Ville Voutilainen wrote: > On 8 June 2017 at 09:45, Lars Knoll wrote: > > IMO, keeping VC++ 2013 while dropping gcc 4.7 doesn't make too much sense. > > We either keep both or drop both. > Agreed on all points. I would drop both. The vendors of those > compilers won't bugfix them any more, either. It's not usually about whether they're being fixed, but whether we can reasonably expect people still using them to want to compile this Qt version. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Jun 8 18:08:57 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 08 Jun 2017 09:08:57 -0700 Subject: [Development] [Releasing] Qt 5.10 pre-built bunaries In-Reply-To: <201706081200.02583.marc.mutz@kdab.com> References: <1D9E87ED-8CA5-404B-BBD8-5E18E921B51D@qt.io> <201706081200.02583.marc.mutz@kdab.com> Message-ID: <1704436.FjRfythQUh@tjmaciei-mobl1> On quinta-feira, 8 de junho de 2017 03:00:02 PDT Marc Mutz wrote: > On Thursday 08 June 2017 08:45:24 Lars Knoll wrote: > > Sure, it's still important that we all know about the possible side > > effects > > of dropping a compiler version before making the decision. > > > > IMO, keeping VC++ 2013 while dropping gcc 4.7 doesn't make too much sense. > > We either keep both or drop both. > > This thread seems pertinent: http://lists.qt-> project.org/pipermail/development/2017-March/029325.html > > TL;DR: > > - Marc proposed to drop GCC 4.7 and MSVC 2013 > - Ville in favour > - Peppe cautioned about slow migration away from MSVC 2013 > - Rafael strongly opposed to dropping GCC 4.7: > * QNX 7 just released > * Very slow migration away from QNX 6 > * suggests to drop QNX 6 support not before Qt 6 > - Alex said still 30% of downloads are for MSVC 2013 > * no-go for 5.10 from him > * 5.11 "realistic chance" > - Olivier suggesting to require min. GCC 4.8.1 iff we drop GCC 4.7 > - Marc linking to https://msdn.microsoft.com/en-us/library/hh567368.aspx > for how much feature dropping 2013 would unlock > > Thread ended inconclusive, but with two strong oppositions to drooping GCC > 4.7 and MSVC 2013 each. Thanks for summarising the discussion. Looks like we're still at the same impasse, on whether QNX 6.6 should be supported by Qt 5.10. While I'd love to see the upgrade, if hardly one is yet using QNX 7, dropping 6 will just create more work for us because we need to keep bugfixing Qt 5.9 and can't tell people to upgrade. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Thu Jun 8 18:09:39 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 08 Jun 2017 19:09:39 +0300 Subject: [Development] Dropping older compilers for Qt 5.10 (was: Qt 5.10 pre-built bunaries) In-Reply-To: <4163411.lHBuFDpqgs@tjmaciei-mobl1> References: <2568778.hfst4LOck6@tjmaciei-mobl1> <4677251496867430@web43g.yandex.ru> <4163411.lHBuFDpqgs@tjmaciei-mobl1> Message-ID: <851451496938179@web7g.yandex.ru> 08.06.2017, 01:11, "Thiago Macieira" : > On quarta-feira, 7 de junho de 2017 13:30:30 PDT Konstantin Tokarev wrote: >>  FWIW, the first really C++11 complete version of GCC is 4.9, 4.8 still has a >>  number of bugs that result in internal compiler errors, compilation errors, >>  or runtime errors in some non-trivial but valid C++11 code. See for example >>  patches in [1, 2] > > 4.9 is a 4-year-old compiler today. I'd love to get rid of the buggy 5.3.x, > but that's too recent. Quick survey shows: > * GCC 4.9 in Ubuntu 14.04 LTS, Debian Jessie, Fedora 21 [*] > * GCC 4.8.5 in the latest OpenSUSE Leap, SUSE Linux Enterprise. and CentOS / >    RHEL. > [*] F21 is not supported by Fedora; minimum support at the time of Qt 5.10's >   release will be F24 > > So I'm guessing we should require GCC 4.8.5 (all the latest fixes). This will > give us full C++11 support in GCC. I'd like to insist that GCC 4.8 does not provide full C++11 support (see my previous mail), i.e. targeting GCC 4.8 implementation of C++11 is still substantially different than targeting C++11 standard. > Clang claims to be fully C++14 compliant in > 3.4, which we already require. > > Then there's MSVC. So... should we begin thinking of dropping MMSVC 2013? > We'll gain by doing that: >  * default and delete members >  * alignas & alignof >  * inheriting constructors >  * noexcept >  * range for (without having to check if it really works) >  * ref qualifiers (no more need for #ifdef) >  * thread_local (QRandomGenerator benefits from this, also obviates the need to >     introduce Q_THREAD_LOCAL) >  * user defined literals >  * Unicode strings >  * unrestricted unions > > Another benefit is that MSVC 2017 and 2015 are supposedly binary compatible > with each other. With care, we can even use this feature in Qt. > > If we require MSVC 2015 with the most recent update (which is over a year old > now), in addition we get: >  * attributes >  * thread-safe statics (finally! could drop the fallback from Q_GLOBAL_STATIC! >     oh, wait, Apple...) >  * uniform initialisation (without having to check if it really works) > > In other words, there'll be exactly one C++11 feature we won't be able to > indiscriminately use: >  * constexpr > > (plus whatever fails due to issues in the the Standard Libraries) > > -- > 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 ville.voutilainen at gmail.com Thu Jun 8 19:02:16 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Thu, 8 Jun 2017 20:02:16 +0300 Subject: [Development] Dropping older compilers for Qt 5.10 (was: Qt 5.10 pre-built bunaries) In-Reply-To: <851451496938179@web7g.yandex.ru> References: <2568778.hfst4LOck6@tjmaciei-mobl1> <4677251496867430@web43g.yandex.ru> <4163411.lHBuFDpqgs@tjmaciei-mobl1> <851451496938179@web7g.yandex.ru> Message-ID: On 8 June 2017 at 19:09, Konstantin Tokarev wrote: >> So I'm guessing we should require GCC 4.8.5 (all the latest fixes). This will >> give us full C++11 support in GCC. > > I'd like to insist that GCC 4.8 does not provide full C++11 support (see my previous mail), > i.e. targeting GCC 4.8 implementation of C++11 is still substantially different than targeting > C++11 standard. GCC 5 is the first version of GCC that has full C++11 support, since the previous ones don't have full library support. From thiago.macieira at intel.com Thu Jun 8 20:20:17 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 08 Jun 2017 11:20:17 -0700 Subject: [Development] Dropping older compilers for Qt 5.10 (was: Qt 5.10 pre-built bunaries) In-Reply-To: References: <851451496938179@web7g.yandex.ru> Message-ID: <4926615.4Xchh3PJPa@tjmaciei-mobl1> On quinta-feira, 8 de junho de 2017 10:02:16 PDT Ville Voutilainen wrote: > On 8 June 2017 at 19:09, Konstantin Tokarev wrote: > >> So I'm guessing we should require GCC 4.8.5 (all the latest fixes). This > >> will give us full C++11 support in GCC. > > > > I'd like to insist that GCC 4.8 does not provide full C++11 support (see > > my previous mail), i.e. targeting GCC 4.8 implementation of C++11 is > > still substantially different than targeting C++11 standard. > > GCC 5 is the first version of GCC that has full C++11 support, since > the previous ones don't have > full library support. Both arguments are understood, but 4.8.1 (ref qualifiers) + bugfixes in later patch releases may be sufficient for Qt's needs. We hardly use the Standard Library, so what we need is the core language support. We just want to get rid of some #ifdefs and macros. For that, we need MSVC 2015 and GCC 4.8 for: * ref qualifiers * thread_local Dropping MSVC 2013 will get us some clean up, but we need to drop GCC 4.7 for the above two too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Thu Jun 8 22:15:26 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 08 Jun 2017 22:15:26 +0200 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) (and sometimes the entire keyboard in Konsole) References: <5875213.LdfPq16Ncl@bola> <7357771.xnueTRxam7@tjmaciei-mobl1> <2317342.6SXUxKMd2A@patux.local> <3609962.4OYlFpake6@tjmaciei-mobl1> Message-ID: <2477485.LyNoFQL0Ho@patux.local> Thiago Macieira wrote: > Try using xev and see if any events are sent between the deadkey and the key. I'll try that, but chances are that won't teach me anything. As I said in my OP, this never affects non-Qt applications like for instance Google Chrome. The fact affects both Qt4 (4.8.7) and Qt5 apps seems like a huge coincidence, unless they share the same basic X event handling. So what I'd need at least for comparison is a Qt equivalent of xev :) > Here's my output for : > > KeyPress event, serial 40, synthetic NO, window 0x800001, ... > KeyRelease event, serial 40, synthetic NO, window 0x800001, > root 0xdb, subw 0x0, time 444468270, (-1603,615), root:(217,676), > state 0x0, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES, > XLookupString gives 2 bytes: (c2 b4) "´" > XFilterEvent returns: False > > KeyPress event, serial 40, synthetic NO, window 0x800001, ... > state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, ... > KeyPress event, serial 40, synthetic NO, window 0x800001, > root 0xdb, subw 0x0, time 444470041, (-1603,615), root:(217,676), > state 0x0, keycode 0 (keysym 0xe9, eacute), same_screen YES, > XLookupString gives 0 bytes: > XmbLookupString gives 2 bytes: (c3 a9) "é" > XFilterEvent returns: False > > KeyRelease event, serial 40, synthetic NO, window 0x800001, > root 0xdb, subw 0x0, time 444470098, (-1603,615), root:(217,676), > state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, > XLookupString gives 1 bytes: (65) "e" > XFilterEvent returns: False > > (note how there's an extra KeyPress I had never noticed before) You mean the actual 'é' keypress in between the 'e' key press and key release? The sequence appears surprising indeed, apparently clients must decide for themselves which events to filter and which to heed, whether they want to treat the deadkey event + keypress themselves or just get the preprocessed keypress. > R From thiago.macieira at intel.com Fri Jun 9 00:57:10 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 08 Jun 2017 15:57:10 -0700 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) (and sometimes the entire keyboard in Konsole) In-Reply-To: <2477485.LyNoFQL0Ho@patux.local> References: <5875213.LdfPq16Ncl@bola> <3609962.4OYlFpake6@tjmaciei-mobl1> <2477485.LyNoFQL0Ho@patux.local> Message-ID: <1565213.EX8p7kZLWA@tjmaciei-mobl1> On Thursday, 8 June 2017 13:15:26 PDT René J. V. Bertin wrote: > I'll try that, but chances are that won't teach me anything. As I said in my > OP, this never affects non-Qt applications like for instance Google Chrome. > The fact affects both Qt4 (4.8.7) and Qt5 apps seems like a huge > coincidence, unless they share the same basic X event handling. It's somewhat a coincidence, because the code was completely rewritten between Qt 4 and 5. However, the people who wrote it inspired themselves on the older Qt 4 code. > So what I'd need at least for comparison is a Qt equivalent of xev That's called qev and you can find in qttools/src/qev. It's not built by default. But I really meant xev. I just want to know if xev receives any extra events in there. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kde at carewolf.com Fri Jun 9 12:51:37 2017 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Fri, 09 Jun 2017 12:51:37 +0200 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) In-Reply-To: <2905997.UJ0fNaHWCn@portia.local> References: <5875213.LdfPq16Ncl@bola> <39395012.2OI0CL8vqR@twilight> <2905997.UJ0fNaHWCn@portia.local> Message-ID: <4443610.cCPfOTp36v@twilight> On Donnerstag, 8. Juni 2017 16:04:19 CEST René J.V. Bertin wrote: > On Thursday June 08 2017 15:43:07 Allan Sandfeld Jensen wrote: > > I just ran into the same thing today not an hour ago. No idea what > > triggered it, but I haven't seen it before. I solved it by starting ibus, > > but I guess that just adds another layer of interpretting keys. Also > > newly started qt5 applications had working dead-keys too, it was just all > > running qt5 applications that broke. > > Wow, at least now I know "it's not just me" ... What DE are you using? > I am running Plasma > I installed ibus a while back to have another mechanism for swapping and > restoring keyboard layouts. Hasn't helped me at all until now (and it's > been running ever since I installed it). > > Next time I'll see if newly started Qt applications are still affected. I > think I must already have tried restarting the application I get this most > often in (KDE4/Qt4 based KMail) without much success. Maybe you ran into > the version that can be cured by cycling keyboard layouts. > Note application launched via the gui are still affected becaues they are forked from an already running launcher. To fully start a new Qt application in KDE you need to launch it from a terminal. 'Allan From rjvbertin at gmail.com Fri Jun 9 13:23:32 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 09 Jun 2017 13:23:32 +0200 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) In-Reply-To: <4443610.cCPfOTp36v@twilight> References: <5875213.LdfPq16Ncl@bola> <2905997.UJ0fNaHWCn@portia.local> <4443610.cCPfOTp36v@twilight> Message-ID: <3489186.zMoAXhL6lu@portia.local> On Friday June 09 2017 12:51:37 Allan Sandfeld Jensen wrote: > > Wow, at least now I know "it's not just me" ... What DE are you using? > > > I am running Plasma Same here, but Plasma4. > Note application launched via the gui are still affected becaues they are > forked from an already running launcher. To fully start a new Qt application > in KDE you need to launch it from a terminal. Even a KDE terminal? :) That's what I do most of the time anyway, much faster in 99% of the cases :) Thiago Macieira wrote: >> So what I'd need at least for comparison is a Qt equivalent of xev > > That's called qev and you can find in qttools/src/qev. > > But I really meant xev. I just want to know if xev receives any extra events > in there. OK, will try both then. R. From rjvbertin at gmail.com Fri Jun 9 13:32:05 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Fri, 09 Jun 2017 13:32:05 +0200 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) (and sometimes the entire keyboard in Konsole) References: <5875213.LdfPq16Ncl@bola> <3609962.4OYlFpake6@tjmaciei-mobl1> <2477485.LyNoFQL0Ho@patux.local> <1565213.EX8p7kZLWA@tjmaciei-mobl1> Message-ID: <21433616.gUqPWKZCZx@portia.local> Thiago Macieira wrote: > That's called qev and you can find in qttools/src/qev. It's not built by > default. > But I really meant xev. I just want to know if xev receives any extra events > in there. In fact, couldn't qev include xev functionality in a native event filter? R. From rjvbertin at gmail.com Fri Jun 9 15:02:08 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Fri, 09 Jun 2017 15:02:08 +0200 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) (and sometimes the entire keyboard in Konsole) References: <5875213.LdfPq16Ncl@bola> <7357771.xnueTRxam7@tjmaciei-mobl1> <2317342.6SXUxKMd2A@patux.local> <3609962.4OYlFpake6@tjmaciei-mobl1> Message-ID: <5248562.atEIcmlaB8@patux.local> Thiago Macieira wrote: > Here's my output for : > > KeyPress event, serial 40, synthetic NO, window 0x800001, > root 0xdb, subw 0x0, time 444468201, (-1603,615), root:(217,676), > state 0x0, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES, > XLookupString gives 2 bytes: (c2 b4) "´" > XmbLookupString gives 0 bytes: > XFilterEvent returns: True > > KeyRelease event, serial 40, synthetic NO, window 0x800001, > root 0xdb, subw 0x0, time 444468270, (-1603,615), root:(217,676), > state 0x0, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES, > XLookupString gives 2 bytes: (c2 b4) "´" > XFilterEvent returns: False > > KeyPress event, serial 40, synthetic NO, window 0x800001, > root 0xdb, subw 0x0, time 444470041, (-1603,615), root:(217,676), > state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, > XLookupString gives 1 bytes: (65) "e" > XmbLookupString gives 1 bytes: (65) "e" > XFilterEvent returns: True > > KeyPress event, serial 40, synthetic NO, window 0x800001, > root 0xdb, subw 0x0, time 444470041, (-1603,615), root:(217,676), > state 0x0, keycode 0 (keysym 0xe9, eacute), same_screen YES, > XLookupString gives 0 bytes: > XmbLookupString gives 2 bytes: (c3 a9) "é" > XFilterEvent returns: False > > KeyRelease event, serial 40, synthetic NO, window 0x800001, > root 0xdb, subw 0x0, time 444470098, (-1603,615), root:(217,676), > state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, > XLookupString gives 1 bytes: (65) "e" > XFilterEvent returns: False > > (note how there's an extra KeyPress I had never noticed before) For future reference, here's what I see under normal conditions when I press AltGr+e e KeyPress event, serial 40, synthetic NO, window 0x7a00001, root 0xf6, subw 0x0, time 120475392, (99,141), root:(101,193), state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 40, synthetic NO, window 0x7a00001, root 0xf6, subw 0x0, time 120475718, (99,141), root:(101,193), state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XmbLookupString gives 0 bytes: XFilterEvent returns: True KeyRelease event, serial 40, synthetic NO, window 0x7a00001, root 0xf6, subw 0x0, time 120475844, (99,141), root:(101,193), state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x7a00001, root 0xf6, subw 0x0, time 120476114, (99,141), root:(101,193), state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 40, synthetic NO, window 0x7a00001, root 0xf6, subw 0x0, time 120476349, (99,141), root:(101,193), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XmbLookupString gives 1 bytes: (65) "e" XFilterEvent returns: True KeyPress event, serial 40, synthetic NO, window 0x7a00001, root 0xf6, subw 0x0, time 120476349, (99,141), root:(101,193), state 0x0, keycode 0 (keysym 0xe9, eacute), same_screen YES, XKeysymToKeycode returns keycode: 11 XLookupString gives 0 bytes: XmbLookupString gives 2 bytes: (c3 a9) "é" XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x7a00001, root 0xf6, subw 0x0, time 120476443, (99,141), root:(101,193), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XFilterEvent returns: False The dead_acute is there twice; I see it appearing only once when I manage to press the AltGr and e keys sufficiently simultaneously. With qev/Qt 5.8 I see this: qt.qpa.input.methods: filterEventFinished return 108 65027 0 false QKeyEvent(ShortcutOverride, Key_AltGr, GroupSwitchModifier) QKeyEvent(KeyPress, Key_AltGr, GroupSwitchModifier) qt.qpa.input.methods: filterEventFinished return 26 65105 128 true qt.qpa.input.methods: filterEventFinished return 26 65105 128 false QKeyEvent(KeyRelease, Key_Dead_Acute, GroupSwitchModifier) qt.qpa.input.methods: filterEventFinished return 108 65027 128 false QKeyEvent(KeyRelease, Key_AltGr) qt.qpa.input.methods.serialize: QIBusText::fromDBusArgument() "(sa{sv}sv)" qt.qpa.input.methods.serialize: QIBusAttributeList::fromDBusArgument() "(sa{sv}av)" QInputMethodEvent(, commit="U+e9") qt.qpa.input.methods: filterEventFinished return 26 101 0 true qt.qpa.input.methods: filterEventFinished return 26 101 0 false QKeyEvent(KeyRelease, Key_E, text="e") And with qev/4.8.7 (is there any way to get the equivalent of qInfo there?): QKeyEvent(ShortcutOverride, key=0x1001103) QKeyEvent(KeyPress, key=0x1001103) QKeyEvent(ShortcutOverride, key=0x1001251, modifiers=0x40000000, text="´") QKeyEvent(KeyPress, key=0x1001251, modifiers=0x40000000, text="´") QKeyEvent(KeyRelease, key=0x1001251, modifiers=0x40000000, text="´") QKeyEvent(KeyRelease, key=0x1001103, modifiers=0x40000000) QKeyEvent(ShortcutOverride, key=0x45, text="e") QKeyEvent(KeyPress, key=0x45, text="e") QKeyEvent(KeyRelease, key=0x45, text="e") (that's the qev source from 5.8.0 built against Qt 4.8.7) A potentially useful observation: I'm typing this message in KNode 4.13.3, the Usenet client from KDE PIM 4.13.3 . I can trigger the issue transiently in there: - with the KNode message editor in focus, swap to another Plasma virtual desktop using the keyboard (say, Ctrl+F1) without moving the mouse - swap back using a corresponding shortcut (say, Ctrl+F2) without moving the mouse When focus is restored (automatically when Focus-follows-mouse) and I try to type an 'é', I get the "´e" sequence I also get when the issue has triggered. I can restore behaviour by moving the mouse to put focus to any other application and then back to the KNode window. I notice that the same applies to KMail4 (which is not a minimally ported Qt3 app like KNode is). R From rjvbertin at gmail.com Fri Jun 9 15:30:11 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Fri, 09 Jun 2017 15:30:11 +0200 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) (way to reproduce) References: <5875213.LdfPq16Ncl@bola> <3609962.4OYlFpake6@tjmaciei-mobl1> <2477485.LyNoFQL0Ho@patux.local> <1565213.EX8p7kZLWA@tjmaciei-mobl1> <21433616.gUqPWKZCZx@portia.local> Message-ID: <1943397.hCS4bU0rkG@patux.local> Yay, I have found a transient way to trigger the issue transiently! github.com:RJVB/qtwheeltest Builds against both Qt4 and Qt5. To trigger the issue under Plasma: - optionally type an é or other accented character to verify things work, and to have the event output on the calling terminal - move the mouse pointer to the titlebar taking care not to lose focus, press the right button (or menu key on the keyboard), expand the "Move to Desktop" submenu, and then hit the keyboard shortcut to send the window to another desktop - without moving the mouse, use the keyboard shortcut to switch to that desktop. For me, the issue is now triggered until I cycle the focus to and fro another app. Under Qt4, trying to enter an é will yield "´e", under Qt5 I'm only able to get the unaccented character. Evidently one cannot use xev now because it'll involve a focus change. But the "protected" text editor window has the event tracer function from qev, which should help. R From kde at carewolf.com Fri Jun 9 16:08:20 2017 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Fri, 09 Jun 2017 16:08:20 +0200 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) (way to reproduce) In-Reply-To: <1943397.hCS4bU0rkG@patux.local> References: <5875213.LdfPq16Ncl@bola> <21433616.gUqPWKZCZx@portia.local> <1943397.hCS4bU0rkG@patux.local> Message-ID: <1811636.glTxlEd0n8@twilight> On Freitag, 9. Juni 2017 15:30:11 CEST René J. V. Bertin wrote: > Yay, I have found a transient way to trigger the issue transiently! > > github.com:RJVB/qtwheeltest > > Builds against both Qt4 and Qt5. > > To trigger the issue under Plasma: > > - optionally type an é or other accented character to verify things work, > and to have the event output on the calling terminal > - move the mouse pointer to the titlebar taking care not to lose focus, > press the right button (or menu key on the keyboard), expand the "Move to > Desktop" submenu, and then hit the keyboard shortcut to send the window to > another desktop > - without moving the mouse, use the keyboard shortcut to switch to that > desktop. > > For me, the issue is now triggered until I cycle the focus to and fro > another app. Under Qt4, trying to enter an é will yield "´e", under Qt5 I'm > only able to get the unaccented character. > > Evidently one cannot use xev now because it'll involve a focus change. But > the "protected" text editor window has the event tracer function from qev, > which should help. > Then my issue is different I think, because I just don't get the dead-key at all composed or not. With qev: QKeyEvent(ShortcutOverride, Key_AltGr, GroupSwitchModifier) QKeyEvent(KeyPress, Key_AltGr, GroupSwitchModifier) QKeyEvent(ShortcutOverride, Key_Dead_Acute, GroupSwitchModifier) QKeyEvent(KeyPress, Key_Dead_Acute, GroupSwitchModifier) QKeyEvent(KeyRelease, Key_Dead_Acute, GroupSwitchModifier) QKeyEvent(KeyRelease, Key_AltGr) QKeyEvent(ShortcutOverride, Key_E, text="e") QKeyEvent(KeyPress, Key_E, text="e") QKeyEvent(KeyRelease, Key_E, text="e") with xev: KeyPress event, serial 40, synthetic NO, window 0x6a00001, root 0xb8, subw 0x0, time 1982840014, (78,1462), root:(2002,1488), state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 40, synthetic NO, window 0x6a00001, root 0xb8, subw 0x0, time 1982840550, (78,1462), root:(2002,1488), state 0x80, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XmbLookupString gives 0 bytes: XFilterEvent returns: True KeyRelease event, serial 40, synthetic NO, window 0x6a00001, root 0xb8, subw 0x0, time 1982840646, (78,1462), root:(2002,1488), state 0x80, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x6a00001, root 0xb8, subw 0x0, time 1982840726, (78,1462), root:(2002,1488), state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 40, synthetic NO, window 0x6a00001, root 0xb8, subw 0x0, time 1982841654, (78,1462), root:(2002,1488), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XmbLookupString gives 1 bytes: (65) "e" XFilterEvent returns: True KeyPress event, serial 40, synthetic NO, window 0x6a00001, root 0xb8, subw 0x0, time 1982841654, (78,1462), root:(2002,1488), state 0x0, keycode 0 (keysym 0xe9, eacute), same_screen YES, XKeysymToKeycode returns keycode: 26 XLookupString gives 0 bytes: XmbLookupString gives 2 bytes: (c3 a9) "é" XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x6a00001, root 0xb8, subw 0x0, time 1982841742, (78,1462), root:(2002,1488), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XFilterEvent returns: False From rjvbertin at gmail.com Fri Jun 9 16:29:52 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Fri, 09 Jun 2017 16:29:52 +0200 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) (way to reproduce) References: <5875213.LdfPq16Ncl@bola> <3609962.4OYlFpake6@tjmaciei-mobl1> <2477485.LyNoFQL0Ho@patux.local> <1565213.EX8p7kZLWA@tjmaciei-mobl1> <21433616.gUqPWKZCZx@portia.local> <1943397.hCS4bU0rkG@patux.local> Message-ID: <4104468.JVtCXg58jG@patux.local> René J. V. Bertin wrote: > Evidently one cannot use xev now because it'll involve a focus change. But the Actually, maybe one can: `xev -id ` Using that and Qt4: xev (all ok): KeyRelease event, serial 22, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126529470, (106,16), root:(680,46), state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyPress event, serial 22, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126529470, (106,16), root:(680,46), state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XmbLookupString gives 0 bytes: XFilterEvent returns: True KeyRelease event, serial 22, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126529632, (106,16), root:(680,46), state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyRelease event, serial 22, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126529660, (106,16), root:(680,46), state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 22, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126529761, (106,16), root:(680,46), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XFilterEvent returns: False KeyPress event, serial 22, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126529761, (106,16), root:(680,46), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XmbLookupString gives 1 bytes: (65) "e" XFilterEvent returns: True KeyPress event, serial 22, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126529761, (106,16), root:(680,46), state 0x0, keycode 0 (keysym 0xe9, eacute), same_screen YES, XKeysymToKeycode returns keycode: 11 XLookupString gives 0 bytes: XmbLookupString gives 2 bytes: (c3 a9) "é" XFilterEvent returns: False KeyRelease event, serial 22, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126529876, (106,16), root:(680,46), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XFilterEvent returns: False qev: QKeyEvent(ShortcutOverride, key=0x1001103) QKeyEvent(KeyPress, key=0x1001103) QKeyEvent(KeyRelease, key=0x1001251, modifiers=0x40000000, text="´") QKeyEvent(KeyRelease, key=0x1001103, modifiers=0x40000000) QInputMethodEvent(, commit="U+e9") QKeyEvent(KeyRelease, key=0x45, text="e") xev (issue triggered): KeyRelease event, serial 24, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126954309, (114,-8), root:(688,22), state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 24, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126954309, (114,-8), root:(688,22), state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False PropertyNotify event, serial 24, synthetic NO, window 0x5400023, atom 0x15f (_NET_WM_USER_TIME), time 126954318, state PropertyNewValue KeyRelease event, serial 24, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126954399, (114,-8), root:(688,22), state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyPress event, serial 24, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126954399, (114,-8), root:(688,22), state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XmbLookupString gives 0 bytes: XFilterEvent returns: True PropertyNotify event, serial 24, synthetic NO, window 0x5400023, atom 0x15f (_NET_WM_USER_TIME), time 126954408, state PropertyNewValue KeyRelease event, serial 24, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126954525, (114,-8), root:(688,22), state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyRelease event, serial 24, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126954621, (114,-8), root:(688,22), state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 24, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126955120, (114,-8), root:(688,22), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XFilterEvent returns: False KeyPress event, serial 24, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126955120, (114,-8), root:(688,22), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XmbLookupString gives 1 bytes: (65) "e" XFilterEvent returns: True KeyPress event, serial 24, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126955120, (114,-8), root:(688,22), state 0x0, keycode 0 (keysym 0xe9, eacute), same_screen YES, XKeysymToKeycode returns keycode: 11 XLookupString gives 0 bytes: XmbLookupString gives 2 bytes: (c3 a9) "é" XFilterEvent returns: False PropertyNotify event, serial 24, synthetic NO, window 0x5400023, atom 0x15f (_NET_WM_USER_TIME), time 126955131, state PropertyNewValue KeyRelease event, serial 24, synthetic NO, window 0x5400023, root 0xf6, subw 0x0, time 126955211, (114,-8), root:(688,22), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XFilterEvent returns: False qev: QKeyEvent(ShortcutOverride, key=0x1001103) QKeyEvent(KeyPress, key=0x1001103) QKeyEvent(ShortcutOverride, key=0x1001251, modifiers=0x40000000, text="´") QKeyEvent(KeyPress, key=0x1001251, modifiers=0x40000000, text="´") QKeyEvent(KeyRelease, key=0x1001251, modifiers=0x40000000, text="´") QKeyEvent(KeyRelease, key=0x1001103, modifiers=0x40000000) QKeyEvent(ShortcutOverride, key=0x45, text="e") QKeyEvent(KeyPress, key=0x45, text="e") QKeyEvent(KeyRelease, key=0x45, text="e") I don't see any difference in the xev output, but there is a difference in the qev output. Same thing, Qt5 qev only: OK: QKeyEvent(ShortcutOverride, Key_AltGr, GroupSwitchModifier) QKeyEvent(KeyPress, Key_AltGr, GroupSwitchModifier) QKeyEvent(KeyRelease, Key_Dead_Acute, GroupSwitchModifier) QKeyEvent(KeyRelease, Key_AltGr) QInputMethodEvent(, commit="U+e9") QInputMethodQueryEvent(queries=0x1, {}) QInputMethodQueryEvent(queries=0x2, {}) QInputMethodQueryEvent(queries=0x1, {}) QInputMethodQueryEvent(queries=0x2, {}) QInputMethodQueryEvent(queries=0x1, {}) QInputMethodQueryEvent(queries=0x2, {}) QInputMethodQueryEvent(queries=0x1, {}) QInputMethodQueryEvent(queries=0x2, {}) QKeyEvent(KeyRelease, Key_E, text="e") Issue triggered: QKeyEvent(ShortcutOverride, Key_AltGr, GroupSwitchModifier) QKeyEvent(KeyPress, Key_AltGr, GroupSwitchModifier) QKeyEvent(ShortcutOverride, Key_Dead_Acute, GroupSwitchModifier) QKeyEvent(KeyPress, Key_Dead_Acute, GroupSwitchModifier) QKeyEvent(KeyRelease, Key_Dead_Acute, GroupSwitchModifier) QKeyEvent(KeyRelease, Key_AltGr) QKeyEvent(ShortcutOverride, Key_E, text="e") QKeyEvent(KeyPress, Key_E, text="e") QInputMethodQueryEvent(queries=0x1, {}) QInputMethodQueryEvent(queries=0x2, {}) QInputMethodQueryEvent(queries=0x1, {}) QInputMethodQueryEvent(queries=0x2, {}) QInputMethodQueryEvent(queries=0x1, {}) QInputMethodQueryEvent(queries=0x2, {}) QInputMethodQueryEvent(queries=0x1, {}) QInputMethodQueryEvent(queries=0x2, {}) QKeyEvent(KeyRelease, Key_E, text="e") issue repaired (after focus change): QKeyEvent(ShortcutOverride, Key_AltGr, GroupSwitchModifier) QKeyEvent(KeyPress, Key_AltGr, GroupSwitchModifier) QKeyEvent(KeyRelease, Key_Dead_Acute, GroupSwitchModifier) QKeyEvent(KeyRelease, Key_AltGr) QInputMethodEvent(, commit="U+e9") QInputMethodQueryEvent(queries=0x1, {}) QInputMethodQueryEvent(queries=0x2, {}) QInputMethodQueryEvent(queries=0x1, {}) QInputMethodQueryEvent(queries=0x2, {}) QInputMethodQueryEvent(queries=0x1, {}) QInputMethodQueryEvent(queries=0x2, {}) QInputMethodQueryEvent(queries=0x1, {}) QInputMethodQueryEvent(queries=0x2, {}) QKeyEvent(KeyRelease, Key_E, text="e") In both Qt4 and Qt5 cases it seems that the difference is an extra Key_Dead_Acute keypress before the intended(?) Key_Dead_Actute key RELEASE. Qt4 seems to interpret that as "insert just an acute accent", wherease Qt5 discards the accent completely. So yes, Allan, we're seeing the same issue. R. From thiago.macieira at intel.com Fri Jun 9 17:53:31 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 09 Jun 2017 08:53:31 -0700 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) (and sometimes the entire keyboard in Konsole) In-Reply-To: <21433616.gUqPWKZCZx@portia.local> References: <5875213.LdfPq16Ncl@bola> <1565213.EX8p7kZLWA@tjmaciei-mobl1> <21433616.gUqPWKZCZx@portia.local> Message-ID: <2664119.y3toWnsp2q@tjmaciei-mobl1> On Friday, 9 June 2017 04:32:05 PDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > That's called qev and you can find in qttools/src/qev. It's not built by > > default. > > But I really meant xev. I just want to know if xev receives any extra > > events in there. > > In fact, couldn't qev include xev functionality in a native event filter? It could, but I think the interesting part of qev is to show how it interpreted the events into Qt. Anyway, qev isn't really being developed. The last commit to it was mine a year ago that made it *usable* by printing the event contents instead of the pointer addresses (10411e51782f7274da626bec01ec3ab8cae8723b qev: Actually print the events, quote "Otherwise, this is the most useless application ever.") We're lucky that whoever did the modularisation in 2011 copied it over (thank you Marius, Prasanth and Liang, IIRC!). It did not receive *any* commits in its Qt 5 or Qt 4 history besides buildsystem and copyright header changes. http://code.qt.io/cgit/qt/qttools.git/log/src/qev/qev.cpp http://code.qt.io/cgit/qt/qt.git/log/tools/qev/qev.cpp -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jun 9 17:55:06 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 09 Jun 2017 08:55:06 -0700 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) (way to reproduce) In-Reply-To: <4104468.JVtCXg58jG@patux.local> References: <5875213.LdfPq16Ncl@bola> <1943397.hCS4bU0rkG@patux.local> <4104468.JVtCXg58jG@patux.local> Message-ID: <1835204.ECY2a0YiAx@tjmaciei-mobl1> On Friday, 9 June 2017 07:29:52 PDT René J. V. Bertin wrote: > KeyRelease event, serial 22, synthetic NO, window 0x5400023, > root 0xf6, subw 0x0, time 126529660, (106,16), root:(680,46), > state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen > YES, XKeysymToKeycode returns keycode: 92 > XLookupString gives 0 bytes: > XFilterEvent returns: False Both you and Allan: where's the key press for the level 3 shift? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jun 9 17:56:43 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 09 Jun 2017 08:56:43 -0700 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) (and sometimes the entire keyboard in Konsole) In-Reply-To: <5248562.atEIcmlaB8@patux.local> References: <5875213.LdfPq16Ncl@bola> <3609962.4OYlFpake6@tjmaciei-mobl1> <5248562.atEIcmlaB8@patux.local> Message-ID: <25853117.XtJnh70pXE@tjmaciei-mobl1> On Friday, 9 June 2017 06:02:08 PDT René J. V. Bertin wrote: > The dead_acute is there twice; Yes, but one is a KeyPress and the other is a KeyRelease. > qt.qpa.input.methods.serialize: QIBusText::fromDBusArgument() "(sa{sv}sv)" > qt.qpa.input.methods.serialize: QIBusAttributeList::fromDBusArgument() > "(sa{sv}av)" > QInputMethodEvent(, commit="U+e9") That's a difference compared to me: I don't have ibus turned on. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kde at carewolf.com Fri Jun 9 18:52:32 2017 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Fri, 09 Jun 2017 18:52:32 +0200 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) (way to reproduce) In-Reply-To: <1835204.ECY2a0YiAx@tjmaciei-mobl1> References: <5875213.LdfPq16Ncl@bola> <4104468.JVtCXg58jG@patux.local> <1835204.ECY2a0YiAx@tjmaciei-mobl1> Message-ID: <13610795.piZXLfNV54@twilight> On Freitag, 9. Juni 2017 17:55:06 CEST Thiago Macieira wrote: > On Friday, 9 June 2017 07:29:52 PDT René J. V. Bertin wrote: > > KeyRelease event, serial 22, synthetic NO, window 0x5400023, > > > > root 0xf6, subw 0x0, time 126529660, (106,16), root:(680,46), > > state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen > > > > YES, XKeysymToKeycode returns keycode: 92 > > > > XLookupString gives 0 bytes: > > XFilterEvent returns: False > > Both you and Allan: where's the key press for the level 3 shift? AltGr. This is with a US-international layout so it requires AltGr to trigger the deadkey accents. 'Allan From thiago.macieira at intel.com Fri Jun 9 21:26:55 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 09 Jun 2017 12:26:55 -0700 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) (way to reproduce) In-Reply-To: <13610795.piZXLfNV54@twilight> References: <5875213.LdfPq16Ncl@bola> <1835204.ECY2a0YiAx@tjmaciei-mobl1> <13610795.piZXLfNV54@twilight> Message-ID: <1908990.dSUGGxpWxV@tjmaciei-mobl1> On Friday, 9 June 2017 09:52:32 PDT Allan Sandfeld Jensen wrote: > On Freitag, 9. Juni 2017 17:55:06 CEST Thiago Macieira wrote: > > On Friday, 9 June 2017 07:29:52 PDT René J. V. Bertin wrote: > > > KeyRelease event, serial 22, synthetic NO, window 0x5400023, > > > > > > root 0xf6, subw 0x0, time 126529660, (106,16), root:(680,46), > > > state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), > > > same_screen > > > > > > YES, XKeysymToKeycode returns keycode: 92 > > > > > > XLookupString gives 0 bytes: > > > XFilterEvent returns: False > > > > Both you and Allan: where's the key press for the level 3 shift? > > AltGr. This is with a US-international layout so it requires AltGr to > trigger the deadkey accents. I know what it is (I have it too, so I can get æ and ø). I was asking about where the KeyPress for it is. Neither your nor René's paste showed it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jun 9 22:31:21 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 09 Jun 2017 13:31:21 -0700 Subject: [Development] Dropping older compilers for Qt 5.10 (was: Qt 5.10 pre-built bunaries) In-Reply-To: <4163411.lHBuFDpqgs@tjmaciei-mobl1> References: <4677251496867430@web43g.yandex.ru> <4163411.lHBuFDpqgs@tjmaciei-mobl1> Message-ID: <1693807.OoSu82cptC@tjmaciei-mobl1> On Wednesday, 7 June 2017 15:10:57 PDT Thiago Macieira wrote: > * Unicode strings > * unrestricted unions > > Another benefit is that MSVC 2017 and 2015 are supposedly binary compatible > with each other. With care, we can even use this feature in Qt. > > If we require MSVC 2015 with the most recent update (which is over a year > old now), in addition we get: > * attributes > * thread-safe statics (finally! could drop the fallback from > Q_GLOBAL_STATIC! oh, wait, Apple...) > * uniform initialisation (without having to check if it really works) Another benefit of requiring MSVC 2015 with updates: Our sources can FINALLY be UTF-8 clean, as that compiler understands the /utf-8 option. That means QStringLiteral(x) can contain any arbitrary UTF-8 text where x is. As well as string concatenation: QStringLiteral("Hello " "world"); ===> I move we drop MSVC 2013, MSVC 2015 RTM and Updates 1 & 2 (Update 3 is the current version and is fine). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ville.voutilainen at gmail.com Fri Jun 9 22:46:42 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Fri, 9 Jun 2017 23:46:42 +0300 Subject: [Development] Dropping older compilers for Qt 5.10 (was: Qt 5.10 pre-built bunaries) In-Reply-To: <1693807.OoSu82cptC@tjmaciei-mobl1> References: <4677251496867430@web43g.yandex.ru> <4163411.lHBuFDpqgs@tjmaciei-mobl1> <1693807.OoSu82cptC@tjmaciei-mobl1> Message-ID: On 9 June 2017 at 23:31, Thiago Macieira wrote: > On Wednesday, 7 June 2017 15:10:57 PDT Thiago Macieira wrote: >> * Unicode strings >> * unrestricted unions >> >> Another benefit is that MSVC 2017 and 2015 are supposedly binary compatible >> with each other. With care, we can even use this feature in Qt. >> >> If we require MSVC 2015 with the most recent update (which is over a year >> old now), in addition we get: >> * attributes >> * thread-safe statics (finally! could drop the fallback from >> Q_GLOBAL_STATIC! oh, wait, Apple...) >> * uniform initialisation (without having to check if it really works) > > Another benefit of requiring MSVC 2015 with updates: > > Our sources can FINALLY be UTF-8 clean, as that compiler understands the > /utf-8 option. That means QStringLiteral(x) can contain any arbitrary UTF-8 > text where x is. > > As well as string concatenation: > QStringLiteral("Hello " "world"); > > ===> > I move we drop MSVC 2013, MSVC 2015 RTM and Updates 1 & 2 (Update 3 is the > current version and is fine). So, what's your take on gcc versions? You seemed hesitant to drop support for QNX 6 here: http://lists.qt-project.org/pipermail/development/2017-June/030113.html Are you suggesting we drop support for the MSVC versions you mentioned, but keep GCC 4.7 support? From thiago.macieira at intel.com Fri Jun 9 22:55:02 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 09 Jun 2017 13:55:02 -0700 Subject: [Development] Dropping older compilers for Qt 5.10 (was: Qt 5.10 pre-built bunaries) In-Reply-To: References: <1693807.OoSu82cptC@tjmaciei-mobl1> Message-ID: <6993214.nkmqxMU9eX@tjmaciei-mobl1> On Friday, 9 June 2017 13:46:42 PDT Ville Voutilainen wrote: > > ===> > > I move we drop MSVC 2013, MSVC 2015 RTM and Updates 1 & 2 (Update 3 is the > > current version and is fine). > > So, what's your take on gcc versions? You seemed hesitant to drop > support for QNX 6 > here: > http://lists.qt-project.org/pipermail/development/2017-June/030113.html Are > you suggesting we drop support for the MSVC versions you mentioned, but > keep GCC 4.7 support? Yes. Let's leave GCC 4.7 as a requirement for now. For once, GCC will be the lowest common denominator we need to support (due to QNX). That will also allow us to judge how much pain we are willing to accept for that old compiler. We may want to drop it for 5.11. Definitely for Qt 6 I'd like to be able to claim full C++11 core language requirement (modulo bugs - see my other reply to myself). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jun 9 22:59:16 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 09 Jun 2017 13:59:16 -0700 Subject: [Development] Dropping older compilers for Qt 5.10 (was: Qt 5.10 pre-built bunaries) In-Reply-To: <4163411.lHBuFDpqgs@tjmaciei-mobl1> References: <4677251496867430@web43g.yandex.ru> <4163411.lHBuFDpqgs@tjmaciei-mobl1> Message-ID: <2544555.RXvyzBjN7R@tjmaciei-mobl1> On Wednesday, 7 June 2017 15:10:57 PDT Thiago Macieira wrote: > In other words, there'll be exactly one C++11 feature we won't be able to > indiscriminately use: > * constexpr Let me point the key word of "indiscriminately". MSVC 2015 (at least Update 3) does have support for constexpr, but it has bugs. Unfortunately, the URL in qcompilerdetection.h is resulting in 404. I'm trying to reproduce the issue again by compiling with the support and checking what breaks. I'll reply in an hour or so with the diagnostic. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Fri Jun 9 23:13:25 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Fri, 09 Jun 2017 23:13:25 +0200 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) (way to reproduce) References: <5875213.LdfPq16Ncl@bola> <1835204.ECY2a0YiAx@tjmaciei-mobl1> <13610795.piZXLfNV54@twilight> <1908990.dSUGGxpWxV@tjmaciei-mobl1> Message-ID: <1641477.zYx9rQ2FgD@patux.local> Thiago Macieira wrote: >> AltGr. This is with a US-international layout so it requires AltGr to >> trigger the deadkey accents. > > I know what it is (I have it too, so I can get æ and ø). I was asking about > where the KeyPress for it is. Neither your nor René's paste showed it. > Did it? That was an oversight then: KeyPress event, serial 40, synthetic NO, window 0x5400001, root 0xf6, subw 0x0, time 136884486, (142,95), root:(1328,147), state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 40, synthetic NO, window 0x5400001, root 0xf6, subw 0x0, time 136884592, (142,95), root:(1328,147), state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XmbLookupString gives 0 bytes: XFilterEvent returns: True KeyRelease event, serial 40, synthetic NO, window 0x5400001, root 0xf6, subw 0x0, time 136884752, (142,95), root:(1328,147), state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x5400001, root 0xf6, subw 0x0, time 136884808, (142,95), root:(1328,147), state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 40, synthetic NO, window 0x5400001, root 0xf6, subw 0x0, time 136884957, (142,95), root:(1328,147), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XmbLookupString gives 1 bytes: (65) "e" XFilterEvent returns: True KeyPress event, serial 40, synthetic NO, window 0x5400001, root 0xf6, subw 0x0, time 136884957, (142,95), root:(1328,147), state 0x0, keycode 0 (keysym 0xe9, eacute), same_screen YES, XKeysymToKeycode returns keycode: 11 XLookupString gives 0 bytes: XmbLookupString gives 2 bytes: (c3 a9) "é" XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x5400001, root 0xf6, subw 0x0, time 136885057, (142,95), root:(1328,147), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XFilterEvent returns: False The keypress also shows up in qev: QKeyEvent(ShortcutOverride, Key_AltGr, GroupSwitchModifier) QKeyEvent(KeyPress, Key_AltGr, GroupSwitchModifier) QKeyEvent(KeyRelease, Key_Dead_Acute, GroupSwitchModifier) QKeyEvent(KeyRelease, Key_AltGr) QInputMethodEvent(, commit="U+e9") QInputMethodQueryEvent(queries=0x1, {}) QInputMethodQueryEvent(queries=0x2, {}) QInputMethodQueryEvent(queries=0x1, {}) QInputMethodQueryEvent(queries=0x2, {}) QInputMethodQueryEvent(queries=0x1, {}) QInputMethodQueryEvent(queries=0x2, {}) QInputMethodQueryEvent(queries=0x1, {}) QInputMethodQueryEvent(queries=0x2, {}) QKeyEvent(KeyRelease, Key_E, text="e") Something curious, when I let xev snoop the events from my wheeltest demonstrator, certain events appear to be inverted (release shows before the press): KeyRelease event, serial 22, synthetic NO, window 0x5400026, root 0xf6, subw 0x0, time 137048790, (68,42), root:(73,89), state 0x0, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) "a" XFilterEvent returns: False KeyRelease event, serial 22, synthetic NO, window 0x5400026, root 0xf6, subw 0x0, time 137059575, (68,42), root:(73,89), state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 22, synthetic NO, window 0x5400026, root 0xf6, subw 0x0, time 137059575, (68,42), root:(73,89), state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False PropertyNotify event, serial 22, synthetic NO, window 0x5400026, atom 0x15f (_NET_WM_USER_TIME), time 137059578, state PropertyNewValue KeyRelease event, serial 22, synthetic NO, window 0x5400026, root 0xf6, subw 0x0, time 137059760, (68,42), root:(73,89), state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyPress event, serial 22, synthetic NO, window 0x5400026, root 0xf6, subw 0x0, time 137059760, (68,42), root:(73,89), state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XmbLookupString gives 0 bytes: XFilterEvent returns: True PropertyNotify event, serial 22, synthetic NO, window 0x5400026, atom 0x15f (_NET_WM_USER_TIME), time 137059762, state PropertyNewValue KeyRelease event, serial 22, synthetic NO, window 0x5400026, root 0xf6, subw 0x0, time 137059946, (68,42), root:(73,89), state 0x80, keycode 26 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyRelease event, serial 22, synthetic NO, window 0x5400026, root 0xf6, subw 0x0, time 137060176, (68,42), root:(73,89), state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 22, synthetic NO, window 0x5400026, root 0xf6, subw 0x0, time 137061031, (68,42), root:(73,89), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XFilterEvent returns: False KeyPress event, serial 22, synthetic NO, window 0x5400026, root 0xf6, subw 0x0, time 137061031, (68,42), root:(73,89), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XmbLookupString gives 1 bytes: (65) "e" XFilterEvent returns: True KeyPress event, serial 22, synthetic NO, window 0x5400026, root 0xf6, subw 0x0, time 137061031, (68,42), root:(73,89), state 0x0, keycode 0 (keysym 0xe9, eacute), same_screen YES, XKeysymToKeycode returns keycode: 11 XLookupString gives 0 bytes: XmbLookupString gives 2 bytes: (c3 a9) "é" XFilterEvent returns: False PropertyNotify event, serial 22, synthetic NO, window 0x5400026, atom 0x15f (_NET_WM_USER_TIME), time 137061033, state PropertyNewValue KeyRelease event, serial 22, synthetic NO, window 0x5400026, root 0xf6, subw 0x0, time 137061162, (68,42), root:(73,89), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XFilterEvent returns: False R. From thiago.macieira at intel.com Fri Jun 9 23:58:06 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 09 Jun 2017 14:58:06 -0700 Subject: [Development] Dropping older compilers for Qt 5.10 (was: Qt 5.10 pre-built bunaries) In-Reply-To: <2544555.RXvyzBjN7R@tjmaciei-mobl1> References: <4163411.lHBuFDpqgs@tjmaciei-mobl1> <2544555.RXvyzBjN7R@tjmaciei-mobl1> Message-ID: <18807473.TvgAfxTQJI@tjmaciei-mobl1> On Friday, 9 June 2017 13:59:16 PDT Thiago Macieira wrote: > On Wednesday, 7 June 2017 15:10:57 PDT Thiago Macieira wrote: > > In other words, there'll be exactly one C++11 feature we won't be able to > > > > indiscriminately use: > > * constexpr > > Let me point the key word of "indiscriminately". > > MSVC 2015 (at least Update 3) does have support for constexpr, but it has > bugs. Unfortunately, the URL in qcompilerdetection.h is resulting in 404. > I'm trying to reproduce the issue again by compiling with the support and > checking what breaks. I'll reply in an hour or so with the diagnostic. Okay... something interesting happened. With two simple fixes submitted now in https://codereview.qt-project.org/196981 qtbase compiled in debug mode (release mode building now but won't finish before I go home). Even tst_compiler seems[*] to be compiling. However, I did find one MSVC feedback item I submitted and is not listed in qcompilerdetection.h. The error is still present in MSVC 2015 Update 3, though not in 2017. The source code is clearly based on tst_qflags. https://connect.microsoft.com/VisualStudio/Feedback/Details/3113430 I'm thinking that we could enable constexpr on Update 3 and just work around in tst_qflags. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From iamsergio at gmail.com Sat Jun 10 20:30:50 2017 From: iamsergio at gmail.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Sat, 10 Jun 2017 19:30:50 +0100 Subject: [Development] Dropping older compilers for Qt 5.10 (was: Qt 5.10 pre-built bunaries) In-Reply-To: <4163411.lHBuFDpqgs@tjmaciei-mobl1> References: <2568778.hfst4LOck6@tjmaciei-mobl1> <4677251496867430@web43g.yandex.ru> <4163411.lHBuFDpqgs@tjmaciei-mobl1> Message-ID: On Thu, Jun 8, 2017 at 11:00 AM, Marc Mutz wrote: > This thread seems pertinent: http://lists.qt- > project.org/pipermail/development/2017-March/029325.html > > TL;DR: (...) > - Peppe cautioned about slow migration away from MSVC 2013 > - Alex said still 30% of downloads are for MSVC 2013 (...) The migration has been slow because there's little incentive for users to update to msvc2015/7. If we drop 2013 for Qt 5.10 then migrations would accelerate. QNX is a much different problem though, you can't just recompile your program with QNX 7. Besides the new toolchain, you'd need a new operating system, new drivers, new BSP, and maybe new hardware. It's too complicated and would hurt part of our ecosystem. I think we should dump msvc2013 but keep QNX 6.6. Regards, Sergio Martins From rjvbertin at gmail.com Sun Jun 11 10:16:30 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sun, 11 Jun 2017 10:16:30 +0200 Subject: [Development] Qt/XCB applications and deadkeys (which cease working) (and sometimes the entire keyboard in Konsole) References: <5875213.LdfPq16Ncl@bola> <1565213.EX8p7kZLWA@tjmaciei-mobl1> <21433616.gUqPWKZCZx@portia.local> <2664119.y3toWnsp2q@tjmaciei-mobl1> Message-ID: <1921478.4GLxeKveG2@patux.local> Thiago Macieira wrote: >> In fact, couldn't qev include xev functionality in a native event filter? > > It could, but I think the interesting part of qev is to show how it > interpreted the events into Qt. > Anyway, qev isn't really being developed. The last commit to it was mine a I noticed that :) What I think should be at least potentially useful is to show the non- interpreted events. Otherwise you just see a list of Qt events and in fact nothing about interpretation. I started to hack the xev.c source with the idea to call it from a native event handler. I dropped that (for now) when I discovered xev's snooping option... R. From rjvbertin at gmail.com Sun Jun 11 10:27:41 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sun, 11 Jun 2017 10:27:41 +0200 Subject: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole) References: <5875213.LdfPq16Ncl@bola> <3609962.4OYlFpake6@tjmaciei-mobl1> <5248562.atEIcmlaB8@patux.local> <25853117.XtJnh70pXE@tjmaciei-mobl1> Message-ID: <3401518.cZRJAs1cJy@patux.local> Thiago Macieira wrote: > That's a difference compared to me: I don't have ibus turned on. Out of curiosity I quit iBus. Coincidence or not, all keyboard input stopped working in all running Qt5 GUI (KF5) applications after a few keystrokes. Snooping with xev shows that the X11 events are still being delivered to the window, and newly launched applications are not affected. I could try attaching a debugger a next time this happens, where could I set a breakpoint? R. From rjvbertin at gmail.com Sun Jun 11 13:12:41 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sun, 11 Jun 2017 13:12:41 +0200 Subject: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole) References: <5875213.LdfPq16Ncl@bola> <3609962.4OYlFpake6@tjmaciei-mobl1> <5248562.atEIcmlaB8@patux.local> <25853117.XtJnh70pXE@tjmaciei-mobl1> <3401518.cZRJAs1cJy@patux.local> Message-ID: <1797524.8aF4O1apqW@patux.local> BTW, any suggestions how I can prevent ibus from being started without uninstalling it or moving key components out of my path? From thiago.macieira at intel.com Sun Jun 11 18:38:40 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 11 Jun 2017 09:38:40 -0700 Subject: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole) In-Reply-To: <1797524.8aF4O1apqW@patux.local> References: <5875213.LdfPq16Ncl@bola> <3401518.cZRJAs1cJy@patux.local> <1797524.8aF4O1apqW@patux.local> Message-ID: <1580699.5268spMcoL@tjmaciei-mobl1> On Sunday, 11 June 2017 04:12:41 PDT René J. V. Bertin wrote: > BTW, any suggestions how I can prevent ibus from being started without > uninstalling it or moving key components out of my path? Check your environment. You must have something that tells Qt to use it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kde at carewolf.com Sun Jun 11 18:54:03 2017 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Sun, 11 Jun 2017 18:54:03 +0200 Subject: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole) In-Reply-To: <3401518.cZRJAs1cJy@patux.local> References: <5875213.LdfPq16Ncl@bola> <25853117.XtJnh70pXE@tjmaciei-mobl1> <3401518.cZRJAs1cJy@patux.local> Message-ID: <27727527.cajhvOmhy1@twilight> On Sonntag, 11. Juni 2017 10:27:41 CEST René J. V. Bertin wrote: > Thiago Macieira wrote: > > That's a difference compared to me: I don't have ibus turned on. > > Out of curiosity I quit iBus. > > Coincidence or not, all keyboard input stopped working in all running Qt5 > GUI (KF5) applications after a few keystrokes. > > Snooping with xev shows that the X11 events are still being delivered to the > window, and newly launched applications are not affected. > > I could try attaching a debugger a next time this happens, where could I set > a breakpoint? > This is the same behavior I saw. When I had the issue with accents, I started ibus, and it fixed it, then I shut down ibus, and the Qt applications that had the issue before, and then worked, stopped responding to input, and newly launched applications worked but had the issue. So something tells Qt applications to start using ibus when it is launched, but they never switch away when it quits. `Allan From rjvbertin at gmail.com Sun Jun 11 20:39:47 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Sun, 11 Jun 2017 20:39:47 +0200 Subject: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole) In-Reply-To: <27727527.cajhvOmhy1@twilight> References: <5875213.LdfPq16Ncl@bola> <3401518.cZRJAs1cJy@patux.local> <27727527.cajhvOmhy1@twilight> Message-ID: <374319341.EvirvCpepM@bola> On Sunday June 11 2017 18:54:03 Allan Sandfeld Jensen wrote: >So something tells Qt applications to start using ibus when it is launched, >but they never switch away when it quits. Couldn't that be simply in qt5/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so (qtbase/src/plugins/platforminputcontexts/ibus)? Sounds like something that might be easier to trace and fix than the accent/deadkey issue. I should add that the recipe I provided to introduce that issue no longer works for me now that I figured out how to disable ibus without uninstalling it. R. From giuseppe.dangelo at kdab.com Mon Jun 12 01:03:41 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 12 Jun 2017 01:03:41 +0200 Subject: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole) In-Reply-To: <3401518.cZRJAs1cJy@patux.local> References: <5875213.LdfPq16Ncl@bola> <3609962.4OYlFpake6@tjmaciei-mobl1> <5248562.atEIcmlaB8@patux.local> <25853117.XtJnh70pXE@tjmaciei-mobl1> <3401518.cZRJAs1cJy@patux.local> Message-ID: Il 11/06/2017 10:27, René J. V. Bertin ha scritto: > Out of curiosity I quit iBus. > > Coincidence or not, all keyboard input stopped working in all running Qt5 GUI > (KF5) applications after a few keystrokes. > > Snooping with xev shows that the X11 events are still being delivered to the > window, and newly launched applications are not affected. > > I could try attaching a debugger a next time this happens, where could I set a > breakpoint? Does applying https://codereview.qt-project.org/#/c/177188/ help? 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 alexander.blasche at qt.io Mon Jun 12 08:30:36 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Mon, 12 Jun 2017 06:30:36 +0000 Subject: [Development] Dropping older compilers for Qt 5.10 (was: Qt 5.10 pre-built bunaries) In-Reply-To: References: <2568778.hfst4LOck6@tjmaciei-mobl1> <4677251496867430@web43g.yandex.ru> <4163411.lHBuFDpqgs@tjmaciei-mobl1> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Sérgio Martins > The migration has been slow because there's little incentive for users to update > to msvc2015/7. If we drop 2013 for Qt 5.10 then migrations would accelerate. That's a viewpoint that does not match reality. > QNX is a much different problem though, you can't just recompile your program > with QNX 7. Besides the new toolchain, you'd need a new operating system, > new drivers, new BSP, and maybe new hardware. It's too complicated and would > hurt part of our ecosystem. > > > I think we should dump msvc2013 but keep QNX 6.6. I am happy to drop msvc2013 for 5.11. -- Alex From rjvbertin at gmail.com Mon Jun 12 09:49:43 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Mon, 12 Jun 2017 09:49:43 +0200 Subject: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole) References: <5875213.LdfPq16Ncl@bola> <3401518.cZRJAs1cJy@patux.local> <1797524.8aF4O1apqW@patux.local> <1580699.5268spMcoL@tjmaciei-mobl1> Message-ID: <2168153.bOGL50Szxy@patux.local> Thiago Macieira wrote: > Check your environment. You must have something that tells Qt to use it. For Qt4 there's QT4_IM_MODULE indeed, and you can configure the input method via qtconfig too. For Qt5 I haven't found anything. In the end I did rename ibus- daemon and ibus-x11, and only then found there's a package called im-config where you can configure this. Annoyingly I didn't write down exactly where that was on by Ubuntu rig, and judging from the file date it was not the /etc/defaults/im_config file I thought I remembered it was :-/ Giuseppe D'Angelo wrote: > Does applying > https://codereview.qt-project.org/#/c/177188/ > help? The patch applies to 5.9.0 and with it I can follow the described recipe without losing keyboard input. R. From rjvbertin at gmail.com Mon Jun 12 09:51:14 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Mon, 12 Jun 2017 09:51:14 +0200 Subject: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole) References: <5875213.LdfPq16Ncl@bola> <3609962.4OYlFpake6@tjmaciei-mobl1> <5248562.atEIcmlaB8@patux.local> <25853117.XtJnh70pXE@tjmaciei-mobl1> <3401518.cZRJAs1cJy@patux.local> Message-ID: <2235673.yd7s6MJPtU@patux.local> Giuseppe D'Angelo wrote: > https://codereview.qt-project.org/#/c/177188/ Sorry, I was a bit too fast, I'm still at 5.8.0 . Curiously the patch applies with a bit of fuzz, so apparently wasn't refactored for 5.8? R. From kde at carewolf.com Mon Jun 12 10:08:55 2017 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Mon, 12 Jun 2017 10:08:55 +0200 Subject: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole) In-Reply-To: <2168153.bOGL50Szxy@patux.local> References: <5875213.LdfPq16Ncl@bola> <1580699.5268spMcoL@tjmaciei-mobl1> <2168153.bOGL50Szxy@patux.local> Message-ID: <2690176.ub1j3r4xDQ@twilight> On Montag, 12. Juni 2017 09:49:43 CEST René J. V. Bertin wrote: > Thiago Macieira wrote: > > Check your environment. You must have something that tells Qt to use it. > > For Qt4 there's QT4_IM_MODULE indeed, and you can configure the input method > via qtconfig too. For Qt5 I haven't found anything. In the end I did rename > ibus- daemon and ibus-x11, and only then found there's a package called > im-config where you can configure this. Annoyingly I didn't write down > exactly where that was on by Ubuntu rig, and judging from the file date it > was not the > /etc/defaults/im_config file I thought I remembered it was :-/ > I am on Debian and found the same thing. Apt-get remove im-config solves the issue. Apparently it is a buggy package that forces Qt to use ibus without ensuring ibus is launched. Btw. In a similar vain of packages having a negative impact on Qt. I also recomment uninstalling at-spi2-core which sets the environment variable to force accessibility always on which has a big negative performance impact. 'Allan From rjvbertin at gmail.com Mon Jun 12 10:17:50 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Mon, 12 Jun 2017 10:17:50 +0200 Subject: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole) References: <5875213.LdfPq16Ncl@bola> <1580699.5268spMcoL@tjmaciei-mobl1> <2168153.bOGL50Szxy@patux.local> <2690176.ub1j3r4xDQ@twilight> Message-ID: <2376691.aGJayiI6Zf@patux.local> Allan Sandfeld Jensen wrote: > I am on Debian and found the same thing. Apt-get remove im-config solves the > issue. Apparently it is a buggy package that forces Qt to use ibus without > ensuring ibus is launched. That's not what I saw. Ibus was always launched at login, and im-config seems to get some length to ensure that applications always use the "best" method available if the user didn't configure things to use a specific method. That's why newly launched Qt applications work fine after exiting ibus. The loss of keyboard input in Qt5 applications is a priori not a packaging fault but a regression in Qt itself. > Btw. In a similar vain of packages having a negative impact on Qt. I also > recomment uninstalling at-spi2-core which sets the environment variable to > force accessibility always on which has a big negative performance impact. Thanks for the suggestion, at least I could uninstall that one without taking a sh*load of other packages along with it... What env. variable would that be (I don't want to log off and on AGAIN just yet :)) Cheers, R. From kde at carewolf.com Mon Jun 12 10:32:17 2017 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Mon, 12 Jun 2017 10:32:17 +0200 Subject: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole) In-Reply-To: <2376691.aGJayiI6Zf@patux.local> References: <5875213.LdfPq16Ncl@bola> <2690176.ub1j3r4xDQ@twilight> <2376691.aGJayiI6Zf@patux.local> Message-ID: <3026867.tYyW34zUoY@twilight> On Montag, 12. Juni 2017 10:17:50 CEST René J. V. Bertin wrote: > Allan Sandfeld Jensen wrote: > > I am on Debian and found the same thing. Apt-get remove im-config solves > > the issue. Apparently it is a buggy package that forces Qt to use ibus > > without ensuring ibus is launched. > > That's not what I saw. Ibus was always launched at login, and im-config > seems to get some length to ensure that applications always use the "best" > method available if the user didn't configure things to use a specific > method. That's why newly launched Qt applications work fine after exiting > ibus. The loss of keyboard input in Qt5 applications is a priori not a > packaging fault but a regression in Qt itself. > > > Btw. In a similar vain of packages having a negative impact on Qt. I also > > recomment uninstalling at-spi2-core which sets the environment variable to > > force accessibility always on which has a big negative performance impact. > > Thanks for the suggestion, at least I could uninstall that one without > taking a sh*load of other packages along with it... > What env. variable would that be (I don't want to log off and on AGAIN just > yet > :)) > QT_LINUX_ACCESSIBILITY_ALWAYS_ON It forces Qt to send accessibility events with new content trees everything something changes. Though the real problem might be that Linux lacks a good way to enable accessibility interfaces at runtime. On macOS and Windows, the same performance impact is only enabled if you start using a system accessibility feature. 'Allan From rjvbertin at gmail.com Mon Jun 12 13:18:25 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Mon, 12 Jun 2017 13:18:25 +0200 Subject: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole) References: <5875213.LdfPq16Ncl@bola> <2690176.ub1j3r4xDQ@twilight> <2376691.aGJayiI6Zf@patux.local> <3026867.tYyW34zUoY@twilight> Message-ID: <7037034.gAFugcbsSJ@patux.local> Allan Sandfeld Jensen wrote: > QT_LINUX_ACCESSIBILITY_ALWAYS_ON Interesting, I have no trace of that variable, and I cannot imagine that uninstalling at-spi2-core would have unset it in all running shells. > Can you check what im_config sets the QT_IM_MODULE to when ibus is not found? That variable isn't set at all on my system. That may have to do with the fact I'm running Kubuntu 14.04 with self-built Qt5 and KF5 stuff installed into /opt/local. But QT4_IM_MODULE=xim, which fits with what I reconfigured as the default input method yesterday as well as with what I understand of im-config's "auto" setting. R. From jani.heikkinen at qt.io Mon Jun 12 13:35:35 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 12 Jun 2017 11:35:35 +0000 Subject: [Development] Qt 5.9.1 soft branching started Message-ID: Hi all, We have today started soft branching from '5.9' to '5.9.1'. That way we should be able to release Qt 5.9.1 still during June. So please use '5.9.1' for new changes targeted to Qt 5.9.1 release. We will do final downmerge from '5.9' to '5.9.1' this Friday (16.6) and after that '5.9' will be for Qt 5.9.2. And please note: We are planning to do regular patch level releases for Qt 5.9 series so no any nice-to-haves in '5.9.1', just fixes for really critical issues. All others must be done in '5.9' & can wait Qt 5.9.2 release. So '5.9.1' is just for getting Qt 5.9.1 quickly out... And at this time we really want to do Qt 5.9.1 on time meaning we won't delay the release because of issues which were already in Qt 5.9.0 release. And we will check case by case all new regressions if those could really delay the release or not: Qt 5.9.2 is planned to be released already on August. br, Jani Heikkinen Release Manager From thiago.macieira at intel.com Mon Jun 12 22:45:18 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 12 Jun 2017 13:45:18 -0700 Subject: [Development] Someone please fix the remaining qrand cases in SSL code Message-ID: <3687553.WI5rtPnQOl@tjmaciei-mobl1> I can't submit changes to SSL-related code, so can someone apply the equivalent of https://codereview.qt-project.org/191738 to the files listed in that commit's message? I cannot review your change either. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From samuel.gaist at edeltech.ch Mon Jun 12 23:40:32 2017 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Mon, 12 Jun 2017 23:40:32 +0200 Subject: [Development] Someone please fix the remaining qrand cases in SSL code In-Reply-To: <3687553.WI5rtPnQOl@tjmaciei-mobl1> References: <3687553.WI5rtPnQOl@tjmaciei-mobl1> Message-ID: > On 12 Jun 2017, at 22:45, Thiago Macieira wrote: > > I can't submit changes to SSL-related code, so can someone apply the > equivalent of https://codereview.qt-project.org/191738 to the files listed in > that commit's message? > > I cannot review your change either. > > -- > 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 Hi, AFAIK, I am not under that restriction so: https://codereview.qt-project.org/#/c/197163/ Cheers Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From prashantpurohit025 at gmail.com Tue Jun 13 06:50:47 2017 From: prashantpurohit025 at gmail.com (Prashant Purohit) Date: Tue, 13 Jun 2017 10:20:47 +0530 Subject: [Development] swapEGLBuffers() : 135 : QQNX: failed to swap EGL buffers, err=12301 on QNX with Qt-5.3.2 Message-ID: Hi All, I am using QNX with Qt-5.3.2 and found below issue and crash: FAULT - qqnxeglwindow.cpp : void QQnxEglWindow::swapEGLBuffers() : 135 : QQNX: failed to swap EGL buffers, err=12301 When I checked on internet for this issue, it was referenced that when Qnx window does not find EGL surface to paint this issue occurs but I have an EGL display surface only and not sure why this error occurs. This issue has occurred only twice on release build and I could not get the back-trace. This seems to be QNX issue as an application software with QT, we do not directly deal with swapEGLBuffers. Please let me know if anyone has faced similar issue or know how to fix this issue. Thanks, Prashant From jani.heikkinen at qt.io Tue Jun 13 12:52:49 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 13 Jun 2017 10:52:49 +0000 Subject: [Development] Qt 5.10 pre-built bunaries In-Reply-To: References: Message-ID: Hi, As a conclusion of subject: only change related to pre-built binaries for 5.10 (from Qt 5.9) is dropping 32 bit iOS. And from 5.11 -> we will drop MSVC2013 as well. There isn't conclusion about mingw yet but let's agree to switch from mingw 32 bit to 64 bit one in 5.11 -> There were also discussion about minimum GCC version but it isn't directly related to pre-built binaries and that's why it needs to be concluded in different thread br Jani From jmcdonnell at blackberry.com Tue Jun 13 15:54:41 2017 From: jmcdonnell at blackberry.com (James McDonnell) Date: Tue, 13 Jun 2017 13:54:41 +0000 Subject: [Development] swapEGLBuffers() : 135 : QQNX: failed to swap EGL buffers, err=12301 on QNX with Qt-5.3.2 In-Reply-To: References: Message-ID: Hi Prashant, Is your application performing a rapid sequence of resizing operations on the EGL window that leaves the size of the window unchanged? We recently discovered that this can cause the QNX Qt platform code to produce this problem. I haven't had a chance to upstream the fix for it yet. We also haven't updated the Qt that QNX produces (which I think is what you're using). You might be able to get around the problem if you can give the application a chance to draw between resize operations. James On 2017-06-13, 12:50 AM, "Development on behalf of Prashant Purohit" wrote: >Hi All, > >I am using QNX with Qt-5.3.2 and found below issue and crash: > >FAULT - qqnxeglwindow.cpp : void QQnxEglWindow::swapEGLBuffers() : 135 >: QQNX: failed to swap EGL buffers, err=12301 > >When I checked on internet for this issue, it was referenced that when >Qnx window does not find EGL surface to paint this issue occurs but I >have an EGL display surface only and not sure why this error occurs. > >This issue has occurred only twice on release build and I could not >get the back-trace. > >This seems to be QNX issue as an application software with QT, we do >not directly deal with swapEGLBuffers. > >Please let me know if anyone has faced similar issue or know how to >fix this issue. > >Thanks, >Prashant >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From prashantpurohit025 at gmail.com Tue Jun 13 18:49:21 2017 From: prashantpurohit025 at gmail.com (Prashant Purohit) Date: Tue, 13 Jun 2017 22:19:21 +0530 Subject: [Development] swapEGLBuffers() : 135 : QQNX: failed to swap EGL buffers, err=12301 on QNX with Qt-5.3.2 In-Reply-To: References: Message-ID: Hi James, Thanks for a quick reply. > You might be able to get around the problem if you can give the > application a chance to draw between resize operations. I am not sure how can I draw between resize operation. Also, since this issue is hardly reproducible, how will I verify the fix which I will do. Do you know anyway with which I can reproduce this issue every-time? Also when will be the QNX-QT fix will be available so that an update in QNX at my side will help me fix this issue? Thanks, Prashant On 6/13/17, James McDonnell wrote: > Hi Prashant, > > Is your application performing a rapid sequence of resizing operations on > the EGL window that leaves the size of the window unchanged? We recently > discovered that this can cause the QNX Qt platform code to produce this > problem. I haven't had a chance to upstream the fix for it yet. We also > haven't updated the Qt that QNX produces (which I think is what you're > using). > > You might be able to get around the problem if you can give the > application a chance to draw between resize operations. > > James > > On 2017-06-13, 12:50 AM, "Development on behalf of Prashant Purohit" > prashantpurohit025 at gmail.com> wrote: > >>Hi All, >> >>I am using QNX with Qt-5.3.2 and found below issue and crash: >> >>FAULT - qqnxeglwindow.cpp : void QQnxEglWindow::swapEGLBuffers() : 135 >>: QQNX: failed to swap EGL buffers, err=12301 >> >>When I checked on internet for this issue, it was referenced that when >>Qnx window does not find EGL surface to paint this issue occurs but I >>have an EGL display surface only and not sure why this error occurs. >> >>This issue has occurred only twice on release build and I could not >>get the back-trace. >> >>This seems to be QNX issue as an application software with QT, we do >>not directly deal with swapEGLBuffers. >> >>Please let me know if anyone has faced similar issue or know how to >>fix this issue. >> >>Thanks, >>Prashant >>_______________________________________________ >>Development mailing list >>Development at qt-project.org >>http://lists.qt-project.org/mailman/listinfo/development > > From jmcdonnell at blackberry.com Tue Jun 13 19:28:49 2017 From: jmcdonnell at blackberry.com (James McDonnell) Date: Tue, 13 Jun 2017 17:28:49 +0000 Subject: [Development] swapEGLBuffers() : 135 : QQNX: failed to swap EGL buffers, err=12301 on QNX with Qt-5.3.2 In-Reply-To: References: Message-ID: On 2017-06-13, 12:49 PM, "Prashant Purohit" wrote: >Hi James, > >Thanks for a quick reply. > >> You might be able to get around the problem if you can give the >> application a chance to draw between resize operations. > >I am not sure how can I draw between resize operation. I'm not sure off-hand either. Another possibility is avoiding such resizing. >Also, since this issue is hardly reproducible, how will I verify the >fix which I will do. You'd have to create a situation where it's more likely to occur. I figured out what it was with a test application that flipped back and forth between two sizes in response to a menu item. > >Do you know anyway with which I can reproduce this issue every-time? Assuming that this is actually the problem, every time would require freezing the rendering thread, resizing away from the current size, resizing back and unfreezing the rendering thread. Might be possible with pthread_suspend/resume. >Also when will be the QNX-QT fix will be available so that an update >in QNX at my side will help me fix this issue? I don't know when (if ever) we'll update the QNX-Qt 5.3.1. :-( > >Thanks, >Prashant > >On 6/13/17, James McDonnell wrote: >> Hi Prashant, >> >> Is your application performing a rapid sequence of resizing operations >>on >> the EGL window that leaves the size of the window unchanged? We >>recently >> discovered that this can cause the QNX Qt platform code to produce this >> problem. I haven't had a chance to upstream the fix for it yet. We >>also >> haven't updated the Qt that QNX produces (which I think is what you're >> using). >> >> You might be able to get around the problem if you can give the >> application a chance to draw between resize operations. >> >> James >> >> On 2017-06-13, 12:50 AM, "Development on behalf of Prashant Purohit" >> >of >> prashantpurohit025 at gmail.com> wrote: >> >>>Hi All, >>> >>>I am using QNX with Qt-5.3.2 and found below issue and crash: >>> >>>FAULT - qqnxeglwindow.cpp : void QQnxEglWindow::swapEGLBuffers() : 135 >>>: QQNX: failed to swap EGL buffers, err=12301 >>> >>>When I checked on internet for this issue, it was referenced that when >>>Qnx window does not find EGL surface to paint this issue occurs but I >>>have an EGL display surface only and not sure why this error occurs. >>> >>>This issue has occurred only twice on release build and I could not >>>get the back-trace. >>> >>>This seems to be QNX issue as an application software with QT, we do >>>not directly deal with swapEGLBuffers. >>> >>>Please let me know if anyone has faced similar issue or know how to >>>fix this issue. >>> >>>Thanks, >>>Prashant >>>_______________________________________________ >>>Development mailing list >>>Development at qt-project.org >>>http://lists.qt-project.org/mailman/listinfo/development >> >> From thiago.macieira at intel.com Tue Jun 13 21:52:34 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 13 Jun 2017 12:52:34 -0700 Subject: [Development] What to do with qrand/qsrand? Message-ID: <12930828.ulrMT707PK@tjmaciei-mobl1> I've changed almost all uses of qrand in Qt sources to QRandomGenerator and eliminated the use of qsrand. That is actually the biggest advantage: not needing to seed the generator. I was quite surprised how much use of qrand we have in our own source code, and not just in examples. (See commits with Change-Id Icd0e0d4b27cb4e5eb892fffd14b5285d43f4afbf). Obviously those functions need to remain in Qt 5, but what should we do to them long-term? See https://lxr.kde.org/ident?_i=qrand&_remember=1 With this many references, I'm not sure we should even add a QT_DEPRECATED warning to it, since that would make trigger-happy "warning--" developers in KDE wholesale moving to something else. Options: 1) do nothing, leave as-is (in Qt 6, use thread_local) 2) deprecate and provide no replacement. That is, tell people to either: - use QRandomGenerator if they need true random, non-bulk - use engines if they need bulk - use rand() if they need C library compatibility 3) deprecate and provide a thread-safe PRNG, which can be used in bulk a) with no seed; or b) with an access to seeding 4) same as #3, but actually use the qrand/qsrand names for (a), qsrand would be empty -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From olivier at woboq.com Wed Jun 14 07:34:52 2017 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 14 Jun 2017 07:34:52 +0200 Subject: [Development] What to do with qrand/qsrand? In-Reply-To: <12930828.ulrMT707PK@tjmaciei-mobl1> References: <12930828.ulrMT707PK@tjmaciei-mobl1> Message-ID: <3040930.Xi51pP6NvA@maurice> Am Dienstag, 13. Juni 2017, 21:52:34 CEST schrieb Thiago Macieira: > I've changed almost all uses of qrand in Qt sources to QRandomGenerator and > eliminated the use of qsrand. That is actually the biggest advantage: not > needing to seed the generator. I was quite surprised how much use of qrand > we have in our own source code, and not just in examples. (See commits with > Change-Id Icd0e0d4b27cb4e5eb892fffd14b5285d43f4afbf). > > Obviously those functions need to remain in Qt 5, but what should we do to > them long-term? See > https://lxr.kde.org/ident?_i=qrand&_remember=1 > > With this many references, I'm not sure we should even add a QT_DEPRECATED > warning to it, since that would make trigger-happy "warning--" developers in > KDE wholesale moving to something else. Can you elaborate? Why would that be a bad thing? > Options: > 1) do nothing, leave as-is (in Qt 6, use thread_local) > > 2) deprecate and provide no replacement. That is, tell people to either: > - use QRandomGenerator if they need true random, non-bulk > - use engines if they need bulk > - use rand() if they need C library compatibility > > 3) deprecate and provide a thread-safe PRNG, which can be used in bulk > a) with no seed; or > b) with an access to seeding > > 4) same as #3, but actually use the qrand/qsrand names > for (a), qsrand would be empty From thiago.macieira at intel.com Wed Jun 14 07:50:33 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 13 Jun 2017 22:50:33 -0700 Subject: [Development] What to do with qrand/qsrand? In-Reply-To: <3040930.Xi51pP6NvA@maurice> References: <12930828.ulrMT707PK@tjmaciei-mobl1> <3040930.Xi51pP6NvA@maurice> Message-ID: <1765562.QydEQYR9xG@tjmaciei-mobl1> On terça-feira, 13 de junho de 2017 22:34:52 PDT Olivier Goffart wrote: > > With this many references, I'm not sure we should even add a QT_DEPRECATED > > warning to it, since that would make trigger-happy "warning--" developers > > in KDE wholesale moving to something else. > > Can you elaborate? Why would that be a bad thing? Because I've seen this type of commit, going way back to the Qt 4 porting days. Instead of taking the time to port, as time goes by, as code is refactored, with patience and testing, we'll have a rush of "warning--" commits that just change the code to use something different without understanding what it does. For example, as QRandomGenerator's documentation says, it should not be used for bulk data. But I fear people will use it for that. > > Options: > > 1) do nothing, leave as-is (in Qt 6, use thread_local) At this point, and after talking to Lars, I'm thinking of just leaving it alone. So option (1). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Wed Jun 14 08:00:40 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 14 Jun 2017 06:00:40 +0000 Subject: [Development] First Qt 5.9.1 snapshot available In-Reply-To: References: Message-ID: Hi all, We have first Qt 5.9.1 snapshot available via online installer. It is a separate 5.9.1 node, not as an update to Qt 5.9.0. Instructions how to install it here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer Content of the snapshot is based on https://codereview.qt-project.org/#/c/196614/, delta to Qt 5.9.0 as an attachment. RTA testing is ongoing and snapshot seems to be pretty much OK. So please test the snapshot & report your effort via https://wiki.qt.io/Qt59_release_testing And please note: We will do regular patch releases for 5.9 series and so on we won't block the release because of old issues. Qt 5.9.1 is released on June and 5.9.2 is targeted to be released on August so if there is still bad issues open in 5.9.1 there is time to fix those for soon coming Qt 5.9.2 (or even Qt 5.9.3 which should be out ~September...) br, Jani -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: qt5.9.1-delta.txt URL: From harald.vistnes at gmail.com Wed Jun 14 11:49:00 2017 From: harald.vistnes at gmail.com (Harald Vistnes) Date: Wed, 14 Jun 2017 11:49:00 +0200 Subject: [Development] Problems building qtwebkit in 5.9.1 Message-ID: Hi, Has there been a change in the dependencies for qtwebkit in 5.9.1? I am not able to build it anymore. I am using these commands: ... perl init-repository --module-subset=all,-ignore,-qtwebkit-examples,-qtwebengine,-qtnetworkauth,-qtspeech,-qtandroidextras,-qtvirtualkeyboard,-qtcanvas3d,-qtdatavis3d,-qtcharts,-qtpurchasing,-qtquickcontrols2,-qtmultimedia,-qtserialport,-qtwayland,-qtdoc configure -prefix %CD%\qtbase -opensource -shared -confirm-license -debug-and-release -release -opengl desktop -qt-zlib -qt-libpng -no-angle -qt-libjpeg -icu -skip qtconnectivity -skip qtlocation -skip qtsensors -skip qtwayland -skip qtserialbus -skip qtserialport -skip qtvirtualkeyboard -skip qtdatavis3d -skip qtcharts -skip qtpurchasing -skip qtcanvas3d -skip qtspeech -skip qtandroidextras -skip qtnetworkauth -skip qtquickcontrols -skip qtwebengine -platform win32-msvc2015 -nomake tests cd qtwebkit ../qtbase/bin/qmake.exe WebKit.pro In 5.9.1 I get the following output from qmake: Running configure tests... Checking for fontconfig... no Checking for gccdepends... no Checking for glx... no Checking for gnuld... no Checking for icu... yes Checking for leveldb... no Checking for libsqlite3... no Checking for libwebp... no Checking for libXcomposite... no Checking for libxml2... no Checking for libXrender... no Checking for libxslt... no Checking for libzlib... no Project ERROR: Could not find feature system-jpeg. I did not get this error in 5.9.0 or in any previous versions. I am on Windows, but a colleague got the same error on Linux. He also tried to configure with -system-jpeg, but with the same result. Thanks, Harald -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederik.gladhorn at qt.io Wed Jun 14 13:18:35 2017 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Wed, 14 Jun 2017 13:18:35 +0200 Subject: [Development] Examples and Demos in qtdoc Message-ID: <2011814.yAGkPeLK5y@frederik-thinkcentre-m93p> Hi all, We recently had a discussion in the Qt Company about how we can improve the first use experience of Qt and one important aspect are the examples and demos. We have a lot of examples that are limited by the Qt module they live in, for example not making use of ready made buttons in Qt Quick. To allow examples to use any Qt module while keeping the build system clean (no cyclic dependencies between modules), I'd like to propose using the qtdoc module to gather fresh and beautiful examples. We currently have a few bigger examples already that would fit this category and plan to invest more into good looking nice and welcoming examples to give new Qt users a positive first impression. Of course we could create a new repo, but considering that we have an existing repo which did contain the demo launcher previously and which is ready to be used, I'd propse going with it, while the name is not perfect. It's already part of the infrastructure and qt5.git, so this seems like an easy way to go forward. Cheers, Frederik From sean.harmer at kdab.com Wed Jun 14 14:15:22 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Wed, 14 Jun 2017 13:15:22 +0100 Subject: [Development] Examples and Demos in qtdoc In-Reply-To: <2011814.yAGkPeLK5y@frederik-thinkcentre-m93p> References: <2011814.yAGkPeLK5y@frederik-thinkcentre-m93p> Message-ID: <1762291.Xer14TdUsM@cartman> Hi, On Wednesday 14 June 2017 13:18:35 Frederik Gladhorn wrote: > Hi all, > > We recently had a discussion in the Qt Company about how we can improve the > first use experience of Qt and one important aspect are the examples and > demos. > > We have a lot of examples that are limited by the Qt module they live in, > for example not making use of ready made buttons in Qt Quick. To allow > examples to use any Qt module while keeping the build system clean (no > cyclic dependencies between modules), I'd like to propose using the qtdoc > module to gather fresh and beautiful examples. > > We currently have a few bigger examples already that would fit this category > and plan to invest more into good looking nice and welcoming examples to > give new Qt users a positive first impression. > > Of course we could create a new repo, but considering that we have an > existing repo which did contain the demo launcher previously and which is > ready to be used, I'd propse going with it, while the name is not perfect. > It's already part of the infrastructure and qt5.git, so this seems like an > easy way to go forward. I agree that we need something like this. Ideally we also need support for git-lfs or some other mechanism for handling large files. Particularly for Qt 3D, getting "nice looking" results often requires HDR textures for environment maps and often other texture inputs too. 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 pasi.keranen at qt.io Wed Jun 14 14:59:25 2017 From: pasi.keranen at qt.io (=?utf-8?B?UGFzaSBLZXLDpG5lbg==?=) Date: Wed, 14 Jun 2017 12:59:25 +0000 Subject: [Development] Examples and Demos in qtdoc In-Reply-To: <1762291.Xer14TdUsM@cartman> References: <2011814.yAGkPeLK5y@frederik-thinkcentre-m93p> <1762291.Xer14TdUsM@cartman> Message-ID: <716D3B51-BEDE-4C7C-8CA3-368764908B91@qt.io> Hi, I agree 100% with the need to have a place to store beautiful demos and examples. And I agree with Sean’s large file support need as Qt 3D Studio examples and demos will also depend on having access to large textures and hdr textures to make things look nice. Even 2D examples can require “large” resources when you are striving to create beautiful results. I’m not 100% sure about qtdoc as the repo though. But I can live with it if that is what is seen as best option by others. Cheers, Pasi -- Pasi Keränen Senior Manager The Qt Company Elektroniikkatie 13 90590, Oulu, Finland On 14/06/2017, 15.15, "Development on behalf of Sean Harmer" wrote: Hi, On Wednesday 14 June 2017 13:18:35 Frederik Gladhorn wrote: > Hi all, > > We recently had a discussion in the Qt Company about how we can improve the > first use experience of Qt and one important aspect are the examples and > demos. > > We have a lot of examples that are limited by the Qt module they live in, > for example not making use of ready made buttons in Qt Quick. To allow > examples to use any Qt module while keeping the build system clean (no > cyclic dependencies between modules), I'd like to propose using the qtdoc > module to gather fresh and beautiful examples. > > We currently have a few bigger examples already that would fit this category > and plan to invest more into good looking nice and welcoming examples to > give new Qt users a positive first impression. > > Of course we could create a new repo, but considering that we have an > existing repo which did contain the demo launcher previously and which is > ready to be used, I'd propse going with it, while the name is not perfect. > It's already part of the infrastructure and qt5.git, so this seems like an > easy way to go forward. I agree that we need something like this. Ideally we also need support for git-lfs or some other mechanism for handling large files. Particularly for Qt 3D, getting "nice looking" results often requires HDR textures for environment maps and often other texture inputs too. 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 annulen at yandex.ru Wed Jun 14 15:30:36 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 14 Jun 2017 16:30:36 +0300 Subject: [Development] Problems building qtwebkit in 5.9.1 In-Reply-To: References: Message-ID: <559511497447036@web35j.yandex.ru> 14.06.2017, 12:49, "Harald Vistnes" : > Hi, > > Has there been a change in the dependencies for qtwebkit in 5.9.1? I am not able to build it anymore. > > I am using these commands: > > ... > perl init-repository --module-subset=all,-ignore,-qtwebkit-examples,-qtwebengine,-qtnetworkauth,-qtspeech,-qtandroidextras,-qtvirtualkeyboard,-qtcanvas3d,-qtdatavis3d,-qtcharts,-qtpurchasing,-qtquickcontrols2,-qtmultimedia,-qtserialport,-qtwayland,-qtdoc > > configure -prefix %CD%\qtbase -opensource -shared -confirm-license -debug-and-release -release -opengl desktop -qt-zlib -qt-libpng -no-angle -qt-libjpeg -icu -skip qtconnectivity -skip qtlocation -skip qtsensors -skip qtwayland -skip qtserialbus -skip qtserialport -skip qtvirtualkeyboard -skip qtdatavis3d -skip qtcharts -skip qtpurchasing -skip qtcanvas3d -skip qtspeech -skip qtandroidextras -skip qtnetworkauth -skip qtquickcontrols -skip qtwebengine -platform win32-msvc2015 -nomake tests > > cd qtwebkit > > ../qtbase/bin/qmake.exe WebKit.pro > > In 5.9.1 I get the following output from qmake: > > Running configure tests... > > Checking for fontconfig... no > Checking for gccdepends... no > Checking for glx... no > Checking for gnuld... no > Checking for icu... yes > Checking for leveldb... no > Checking for libsqlite3... no > Checking for libwebp... no > Checking for libXcomposite... no > Checking for libxml2... no > Checking for libXrender... no > Checking for libxslt... no > Checking for libzlib... no > Project ERROR: Could not find feature system-jpeg. > > I did not get this error in 5.9.0 or in any previous versions. You should use 5.212 branch of QtWebKit instead of 5.9.1. Build instruction: https://github.com/annulen/webkit/wiki/Building-QtWebKit-on-Windows > > I am on Windows, but a colleague got the same error on Linux. He also tried to configure with -system-jpeg, but with the same result. > > Thanks, > Harald > > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development --  Regards, Konstantin From perezmeyer at gmail.com Wed Jun 14 16:56:21 2017 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Wed, 14 Jun 2017 11:56:21 -0300 Subject: [Development] New configuration system docs and FBX issues In-Reply-To: References: <1716189.cOT8g0p9p3@tjmaciei-mobl1> Message-ID: <15766816.M6QSYTCOGU@tonks> On martes, 2 de mayo de 2017 08:47:34 -03 Sean Harmer wrote: > Hi, > > On 01/05/2017 14:16, Thiago Macieira wrote: > > On Monday, 1 May 2017 03:17:23 -03 Sean Harmer wrote: > >> Hi, > >> > >> is there any documentation for the new configuration system please? > >> > >> My specific issue is that I need a config test that uses different > >> library names on each platform and I can't see how to achieve this. On > >> windows I want the FBX config test in Qt 3D to link against the static > >> FBX library libfbxsdk-md.lib whereas on linux it would be > >> libfbxsdk-static.a and on macOS libfbxsdk.a. > > > > Please make sure we're abe to link against the dynamic version of that > > library on Linux. > > Why the preference for dynamic linking here? It's another file to have > to distribute? I don't particularly mind either way but is there a > policy for such things? Possibly because it makes it easier for distributions to create patches to link against the system version. -- 20:57 * m4rgin4l patento el proceso de invencion 20:57 < m4rgin4l> de aqui en mas cualquier inventor me tiene que pagar regalias por inventar algo 20:57 * m4rgin4l tiene la patente pendiente del metodo cientifico 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 giuseppe.dangelo at kdab.com Wed Jun 14 17:25:31 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Wed, 14 Jun 2017 17:25:31 +0200 Subject: [Development] Someone please fix the remaining qrand cases in SSL code In-Reply-To: <3687553.WI5rtPnQOl@tjmaciei-mobl1> References: <3687553.WI5rtPnQOl@tjmaciei-mobl1> Message-ID: <9735d2f9-859f-2f7b-d7c3-153580c56310@kdab.com> Il 12/06/2017 22:45, Thiago Macieira ha scritto: > I can't submit changes to SSL-related code, so can someone apply the > equivalent ofhttps://codereview.qt-project.org/191738 to the files listed in > that commit's message? There are a couple of problems arising from there: 1) some place has a "TODO: use a CSPRNG". Given the current QRandomGenerator API, is there a way to know if a CSPRNG is actually being used or we're falling back to a plain PRNG? 2) a test wants to generate a few MB of random data. Ideally this would be a no-brainer -- QRandomGenerator plus an engine from the standard library, but we can't use those engines yet (or can we?). So those places will need to keep qrand()? 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 jhihn at gmx.com Wed Jun 14 17:26:50 2017 From: jhihn at gmx.com (Jason H) Date: Wed, 14 Jun 2017 17:26:50 +0200 Subject: [Development] What to do with qrand/qsrand? In-Reply-To: <12930828.ulrMT707PK@tjmaciei-mobl1> References: <12930828.ulrMT707PK@tjmaciei-mobl1> Message-ID: Given the number of softwares that are compromised by bad random number generation practices, I'd suggest we invert the normal behavior - random by default. If they need predictability then make them seed with a constant seed. For a more detailed talk on secure random: https://www.youtube.com/watch?v=n_xiOYvr6oY > Sent: Tuesday, June 13, 2017 at 3:52 PM > From: "Thiago Macieira" > To: development at qt-project.org > Subject: [Development] What to do with qrand/qsrand? > > I've changed almost all uses of qrand in Qt sources to QRandomGenerator and > eliminated the use of qsrand. That is actually the biggest advantage: not > needing to seed the generator. I was quite surprised how much use of qrand we > have in our own source code, and not just in examples. (See commits with > Change-Id Icd0e0d4b27cb4e5eb892fffd14b5285d43f4afbf). > > Obviously those functions need to remain in Qt 5, but what should we do to > them long-term? See > https://lxr.kde.org/ident?_i=qrand&_remember=1 > > With this many references, I'm not sure we should even add a QT_DEPRECATED > warning to it, since that would make trigger-happy "warning--" developers in > KDE wholesale moving to something else. > > Options: > 1) do nothing, leave as-is (in Qt 6, use thread_local) > > 2) deprecate and provide no replacement. That is, tell people to either: > - use QRandomGenerator if they need true random, non-bulk > - use engines if they need bulk > - use rand() if they need C library compatibility > > 3) deprecate and provide a thread-safe PRNG, which can be used in bulk > a) with no seed; or > b) with an access to seeding > > 4) same as #3, but actually use the qrand/qsrand names > for (a), qsrand would be empty > > -- > 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 Jun 14 17:45:01 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 14 Jun 2017 08:45:01 -0700 Subject: [Development] What to do with qrand/qsrand? In-Reply-To: References: <12930828.ulrMT707PK@tjmaciei-mobl1> Message-ID: <4629904.mVDHE3p6co@tjmaciei-mobl1> On quarta-feira, 14 de junho de 2017 08:26:50 PDT Jason H wrote: > Given the number of softwares that are compromised by bad random number > generation practices, I'd suggest we invert the normal behavior - random by > default. If they need predictability then make them seed with a constant > seed. That is why I added QRandomGenerator, which has a (reasonably) secure default behaviour. But it will degrade if you abuse it. The question though is what to do with qrand. Code using it is not secure at all, so does it matter if we change it? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From szehowe.koh at gmail.com Wed Jun 14 17:54:23 2017 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Wed, 14 Jun 2017 23:54:23 +0800 Subject: [Development] Examples and Demos in qtdoc In-Reply-To: <2011814.yAGkPeLK5y@frederik-thinkcentre-m93p> References: <2011814.yAGkPeLK5y@frederik-thinkcentre-m93p> Message-ID: On 14 June 2017 at 19:18, Frederik Gladhorn wrote: > > Hi all, > > We recently had a discussion in the Qt Company about how we can improve the > first use experience of Qt and one important aspect are the examples and demos. +1 > We have a lot of examples that are limited by the Qt module they live in, for > example not making use of ready made buttons in Qt Quick. To allow examples to > use any Qt module while keeping the build system clean (no cyclic dependencies > between modules), I'd like to propose using the qtdoc module to gather fresh > and beautiful examples. > > We currently have a few bigger examples already that would fit this category > and plan to invest more into good looking nice and welcoming examples to give > new Qt users a positive first impression. Fresh and beautiful is good. Does this initiative also involve cleaning up existing examples (including removing them, where appropriate)? For example, the old rendering at http://doc.qt.io/qt-5/qtquick-scenegraph-textureinsgnode-example.html would detract from the nice and welcoming bits on display. One reason to avoid a large-scale cleanup, though, is to avoid link rot. > Of course we could create a new repo, but considering that we have an existing > repo which did contain the demo launcher previously and which is ready to be > used, I'd propse going with it, while the name is not perfect. It's already > part of the infrastructure and qt5.git, so this seems like an easy way to go > forward. qtdoc.git currently houses a number of non-flashy but nonetheless important examples and documents (e.g. signals and slots, platform notes). Would it be better to keep a separate repo for wowing newcomers (say, "qtshowcase.git")? Especially since there will be many large files involved, as Sean mentioned. Regards, Sze-Howe From thiago.macieira at intel.com Wed Jun 14 17:56:37 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 14 Jun 2017 08:56:37 -0700 Subject: [Development] Someone please fix the remaining qrand cases in SSL code In-Reply-To: <9735d2f9-859f-2f7b-d7c3-153580c56310@kdab.com> References: <3687553.WI5rtPnQOl@tjmaciei-mobl1> <9735d2f9-859f-2f7b-d7c3-153580c56310@kdab.com> Message-ID: <5370406.SKJbgrsMXo@tjmaciei-mobl1> On quarta-feira, 14 de junho de 2017 08:25:31 PDT Giuseppe D'Angelo wrote: > Il 12/06/2017 22:45, Thiago Macieira ha scritto: > > I can't submit changes to SSL-related code, so can someone apply the > > equivalent ofhttps://codereview.qt-project.org/191738 to the files listed > > in that commit's message? > > There are a couple of problems arising from there: > > 1) some place has a "TODO: use a CSPRNG". Given the current > QRandomGenerator API, is there a way to know if a CSPRNG is actually > being used or we're falling back to a plain PRNG? It's not in the API, but in all non-misconfigured systems, it should be CSPRNG. You can misconfigure your system by running your Qt application in a chroot that doesn't have /dev/random or /dev/urandom. There's also the issue of the system and CPU entropy pools. This could be an issue if the application uses QRandomGenerator in the first few hundred ms after boot. That can only affect device manufacturers and they should inspect their systems to know if that is happening. At least on Linux, once seeded, /dev/urandom does not stop working, so if we opened it (no bad chroot) and it has worked (system collected some entropy), the fallback should never kick in. Yes, that means the Mersenne Twister fallback is actually dead code on Linux. But this means that QRandomGenerator is good for unattended CSPRNG uses, such as networking code. For key generation, I'd use /dev/random and require the user to move the mouse. > 2) a test wants to generate a few MB of random data. Ideally this would > be a no-brainer -- QRandomGenerator plus an engine from the standard > library, but we can't use those engines yet (or can we?). So those > places will need to keep qrand()? #if QT_CONFIG(cxx11_random), after https://codereview.qt-project.org/196612 integrates. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tuukka.turunen at qt.io Wed Jun 14 19:29:54 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Wed, 14 Jun 2017 17:29:54 +0000 Subject: [Development] Examples and Demos in qtdoc In-Reply-To: References: <2011814.yAGkPeLK5y@frederik-thinkcentre-m93p> Message-ID: Hi, Yes, we would like to overall improve the examples. This is related to having a new repo for examples, but not fully the same thing. Main goal in example improvement being to make them more useful in what they are: examples of how to use Qt. Currently there are some examples that implement their own rudimentary controls instead of using Qt Quick Controls 2. We also have some examples that do not properly leverage our tooling. Some examples might not show the very best way to do things, as the new APIs allow even better way than at the time of creating the example. What comes to WOW, we do need to have great looking demos and at least some examples should look good as well. However, that WOW should not be the ultimate goal. The purpose of examples is to help users make better use of Qt and sometimes making things too shiny can be counterproductive. Another thing is that this WOW is a quite subjective matter and different trends come and go. It is fine to make an example look great, but that should not be the sole purpose. Yours, Tuukka On 14/06/2017, 18.54, "Development on behalf of Sze Howe Koh" wrote: On 14 June 2017 at 19:18, Frederik Gladhorn wrote: > > Hi all, > > We recently had a discussion in the Qt Company about how we can improve the > first use experience of Qt and one important aspect are the examples and demos. +1 > We have a lot of examples that are limited by the Qt module they live in, for > example not making use of ready made buttons in Qt Quick. To allow examples to > use any Qt module while keeping the build system clean (no cyclic dependencies > between modules), I'd like to propose using the qtdoc module to gather fresh > and beautiful examples. > > We currently have a few bigger examples already that would fit this category > and plan to invest more into good looking nice and welcoming examples to give > new Qt users a positive first impression. Fresh and beautiful is good. Does this initiative also involve cleaning up existing examples (including removing them, where appropriate)? For example, the old rendering at http://doc.qt.io/qt-5/qtquick-scenegraph-textureinsgnode-example.html would detract from the nice and welcoming bits on display. One reason to avoid a large-scale cleanup, though, is to avoid link rot. > Of course we could create a new repo, but considering that we have an existing > repo which did contain the demo launcher previously and which is ready to be > used, I'd propse going with it, while the name is not perfect. It's already > part of the infrastructure and qt5.git, so this seems like an easy way to go > forward. qtdoc.git currently houses a number of non-flashy but nonetheless important examples and documents (e.g. signals and slots, platform notes). Would it be better to keep a separate repo for wowing newcomers (say, "qtshowcase.git")? Especially since there will be many large files involved, as Sean mentioned. Regards, Sze-Howe _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From joerg.bornemann at qt.io Thu Jun 15 09:53:31 2017 From: joerg.bornemann at qt.io (Joerg Bornemann) Date: Thu, 15 Jun 2017 09:53:31 +0200 Subject: [Development] Examples and Demos in qtdoc In-Reply-To: <716D3B51-BEDE-4C7C-8CA3-368764908B91@qt.io> References: <2011814.yAGkPeLK5y@frederik-thinkcentre-m93p> <1762291.Xer14TdUsM@cartman> <716D3B51-BEDE-4C7C-8CA3-368764908B91@qt.io> Message-ID: On 14/06/2017 14:59, Pasi Keränen wrote: > I’m not 100% sure about qtdoc as the repo though. But I can live with it if that is what is seen as best option by others. There are two kinds of examples: 1. Simple examples demonstrating the use of a certain technique. Those usually come with detailed source code documentation. 2. Complex examples demonstrating much of the bling that's possible. Those are not source-documented, because writing the docs would be too laborious, and who would want to read them anyway. I believe that examples of category 1 should live in the qdoc repository / in their respective module repository. Examples of category 2 deserve a separate space. The "bigger examples" from Frederik's original mail are category 2. In Qt4 those were called "demos". There could be a "qtdemos" repo with git-lfs. In qtwebengine there's this question bobbing up every once in a while what to do with the demobrowser example. As an example, it actually needs source documentation. But it's too big. There are voices that want to remove it. Instead it could live on in such a qtdemos repo. Cheers, Joerg From mitch.curtis at qt.io Thu Jun 15 15:23:11 2017 From: mitch.curtis at qt.io (Mitch Curtis) Date: Thu, 15 Jun 2017 13:23:11 +0000 Subject: [Development] Examples and Demos in qtdoc In-Reply-To: References: <2011814.yAGkPeLK5y@frederik-thinkcentre-m93p> <1762291.Xer14TdUsM@cartman> <716D3B51-BEDE-4C7C-8CA3-368764908B91@qt.io> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt- > project.org] On Behalf Of Joerg Bornemann > Sent: Thursday, 15 June 2017 9:54 AM > To: Pasi Keränen ; development at qt-project.org > Subject: Re: [Development] Examples and Demos in qtdoc > > On 14/06/2017 14:59, Pasi Keränen wrote: > > > I’m not 100% sure about qtdoc as the repo though. But I can live with it if > that is what is seen as best option by others. > > There are two kinds of examples: > 1. Simple examples demonstrating the use of a certain technique. > Those usually come with detailed source code documentation. > 2. Complex examples demonstrating much of the bling that's possible. > Those are not source-documented, because writing the docs would be > too laborious, and who would want to read them anyway. > > I believe that examples of category 1 should live in the qdoc repository / in > their respective module repository. Examples of category 2 deserve a > separate space. > > The "bigger examples" from Frederik's original mail are category 2. In > Qt4 those were called "demos". There could be a "qtdemos" repo with git- > lfs. > > In qtwebengine there's this question bobbing up every once in a while what > to do with the demobrowser example. As an example, it actually needs > source documentation. But it's too big. There are voices that want to remove > it. Instead it could live on in such a qtdemos repo. +1 > > Cheers, > > Joerg > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Fri Jun 16 01:07:03 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 15 Jun 2017 16:07:03 -0700 Subject: [Development] Let's please drop MSVC 2013 for 5.10 Message-ID: <1689164.Dtr7ddWLJc@tjmaciei-mobl1> We have not one, not two, but THREE integration failures TODAY alone caused by that compiler failing to meet what we've come to expect from C++11. This is going to happen again and again. So I'm pleading again: can we drop it? What are the download numbers for 5.9.0? Issue 1 (12:19 GMT): https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1497525737 FAIL! : tst_QRandomGenerator::stdGenerateCanonical(default) '[] { QRandomGenerator rd; qreal value = std::generate_canonical(rd); return value > 0 && value < 1 && value != RandomValueFP; }()' returned FALSE. (1st try) Turns out that std::generate_canonical with MSVC 2013's Standard Library NEVER generates a correct value. The function is specified to return a number in the range [0,1), but the implementation always returns a number >= 1. Issue 2 (19:47 GMT): https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1497552138 FAIL! : tst_QLocale::formattedDataSize(Russian-IEC-0) Compared values are not the same Actual (QLocale(language).formattedDataSize(bytes, decimalPlaces, units)): "0 \u0431\u0430\u0439\u0442\u044B" Expected (output) : "0 ?????" The source code had "0 \u0431...", but with MSVC 2013 (and 2015 until Update 2), the Unicode codepoint U+0431 is attempted to be converted to the execution character set. Without the /utf-8 option added in MSVC 2015 Update 2, the conversion fails and the compiler prints: warning C4566: character represented by universal-character-name '\u0431' cannot be represented in the current code page (1252) [ok, not a C++11 issue per se, but we still want to use Unicode source code] Issue 3 (21:18 GMT): https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1497560567 C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\xutility(371) : error C2825: '_Iter': must be a class or namespace when followed by '::' text\qfontsubset.cpp(200) : see reference to class template instantiation 'std::iterator_traits' being compiled Source: QVector reverseMap(0x10000, 0); Both elements are int, so they seem to match the constructor being added in https://codereview.qt-project.org/151324: template = true> QVector(InputIterator f, InputIterator l); But it shouldn't because of that SFINAE exclusion. The compiler failed (expression SFINAE?). I know the first two can be worked around: 1) QSKIP MSVC 2013 2) rewrite with UTF-8 byte escape sequences ("\xd0\xb1") But I repeat: these problems are going to turn up again and again. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From iamsergio at gmail.com Fri Jun 16 01:27:09 2017 From: iamsergio at gmail.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Fri, 16 Jun 2017 00:27:09 +0100 Subject: [Development] Qt 5.10 pre-built bunaries In-Reply-To: References: Message-ID: On Tue, Jun 13, 2017 at 11:52 AM, Jani Heikkinen wrote: > Hi, > > As a conclusion of subject: > > only change related to pre-built binaries for 5.10 (from Qt 5.9) is dropping 32 bit iOS. > And from 5.11 -> we will drop MSVC2013 as well. Hi Jani, >From what I read in this thread I don't see that conclusion re 2013, in fact there seems to be more people and arguments in favor of removing it. Regards, Sergio Martins From Shawn.Rutledge at qt.io Fri Jun 16 01:38:25 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Thu, 15 Jun 2017 23:38:25 +0000 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: <1689164.Dtr7ddWLJc@tjmaciei-mobl1> References: <1689164.Dtr7ddWLJc@tjmaciei-mobl1> Message-ID: <5E6935E2-CEFA-4685-91D4-8FC6117676F6@qt.io> > On 15 Jun 2017, at 16:07, Thiago Macieira wrote: > > We have not one, not two, but THREE integration failures TODAY alone caused by > that compiler failing to meet what we've come to expect from C++11. This is > going to happen again and again. > > So I'm pleading again: can we drop it? What are the download numbers for > 5.9.0? +1 from me From lars.knoll at qt.io Fri Jun 16 08:16:30 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 16 Jun 2017 06:16:30 +0000 Subject: [Development] Qt 5.10 pre-built bunaries In-Reply-To: References: Message-ID: <1E4EBEB3-FAB8-41D9-A412-8DF46BE027A9@qt.io> > On 16 Jun 2017, at 01:27, Sérgio Martins wrote: > > On Tue, Jun 13, 2017 at 11:52 AM, Jani Heikkinen wrote: >> Hi, >> >> As a conclusion of subject: >> >> only change related to pre-built binaries for 5.10 (from Qt 5.9) is dropping 32 bit iOS. >> And from 5.11 -> we will drop MSVC2013 as well. > > Hi Jani, > > > From what I read in this thread I don't see that conclusion re 2013, > in fact there seems to be more people and arguments in favor of > removing it. We’re one month away from the feature freeze, and in July half of the developers are on vacation. So there’s relatively little benefit from dropping 2013 now, as dev currently works with it. So I’m with Jani here, and think that dropping it from the dev branch in a month from now, when we branch 5.10 makes most sense. Cheers, Lars From thiago.macieira at intel.com Fri Jun 16 08:36:57 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 15 Jun 2017 23:36:57 -0700 Subject: [Development] [Releasing] Qt 5.10 pre-built bunaries In-Reply-To: <1E4EBEB3-FAB8-41D9-A412-8DF46BE027A9@qt.io> References: <1E4EBEB3-FAB8-41D9-A412-8DF46BE027A9@qt.io> Message-ID: <78847837.tdR9O3rfJY@tjmaciei-mobl1> On Thursday, 15 June 2017 23:16:30 PDT Lars Knoll wrote: > We’re one month away from the feature freeze, and in July half of the > developers are on vacation. So there’s relatively little benefit from > dropping 2013 now, as dev currently works with it. The difference is whether we have to put up with MSVC 2013 and find workarounds for half a month or for 7 months. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lars.knoll at qt.io Fri Jun 16 08:43:40 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 16 Jun 2017 06:43:40 +0000 Subject: [Development] [Releasing] Qt 5.10 pre-built bunaries In-Reply-To: <78847837.tdR9O3rfJY@tjmaciei-mobl1> References: <1E4EBEB3-FAB8-41D9-A412-8DF46BE027A9@qt.io> <78847837.tdR9O3rfJY@tjmaciei-mobl1> Message-ID: <8F57244B-110F-4AD7-AA2B-4BCB10C70A32@qt.io> > On 16 Jun 2017, at 08:36, Thiago Macieira wrote: > > On Thursday, 15 June 2017 23:16:30 PDT Lars Knoll wrote: >> We’re one month away from the feature freeze, and in July half of the >> developers are on vacation. So there’s relatively little benefit from >> dropping 2013 now, as dev currently works with it. > > The difference is whether we have to put up with MSVC 2013 and find workarounds > for half a month or for 7 months. I also want to get rid of it rather sooner than later. But we have to deal with the compiler for quite a while in 5.9 anyway, and I’d expect that a lot of the bug fixes will go there. So the question is how much we’re gaining dropping it now a month before the 5.10 freeze. In any case, I’ve asked for download numbers for 2013. I’d like to see those before we make the decision. Cheers, Lars From tony.sarajarvi at qt.io Fri Jun 16 08:44:08 2017 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Fri, 16 Jun 2017 06:44:08 +0000 Subject: [Development] CI problems Message-ID: Hi We're facing an unknown problem with contacting our RHEL 6.6 virtual machines. This stops all CI from progressing. We're investigating. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From santtu.ahonen at qt.io Fri Jun 16 08:57:28 2017 From: santtu.ahonen at qt.io (Santtu Ahonen) Date: Fri, 16 Jun 2017 06:57:28 +0000 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: <5E6935E2-CEFA-4685-91D4-8FC6117676F6@qt.io> References: <1689164.Dtr7ddWLJc@tjmaciei-mobl1> <5E6935E2-CEFA-4685-91D4-8FC6117676F6@qt.io> Message-ID: >From: Shawn Rutledge >> On 15 Jun 2017, at 16:07, Thiago Macieira wrote: >> >> We have not one, not two, but THREE integration failures TODAY alone >> caused by that compiler failing to meet what we've come to expect from >> C++11. This is going to happen again and again. >> >> So I'm pleading again: can we drop it? What are the download numbers >> for 5.9.0? > >+1 from me Hi all We also have paying customers whom may be using MSVC2013 and whom are not on this list, thus we need to look at this from business side too. Not ready yet to give my vote for dropping it but will get back to this in due time. Regards, Santtu -- Product Manager, Qt for Device Creation (PM4QtDC) Mobile: +358408031045 santtu.ahonen at qt.io From cristian.adam at gmail.com Fri Jun 16 09:03:56 2017 From: cristian.adam at gmail.com (Cristian Adam) Date: Fri, 16 Jun 2017 09:03:56 +0200 Subject: [Development] Dropping older compilers for Qt 5.10 (was: Qt 5.10 pre-built bunaries) In-Reply-To: References: <4677251496867430@web43g.yandex.ru> <4163411.lHBuFDpqgs@tjmaciei-mobl1> <1693807.OoSu82cptC@tjmaciei-mobl1> Message-ID: On Fri, Jun 9, 2017 at 10:46 PM, Ville Voutilainen < ville.voutilainen at gmail.com> wrote: > > So, what's your take on gcc versions? You seemed hesitant to drop > support for QNX 6 > here: http://lists.qt-project.org/pipermail/development/2017- > June/030113.html > Are you suggesting we drop support for the MSVC versions you mentioned, > but keep > GCC 4.7 support? > > Rumor has it that QNX is offering GCC 4.9 for QNX 6.6 to certain customers for quite a while now . Could you guys ask QNX about this? GCC 4.9 should have more C++11 support than GCC 4.7 Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.harmer at kdab.com Fri Jun 16 10:01:53 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Fri, 16 Jun 2017 09:01:53 +0100 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: References: <1689164.Dtr7ddWLJc@tjmaciei-mobl1> <5E6935E2-CEFA-4685-91D4-8FC6117676F6@qt.io> Message-ID: <2686471.WCMuy96l6A@cartman> On Friday 16 June 2017 06:57:28 Santtu Ahonen wrote: > >From: Shawn Rutledge > > > >> On 15 Jun 2017, at 16:07, Thiago Macieira > >> wrote: > >> > >> We have not one, not two, but THREE integration failures TODAY alone > >> caused by that compiler failing to meet what we've come to expect from > >> C++11. This is going to happen again and again. > >> > >> So I'm pleading again: can we drop it? What are the download numbers > >> for 5.9.0? > > > >+1 from me > > Hi all > > We also have paying customers whom may be using MSVC2013 and whom are not on > this list, thus we need to look at this from business side too. Not ready > yet to give my vote for dropping it but will get back to this in due time. They have 5.9 as an LTS now. I'm with Thiago here, and would love us to drop MSVC2013. The pain/benefit ratio is not good. Cheers, Sean From lars.knoll at qt.io Fri Jun 16 11:30:48 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 16 Jun 2017 09:30:48 +0000 Subject: [Development] Examples and Demos in qtdoc In-Reply-To: References: <2011814.yAGkPeLK5y@frederik-thinkcentre-m93p> <1762291.Xer14TdUsM@cartman> <716D3B51-BEDE-4C7C-8CA3-368764908B91@qt.io> Message-ID: <6EC67B94-1E41-4EE5-9C06-E47EDCBFC315@qt.io> On 15 Jun 2017, at 15:23, Mitch Curtis > wrote: -----Original Message----- From: Development [mailto:development-bounces+mitch.curtis=qt.io@qt- project.org] On Behalf Of Joerg Bornemann Sent: Thursday, 15 June 2017 9:54 AM To: Pasi Keränen >; development at qt-project.org Subject: Re: [Development] Examples and Demos in qtdoc On 14/06/2017 14:59, Pasi Keränen wrote: I’m not 100% sure about qtdoc as the repo though. But I can live with it if that is what is seen as best option by others. There are two kinds of examples: 1. Simple examples demonstrating the use of a certain technique. Those usually come with detailed source code documentation. 2. Complex examples demonstrating much of the bling that's possible. Those are not source-documented, because writing the docs would be too laborious, and who would want to read them anyway. I believe that examples of category 1 should live in the qdoc repository / in their respective module repository. Examples of category 2 deserve a separate space. The "bigger examples" from Frederik's original mail are category 2. In Qt4 those were called "demos". There could be a "qtdemos" repo with git- lfs. In qtwebengine there's this question bobbing up every once in a while what to do with the demobrowser example. As an example, it actually needs source documentation. But it's too big. There are voices that want to remove it. Instead it could live on in such a qtdemos repo. +1 That sounds like a good idea. So documented examples in qtdoc, larger demos (that can also contain lots of image data) in a separate qtdemos repo. Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Fri Jun 16 14:05:46 2017 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Fri, 16 Jun 2017 12:05:46 +0000 Subject: [Development] CI problems In-Reply-To: References: Message-ID: Hi All seem to be working again. We also had some problems with servers not seeing LUNs for some reason, and we fixed those as well. -T From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Tony Sarajärvi Sent: perjantai 16. kesäkuuta 2017 9.44 To: development at qt-project.org Subject: [Development] CI problems Hi We're facing an unknown problem with contacting our RHEL 6.6 virtual machines. This stops all CI from progressing. We're investigating. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From szehowe.koh at gmail.com Fri Jun 16 16:17:53 2017 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Fri, 16 Jun 2017 22:17:53 +0800 Subject: [Development] "Getting started" tutorials (Was: Examples and Demos in qtdoc) In-Reply-To: References: Message-ID: On 15 June 2017 at 01:29, Tuukka Turunen wrote: > Hi, > > Yes, we would like to overall improve the examples. This is related to having a new repo for examples, but not fully the same thing. Main goal in example improvement being to make them more useful in what they are: examples of how to use Qt. Currently there are some examples that implement their own rudimentary controls instead of using Qt Quick Controls 2. We also have some examples that do not properly leverage our tooling. Some examples might not show the very best way to do things, as the new APIs allow even better way than at the time of creating the example. > > What comes to WOW, we do need to have great looking demos and at least some examples should look good as well. However, that WOW should not be the ultimate goal. The purpose of examples is to help users make better use of Qt and sometimes making things too shiny can be counterproductive. Another thing is that this WOW is a quite subjective matter and different trends come and go. It is fine to make an example look great, but that should not be the sole purpose. > > Yours, > > Tuukka Understood. On the topic of showing users "how to use Qt" and "leverage our tooling", I feel that our "getting started" tutorials/examples need some love too. IMHO, the "Getting Started" tutorial from Qt 4.3 ( https://doc.qt.io/archives/4.3/tutorial-t1.html) is more accessible to beginners than http://doc.qt.io/qt-5/gettingstartedqt.html mainly because the Qt 4.3 tute presents material in digestible chunks. Readers are introduced to the bare bones, and get to compile and interact with their code very early on. Then, the tute gradually introduces more and more concepts across a number of chapters; each chapter builds upon the previous. The reader gets to build and try out the new concepts in each chapter, before moving on to the next. In contrast, the Qt 5 tutorial takes the reader through a multitude of concepts (Qt Designer, the UIC file format, the *.pro file, subclassing widgets, the Q_OBJECT macro, properties, signals and slots, layouts, and many different classes) before the reader is taught how to compile and run their first app. If the reader made a mistake somewhere along the way, it's hard to find out where. There is far too much material packed into a single "getting started" article. I'm thinking of spending some time to update the Qt 4.3 tutorial (chapters 1 - 7) for Qt 5, presented in a few different ways to show how to do the same thing using different Qt technologies: 1. C++ only 2. C++ with Qt Designer 3. QML only 4. QML with Qt Quick Designer Is this something you'd want in the official documentation? Regards, Sze-Howe -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Jun 16 17:44:42 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 16 Jun 2017 08:44:42 -0700 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: References: <1689164.Dtr7ddWLJc@tjmaciei-mobl1> <5E6935E2-CEFA-4685-91D4-8FC6117676F6@qt.io> Message-ID: <2092740.Ufj3m04QdV@tjmaciei-mobl1> On Thursday, 15 June 2017 23:57:28 PDT Santtu Ahonen wrote: > We also have paying customers whom may be using MSVC2013 and whom are not on > this list, thus we need to look at this from business side too. Not ready > yet to give my vote for dropping it but will get back to this in due time. This is the development mailing list, we don't expect the users to be here. That's why you're here and your opinion counts. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jun 16 18:11:46 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 16 Jun 2017 09:11:46 -0700 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: <1689164.Dtr7ddWLJc@tjmaciei-mobl1> References: <1689164.Dtr7ddWLJc@tjmaciei-mobl1> Message-ID: <5191286.6Eph5ZQXIL@tjmaciei-mobl1> On Thursday, 15 June 2017 16:07:03 PDT Thiago Macieira wrote: > We have not one, not two, but THREE integration failures TODAY alone caused > by that compiler failing to meet what we've come to expect from C++11. This > is going to happen again and again. Fourth reason, just over 24 hours since the first: https://codereview.qt-project.org/197638 requires a constexpr constructor to avoid introducing a load-time initialisation. Guess which compiler doesn't support the feature? I'm going to give Allan +2 even if it causes detrimental side effects for MSVC 2013. Sorry, I can't seem to care anymore for old compilers. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sschilz at pasco.com Fri Jun 16 18:23:58 2017 From: sschilz at pasco.com (Steve Schilz) Date: Fri, 16 Jun 2017 16:23:58 +0000 Subject: [Development] Development Digest, Vol 69, Issue 22 - Getting Started Tutorials Message-ID: Sze-Howe Wrote: > On the topic of showing users "how to use Qt" and "leverage our tooling", I feel that our "getting started" tutorials/examples need some love too. > > IMHO, the "Getting Started" tutorial from Qt 4.3 ( > https://doc.qt.io/archives/4.3/tutorial-t1.html) is more accessible to beginners than http://doc.qt.io/qt-5/gettingstartedqt.html mainly because the Qt 4.3 tute > presents material in digestible chunks. Readers are introduced to the bare bones, and get to compile and interact with their code very early on. Then, the tute > gradually introduces more and more concepts across a number of chapters; each chapter builds upon the previous. The reader gets to build and try out the new > concepts in each chapter, before moving on to the next. > > In contrast, the Qt 5 tutorial takes the reader through a multitude of concepts (Qt Designer, the UIC file format, the *.pro file, subclassing widgets, the Q_OBJECT > macro, properties, signals and slots, layouts, and many different classes) before the reader is taught how to compile and run their first app. If the reader made a > mistake somewhere along the way, it's hard to find out where. There is far too much material packed into a single "getting started" article. > > I'm thinking of spending some time to update the Qt 4.3 tutorial (chapters > 1 - 7) for Qt 5, presented in a few different ways to show how to do the same thing using different Qt technologies: > > > 1. C++ only > 2. C++ with Qt Designer > 3. QML only > 4. QML with Qt Quick Designer > > Is this something you'd want in the official documentation? > > >Regards, >Sze-Howe Well, when I got my current job 7 years ago they asked me about Qt, and I went through the Cannon Field tutorial: https://doc.qt.io/archives/qtextended4.4/tutorials-tutorial.html, It was a fun progression from hello world through a very rudimentary game. I was able to talk about what I learned in the second Interview and I got the job. I have been very successful in learning other languages with that sort of chapter-based incremental tutorial. They take a little while to get through, but at the end of it, you have a firm grasp of the fundamentals. +1 Steve Schilz PASCO scientific think science From mandeepsandhu.chd at gmail.com Fri Jun 16 18:27:34 2017 From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu) Date: Fri, 16 Jun 2017 09:27:34 -0700 Subject: [Development] "Getting started" tutorials (Was: Examples and Demos in qtdoc) In-Reply-To: References: Message-ID: > > On the topic of showing users "how to use Qt" and "leverage our tooling", > I feel that our "getting started" tutorials/examples need some love too. > > IMHO, the "Getting Started" tutorial from Qt 4.3 ( > https://doc.qt.io/archives/4.3/tutorial-t1.html) is more accessible to > beginners than http://doc.qt.io/qt-5/gettingstartedqt.html mainly because > the Qt 4.3 tute presents material in digestible chunks. Readers are > introduced to the bare bones, and get to compile and interact with their > code very early on. Then, the tute gradually introduces more and more > concepts across a number of chapters; each chapter builds upon the > previous. The reader gets to build and try out the new concepts in each > chapter, before moving on to the next. > > In contrast, the Qt 5 tutorial takes the reader through a multitude of > concepts (Qt Designer, the UIC file format, the *.pro file, subclassing > widgets, the Q_OBJECT macro, properties, signals and slots, layouts, and > many different classes) before the reader is taught how to compile and run > their first app. If the reader made a mistake somewhere along the way, it's > hard to find out where. There is far too much material packed into a single > "getting started" article. > > I'm thinking of spending some time to update the Qt 4.3 tutorial (chapters > 1 - 7) for Qt 5, presented in a few different ways to show how to do the > same thing using different Qt technologies: > > 1. C++ only > 2. C++ with Qt Designer > 3. QML only > 4. QML with Qt Quick Designer > > Is this something you'd want in the official documentation? > +1 for this approach. I had a quick look at the Qt5 tut & it was a bit overwhelming for a beginner IMO. I think separating out the core C++ parts from the UI part would be beneficial for newbies. Making easily digestable examples each of these topics will go a long way in helping more ppl get on board. My 2¢. -mandeep > > > Regards, > Sze-Howe > > _______________________________________________ > 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 dh at navsystems-uk.com Fri Jun 16 18:45:29 2017 From: dh at navsystems-uk.com (NAVSYSTEMS LTD) Date: Fri, 16 Jun 2017 16:45:29 +0000 Subject: [Development] QtScript (deprecated) vs QJSEngine and reasons why QJSEngine isn't up to scratch Message-ID: <3EC5AC7C-05C4-49C3-B754-CF3F5A0CB32C@navsystems-uk.com> I have been using QtScript for many years (along with many other qt modules). Porting from QtScript to QJSEngine is clearly not trivial especially when I have multiple QScriptEngine uses in many processes but thats specific to my use not general. One very nice feature in QtScript is the debugger. In fact the debugger can even be split out into a separate process e.g a remote debugger (using QScriptDebuggerFrontend/Backend and a developer built of QScriptTools) and I'm sure others use this feature too. The debugger isn't simply a nice feature as without a debugger the amount of time needed to develop and debug scripts becomes so great its probably a non-starter. So looking at QJSEngine the first major obstacle to porting is the utter lack of any debugger support. This means for me at least QJSEngine is still not up to the job. I use scripts in several different applications (suites of applications actually), for us, they are not used for UI interaction but for behind the scenes custom data processing and realtime control. Our applications expose hundreds of QObject based classes and other data types to script land. Use of signals and slots and exposing signals to javascript is commonplace. For one application that is installed on unattended computers in remote locations the ability to connect a remote script debugger is an absolutely essential feature. So to keep this post short and to the point I won't ramble on anymore but will simply state that the first and probably most important deficiency, as I see it, is simply the lack of debugger support in QJSEngine. I am certain that there are others. There have been some posts earlier relating to QJSEngine vs QtScript performance but I cannot comment as I have not tried to port anything other than a simple test application and I have not benchmarked it either. I strongly suspect that the lack of debugger will make adoption of QJSEngine far less likely for many existing QtScript users other than those who's use cases are very trivial. NB I also use WebKit and am looking at the QWebEngine replacement but thats a whole other story and is similar and also rather unpleasant. Of course deprecation has to happen sometimes but premature deprecation and removal of features tend to force people to stick with the earlier working version s. So the question I would like to ask is are there any plans to extend the QJSEngine framework to add debugger support or should I assume I'm going to be stuck forever? NavSystems (IOM) Ltd. +44 (0)1624 851253 Mobile: +44 (0)7624 330943 Use Skype to call me or send files. Registered in the Isle of Man No: 122393C VAT: GB 003 1736 25 Registered office: Kissack Court, Parliament Street, Ramsey, Isle of Man, IM8 1AT Consider the Environment. Do you really need to print this e-mail? Information in this e-mail may be confidential and is intended only for the recipients to which it is addressed. Please notify the sender if you receive this e-mail by mistake. -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Fri Jun 16 18:48:35 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 16 Jun 2017 19:48:35 +0300 Subject: [Development] QtScript (deprecated) vs QJSEngine and reasons why QJSEngine isn't up to scratch In-Reply-To: <3EC5AC7C-05C4-49C3-B754-CF3F5A0CB32C@navsystems-uk.com> References: <3EC5AC7C-05C4-49C3-B754-CF3F5A0CB32C@navsystems-uk.com> Message-ID: <2318861497631715@web14o.yandex.ru> 16.06.2017, 19:45, "NAVSYSTEMS LTD" : > NB I also use WebKit and am looking at the QWebEngine replacement but thats a whole other story and is similar and also rather unpleasant. http://lists.qt-project.org/pipermail/development/2017-May/029795.html Sorry, I don't have anything to comment on QtScript > Of course deprecation has to happen sometimes but premature deprecation and removal of features tend to force people to stick with the earlier working version s. So the question I would like to ask is are there any plans to extend the QJSEngine framework to add debugger support or should I assume I'm going to be stuck forever? > > NavSystems (IOM) Ltd. +44 (0)1624 851253 > Mobile:   +44 (0)7624 330943 > Use Skype to call me or send files. > Registered in the Isle of Man No: 122393C  VAT: GB 003 1736 25 > Registered office: Kissack Court, Parliament Street, Ramsey, Isle of Man, IM8 1AT > Consider the Environment. Do you really need to print this e-mail? > Information in this e-mail may be confidential and is intended only for the recipients to which it is addressed. > Please notify the sender if you receive this e-mail by mistake. > , > > _______________________________________________ > 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 Jun 16 21:05:34 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 16 Jun 2017 19:05:34 +0000 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: <5191286.6Eph5ZQXIL@tjmaciei-mobl1> References: <1689164.Dtr7ddWLJc@tjmaciei-mobl1> <5191286.6Eph5ZQXIL@tjmaciei-mobl1> Message-ID: <06A0204F-3ABC-406C-B05E-DEC93162CDBB@qt.io> > On 16 Jun 2017, at 18:11, Thiago Macieira wrote: > > On Thursday, 15 June 2017 16:07:03 PDT Thiago Macieira wrote: >> We have not one, not two, but THREE integration failures TODAY alone caused >> by that compiler failing to meet what we've come to expect from C++11. This >> is going to happen again and again. > > Fourth reason, just over 24 hours since the first: > > https://codereview.qt-project.org/197638 requires a constexpr constructor to > avoid introducing a load-time initialisation. Guess which compiler doesn't > support the feature? > > I'm going to give Allan +2 even if it causes detrimental side effects for MSVC > 2013. Sorry, I can't seem to care anymore for old compilers. I don't mind at all if the code generated is less optimal on 2013. That's what you get by using older compilers. Cheers, Lars From apoenitz at t-online.de Fri Jun 16 20:14:20 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Fri, 16 Jun 2017 20:14:20 +0200 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: <1689164.Dtr7ddWLJc@tjmaciei-mobl1> References: <1689164.Dtr7ddWLJc@tjmaciei-mobl1> Message-ID: <20170616181419.GA2965@klara.mpi.htwm.de> On Thu, Jun 15, 2017 at 04:07:03PM -0700, Thiago Macieira wrote: > character set. Without the /utf-8 option added in MSVC 2015 Update 2, the > conversion fails and the compiler prints: > > warning C4566: character represented by universal-character-name '\u0431' > cannot be represented in the current code page (1252) > > [ok, not a C++11 issue per se, but we still want to use Unicode source code] There was never *consensus* on using something outside plain ASCII in Qt sources. This is predicted, self-inflicted pain. > But I repeat: these problems are going to turn up again and again. Of course. But the problem is not compilers. Andre' From Shawn.Rutledge at qt.io Fri Jun 16 21:18:25 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Fri, 16 Jun 2017 19:18:25 +0000 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: <20170616181419.GA2965@klara.mpi.htwm.de> References: <1689164.Dtr7ddWLJc@tjmaciei-mobl1> <20170616181419.GA2965@klara.mpi.htwm.de> Message-ID: <89916CD3-78C0-4B9D-8840-86500EB17D63@qt.io> > On 16 Jun 2017, at 11:14, André Pönitz wrote: > > On Thu, Jun 15, 2017 at 04:07:03PM -0700, Thiago Macieira wrote: >> character set. Without the /utf-8 option added in MSVC 2015 Update 2, the >> conversion fails and the compiler prints: >> >> warning C4566: character represented by universal-character-name '\u0431' >> cannot be represented in the current code page (1252) >> >> [ok, not a C++11 issue per se, but we still want to use Unicode source code] > > There was never *consensus* on using something outside plain ASCII in > Qt sources. The backslash, u, and the digits are all ASCII characters. This time we are not talking about utf-8 in source code. From thiago.macieira at intel.com Fri Jun 16 21:52:24 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 16 Jun 2017 12:52:24 -0700 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: <20170616181419.GA2965@klara.mpi.htwm.de> References: <1689164.Dtr7ddWLJc@tjmaciei-mobl1> <20170616181419.GA2965@klara.mpi.htwm.de> Message-ID: <6293334.ryQYIoHLan@tjmaciei-mobl1> On Friday, 16 June 2017 11:14:20 PDT André Pönitz wrote: > On Thu, Jun 15, 2017 at 04:07:03PM -0700, Thiago Macieira wrote: > > character set. Without the /utf-8 option added in MSVC 2015 Update 2, the > > conversion fails and the compiler prints: > > > > warning C4566: character represented by universal-character-name '\u0431' > > cannot be represented in the current code page (1252) > > > > [ok, not a C++11 issue per se, but we still want to use Unicode source > > code] > There was never *consensus* on using something outside plain ASCII in > Qt sources. > > This is predicted, self-inflicted pain. Right, we've had to live with ASCII-only sources for the last 25 years. We could wait a little longer. I just don't want to! Here's a tricky question: how do you create a QStringLiteral with non-ASCII characters that will work on all our supported compilers? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From apoenitz at t-online.de Fri Jun 16 21:01:32 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Fri, 16 Jun 2017 21:01:32 +0200 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: <89916CD3-78C0-4B9D-8840-86500EB17D63@qt.io> References: <1689164.Dtr7ddWLJc@tjmaciei-mobl1> <20170616181419.GA2965@klara.mpi.htwm.de> <89916CD3-78C0-4B9D-8840-86500EB17D63@qt.io> Message-ID: <20170616190132.GA4613@klara.mpi.htwm.de> On Fri, Jun 16, 2017 at 07:18:25PM +0000, Shawn Rutledge wrote: > > > On 16 Jun 2017, at 11:14, André Pönitz wrote: > > > > On Thu, Jun 15, 2017 at 04:07:03PM -0700, Thiago Macieira wrote: > >> character set. Without the /utf-8 option added in MSVC 2015 Update 2, the > >> conversion fails and the compiler prints: > >> > >> warning C4566: character represented by universal-character-name '\u0431' > >> cannot be represented in the current code page (1252) > >> > >> [ok, not a C++11 issue per se, but we still want to use Unicode source code] > > > > There was never *consensus* on using something outside plain ASCII in > > Qt sources. > > The backslash, u, and the digits are all ASCII characters. > This time we are not talking about utf-8 in source code. The broad topic would be "insisting on ways to write code that - while being formally correct - cause pain already in our own processes, not to mention those of our users." Andre' From fromqt at tungware.se Fri Jun 16 22:10:10 2017 From: fromqt at tungware.se (Henry Skoglund) Date: Fri, 16 Jun 2017 22:10:10 +0200 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: <6293334.ryQYIoHLan@tjmaciei-mobl1> References: <1689164.Dtr7ddWLJc@tjmaciei-mobl1> <20170616181419.GA2965@klara.mpi.htwm.de> <6293334.ryQYIoHLan@tjmaciei-mobl1> Message-ID: On 2017-06-16 21:52, Thiago Macieira wrote: > On Friday, 16 June 2017 11:14:20 PDT André Pönitz wrote: >> On Thu, Jun 15, 2017 at 04:07:03PM -0700, Thiago Macieira wrote: >>> character set. Without the /utf-8 option added in MSVC 2015 Update 2, the >>> conversion fails and the compiler prints: >>> >>> warning C4566: character represented by universal-character-name '\u0431' >>> cannot be represented in the current code page (1252) >>> >>> [ok, not a C++11 issue per se, but we still want to use Unicode source >>> code] >> There was never *consensus* on using something outside plain ASCII in >> Qt sources. >> >> This is predicted, self-inflicted pain. > > Right, we've had to live with ASCII-only sources for the last 25 years. We > could wait a little longer. > > I just don't want to! > > Here's a tricky question: how do you create a QStringLiteral with non-ASCII > characters that will work on all our supported compilers? > That question reminds me of the discussion last August http://lists.qt-project.org/pipermail/interest/2016-August/023882.html about Unicode code points in MSVC and how to fix so that tr("Coördinaat") or tr("Co\u00F6rdinaat"); worked with old MSVC compilers. My workaround: use raw UTF8 hex bytes: tr("Co\xC3\xB6rdinaat"); I think using that stunt should allow you to encode any non-ASCII characters inside a QStringLiteral with any compiler that supports "\x..." Rgrds Henry From thiago.macieira at intel.com Fri Jun 16 22:23:07 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 16 Jun 2017 13:23:07 -0700 Subject: [Development] What changed in the RHEL 6.6 machines that cause tst_QUdpSocket::linkLocalIPv6 to fail? Message-ID: <2185212.Na4rmT2Jrh@tjmaciei-mobl1> QDEBUG : tst_QUdpSocket::linkLocalIPv6(WithoutProxy) QHostAddress("fe80::250:56ff:feab:4818%eth1") FAIL! : tst_QUdpSocket::linkLocalIPv6(WithoutProxy) '(neutralReadSpy.count() > 0)' returned FALSE. () Loc: [../tst_qudpsocket.cpp(1600)] This test was passing on Linux without a problem for years. Red Hat Enterprise Linux 6.6 isn't a new distribution, so I assume that the test was passing on it for some time. So can someone investigate what changed that is causing it to fail? I'm also interested in two details about this: 1) eth1 is listed, but not eth0. Is eth0 down? 2) what kind of virtual network is eth1 connected to? That test has two blacklists already, one for Windows and one for Darwin, because those systems have network interfaces that, despite being up and running, don't really work and don't loop back packets. I can't blacklist "eth1" on the test, that's too generic a name. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jun 16 22:25:34 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 16 Jun 2017 13:25:34 -0700 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: References: <1689164.Dtr7ddWLJc@tjmaciei-mobl1> <6293334.ryQYIoHLan@tjmaciei-mobl1> Message-ID: <3047186.KsSEvB5OfZ@tjmaciei-mobl1> On Friday, 16 June 2017 13:10:10 PDT Henry Skoglund wrote: > That question reminds me of the discussion last August > http://lists.qt-project.org/pipermail/interest/2016-August/023882.html > about Unicode code points in MSVC and how to fix so that > tr("Coördinaat") or tr("Co\u00F6rdinaat"); worked with old MSVC compilers. > > My workaround: use raw UTF8 hex bytes: tr("Co\xC3\xB6rdinaat"); > > I think using that stunt should allow you to encode any non-ASCII > characters inside a QStringLiteral with any compiler that supports "\x..." You'd be wrong. That trick works for tr("Co\xC3\xB6rdinaat"); and the QString constructor. It does NOT work for QStringLiteral. So to answer my question: Q: How does one create a QStringLiteral containing non-ASCII characters that will work on all our supported compilers? A: You don't, unless you drop MSVC 2013 from that list in the first place. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jun 16 23:21:08 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 16 Jun 2017 14:21:08 -0700 Subject: [Development] What changed in the RHEL 6.6 machines that cause tst_QUdpSocket::linkLocalIPv6 to fail? In-Reply-To: <2185212.Na4rmT2Jrh@tjmaciei-mobl1> References: <2185212.Na4rmT2Jrh@tjmaciei-mobl1> Message-ID: <2209669.PjnOdga9Be@tjmaciei-mobl1> On Friday, 16 June 2017 13:23:07 PDT Thiago Macieira wrote: > QDEBUG : tst_QUdpSocket::linkLocalIPv6(WithoutProxy) > QHostAddress("fe80::250:56ff:feab:4818%eth1") > FAIL! : tst_QUdpSocket::linkLocalIPv6(WithoutProxy) > '(neutralReadSpy.count() > > 0)' returned FALSE. () > > Loc: [../tst_qudpsocket.cpp(1600)] Emergency workaround: https://codereview.qt-project.org/197753 (compiles and works for me on bare metal, no test on a VM) This commit basically disables the test entirely on virtual machines. If any QtNetwork developers use virtual machines, please make sure you get bare-metal hardware for all three platforms. You won't be doing your job if you continue with VMs. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Jun 17 00:10:41 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 16 Jun 2017 15:10:41 -0700 Subject: [Development] CI problems In-Reply-To: References: Message-ID: <3145816.5MFDlOBuvq@tjmaciei-mobl1> On Thursday, 15 June 2017 23:44:08 PDT Tony Sarajärvi wrote: > Hi > > We're facing an unknown problem with contacting our RHEL 6.6 virtual > machines. This stops all CI from progressing. We're investigating. Pretty sure that either what caused this problem or the solution is the reason why tst_QUdpSocket::linkLocalIPv6 is now failing. The test wasn't failing until then. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From samuel.gaist at edeltech.ch Sat Jun 17 00:18:50 2017 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Sat, 17 Jun 2017 00:18:50 +0200 Subject: [Development] "Getting started" tutorials (Was: Examples and Demos in qtdoc) In-Reply-To: References: Message-ID: > On 16 Jun 2017, at 16:17, Sze Howe Koh wrote: > > On 15 June 2017 at 01:29, Tuukka Turunen wrote: > > Hi, > > > > Yes, we would like to overall improve the examples. This is related to having a new repo for examples, but not fully the same thing. Main goal in example improvement being to make them more useful in what they are: examples of how to use Qt. Currently there are some examples that implement their own rudimentary controls instead of using Qt Quick Controls 2. We also have some examples that do not properly leverage our tooling. Some examples might not show the very best way to do things, as the new APIs allow even better way than at the time of creating the example. > > > > What comes to WOW, we do need to have great looking demos and at least some examples should look good as well. However, that WOW should not be the ultimate goal. The purpose of examples is to help users make better use of Qt and sometimes making things too shiny can be counterproductive. Another thing is that this WOW is a quite subjective matter and different trends come and go. It is fine to make an example look great, but that should not be the sole purpose. > > > > Yours, > > > > Tuukka > > Understood. > > On the topic of showing users "how to use Qt" and "leverage our tooling", I feel that our "getting started" tutorials/examples need some love too. > > IMHO, the "Getting Started" tutorial from Qt 4.3 (https://doc.qt.io/archives/4.3/tutorial-t1.html) is more accessible to beginners than http://doc.qt.io/qt-5/gettingstartedqt.html mainly because the Qt 4.3 tute presents material in digestible chunks. Readers are introduced to the bare bones, and get to compile and interact with their code very early on. Then, the tute gradually introduces more and more concepts across a number of chapters; each chapter builds upon the previous. The reader gets to build and try out the new concepts in each chapter, before moving on to the next. > > In contrast, the Qt 5 tutorial takes the reader through a multitude of concepts (Qt Designer, the UIC file format, the *.pro file, subclassing widgets, the Q_OBJECT macro, properties, signals and slots, layouts, and many different classes) before the reader is taught how to compile and run their first app. If the reader made a mistake somewhere along the way, it's hard to find out where. There is far too much material packed into a single "getting started" article. > > I'm thinking of spending some time to update the Qt 4.3 tutorial (chapters 1 - 7) for Qt 5, presented in a few different ways to show how to do the same thing using different Qt technologies: > > 1. C++ only > 2. C++ with Qt Designer > 3. QML only > 4. QML with Qt Quick Designer > > Is this something you'd want in the official documentation? > > > Regards, > Sze-Howe > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development +100 We seem to, lately, have a lot of beginners on the forum that would benefit from such a nice set of tutorials. Cheers, Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From apoenitz at t-online.de Sat Jun 17 01:35:54 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Sat, 17 Jun 2017 01:35:54 +0200 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: <6293334.ryQYIoHLan@tjmaciei-mobl1> References: <1689164.Dtr7ddWLJc@tjmaciei-mobl1> <20170616181419.GA2965@klara.mpi.htwm.de> <6293334.ryQYIoHLan@tjmaciei-mobl1> Message-ID: <20170616233553.GA4977@klara.mpi.htwm.de> On Fri, Jun 16, 2017 at 12:52:24PM -0700, Thiago Macieira wrote: > Here's a tricky question: how do you create a QStringLiteral with non-ASCII > characters that will work on all our supported compilers? I don't have to, unless I have profiler supported evidence that it matters. In the common case where it does not matter, the string can be created at run time. For the rare (vulgo: non-existent) case where that would matter in Qt sources, something QStringLiteral-like along the lines of #define QSTRINGLITERAL(...) \ []() -> QString { \ const ushort X[] = { __VA_ARGS__ }; \ enum { Size = sizeof(X) / sizeof(X[0]) }; \ static const QStaticStringData qstring_literal = { \ { Q_REFCOUNT_INITIALIZE_STATIC, Size, 0, 0, sizeof(QStringData) }, \ __VA_ARGS__ \ }; \ QStringDataPtr holder = { qstring_literal.data_ptr() }; \ const QString qstring_literal_temp(holder); \ return qstring_literal_temp; }() and using QSTRINGLITERAL('M', 0xf6, 0xf6, 0xf6, 'p', '!') instead of QStringLiteral("Möööp!") should be possible to use, too. Andre' From thiago.macieira at intel.com Sat Jun 17 04:09:20 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 16 Jun 2017 19:09:20 -0700 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: <20170616233553.GA4977@klara.mpi.htwm.de> References: <1689164.Dtr7ddWLJc@tjmaciei-mobl1> <6293334.ryQYIoHLan@tjmaciei-mobl1> <20170616233553.GA4977@klara.mpi.htwm.de> Message-ID: <1968163.2PbfAQ7WLo@tjmaciei-mobl1> On Friday, 16 June 2017 16:35:54 PDT André Pönitz wrote: > On Fri, Jun 16, 2017 at 12:52:24PM -0700, Thiago Macieira wrote: > > Here's a tricky question: how do you create a QStringLiteral with > > non-ASCII > > characters that will work on all our supported compilers? > > I don't have to, unless I have profiler supported evidence that > it matters. QStringLiteral is infinitely faster at runtime than QString::fromUtf8. It also occupies roughly 33% less memory than QString::fromUtf8 of a literal, as the latter needs the narrow character equivalent (read-only memory) plus the UTF-16 converted text (heap, which has overhead). This is for a simple, static message. > In the common case where it does not matter, the string can be > created at run time. At a cost and overhead. > QSTRINGLITERAL('M', 0xf6, 0xf6, 0xf6, 'p', '!') > > instead of > > QStringLiteral("Möööp!") Yeah, no thanks. The whole point is that we can do better. All we need to do is drop an old, buggy compiler. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ulf.hermann at qt.io Sat Jun 17 10:08:39 2017 From: ulf.hermann at qt.io (Ulf Hermann) Date: Sat, 17 Jun 2017 08:08:39 +0000 Subject: [Development] QtScript (deprecated) vs QJSEngine and reasons why QJSEngine isn't up to scratch In-Reply-To: <3EC5AC7C-05C4-49C3-B754-CF3F5A0CB32C@navsystems-uk.com> References: <3EC5AC7C-05C4-49C3-B754-CF3F5A0CB32C@navsystems-uk.com> Message-ID: Hi, Since at least Qt 5.8 (maybe even earlier, I cannot look it up right now) you can use the QML debugger with plain QJSEngines. Just start the application through Qt Creator's debug mode or use the "-qmljsdebugger=port:..." argument and connect with Qt Creator to the specified port. The QML debugger will give you many familiar debugging facilities like single stepping, break points, etc. regards, Ulf ________________________________ From: Development on behalf of NAVSYSTEMS LTD Sent: Friday, June 16, 2017 6:45:29 PM To: development at qt-project.org Subject: [Development] QtScript (deprecated) vs QJSEngine and reasons why QJSEngine isn't up to scratch I have been using QtScript for many years (along with many other qt modules). Porting from QtScript to QJSEngine is clearly not trivial especially when I have multiple QScriptEngine uses in many processes but thats specific to my use not general. One very nice feature in QtScript is the debugger. In fact the debugger can even be split out into a separate process e.g a remote debugger (using QScriptDebuggerFrontend/Backend and a developer built of QScriptTools) and I'm sure others use this feature too. The debugger isn't simply a nice feature as without a debugger the amount of time needed to develop and debug scripts becomes so great its probably a non-starter. So looking at QJSEngine the first major obstacle to porting is the utter lack of any debugger support. This means for me at least QJSEngine is still not up to the job. I use scripts in several different applications (suites of applications actually), for us, they are not used for UI interaction but for behind the scenes custom data processing and realtime control. Our applications expose hundreds of QObject based classes and other data types to script land. Use of signals and slots and exposing signals to javascript is commonplace. For one application that is installed on unattended computers in remote locations the ability to connect a remote script debugger is an absolutely essential feature. So to keep this post short and to the point I won't ramble on anymore but will simply state that the first and probably most important deficiency, as I see it, is simply the lack of debugger support in QJSEngine. I am certain that there are others. There have been some posts earlier relating to QJSEngine vs QtScript performance but I cannot comment as I have not tried to port anything other than a simple test application and I have not benchmarked it either. I strongly suspect that the lack of debugger will make adoption of QJSEngine far less likely for many existing QtScript users other than those who's use cases are very trivial. NB I also use WebKit and am looking at the QWebEngine replacement but thats a whole other story and is similar and also rather unpleasant. Of course deprecation has to happen sometimes but premature deprecation and removal of features tend to force people to stick with the earlier working version s. So the question I would like to ask is are there any plans to extend the QJSEngine framework to add debugger support or should I assume I'm going to be stuck forever? NavSystems (IOM) Ltd. +44 (0)1624 851253 Mobile: +44 (0)7624 330943 Use Skype to call me or send files. Registered in the Isle of Man No: 122393C VAT: GB 003 1736 25 Registered office: Kissack Court, Parliament Street, Ramsey, Isle of Man, IM8 1AT Consider the Environment. Do you really need to print this e-mail? Information in this e-mail may be confidential and is intended only for the recipients to which it is addressed. Please notify the sender if you receive this e-mail by mistake. -------------- next part -------------- An HTML attachment was scrubbed... URL: From antonxx at gmx.de Sat Jun 17 10:36:00 2017 From: antonxx at gmx.de (anton) Date: Sat, 17 Jun 2017 10:36:00 +0200 Subject: [Development] QtScript (deprecated) vs QJSEngine and reasons why QJSEngine isn't up to scratch In-Reply-To: <3EC5AC7C-05C4-49C3-B754-CF3F5A0CB32C@navsystems-uk.com> References: <3EC5AC7C-05C4-49C3-B754-CF3F5A0CB32C@navsystems-uk.com> Message-ID: <3d4d257d-8e2c-ca6c-8a50-9138bfc00f1c@gmx.de> Hi, to be honest ... I still didn't start full with Qt (only one QtWidget Application).. so I am no expert. > application and I have not benchmarked it either. I strongly suspect > that the lack of debugger will make adoption of QJSEngine far less > likely for many existing QtScript users other than those who's use cases > are very trivial. NB I also use WebKit and am looking at the QWebEngine but if I understood, with QtScript you can create an application with scripting (macro) support, and even the debugger can be integrated in your application right? So if my customer use scripting in the application he can debug it (so QtScript is what VBA is for Excel). Right? Actually it seems that you can debug something in QtCreator with QML (as Ulf responded) but since in QtCreator the QML designer still ignores the TreeView control (in Qt 5.8 I think it was partialy somewhere but in Qt 5.9/QtCreator 4.3.1 its disappeared). One of my question on the QtCreator blog.qt.io concerning QML was answered but my second post asking about TreeView was not published/deleted... So QML seems for mobile development, and if you want Desktop applications QtWidget seems the reality (or can you immagine a file browser like Windows Explorer without Tree View) .. my thoughts... Qt is nice but some things are not adressed since some Qt versions and talking about seems "forbidden". I don't know if I should give Qt a try for the next project I would really really like, but continuity is important for me and the QtScript and my "small" TreeView critics make me rethink it ... Anton From apoenitz at t-online.de Sat Jun 17 11:14:18 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Sat, 17 Jun 2017 11:14:18 +0200 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: <1968163.2PbfAQ7WLo@tjmaciei-mobl1> References: <1689164.Dtr7ddWLJc@tjmaciei-mobl1> <6293334.ryQYIoHLan@tjmaciei-mobl1> <20170616233553.GA4977@klara.mpi.htwm.de> <1968163.2PbfAQ7WLo@tjmaciei-mobl1> Message-ID: <20170617091418.GA1628@klara.mpi.htwm.de> On Fri, Jun 16, 2017 at 07:09:20PM -0700, Thiago Macieira wrote: > On Friday, 16 June 2017 16:35:54 PDT André Pönitz wrote: > > On Fri, Jun 16, 2017 at 12:52:24PM -0700, Thiago Macieira wrote: > > > Here's a tricky question: how do you create a QStringLiteral with > > > non-ASCII characters that will work on all our supported > > > compilers? > > > > I don't have to, unless I have profiler supported evidence that it > > matters. > > QStringLiteral is infinitely faster at runtime than QString::fromUtf8. > It also occupies roughly 33% less memory than QString::fromUtf8 of a > literal, as the latter needs the narrow character equivalent > (read-only memory) plus the UTF-16 converted text (heap, which has > overhead). We are talking about a handful strings with non-7-bit chars, mostly in tests. Cycles spend for these cases will never sum up to the order of magnitude to one failed CI integration. > This is for a simple, static message. > > > In the common case where it does not matter, the string can be > > created at run time. > > At a cost and overhead. Dwarfed by the costs of the proposed alternative. > > QSTRINGLITERAL('M', 0xf6, 0xf6, 0xf6, 'p', '!') > > > > instead of > > > > QStringLiteral("Möööp!") > > Yeah, no thanks. We are talking about a handful strings with non-7-bit chars, mostly in tests. Worse uglifications have been proposed to Qt proper for even less gain. > The whole point is that we can do better. All we need to do is drop an > old, buggy compiler. That's not 'better', that's a price to pay. I don't have any stake in MSVC nor in Windows in general, in fact given that it's weekend, I do not care at all. Decision making should weigh pros and cons. The observed pattern is however "We see something sub-optimal, therefore we choose the other approach, not matter matter what". This is unreasonable. Andre' From philwave at gmail.com Sat Jun 17 14:14:25 2017 From: philwave at gmail.com (Philippe) Date: Sat, 17 Jun 2017 14:14:25 +0200 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: <20170617091418.GA1628@klara.mpi.htwm.de> References: <1968163.2PbfAQ7WLo@tjmaciei-mobl1> <20170617091418.GA1628@klara.mpi.htwm.de> Message-ID: <20170617141424.0FA8.6F0322A@gmail.com> > Decision making should weigh pros and cons. The observed pattern is > however "We see something sub-optimal, therefore we choose the other > approach, not matter matter what". This is unreasonable. I don't see reasonnable the use of the latest Qt technology on one hand (5.10), together with an old compiler (VS 2013) that does not even support well the C++ standard defined back in 2011. This sounds reasonnable that ressources are spent fixing Qt issues rather than solutions around compiler quirks. If some users think otherwise, they can still modify Qt (5.10) to use with their old favorite compiler. Philippe On Sat, 17 Jun 2017 11:14:18 +0200 André Pönitz wrote: > On Fri, Jun 16, 2017 at 07:09:20PM -0700, Thiago Macieira wrote: > > On Friday, 16 June 2017 16:35:54 PDT André Pönitz wrote: > > > On Fri, Jun 16, 2017 at 12:52:24PM -0700, Thiago Macieira wrote: > > > > Here's a tricky question: how do you create a QStringLiteral with > > > > non-ASCII characters that will work on all our supported > > > > compilers? > > > > > > I don't have to, unless I have profiler supported evidence that it > > > matters. > > > > QStringLiteral is infinitely faster at runtime than QString::fromUtf8. > > It also occupies roughly 33% less memory than QString::fromUtf8 of a > > literal, as the latter needs the narrow character equivalent > > (read-only memory) plus the UTF-16 converted text (heap, which has > > overhead). > > We are talking about a handful strings with non-7-bit chars, > mostly in tests. > > Cycles spend for these cases will never sum up to the order of > magnitude to one failed CI integration. > > > This is for a simple, static message. > > > > > In the common case where it does not matter, the string can be > > > created at run time. > > > > At a cost and overhead. > > Dwarfed by the costs of the proposed alternative. > > > > QSTRINGLITERAL('M', 0xf6, 0xf6, 0xf6, 'p', '!') > > > > > > instead of > > > > > > QStringLiteral("Möööp!") > > > > Yeah, no thanks. > > We are talking about a handful strings with non-7-bit chars, > mostly in tests. > > Worse uglifications have been proposed to Qt proper for even > less gain. > > > The whole point is that we can do better. All we need to do is drop an > > old, buggy compiler. > > That's not 'better', that's a price to pay. > > I don't have any stake in MSVC nor in Windows in general, in fact > given that it's weekend, I do not care at all. > > Decision making should weigh pros and cons. The observed pattern is > however "We see something sub-optimal, therefore we choose the other > approach, not matter matter what". This is unreasonable. > > Andre' > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From aha_1980 at gmx.de Sun Jun 18 17:24:56 2017 From: aha_1980 at gmx.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Sun, 18 Jun 2017 17:24:56 +0200 Subject: [Development] First Qt 5.9.1 snapshot available In-Reply-To: References: Message-ID: Hi Jani, I've got two questions regarding the 5.9.1 release: 1. There have been no "changes file" templates provided so far. I guess this will lead to last-minute hectic if you want to release in June. It would be good to have such templates as soon as the release branch is created. 2. For 5.8.0, I saw that binary compatibility files were added. Did I miss something or is this discontinued for 5.9.0? How do you assure BC during the 5.9 patch releases? Best regards, André Am 14.06.2017 um 08:00 schrieb Jani Heikkinen: > Hi all, > > We have first Qt 5.9.1 snapshot available via online installer. It is a separate 5.9.1 node, not as an update to Qt 5.9.0. Instructions how to install it here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer > > Content of the snapshot is based on https://codereview.qt-project.org/#/c/196614/, delta to Qt 5.9.0 as an attachment. > > RTA testing is ongoing and snapshot seems to be pretty much OK. So please test the snapshot & report your effort via https://wiki.qt.io/Qt59_release_testing > > And please note: We will do regular patch releases for 5.9 series and so on we won't block the release because of old issues. Qt 5.9.1 is released on June and 5.9.2 is targeted to be released on August so if there is still bad issues open in 5.9.1 there is time to fix those for soon coming Qt 5.9.2 (or even Qt 5.9.3 which should be out ~September...) > > br, > Jani > > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From aha_1980 at gmx.de Sun Jun 18 17:32:59 2017 From: aha_1980 at gmx.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Sun, 18 Jun 2017 17:32:59 +0200 Subject: [Development] Qt 5.10 pre-built bunaries In-Reply-To: References: Message-ID: Hi Jani, Am 13.06.2017 um 12:52 schrieb Jani Heikkinen: > Hi, > > As a conclusion of subject: > > only change related to pre-built binaries for 5.10 (from Qt 5.9) is dropping 32 bit iOS. > And from 5.11 -> we will drop MSVC2013 as well. > > There isn't conclusion about mingw yet but let's agree to switch from mingw 32 bit to 64 bit one in 5.11 Right, there was no conclusion so far. Are there technical issues that you want to discontinue 32 bit packages? Most Windows applications are still 32 bit and they run fine in Windows 32 and 64 bit environments. I still have a Development Notebook running 32 bit Windows 7 and I use the Qt MinGW package (as it contains Qt, Creator, Compiler and Debugger in one package). If you drop MSVC2013, could you instead deliver both MinGW 32 and 64 bit? Best regards, André > > There were also discussion about minimum GCC version but it isn't directly related to pre-built binaries and that's why it needs to be concluded in different thread > > br > Jani > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From marc.mutz at kdab.com Sun Jun 18 20:16:41 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sun, 18 Jun 2017 20:16:41 +0200 Subject: [Development] [Releasing] Qt 5.10 pre-built bunaries In-Reply-To: <8F57244B-110F-4AD7-AA2B-4BCB10C70A32@qt.io> References: <1E4EBEB3-FAB8-41D9-A412-8DF46BE027A9@qt.io> <78847837.tdR9O3rfJY@tjmaciei-mobl1> <8F57244B-110F-4AD7-AA2B-4BCB10C70A32@qt.io> Message-ID: <7e435d8f15f76e5d3deb669b7c4e5061@kdab.com> On 2017-06-16 08:43, Lars Knoll wrote: >> On 16 Jun 2017, at 08:36, Thiago Macieira >> wrote: >> >> On Thursday, 15 June 2017 23:16:30 PDT Lars Knoll wrote: >>> We’re one month away from the feature freeze, and in July half of the >>> developers are on vacation. So there’s relatively little benefit from >>> dropping 2013 now, as dev currently works with it. >> >> The difference is whether we have to put up with MSVC 2013 and find >> workarounds >> for half a month or for 7 months. > > I also want to get rid of it rather sooner than later. But we have to > deal with the compiler for quite a while in 5.9 anyway, and I’d expect > that a lot of the bug fixes will go there. So the question is how much > we’re gaining dropping it now a month before the 5.10 freeze. QStringView, at least, is full of MSVC 2013 work-arounds. The most important is the requirement to use QStringViewLiteral instead of just u"foo". From thiago.macieira at intel.com Sun Jun 18 21:40:50 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 18 Jun 2017 12:40:50 -0700 Subject: [Development] [Releasing] Qt 5.10 pre-built bunaries In-Reply-To: <7e435d8f15f76e5d3deb669b7c4e5061@kdab.com> References: <8F57244B-110F-4AD7-AA2B-4BCB10C70A32@qt.io> <7e435d8f15f76e5d3deb669b7c4e5061@kdab.com> Message-ID: <1775553.0j9mv5fSaZ@tjmaciei-mobl1> On Sunday, 18 June 2017 11:16:41 PDT Marc Mutz wrote: > QStringView, at least, is full of MSVC 2013 work-arounds. The most > important is the requirement to use QStringViewLiteral instead of just > u"foo". And I'd rather we hadn't introduced yet another compatibility macro. Actually, please delete it. We'll use u"" when we can, and we don't need to create QStringView literals until we can. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Mon Jun 19 08:20:58 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 19 Jun 2017 06:20:58 +0000 Subject: [Development] First Qt 5.9.1 snapshot available In-Reply-To: References: Message-ID: > -----Original Message----- > From: André Hartmann [mailto:aha_1980 at gmx.de] > Sent: sunnuntai 18. kesäkuuta 2017 18.25 > To: Jani Heikkinen ; development at qt-project.org; > interest at qt-project.org > Cc: releasing at qt-project.org > Subject: Re: [Development] First Qt 5.9.1 snapshot available > > Hi Jani, > > I've got two questions regarding the 5.9.1 release: > > 1. There have been no "changes file" templates provided so far. I guess this > will lead to last-minute hectic if you want to release in June. It would be good > to have such templates as soon as the release branch is created. To be honest, it should be maintainers who does these change files from the begining, not the release team. But because it seems to be really hard to be done we in the release team have done these initial ones lately. Doing these too early won't help at all because many changes might be missing and that's why we are planning to do these immediately after branching from '5.9' -> '5.9.1' is finalized. I know it will be tight but let's try to get it done really quickly at this time. But to be honest we need to find a better way to do this now when we are trying to do these reqular patch level releases... > > 2. For 5.8.0, I saw that binary compatibility files were added. Did I miss > something or is this discontinued for 5.9.0? How do you assure BC during the > 5.9 patch releases? > No, this is continuing. 5.9.0 bc files are still missing and 5.9.1 is still compared to 5.8.0. 5.9.0 bc files will be added as soon as possible br, Jani > Best regards, > André > > Am 14.06.2017 um 08:00 schrieb Jani Heikkinen: > > Hi all, > > > > We have first Qt 5.9.1 snapshot available via online installer. It is > > a separate 5.9.1 node, not as an update to Qt 5.9.0. Instructions how > > to install it here: > > https://wiki.qt.io/How_to_get_snapshot_via_online_installer > > > > Content of the snapshot is based on https://codereview.qt- > project.org/#/c/196614/, delta to Qt 5.9.0 as an attachment. > > > > RTA testing is ongoing and snapshot seems to be pretty much OK. So > > please test the snapshot & report your effort via > > https://wiki.qt.io/Qt59_release_testing > > > > And please note: We will do regular patch releases for 5.9 series and > > so on we won't block the release because of old issues. Qt 5.9.1 is > > released on June and 5.9.2 is targeted to be released on August so if > > there is still bad issues open in 5.9.1 there is time to fix those for > > soon coming Qt 5.9.2 (or even Qt 5.9.3 which should be out > > ~September...) > > > > br, > > Jani > > > > > > > > > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > From jani.heikkinen at qt.io Mon Jun 19 08:31:59 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 19 Jun 2017 06:31:59 +0000 Subject: [Development] Qt 5.9.1 branching finalized In-Reply-To: References: Message-ID: Hi all, Final downmerge is now done and '5.9' is for '5.9.2' from now on. We will start doing Qt 5.9.1 "rc" now to see if there is still some issue to be fixed before official release. But the target is that current '5.9.1' is final content for the release so please not try to get in any nice-to-haves anymore. Change files are still missing and we will do those soon today. Let's get those in as soon as possible br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Monday, June 12, 2017 2:35 PM To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Development] Qt 5.9.1 soft branching started Hi all, We have today started soft branching from '5.9' to '5.9.1'. That way we should be able to release Qt 5.9.1 still during June. So please use '5.9.1' for new changes targeted to Qt 5.9.1 release. We will do final downmerge from '5.9' to '5.9.1' this Friday (16.6) and after that '5.9' will be for Qt 5.9.2. And please note: We are planning to do regular patch level releases for Qt 5.9 series so no any nice-to-haves in '5.9.1', just fixes for really critical issues. All others must be done in '5.9' & can wait Qt 5.9.2 release. So '5.9.1' is just for getting Qt 5.9.1 quickly out... And at this time we really want to do Qt 5.9.1 on time meaning we won't delay the release because of issues which were already in Qt 5.9.0 release. And we will check case by case all new regressions if those could really delay the release or not: Qt 5.9.2 is planned to be released already on August. br, Jani Heikkinen Release Manager _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jpnurmi at qt.io Mon Jun 19 08:34:26 2017 From: jpnurmi at qt.io (J-P Nurmi) Date: Mon, 19 Jun 2017 06:34:26 +0000 Subject: [Development] Flaky auto tests on macOS 10.12 Message-ID: <0A65F222-D58B-440B-A156-E43234E4BA6F@qt.io> Hi all, After a few successful qt5.git CI rounds, auto tests were enabled for macOS 10.12 in the CI last week. [*] Even though many flaky auto tests had been already blacklisted on macOS 10.12 earlier (https://bugreports.qt.io/browse/QTBUG-58968), it became nearly impossible to integrate any qtbase patch due to random timer/eventloop/animation related auto test failures on macOS 10.12. As agreed earlier (http://lists.qt-project.org/pipermail/development/2017-February/028715.html), an action was taken to blacklist/skip several more auto tests on macOS 10.12: Extend blacklisting of tst_QElapsedTimer::elapsed to cover macOS 10.12 - https://bugreports.qt.io/browse/QTBUG-58713 - https://codereview.qt-project.org/#/c/195625/ Blacklist tst_QGuiEventLoop::processEvents in macOS 10.12 - https://bugreports.qt.io/browse/QTBUG-61131 - https://codereview.qt-project.org/#/c/196087/ Blacklist flaky tst_QTimeLine tests on macOS 10.12 - https://bugreports.qt.io/browse/QTBUG-61037 - https://codereview.qt-project.org/#/c/195608/ Skip unreliable tst_QTimer::moveToThread() on macOS 10.12 - https://bugreports.qt.io/browse/QTBUG-59679 - https://codereview.qt-project.org/#/c/197769/ Blacklist flaky tst_QGuiEventLoop::testQuitLock() on macOS 10.12 - https://bugreports.qt.io/browse/QTBUG-61499 - https://codereview.qt-project.org/#/c/197791/ Blacklist tst_QParallelAnimationGroup::deleteChildrenWithRunningGroup() - https://bugreports.qt.io/browse/QTBUG-61500 - https://codereview.qt-project.org/#/c/197792/ Quoting Lars: " Anybody who get’s one of those bug reports assigned please look at them immediately and try to see what’s going wrong. This is not always easy or straightforward, as they aren’t always reproducible outside the CI system. Here are a few pointers to help: Have a look at https://wiki.qt.io/Writing_good_tests , and check that the test is following the rules there. Often tests fail more easily under high load, so this is something to check as well. If you’re working for The Qt Company, you have the additional option of creating a VM inside the CI system or running test builds of a pushed change in the CI system. If you’re not working for TQtC, ask someone who does and we can schedule a build of any patch you push to gerrit inside the CI on the platform of your choice (with results being reported back to the gerrit change). If the test is flaky due to some external dependency (e.g. the network test server), you might want to file them as a subtask for getting a better test server in place and keep it blacklisted. In almost all other cases, you should try to fix the test (or the bug in Qt). If it's not possible to fix the test, think about how it could be rewritten. If the test is worthless (for example because it doesn’t test anything we haven’t covered in other ways), remove it. In any case, please handle those bug reports quickly, as said above they will block the release until handled. Please don’t down-prioritize these bugs reports without very good reasons (and talking to the module maintainer). I hope that as many people as possible will help in the effort. Fixing those flaky tests is quite some work right now, but in the longer term we will benefit us all when integrations go in more smoothly and we can more easily update qt5.git and get releases out. " [*] The timing, during the 5.9.1 soft freeze week, was a bit unfortunate, but this is a separate discussion. -- J-P Nurmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Mon Jun 19 11:36:19 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 19 Jun 2017 09:36:19 +0000 Subject: [Development] What changed in the RHEL 6.6 machines that cause tst_QUdpSocket::linkLocalIPv6 to fail? In-Reply-To: <2185212.Na4rmT2Jrh@tjmaciei-mobl1> References: <2185212.Na4rmT2Jrh@tjmaciei-mobl1> Message-ID: Thiago Macieira (16 June 2017 22:23) > QDEBUG : tst_QUdpSocket::linkLocalIPv6(WithoutProxy) QHostAddress("fe80::250:56ff:feab:4818%eth1") > FAIL! : tst_QUdpSocket::linkLocalIPv6(WithoutProxy) '(neutralReadSpy.count() > 0)' returned FALSE. () > Loc: [../tst_qudpsocket.cpp(1600)] I note that this line ends in a comment: QTRY_VERIFY(neutralReadSpy.count() > 0); //note may need to accept a firewall prompt COIN folks: please check RHEL 6.6 hasn't auto-enabled some firewall ! ISTR that I've hit Red Hat on-by-default fire-walls that I had to turn off when testing CFEngine in my last job ... Eddy. From Simon.Hausmann at qt.io Mon Jun 19 11:38:04 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Mon, 19 Jun 2017 09:38:04 +0000 Subject: [Development] What changed in the RHEL 6.6 machines that cause tst_QUdpSocket::linkLocalIPv6 to fail? In-Reply-To: References: <2185212.Na4rmT2Jrh@tjmaciei-mobl1>, Message-ID: Hi, I've checked that all iptables for IPv4 and IPv6 are empty. Simon ________________________________ From: Development on behalf of Edward Welbourne Sent: Monday, June 19, 2017 11:36:19 AM To: Thiago Macieira Cc: development at qt-project.org Subject: Re: [Development] What changed in the RHEL 6.6 machines that cause tst_QUdpSocket::linkLocalIPv6 to fail? Thiago Macieira (16 June 2017 22:23) > QDEBUG : tst_QUdpSocket::linkLocalIPv6(WithoutProxy) QHostAddress("fe80::250:56ff:feab:4818%eth1") > FAIL! : tst_QUdpSocket::linkLocalIPv6(WithoutProxy) '(neutralReadSpy.count() > 0)' returned FALSE. () > Loc: [../tst_qudpsocket.cpp(1600)] I note that this line ends in a comment: QTRY_VERIFY(neutralReadSpy.count() > 0); //note may need to accept a firewall prompt COIN folks: please check RHEL 6.6 hasn't auto-enabled some firewall ! ISTR that I've hit Red Hat on-by-default fire-walls that I had to turn off when testing CFEngine in my last job ... Eddy. _______________________________________________ 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 a.volkov at rusbitech.ru Mon Jun 19 11:52:12 2017 From: a.volkov at rusbitech.ru (Alexander Volkov) Date: Mon, 19 Jun 2017 12:52:12 +0300 Subject: [Development] Enabling private features for separate modules Message-ID: <8862eb84-1a19-ca9a-38c4-9a9598c3dd35@rusbitech.ru> Hi, I build qtwebengine as a separate module. What is the right way to enable system-ffmpeg feature? It's not auto-detected: "system-ffmpeg": { "label": "ffmpeg", "autoDetect": false, "condition": "libs.ffmpeg && features.system-opus && features.system-webp", "output": [ "privateFeature" ] } Cheers, Alexander. From oswald.buddenhagen at qt.io Mon Jun 19 11:53:48 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 19 Jun 2017 11:53:48 +0200 Subject: [Development] Enabling private features for separate modules In-Reply-To: <8862eb84-1a19-ca9a-38c4-9a9598c3dd35@rusbitech.ru> References: <8862eb84-1a19-ca9a-38c4-9a9598c3dd35@rusbitech.ru> Message-ID: <20170619095348.GV18408@troll08> On Mon, Jun 19, 2017 at 12:52:12PM +0300, Alexander Volkov wrote: > Hi, > > I build qtwebengine as a separate module. > What is the right way to enable system-ffmpeg feature? > you use qmake [usual qmake args] -- [configure args] From jani.heikkinen at qt.io Mon Jun 19 12:29:25 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 19 Jun 2017 10:29:25 +0000 Subject: [Development] Qt 5.9.1 initial change files available Message-ID: Hi all initial change files available, see https://codereview.qt-project.org/#/q/message:%22Add+changes%22+branch:5.9.1,n,z Maintainers: Please do needed modifications & get approval as soon as possible (today/latest tomorrow) br, Jani Heikkinen Release Manager From sean.harmer at kdab.com Mon Jun 19 12:38:20 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 19 Jun 2017 11:38:20 +0100 Subject: [Development] Qt 5.9.1 initial change files available In-Reply-To: References: Message-ID: <26752381.eWshmlupiN@cartman> On Monday, 19 June 2017 11:29:25 BST Jani Heikkinen wrote: > Hi all > > initial change files available, see > https://codereview.qt-project.org/#/q/message:%22Add+changes%22+branch:5.9. > 1,n,z > > Maintainers: Please do needed modifications & get approval as soon as > possible (today/latest tomorrow) Done. Sean > > br, > > Jani Heikkinen > Release Manager > > _______________________________________________ > 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 Morten.Sorvig at qt.io Mon Jun 19 12:40:24 2017 From: Morten.Sorvig at qt.io (=?iso-8859-1?Q?Morten_S=F8rvig?=) Date: Mon, 19 Jun 2017 10:40:24 +0000 Subject: [Development] Flaky auto tests on macOS 10.12 In-Reply-To: <0A65F222-D58B-440B-A156-E43234E4BA6F@qt.io> References: <0A65F222-D58B-440B-A156-E43234E4BA6F@qt.io> Message-ID: <1B599F8E-92ED-468E-997F-0CD964FF7628@qt.io> > On 19 Jun 2017, at 08:34, J-P Nurmi wrote: > > > [*] The timing, during the 5.9.1 soft freeze week, was a bit unfortunate, but this is a separate discussion. Introducing a new configuration to the CI system should be considered a development task, subject to the usual branch policies. Can we establish that this happens in dev first, ideally before the feature freeze? Morten From Morten.Sorvig at qt.io Mon Jun 19 12:48:42 2017 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Mon, 19 Jun 2017 10:48:42 +0000 Subject: [Development] What changed in the RHEL 6.6 machines that cause tst_QUdpSocket::linkLocalIPv6 to fail? In-Reply-To: <2209669.PjnOdga9Be@tjmaciei-mobl1> References: <2185212.Na4rmT2Jrh@tjmaciei-mobl1> <2209669.PjnOdga9Be@tjmaciei-mobl1> Message-ID: > On 16 Jun 2017, at 23:21, Thiago Macieira wrote: > > On Friday, 16 June 2017 13:23:07 PDT Thiago Macieira wrote: >> QDEBUG : tst_QUdpSocket::linkLocalIPv6(WithoutProxy) >> QHostAddress("fe80::250:56ff:feab:4818%eth1") >> FAIL! : tst_QUdpSocket::linkLocalIPv6(WithoutProxy) >> '(neutralReadSpy.count() >>> 0)' returned FALSE. () >> >> Loc: [../tst_qudpsocket.cpp(1600)] > > Emergency workaround: https://codereview.qt-project.org/197753 > (compiles and works for me on bare metal, no test on a VM) > > This commit basically disables the test entirely on virtual machines. If any > QtNetwork developers use virtual machines, please make sure you get bare-metal > hardware for all three platforms. You won't be doing your job if you continue > with VMs. This does seem a bit heavy-handed to me. - Can we self-test the network interface and QSKIP if it’s not in working order? - We can blacklist on CI only: https://codereview.qt-project.org/#/c/197692/ (modifying that patch to blacklist all Linux CI if needed.) Morten From a.volkov at rusbitech.ru Mon Jun 19 12:52:59 2017 From: a.volkov at rusbitech.ru (Alexander Volkov) Date: Mon, 19 Jun 2017 13:52:59 +0300 Subject: [Development] Enabling private features for separate modules In-Reply-To: <20170619095348.GV18408@troll08> References: <8862eb84-1a19-ca9a-38c4-9a9598c3dd35@rusbitech.ru> <20170619095348.GV18408@troll08> Message-ID: <88a5a328-4bce-4800-a1e7-443c50687547@rusbitech.ru> 19.06.2017 12:53, Oswald Buddenhagen пишет: > On Mon, Jun 19, 2017 at 12:52:12PM +0300, Alexander Volkov wrote: >> Hi, >> >> I build qtwebengine as a separate module. >> What is the right way to enable system-ffmpeg feature? >> > you use > > qmake [usual qmake args] -- [configure args] > $ qmake -- -system-ffmpeg ***Unknown option -system-ffmpeg From dominik.holland at pelagicore.com Mon Jun 19 12:59:35 2017 From: dominik.holland at pelagicore.com (Dominik Holland) Date: Mon, 19 Jun 2017 12:59:35 +0200 Subject: [Development] Enabling private features for separate modules In-Reply-To: <88a5a328-4bce-4800-a1e7-443c50687547@rusbitech.ru> References: <8862eb84-1a19-ca9a-38c4-9a9598c3dd35@rusbitech.ru> <20170619095348.GV18408@troll08> <88a5a328-4bce-4800-a1e7-443c50687547@rusbitech.ru> Message-ID: Am 06/19/2017 um 12:52 PM schrieb Alexander Volkov: > 19.06.2017 12:53, Oswald Buddenhagen пишет: >> On Mon, Jun 19, 2017 at 12:52:12PM +0300, Alexander Volkov wrote: >>> Hi, >>> >>> I build qtwebengine as a separate module. >>> What is the right way to enable system-ffmpeg feature? >>> >> you use >> >> qmake [usual qmake args] -- [configure args] >> > > $ qmake -- -system-ffmpeg > ***Unknown option -system-ffmpeg I think it needs to be: qmake -- --enable-system-ffmpeg if you want to add your own options you can also add a "commandline" section to configure.json Dominik From tony.sarajarvi at qt.io Mon Jun 19 13:09:31 2017 From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=) Date: Mon, 19 Jun 2017 11:09:31 +0000 Subject: [Development] Flaky auto tests on macOS 10.12 In-Reply-To: <1B599F8E-92ED-468E-997F-0CD964FF7628@qt.io> References: <0A65F222-D58B-440B-A156-E43234E4BA6F@qt.io> <1B599F8E-92ED-468E-997F-0CD964FF7628@qt.io> Message-ID: It is the intention that we do this. But we're constantly running, not beside our horse, but after it. We have just begun activating ourselves to discuss about 5.10 platforms and we have FF coming up in two weeks (counting out July here). It took months to blacklist all the cases for 10.12 alone. So yes, I agree that how we do this is not good, but at some point we find it good enough. I ran qt5 builds through twice without failures and deemed it fit. Before that I kept blacklisting everything I saw (which actually isn't good either). Dev branch is actually the place where they should be put yes. Unfortunately we are too late for that. We need 10.12 in 5.9, and for it to still be in dev branch, we should have put it in January. We were still working with our 5.8 platforms at that time. As I said...the horse is running away from us 😉 -Tony -----Original Message----- From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Morten Sørvig Sent: maanantai 19. kesäkuuta 2017 13.40 To: development at qt-project.org Subject: Re: [Development] Flaky auto tests on macOS 10.12 > On 19 Jun 2017, at 08:34, J-P Nurmi wrote: > > > [*] The timing, during the 5.9.1 soft freeze week, was a bit unfortunate, but this is a separate discussion. Introducing a new configuration to the CI system should be considered a development task, subject to the usual branch policies. Can we establish that this happens in dev first, ideally before the feature freeze? Morten _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From a.volkov at rusbitech.ru Mon Jun 19 13:33:12 2017 From: a.volkov at rusbitech.ru (Alexander Volkov) Date: Mon, 19 Jun 2017 14:33:12 +0300 Subject: [Development] Enabling private features for separate modules In-Reply-To: References: <8862eb84-1a19-ca9a-38c4-9a9598c3dd35@rusbitech.ru> <20170619095348.GV18408@troll08> <88a5a328-4bce-4800-a1e7-443c50687547@rusbitech.ru> Message-ID: <6b9c025e-7e73-5e2a-78c9-8765fcd0cb55@rusbitech.ru> 19.06.2017 13:59, Dominik Holland пишет: >> $ qmake -- -system-ffmpeg >> ***Unknown option -system-ffmpeg > I think it needs to be: > > qmake -- --enable-system-ffmpeg > > if you want to add your own options you can also add a "commandline" > section to configure.json It also doesn't work. Somehow this way of passing extra arguments with '--' doesn't work in release builds. I tested it in my developer build and it works. Also I found that it was introduced by https://codereview.qt-project.org/#/c/159056/ and there is another way of passing extra arguments with QMAKE_EXTRA_ARGS: qmake QMAKE_EXTRA_ARGS+="-system-ffmpeg" works. From Morten.Sorvig at qt.io Mon Jun 19 14:31:01 2017 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Mon, 19 Jun 2017 12:31:01 +0000 Subject: [Development] Flaky auto tests on macOS 10.12 In-Reply-To: References: <0A65F222-D58B-440B-A156-E43234E4BA6F@qt.io> <1B599F8E-92ED-468E-997F-0CD964FF7628@qt.io> Message-ID: <8E91C050-4799-4563-8B2F-EC20464A6AF6@qt.io> > On 19 Jun 2017, at 13:09, Tony Sarajärvi wrote: > > It is the intention that we do this. But we're constantly running, not beside our horse, but after it. We have just begun activating ourselves to discuss about 5.10 platforms and we have FF coming up in two weeks (counting out July here). > It took months to blacklist all the cases for 10.12 alone. So yes, I agree that how we do this is not good, but at some point we find it good enough. I ran qt5 builds through twice without failures and deemed it fit. Before that I kept blacklisting everything I saw (which actually isn't good either). > > Dev branch is actually the place where they should be put yes. Unfortunately we are too late for that. We need 10.12 in 5.9, and for it to still be in dev branch, we should have put it in January. We were still working with our 5.8 platforms at that time. As I said...the horse is running away from us 😉 The process could be (using the current branches and os versions as examples): - Add 10.12 to dev. - Stabilize/fix/blacklist (backport changes to 5.9) - Qt is now tested on 10.12. Also the 5.9 codebase, since it is similar to dev. - Then add 10.12 to 5.9 - With less disruption since Qt already has been stabilized. Morten From kde at carewolf.com Mon Jun 19 15:18:09 2017 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Mon, 19 Jun 2017 15:18:09 +0200 Subject: [Development] Enabling private features for separate modules In-Reply-To: <8862eb84-1a19-ca9a-38c4-9a9598c3dd35@rusbitech.ru> References: <8862eb84-1a19-ca9a-38c4-9a9598c3dd35@rusbitech.ru> Message-ID: <1749491.0S8jN3CFWF@twilight> On Montag, 19. Juni 2017 11:52:12 CEST Alexander Volkov wrote: > Hi, > > I build qtwebengine as a separate module. > What is the right way to enable system-ffmpeg feature? > It's not auto-detected: > "system-ffmpeg": { > "label": "ffmpeg", > "autoDetect": false, > "condition": "libs.ffmpeg && features.system-opus && > features.system-webp", > "output": [ "privateFeature" ] > } > If all else fail you can always edit the generate qtwebengine-config.pri file and move the feature from disabled features to enabled features. ' Allan From thiago.macieira at intel.com Mon Jun 19 17:34:40 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 19 Jun 2017 08:34:40 -0700 Subject: [Development] What changed in the RHEL 6.6 machines that cause tst_QUdpSocket::linkLocalIPv6 to fail? In-Reply-To: References: <2185212.Na4rmT2Jrh@tjmaciei-mobl1> <2209669.PjnOdga9Be@tjmaciei-mobl1> Message-ID: <2115990.25ASScUbNh@tjmaciei-mobl1> On Monday, 19 June 2017 03:48:42 PDT Morten Sørvig wrote: > - Can we self-test the network interface and QSKIP if it’s not in working > order? That's the test itself: it tries to send a packet back to itself and see if it arrives. > - We can blacklist on CI only: > https://codereview.qt-project.org/#/c/197692/ (modifying that patch to > blacklist all Linux CI if needed.) I don't believe in blacklisting if we can find and fix the root cause. That's what I did for the "utun" interface on Darwin machines, when a blacklist was proposed. But I haven't been able to figure that out for RHEL yet. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oswald.buddenhagen at qt.io Mon Jun 19 19:06:25 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 19 Jun 2017 19:06:25 +0200 Subject: [Development] Enabling private features for separate modules In-Reply-To: <88a5a328-4bce-4800-a1e7-443c50687547@rusbitech.ru> References: <8862eb84-1a19-ca9a-38c4-9a9598c3dd35@rusbitech.ru> <20170619095348.GV18408@troll08> <88a5a328-4bce-4800-a1e7-443c50687547@rusbitech.ru> Message-ID: <20170619170625.GW18408@troll08> On Mon, Jun 19, 2017 at 01:52:59PM +0300, Alexander Volkov wrote: > 19.06.2017 12:53, Oswald Buddenhagen пишет: > > On Mon, Jun 19, 2017 at 12:52:12PM +0300, Alexander Volkov wrote: > >> Hi, > >> > >> I build qtwebengine as a separate module. > >> What is the right way to enable system-ffmpeg feature? > >> > > you use > > > > qmake [usual qmake args] -- [configure args] > > > > $ qmake -- -system-ffmpeg > ***Unknown option -system-ffmpeg > you need to specify a file/directory, if only ".". From a.volkov at rusbitech.ru Mon Jun 19 19:32:43 2017 From: a.volkov at rusbitech.ru (Alexander Volkov) Date: Mon, 19 Jun 2017 20:32:43 +0300 Subject: [Development] Enabling private features for separate modules In-Reply-To: <20170619170625.GW18408@troll08> References: <8862eb84-1a19-ca9a-38c4-9a9598c3dd35@rusbitech.ru> <20170619095348.GV18408@troll08> <88a5a328-4bce-4800-a1e7-443c50687547@rusbitech.ru> <20170619170625.GW18408@troll08> Message-ID: <06440842-7c1b-2fad-8dae-d59b20ac45d6@rusbitech.ru> 19.06.2017 20:06, Oswald Buddenhagen пишет: > On Mon, Jun 19, 2017 at 01:52:59PM +0300, Alexander Volkov wrote: >> 19.06.2017 12:53, Oswald Buddenhagen пишет: >>> On Mon, Jun 19, 2017 at 12:52:12PM +0300, Alexander Volkov wrote: >>>> Hi, >>>> >>>> I build qtwebengine as a separate module. >>>> What is the right way to enable system-ffmpeg feature? >>>> >>> you use >>> >>> qmake [usual qmake args] -- [configure args] >>> >> $ qmake -- -system-ffmpeg >> ***Unknown option -system-ffmpeg >> > you need to specify a file/directory, if only ".". > Yes, it works this way, thanks. Is there a reason for such behavior or is it a bug? From oswald.buddenhagen at qt.io Tue Jun 20 08:32:35 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 20 Jun 2017 08:32:35 +0200 Subject: [Development] Enabling private features for separate modules In-Reply-To: <06440842-7c1b-2fad-8dae-d59b20ac45d6@rusbitech.ru> References: <8862eb84-1a19-ca9a-38c4-9a9598c3dd35@rusbitech.ru> <20170619095348.GV18408@troll08> <88a5a328-4bce-4800-a1e7-443c50687547@rusbitech.ru> <20170619170625.GW18408@troll08> <06440842-7c1b-2fad-8dae-d59b20ac45d6@rusbitech.ru> Message-ID: <20170620063235.GA25928@ugly> On Mon, Jun 19, 2017 at 08:32:43PM +0300, Alexander Volkov wrote: > 19.06.2017 20:06, Oswald Buddenhagen пишет: > > On Mon, Jun 19, 2017 at 01:52:59PM +0300, Alexander Volkov wrote: > >> $ qmake -- -system-ffmpeg > >> ***Unknown option -system-ffmpeg > >> > > you need to specify a file/directory, if only ".". > > > Yes, it works this way, thanks. > Is there a reason for such behavior or is it a bug? > bug. patches welcome. From Morten.Sorvig at qt.io Tue Jun 20 11:14:20 2017 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Tue, 20 Jun 2017 09:14:20 +0000 Subject: [Development] What changed in the RHEL 6.6 machines that cause tst_QUdpSocket::linkLocalIPv6 to fail? In-Reply-To: <2115990.25ASScUbNh@tjmaciei-mobl1> References: <2185212.Na4rmT2Jrh@tjmaciei-mobl1> <2209669.PjnOdga9Be@tjmaciei-mobl1> <2115990.25ASScUbNh@tjmaciei-mobl1> Message-ID: <10C253C8-18A0-488B-A86D-0241788A92E7@qt.io> > On 19 Jun 2017, at 17:34, Thiago Macieira wrote: > > On Monday, 19 June 2017 03:48:42 PDT Morten Sørvig wrote: >> - Can we self-test the network interface and QSKIP if it’s not in working >> order? > > That's the test itself: it tries to send a packet back to itself and see if it > arrives. Yes, but the system under test is the Qt network stack, not the OS network stack. So if the OS network stack is missing or not operable that’s a N/A result, not a fail. Though as a practical matter having a test sometimes SKIPs based on external conditions might be too unpredictable. > >> - We can blacklist on CI only: >> https://codereview.qt-project.org/#/c/197692/ (modifying that patch to >> blacklist all Linux CI if needed.) > > I don't believe in blacklisting if we can find and fix the root cause. That's > what I did for the "utun" interface on Darwin machines, when a blacklist was > proposed. But I haven't been able to figure that out for RHEL yet. I agree that getting to the root cause is preferable. We can do both: blacklist immediately to get integrations going again while investigating. Morten From edward.welbourne at qt.io Tue Jun 20 11:40:37 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 20 Jun 2017 09:40:37 +0000 Subject: [Development] What changed in the RHEL 6.6 machines that cause tst_QUdpSocket::linkLocalIPv6 to fail? In-Reply-To: <10C253C8-18A0-488B-A86D-0241788A92E7@qt.io> References: <2185212.Na4rmT2Jrh@tjmaciei-mobl1> <2209669.PjnOdga9Be@tjmaciei-mobl1> <2115990.25ASScUbNh@tjmaciei-mobl1>, <10C253C8-18A0-488B-A86D-0241788A92E7@qt.io> Message-ID: Morten Sørvig (20 June 2017 11:14): > I agree that getting to the root cause is preferable. We can do both: > blacklist immediately to get integrations going again while > investigating. https://codereview.qt-project.org/196699 has done that, in 5.9; we just need an upmerge to dev to get going again, Eddy. From Simon.Hausmann at qt.io Tue Jun 20 11:41:18 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 20 Jun 2017 09:41:18 +0000 Subject: [Development] What changed in the RHEL 6.6 machines that cause tst_QUdpSocket::linkLocalIPv6 to fail? In-Reply-To: References: <2185212.Na4rmT2Jrh@tjmaciei-mobl1> <2209669.PjnOdga9Be@tjmaciei-mobl1> <2115990.25ASScUbNh@tjmaciei-mobl1>, <10C253C8-18A0-488B-A86D-0241788A92E7@qt.io>, Message-ID: The upmerge went in this morning. qtbase dev should be fine again. In parallel we're investing the root cause. Simon ________________________________ From: Development on behalf of Edward Welbourne Sent: Tuesday, June 20, 2017 11:40:37 AM To: Morten Sørvig Cc: Qt Project Development Mailing-List Subject: Re: [Development] What changed in the RHEL 6.6 machines that cause tst_QUdpSocket::linkLocalIPv6 to fail? Morten Sørvig (20 June 2017 11:14): > I agree that getting to the root cause is preferable. We can do both: > blacklist immediately to get integrations going again while > investigating. https://codereview.qt-project.org/196699 has done that, in 5.9; we just need an upmerge to dev to get going again, Eddy. _______________________________________________ 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 Morten.Sorvig at qt.io Tue Jun 20 13:56:17 2017 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Tue, 20 Jun 2017 11:56:17 +0000 Subject: [Development] Flaky auto tests on macOS 10.12 In-Reply-To: <0A65F222-D58B-440B-A156-E43234E4BA6F@qt.io> References: <0A65F222-D58B-440B-A156-E43234E4BA6F@qt.io> Message-ID: > On 19 Jun 2017, at 08:34, J-P Nurmi wrote: > > Hi all, > > After a few successful qt5.git CI rounds, auto tests were enabled for macOS 10.12 in the CI last week. [*] Even though many flaky auto tests had been already blacklisted on macOS 10.12 earlier (https://bugreports.qt.io/browse/QTBUG-58968), it became nearly impossible to integrate any qtbase patch due to random timer/eventloop/animation related auto test failures on macOS 10.12. As agreed earlier (http://lists.qt-project.org/pipermail/development/2017-February/028715.html), an action was taken to blacklist/skip several more auto tests on macOS 10.12: I went through the list and most of these are not reproducible locally. (see list below for details). This matches the pattern we’ve been seeing for some time with CI-only failures. So I think the priority for the reports should be reduced once the tests have been blacklisted and they are no longer blocking development, due to them being hard to reproduce as well as being less likely to be hit by users. Morten > > Extend blacklisting of tst_QElapsedTimer::elapsed to cover macOS 10.12 > - https://bugreports.qt.io/browse/QTBUG-58713 > - https://codereview.qt-project.org/#/c/195625/ Not reproducible. > > Blacklist tst_QGuiEventLoop::processEvents in macOS 10.12 > - https://bugreports.qt.io/browse/QTBUG-61131 > - https://codereview.qt-project.org/#/c/196087/ Reproducible. Looks like 10.12 is sending an extra event at startup which the test fails to account for (see QTBUG-61131 for details). > > Blacklist flaky tst_QTimeLine tests on macOS 10.12 > - https://bugreports.qt.io/browse/QTBUG-61037 > - https://codereview.qt-project.org/#/c/195608/ Not reproducible. > > Skip unreliable tst_QTimer::moveToThread() on macOS 10.12 > - https://bugreports.qt.io/browse/QTBUG-59679 > - https://codereview.qt-project.org/#/c/197769/ Not reproducible (however, warnings). QWARN : tst_QTimer::moveToThread() QObject::killTimer: Timers cannot be stopped from another thread QWARN : tst_QTimer::moveToThread() QObject::~QObject: Timers cannot be stopped from another thread > > Blacklist flaky tst_QGuiEventLoop::testQuitLock() on macOS 10.12 > - https://bugreports.qt.io/browse/QTBUG-61499 > - https://codereview.qt-project.org/#/c/197791/ Not reproducible. > > Blacklist tst_QParallelAnimationGroup::deleteChildrenWithRunningGroup() > - https://bugreports.qt.io/browse/QTBUG-61500 > - https://codereview.qt-project.org/#/c/197792/ Not reproducible. From tor.arne.vestbo at qt.io Tue Jun 20 14:17:39 2017 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Tue, 20 Jun 2017 14:17:39 +0200 Subject: [Development] Flaky auto tests on macOS 10.12 In-Reply-To: References: <0A65F222-D58B-440B-A156-E43234E4BA6F@qt.io> Message-ID: <7e7f22cf-a121-a9d7-32d0-2a19f35efee2@qt.io> On 20/06/2017 13:56, Morten Sørvig wrote: >> Blacklist flaky tst_QGuiEventLoop::testQuitLock() on macOS 10.12 >> - https://bugreports.qt.io/browse/QTBUG-61499 >> - https://codereview.qt-project.org/#/c/197791/ > > Not reproducible. I could repro this on 10.10-10.13 under load. tor arne From thiago.macieira at intel.com Tue Jun 20 16:52:40 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 20 Jun 2017 07:52:40 -0700 Subject: [Development] What changed in the RHEL 6.6 machines that cause tst_QUdpSocket::linkLocalIPv6 to fail? In-Reply-To: <10C253C8-18A0-488B-A86D-0241788A92E7@qt.io> References: <2185212.Na4rmT2Jrh@tjmaciei-mobl1> <2115990.25ASScUbNh@tjmaciei-mobl1> <10C253C8-18A0-488B-A86D-0241788A92E7@qt.io> Message-ID: <1665172.LlSPbjbBZm@tjmaciei-mobl1> On Tuesday, 20 June 2017 02:14:20 PDT Morten Sørvig wrote: > Yes, but the system under test is the Qt network stack, not the OS network > stack. So if the OS network stack is missing or not operable that’s a N/A > result, not a fail. It's not too difficult to write the native code to do the same. It's just cumbersome, because we need to write it twice (BSD sockets and WinSock). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ari.salmi at snowgrains.com Wed Jun 21 12:58:48 2017 From: ari.salmi at snowgrains.com (Ari Salmi) Date: Wed, 21 Jun 2017 13:58:48 +0300 Subject: [Development] QtCloudMessaging repository request to Qt Message-ID: Hi there, I am developing a Qt API to wrap cloud push services to mobile apps and embedded devices. This includes examples for using Google Firebase (firebase.google.com) for mobile app development and similar a solution for embedded space as well (which has increasing demand). For contribution to Qt the new repository is needed. Name of the project: Qt Cloud Messaging Responsible person: Ari Salmi / SnowGrains gerrit username: snowgrains gerrit email: snowgrains at snowgrains.com desired repository name: qtcloudmessaging Some background: The closest match is the Qt Mobility's QMessaging service, which more or less concentrated to SMS, mms and email services inside a (nokia) phones taking care of the contacts etc. Unfortunately that API is not expandable to other platforms and cannot be used. One aim on this is to create Qt API that wraps (and developers can do more wrappers with same API) e.g. Google firebase, or onesignal type of push messaging services - for mobile and desktop apps. More important aim is to provide similar messaging to/from iot and other embedded devices, like cars. This is the place where we are lacking the offering from the Qt point of view. One embedded backend solution that has scale able offering is Kaltiot.com. I've included it as one backend for embedded story. Thank you and best regards, Ari -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesus.fernandez at qt.io Wed Jun 21 13:07:43 2017 From: jesus.fernandez at qt.io (Jesus Fernandez) Date: Wed, 21 Jun 2017 11:07:43 +0000 Subject: [Development] QtCloudMessaging repository request to Qt In-Reply-To: References: Message-ID: Hi Ari, Is your project dependent on QtNetworkAuth for dealing with Google API? Best regards, Jesús -- Best regards, Jesús On 2017-06-21 12:59:05+02:00 Ari Salmi wrote: Hi there, I am developing a Qt API to wrap cloud push services to mobile apps and embedded devices. This includes examples for using Google Firebase (firebase.google.com) for mobile app development and similar a solution for embedded space as well (which has increasing demand). For contribution to Qt the new repository is needed. Name of the project: Qt Cloud Messaging Responsible person: Ari Salmi / SnowGrains gerrit username: snowgrains gerrit email: snowgrains at snowgrains.com desired repository name: qtcloudmessaging Some background: The closest match is the Qt Mobility's QMessaging service, which more or less concentrated to SMS, mms and email services inside a (nokia) phones taking care of the contacts etc. Unfortunately that API is not expandable to other platforms and cannot be used. One aim on this is to create Qt API that wraps (and developers can do more wrappers with same API) e.g. Google firebase, or onesignal type of push messaging services - for mobile and desktop apps. More important aim is to provide similar messaging to/from iot and other embedded devices, like cars. This is the place where we are lacking the offering from the Qt point of view. One embedded backend solution that has scale able offering is Kaltiot.com. I've included it as one backend for embedded story. Thank you and best regards, Ari -------------- next part -------------- An HTML attachment was scrubbed... URL: From ari.salmi at snowgrains.com Wed Jun 21 13:19:13 2017 From: ari.salmi at snowgrains.com (Ari Salmi) Date: Wed, 21 Jun 2017 14:19:13 +0300 Subject: [Development] QtCloudMessaging repository request to Qt In-Reply-To: References: Message-ID: Hi Jesús, Thanks for question and reaction! Qt Cloud Messaging API itself is not dependent on QtNetworkAuth, but it can be backend-solution dependent. e.g: Google firebase backend solution for Android and iOS are using firebase's c++ binaries (which app developer should give env, path when compiling) and real communication goes through those elements. Also in addition developer can create the cloud messaging server elements also with this same API, so I've included REST API interfaces (QtNetwork) to firebase and to Kaltiot.com backends. Those needs (after Qt5.6) libssl and libcrypto libraries included in to the applications (included in the example). Thanks, Ari br, Ari Ari Salmi SnowGrains 2017-06-21 14:07 GMT+03:00 Jesus Fernandez : > Hi Ari, > > Is your project dependent on QtNetworkAuth for dealing with Google API? > > Best regards, > Jesús > -- > Best regards, > Jesús > > > On 2017-06-21 12:59:05+02:00 Ari Salmi wrote: > > Hi there, > > I am developing a Qt API to wrap cloud push services to mobile apps and > embedded devices. > This includes examples for using Google Firebase (firebase.google.com) > for mobile app development and similar a solution for embedded space as > well (which has increasing demand). > > For contribution to Qt the new repository is needed. > > Name of the project: > Qt Cloud Messaging > > Responsible person: > Ari Salmi / SnowGrains > gerrit username: snowgrains > gerrit email: snowgrains at snowgrains.com > > desired repository name: > qtcloudmessaging > Some background: > The closest match is the Qt Mobility's QMessaging service, which more or > less concentrated to SMS, mms and email services inside a (nokia) phones > taking care of the contacts etc. Unfortunately that API is not expandable > to other platforms and cannot be used. One aim on this is to create Qt API > that wraps (and developers can do more wrappers with same API) e.g. Google > firebase, or onesignal type of push messaging services - for mobile > and desktop apps. > > More important aim is to provide similar messaging to/from iot and other > embedded devices, like cars. This is the place where we are lacking the > offering from the Qt point of view. One embedded backend solution that has > scale able offering is Kaltiot.com. I've included it as one backend for > embedded story. > Thank you and best regards, > Ari > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesus.fernandez at qt.io Wed Jun 21 13:24:39 2017 From: jesus.fernandez at qt.io (Jesus Fernandez) Date: Wed, 21 Jun 2017 11:24:39 +0000 Subject: [Development] QtCloudMessaging repository request to Qt In-Reply-To: References: , Message-ID: With QtNetworkAuth + QNetworkAccessManager the Firebase C++ API is not needed. So it will remove this dependency and support more platforms than the platforms supported by the Firebase libs. Thank you for the explanation :) -- Best regards, Jesús On 2017-06-21 13:19:24+02:00 Ari Salmi wrote: Hi Jesús, Thanks for question and reaction! Qt Cloud Messaging API itself is not dependent on QtNetworkAuth, but it can be backend-solution dependent. e.g: Google firebase backend solution for Android and iOS are using firebase's c++ binaries (which app developer should give env, path when compiling) and real communication goes through those elements. Also in addition developer can create the cloud messaging server elements also with this same API, so I've included REST API interfaces (QtNetwork) to firebase and to Kaltiot.com backends. Those needs (after Qt5.6) libssl and libcrypto libraries included in to the applications (included in the example). Thanks, Ari br, Ari Ari Salmi SnowGrains 2017-06-21 14:07 GMT+03:00 Jesus Fernandez >: Hi Ari, Is your project dependent on QtNetworkAuth for dealing with Google API? Best regards, Jesús -- Best regards, Jesús On 2017-06-21 12:59:05+02:00 Ari Salmi wrote: Hi there, I am developing a Qt API to wrap cloud push services to mobile apps and embedded devices. This includes examples for using Google Firebase (firebase.google.com) for mobile app development and similar a solution for embedded space as well (which has increasing demand). For contribution to Qt the new repository is needed. Name of the project: Qt Cloud Messaging Responsible person: Ari Salmi / SnowGrains gerrit username: snowgrains gerrit email: snowgrains at snowgrains.com desired repository name: qtcloudmessaging Some background: The closest match is the Qt Mobility's QMessaging service, which more or less concentrated to SMS, mms and email services inside a (nokia) phones taking care of the contacts etc. Unfortunately that API is not expandable to other platforms and cannot be used. One aim on this is to create Qt API that wraps (and developers can do more wrappers with same API) e.g. Google firebase, or onesignal type of push messaging services - for mobile and desktop apps. More important aim is to provide similar messaging to/from iot and other embedded devices, like cars. This is the place where we are lacking the offering from the Qt point of view. One embedded backend solution that has scale able offering is Kaltiot.com. I've included it as one backend for embedded story. Thank you and best regards, Ari -------------- next part -------------- An HTML attachment was scrubbed... URL: From mardy at users.sourceforge.net Thu Jun 22 23:20:39 2017 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Thu, 22 Jun 2017 23:20:39 +0200 Subject: [Development] XMLHttpRequest.send() with arbitrary data Message-ID: <75013edd-d7f9-0d55-a507-4ad386b11c49@users.sourceforge.net> Hi all, my understanding looking at the implementation of the XMLHttpRequest.send() method in QtDeclarative [1] is that the said method only accepts UTF-8 data as parameter. Now, I would like to be able to send arbitrary data (in order to, for example, upload a JPEG image to flickr) and I believe that the limitation above is preventing me from doing so: my QByteArray (which I'm actually preparing from the C++ side and then converting into a QString with QString::fromUtf8()) is not being transmitted properly. No surprise here, as I understand that the QString::fromUtf8() method will stop as soon as a zero byte is found. But than, what is the way forward? I see that javascript has some more types such as Blob and ArrayBufferView, which at least judging by the name could be suitable types for transporting binary data. I see that there is a newArrayBuffer() method in QJSEngine's private class; would exporting that to the client help in any way? Or should the implementation of XMLHttpRequest.send() try to first convert its parameter to a QByteArray (via QJSValue::fromScriptValue()) and only fallback to QString if that fails? Ciao, Alberto [1]: http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/qml/qml/qqmlxmlhttprequest.cpp?h=dev#n1814 From Liang.Qi at qt.io Fri Jun 23 09:27:48 2017 From: Liang.Qi at qt.io (Liang Qi) Date: Fri, 23 Jun 2017 07:27:48 +0000 Subject: [Development] qtbase dev is blocked in CI Message-ID: <5B45B01B-3566-42FF-80C7-7FF19B4FE8D0@qt.io> Hi, There is an integration sucks from last night for qtbase dev branch. And we can’t restart coin to cancel it due to current 5.9.1 integrations. Hope we can fix the issue this afternoon or a bit later today. So please don’t stage changes in qtbase dev for now, thanks. Best Regards, Liang From Simon.Hausmann at qt.io Fri Jun 23 10:08:05 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 23 Jun 2017 08:08:05 +0000 Subject: [Development] XMLHttpRequest.send() with arbitrary data In-Reply-To: <75013edd-d7f9-0d55-a507-4ad386b11c49@users.sourceforge.net> References: <75013edd-d7f9-0d55-a507-4ad386b11c49@users.sourceforge.net> Message-ID: Hi, I think send() should be fixed to support more than just strings as parameters. For example in browsers you can use send() with array buffers and blob objects. We don't support the latter, but the former we do and they are also our mapping for QByteArray. Want to give it a try? It should be a relatively straight-forward change and we have good XHR test coverage, so it should be easy to extend the tests to cover this. Simon ________________________________ From: Development on behalf of Alberto Mardegan Sent: Thursday, June 22, 2017 11:20:39 PM To: development at qt-project.org Subject: [Development] XMLHttpRequest.send() with arbitrary data Hi all, my understanding looking at the implementation of the XMLHttpRequest.send() method in QtDeclarative [1] is that the said method only accepts UTF-8 data as parameter. Now, I would like to be able to send arbitrary data (in order to, for example, upload a JPEG image to flickr) and I believe that the limitation above is preventing me from doing so: my QByteArray (which I'm actually preparing from the C++ side and then converting into a QString with QString::fromUtf8()) is not being transmitted properly. No surprise here, as I understand that the QString::fromUtf8() method will stop as soon as a zero byte is found. But than, what is the way forward? I see that javascript has some more types such as Blob and ArrayBufferView, which at least judging by the name could be suitable types for transporting binary data. I see that there is a newArrayBuffer() method in QJSEngine's private class; would exporting that to the client help in any way? Or should the implementation of XMLHttpRequest.send() try to first convert its parameter to a QByteArray (via QJSValue::fromScriptValue()) and only fallback to QString if that fails? Ciao, Alberto [1]: http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/qml/qml/qqmlxmlhttprequest.cpp?h=dev#n1814 _______________________________________________ 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 alexander.blasche at qt.io Fri Jun 23 13:43:02 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Fri, 23 Jun 2017 11:43:02 +0000 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: <20170617141424.0FA8.6F0322A@gmail.com> References: <1968163.2PbfAQ7WLo@tjmaciei-mobl1> <20170617091418.GA1628@klara.mpi.htwm.de> <20170617141424.0FA8.6F0322A@gmail.com> Message-ID: Him I'd like to update and conclude this discussion. After crunching the numbers, we have a 30% download ratio for MSVC2013 (compared to total Win downloads including 5.9.0). That's a very significant amount. Theerfore we cannot drop MSVC2013. At the same time the confirmation was given that 5.11 will no longer support MSVC2013. Once dev has been branched off for Qt 5.10 development, feel free to make use of this decision in the new (5.11) dev branch. -- Alex > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Philippe > Sent: Saturday, 17 June 2017 14:14 > To: development at qt-project.org > Subject: Re: [Development] Let's please drop MSVC 2013 for 5.10 > > > Decision making should weigh pros and cons. The observed pattern is > > however "We see something sub-optimal, therefore we choose the other > > approach, not matter matter what". This is unreasonable. > > I don't see reasonnable the use of the latest Qt technology on one hand (5.10), > together with an old compiler (VS 2013) that does not even support well the C++ > standard defined back in 2011. > > This sounds reasonnable that ressources are spent fixing Qt issues rather than > solutions around compiler quirks. > > If some users think otherwise, they can still modify Qt (5.10) to use with their old > favorite compiler. > > Philippe > > On Sat, 17 Jun 2017 11:14:18 +0200 > André Pönitz wrote: > > > On Fri, Jun 16, 2017 at 07:09:20PM -0700, Thiago Macieira wrote: > > > On Friday, 16 June 2017 16:35:54 PDT André Pönitz wrote: > > > > On Fri, Jun 16, 2017 at 12:52:24PM -0700, Thiago Macieira wrote: > > > > > Here's a tricky question: how do you create a QStringLiteral > > > > > with non-ASCII characters that will work on all our supported > > > > > compilers? > > > > > > > > I don't have to, unless I have profiler supported evidence that it > > > > matters. > > > > > > QStringLiteral is infinitely faster at runtime than QString::fromUtf8. > > > It also occupies roughly 33% less memory than QString::fromUtf8 of a > > > literal, as the latter needs the narrow character equivalent > > > (read-only memory) plus the UTF-16 converted text (heap, which has > > > overhead). > > > > We are talking about a handful strings with non-7-bit chars, mostly in > > tests. > > > > Cycles spend for these cases will never sum up to the order of > > magnitude to one failed CI integration. > > > > > This is for a simple, static message. > > > > > > > In the common case where it does not matter, the string can be > > > > created at run time. > > > > > > At a cost and overhead. > > > > Dwarfed by the costs of the proposed alternative. > > > > > > QSTRINGLITERAL('M', 0xf6, 0xf6, 0xf6, 'p', '!') > > > > > > > > instead of > > > > > > > > QStringLiteral("Möööp!") > > > > > > Yeah, no thanks. > > > > We are talking about a handful strings with non-7-bit chars, mostly in > > tests. > > > > Worse uglifications have been proposed to Qt proper for even less > > gain. > > > > > The whole point is that we can do better. All we need to do is drop > > > an old, buggy compiler. > > > > That's not 'better', that's a price to pay. > > > > I don't have any stake in MSVC nor in Windows in general, in fact > > given that it's weekend, I do not care at all. > > > > Decision making should weigh pros and cons. The observed pattern is > > however "We see something sub-optimal, therefore we choose the other > > approach, not matter matter what". This is unreasonable. > > > > Andre' > > _______________________________________________ > > 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 mardy at users.sourceforge.net Fri Jun 23 15:06:56 2017 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Fri, 23 Jun 2017 15:06:56 +0200 Subject: [Development] XMLHttpRequest.send() with arbitrary data In-Reply-To: References: <75013edd-d7f9-0d55-a507-4ad386b11c49@users.sourceforge.net> Message-ID: <85561b61-a6ca-5f13-ec89-232ac1a5d9d4@users.sourceforge.net> On 06/23/2017 10:08 AM, Simon Hausmann wrote: > I think send() should be fixed to support more than just strings as > parameters. For example in browsers > > you can use send() with array buffers and blob objects. We don't support > the latter, but the former we do > > and they are also our mapping for QByteArray. > > > Want to give it a try? It should be a relatively straight-forward change > and we have good XHR test coverage, so > > it should be easy to extend the tests to cover this. Why not :-) I filed https://bugreports.qt.io/browse/QTBUG-61599, feel free to assign that to me. Ciao, Alberto From thiago.macieira at intel.com Fri Jun 23 17:52:20 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 23 Jun 2017 08:52:20 -0700 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: References: <1968163.2PbfAQ7WLo@tjmaciei-mobl1> <20170617141424.0FA8.6F0322A@gmail.com> Message-ID: <2158433.yyUIndMjxJ@tjmaciei-mobl1> On Friday, 23 June 2017 04:43:02 PDT Alex Blasche wrote: > Him > > I'd like to update and conclude this discussion. > > After crunching the numbers, we have a 30% download ratio for MSVC2013 > (compared to total Win downloads including 5.9.0). That's a very > significant amount. Theerfore we cannot drop MSVC2013. At the same time the > confirmation was given that 5.11 will no longer support MSVC2013. Once dev > has been branched off for Qt 5.10 development, feel free to make use of > this decision in the new (5.11) dev branch. Thanks for the numbers, Alex. It's still too high a use for us to drop it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Fri Jun 23 18:17:55 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 23 Jun 2017 18:17:55 +0200 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: <2158433.yyUIndMjxJ@tjmaciei-mobl1> References: <1968163.2PbfAQ7WLo@tjmaciei-mobl1> <20170617141424.0FA8.6F0322A@gmail.com> <2158433.yyUIndMjxJ@tjmaciei-mobl1> Message-ID: On 2017-06-23 17:52, Thiago Macieira wrote: > On Friday, 23 June 2017 04:43:02 PDT Alex Blasche wrote: >> Him >> >> I'd like to update and conclude this discussion. >> >> After crunching the numbers, we have a 30% download ratio for MSVC2013 >> (compared to total Win downloads including 5.9.0). That's a very >> significant amount. Theerfore we cannot drop MSVC2013. At the same >> time the >> confirmation was given that 5.11 will no longer support MSVC2013. Once >> dev >> has been branched off for Qt 5.10 development, feel free to make use >> of >> this decision in the new (5.11) dev branch. > > Thanks for the numbers, Alex. It's still too high a use for us to drop > it. I don't care much, as QStringView does compile with MSVC2013 already, and QStringViewLiteral is private API, *but*: The above argument makes no sense to me. What value does quoting download numbers for 5.9, an LTS, have, to argue about dropping the compiler from 5.10. Ever since we provide LTSs (yes, once), we drop compilers in the version _after_ the LTS, which is kind of the natural point to drop stuff. This whole thing reminds me of the MSVC 2012 discussion for 5.7. In the end, we dropped 2012 for 5.7, and with it the whole WinCE platform. Now, 18 months later, 2013 is in exactly the same position as 2012 was back then, except dropping 2013 does not entail dropping a whole MS ecosystem, too. Do you have the download stats of 5.6 for MSVC 2012 from 18 months ago? I'd not be surprised if 2012 had 30% share back then, too. Those users are served by 5.6 LTS for another 18 months as much as 2013 users will be served by 5.9 LTS for another *three years*. Thanks, Marc From thiago.macieira at intel.com Fri Jun 23 19:50:48 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 23 Jun 2017 10:50:48 -0700 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: References: <1968163.2PbfAQ7WLo@tjmaciei-mobl1> <2158433.yyUIndMjxJ@tjmaciei-mobl1> Message-ID: <5596248.PT29qLocbZ@tjmaciei-mobl1> On Friday, 23 June 2017 09:17:55 PDT Marc Mutz wrote: > The above argument makes no sense to me. What value does quoting > download numbers for 5.9, an LTS, have, to argue about dropping the > compiler from 5.10. Ever since we provide LTSs (yes, once), we drop > compilers in the version _after_ the LTS, which is kind of the natural > point to drop stuff. The point is that in June 2017, 30% of the Windows downloads were for MSVC 2013. it doesn't matter that this is an LTS release or not: way too many people are using that compiler. We need to "wean" them off 2013, so I'm starting a note in the 5.9.1 changelog that it will be gone in 5.11 (one year advance notice): https://codereview.qt-project.org/198430 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From enmarantispam at gmail.com Fri Jun 23 20:03:09 2017 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Fri, 23 Jun 2017 21:03:09 +0300 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: <5596248.PT29qLocbZ@tjmaciei-mobl1> References: <1968163.2PbfAQ7WLo@tjmaciei-mobl1> <2158433.yyUIndMjxJ@tjmaciei-mobl1> <5596248.PT29qLocbZ@tjmaciei-mobl1> Message-ID: > way too many people are using that compiler. And will still be using it one year from now. If ppl are still stuck on 2013 now that vastly superior 2015 is out for quite some time and for free to boot it's entirely unlikely anything will change within a year. More than likely they will stick with Qt5.9 for as long as LTS period will allow them. On Fri, Jun 23, 2017 at 8:50 PM, Thiago Macieira wrote: > On Friday, 23 June 2017 09:17:55 PDT Marc Mutz wrote: > > The above argument makes no sense to me. What value does quoting > > download numbers for 5.9, an LTS, have, to argue about dropping the > > compiler from 5.10. Ever since we provide LTSs (yes, once), we drop > > compilers in the version _after_ the LTS, which is kind of the natural > > point to drop stuff. > > The point is that in June 2017, 30% of the Windows downloads were for MSVC > 2013. it doesn't matter that this is an LTS release or not: way too many > people are using that compiler. We need to "wean" them off 2013, so I'm > starting a note in the 5.9.1 changelog that it will be gone in 5.11 (one > year > advance notice): > > https://codereview.qt-project.org/198430 > > -- > 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 thiago.macieira at intel.com Fri Jun 23 21:15:27 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 23 Jun 2017 12:15:27 -0700 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: References: <1968163.2PbfAQ7WLo@tjmaciei-mobl1> <5596248.PT29qLocbZ@tjmaciei-mobl1> Message-ID: <1810914.cXWp6WUpSE@tjmaciei-mobl1> On Friday, 23 June 2017 11:03:09 PDT NIkolai Marchenko wrote: > > way too many people are using that compiler. > > And will still be using it one year from now. I somehow expect people to upgrade their compilers at the first chance that they get. If you're about to update Qt, might as well upgrade the compiler. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From enmarantispam at gmail.com Fri Jun 23 21:27:10 2017 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Fri, 23 Jun 2017 22:27:10 +0300 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: <1810914.cXWp6WUpSE@tjmaciei-mobl1> References: <1968163.2PbfAQ7WLo@tjmaciei-mobl1> <5596248.PT29qLocbZ@tjmaciei-mobl1> <1810914.cXWp6WUpSE@tjmaciei-mobl1> Message-ID: > I somehow expect people to upgrade their compilers at the first chance that they get Yes, that's why most people (me included) upgraded the moment Qt started shipping with msvc2015 binaries. Everyone still stuck on 2013 is either under hard library recompilation/dependency constraints or just doesn't care. Both of the above are unlikely to change come 5.10 or 5.11. On the other hand, people who jump to 5.10 will get stranded and wanting they never left the LTS release if 5.10 happens to have stuff that actually requires long term support which, for it, will come in the form of direct upgrade to 5.11. On Fri, Jun 23, 2017 at 10:15 PM, Thiago Macieira wrote: > On Friday, 23 June 2017 11:03:09 PDT NIkolai Marchenko wrote: > > > way too many people are using that compiler. > > > > And will still be using it one year from now. > > I somehow expect people to upgrade their compilers at the first chance that > they get. If you're about to update Qt, might as well upgrade the compiler. > > -- > 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 marc.mutz at kdab.com Fri Jun 23 21:23:55 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 23 Jun 2017 21:23:55 +0200 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: <5596248.PT29qLocbZ@tjmaciei-mobl1> References: <1968163.2PbfAQ7WLo@tjmaciei-mobl1> <2158433.yyUIndMjxJ@tjmaciei-mobl1> <5596248.PT29qLocbZ@tjmaciei-mobl1> Message-ID: [forgot to CC list] On 2017-06-23 19:50, Thiago Macieira wrote: > On Friday, 23 June 2017 09:17:55 PDT Marc Mutz wrote: >> The above argument makes no sense to me. What value does quoting >> download numbers for 5.9, an LTS, have, to argue about dropping the >> compiler from 5.10. Ever since we provide LTSs (yes, once), we drop >> compilers in the version _after_ the LTS, which is kind of the natural >> point to drop stuff. > > The point is that in June 2017, 30% of the Windows downloads were for > MSVC > 2013. it doesn't matter that this is an LTS release or not: way too > many > people are using that compiler. We need to "wean" them off 2013, so I'm > starting a note in the 5.9.1 changelog that it will be gone in 5.11 > (one year > advance notice): We didn't "wean people off" 2012, either. And how can we decide to drop 2013 in 5.11 if we don't know what the download numbers will be, then, yet? Who's crystal ball makes such decisions possible? Thanks, Marc From adam.treat at qt.io Fri Jun 23 21:45:32 2017 From: adam.treat at qt.io (Adam Treat) Date: Fri, 23 Jun 2017 15:45:32 -0400 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: References: <1968163.2PbfAQ7WLo@tjmaciei-mobl1> <2158433.yyUIndMjxJ@tjmaciei-mobl1> <5596248.PT29qLocbZ@tjmaciei-mobl1> Message-ID: On 06/23/2017 03:23 PM, Marc Mutz wrote: > [forgot to CC list] > > On 2017-06-23 19:50, Thiago Macieira wrote: >> On Friday, 23 June 2017 09:17:55 PDT Marc Mutz wrote: >>> The above argument makes no sense to me. What value does quoting >>> download numbers for 5.9, an LTS, have, to argue about dropping the >>> compiler from 5.10. Ever since we provide LTSs (yes, once), we drop >>> compilers in the version _after_ the LTS, which is kind of the natural >>> point to drop stuff. >> >> The point is that in June 2017, 30% of the Windows downloads were for >> MSVC >> 2013. it doesn't matter that this is an LTS release or not: way too many >> people are using that compiler. We need to "wean" them off 2013, so I'm >> starting a note in the 5.9.1 changelog that it will be gone in 5.11 >> (one year >> advance notice): > > We didn't "wean people off" 2012, either. And how can we decide to > drop 2013 in 5.11 if we don't know what the download numbers will be, > then, yet? Who's crystal ball makes such decisions possible? Now you favor using retrospective downloads as sole criterion? You only want to drop support when downloads go below a certain threshold? Or is this your attempt at a reductio ad absurdum argument that using downloads to inform is only legit when used retrospectively as sole criterion? From marc.mutz at kdab.com Fri Jun 23 22:08:01 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 23 Jun 2017 22:08:01 +0200 Subject: [Development] Let's please drop MSVC 2013 for 5.10 In-Reply-To: References: <1968163.2PbfAQ7WLo@tjmaciei-mobl1> <2158433.yyUIndMjxJ@tjmaciei-mobl1> <5596248.PT29qLocbZ@tjmaciei-mobl1> Message-ID: <6d6d7304b0b7b5fed8e1fd9ba8242127@kdab.com> On 2017-06-23 21:45, Adam Treat wrote: > On 06/23/2017 03:23 PM, Marc Mutz wrote: >> [forgot to CC list] >> >> On 2017-06-23 19:50, Thiago Macieira wrote: >>> On Friday, 23 June 2017 09:17:55 PDT Marc Mutz wrote: >>>> The above argument makes no sense to me. What value does quoting >>>> download numbers for 5.9, an LTS, have, to argue about dropping the >>>> compiler from 5.10. Ever since we provide LTSs (yes, once), we drop >>>> compilers in the version _after_ the LTS, which is kind of the >>>> natural >>>> point to drop stuff. >>> >>> The point is that in June 2017, 30% of the Windows downloads were for >>> MSVC >>> 2013. it doesn't matter that this is an LTS release or not: way too >>> many >>> people are using that compiler. We need to "wean" them off 2013, so >>> I'm >>> starting a note in the 5.9.1 changelog that it will be gone in 5.11 >>> (one year >>> advance notice): >> >> We didn't "wean people off" 2012, either. And how can we decide to >> drop 2013 in 5.11 if we don't know what the download numbers will be, >> then, yet? Who's crystal ball makes such decisions possible? > > Now you favor using retrospective downloads as sole criterion? You > only want to drop support when downloads go below a certain threshold? > > Or is this your attempt at a reductio ad absurdum argument that using > downloads to inform is only legit when used retrospectively as sole > criterion? Neither. In particular, it's not about downloads as a sole criterion. I was wondering how we can know that by 5.11 the download ratio for 2013 is sufficiently low so as to commit to the drop date already now whilst at the same time using the current high download numbers to prevent dropping 2013 from 5.10 right now. What's the contingency plan in case the download numbers six months from now are still 30%? Either we still drop, because we said so, then the download argument becomes totally bogus, or we don't drop, in which case the announcement Thiago intends to add to the 5.9.1 changelog will be totally bogus. The deeper point is that I think we should drop stuff in LTS+1, not after LTS+1. If we don't drop 2013 for 5.10, we need to carry it until the next Qt 5 LTS, imo. I don't care much either way, as my baby (QStringView) works fine with MSVC 2013. But getting there _was_ hard, and the pain will only grow for every new feature we add (though GCC can also be a PITA, as QThread::create() currently shows). Thanks, Marc From rjvbertin at gmail.com Sun Jun 25 12:35:15 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Sun, 25 Jun 2017 12:35:15 +0200 Subject: [Development] right-to-left mode on Mac Message-ID: <44151223.1XmRvHF6NA@portia.local> Hello, I notice that most styles invert the menu design when you activate right-to-left layout mode, putting the shortcut hint to the left of the (right-aligned) menu item text (and right-aligning texted separators if those are supported and asymmetric). The Mac theme doesn't. Shortcut hints are displayed as "C" instead of "C" but they continue to be shown to the right of the (left-aligned) menu text. Is that what Apple's HIG dictate? Regards, R. From perezmeyer at gmail.com Mon Jun 26 13:10:15 2017 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Mon, 26 Jun 2017 08:10:15 -0300 Subject: [Development] Detecting hunspell in virtualkeyboard: do we really need pkg-config? Message-ID: <3131645.DixTY5aFW4@tonks> I started to work on auto detecting hunspell in virtualkeyboard and later found out that: (1) It is currently relying on pkg-config to do the job. (2) If the embedded code is present is preferred over the system version. I find (1) rather strange except maybe if pkg-config gives some other info apart from the -l flag. If that's not the case the dependency is avoidable with a simple config.test. Would it be preferrable to keep it like this or should I push my chabges to gerri? (and if so, to which branch? I'm kind of disconeected from Qt development thhese days). With respect (2): normally one would prefer the system lib over the embedded one. Is there a reason to keep things as they are or should I revert this logic? (maybe in the above patch if ACKed). Cheers, Lisandro. -- If you realize that you are in a hole... stop digging. Anonimous, thanks to ScottK. 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 oswald.buddenhagen at qt.io Mon Jun 26 14:26:53 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 26 Jun 2017 14:26:53 +0200 Subject: [Development] Detecting hunspell in virtualkeyboard: do we really need pkg-config? In-Reply-To: <3131645.DixTY5aFW4@tonks> References: <3131645.DixTY5aFW4@tonks> Message-ID: <20170626122653.GI18408@troll08> On Mon, Jun 26, 2017 at 08:10:15AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > I started to work on auto detecting hunspell in virtualkeyboard and later > found out that: > > (1) It is currently relying on pkg-config to do the job. > (2) If the embedded code is present is preferred over the system version. > > I find (1) rather strange except maybe if pkg-config gives some other info > apart from the -l flag. If that's not the case the dependency is avoidable > with a simple config.test. > > Would it be preferrable to keep it like this or should I push my chabges to > gerri? (and if so, to which branch? I'm kind of disconeected from Qt > development thhese days). > > With respect (2): normally one would prefer the system lib over the embedded > one. Is there a reason to keep things as they are or should I revert this > logic? (maybe in the above patch if ACKed). > before you spend any more time on this, have a look at https://codereview.qt-project.org/175873 first. (volunteers welcome, btw) From perezmeyer at gmail.com Mon Jun 26 15:05:55 2017 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Mon, 26 Jun 2017 10:05:55 -0300 Subject: [Development] Detecting hunspell in virtualkeyboard: do we really need pkg-config? In-Reply-To: <20170626122653.GI18408@troll08> References: <3131645.DixTY5aFW4@tonks> <20170626122653.GI18408@troll08> Message-ID: <23416254.6kPE84DxqO@tonks> On lunes, 26 de junio de 2017 14:26:53 -03 Oswald Buddenhagen wrote: > On Mon, Jun 26, 2017 at 08:10:15AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > > I started to work on auto detecting hunspell in virtualkeyboard and later > > found out that: > > > > (1) It is currently relying on pkg-config to do the job. > > (2) If the embedded code is present is preferred over the system version. > > > > I find (1) rather strange except maybe if pkg-config gives some other info > > apart from the -l flag. If that's not the case the dependency is avoidable > > with a simple config.test. > > > > Would it be preferrable to keep it like this or should I push my chabges > > to > > gerri? (and if so, to which branch? I'm kind of disconeected from Qt > > development thhese days). > > > > With respect (2): normally one would prefer the system lib over the > > embedded one. Is there a reason to keep things as they are or should I > > revert this logic? (maybe in the above patch if ACKed). > > before you spend any more time on this, have a look at > https://codereview.qt-project.org/175873 first. > (volunteers welcome, btw) Oh, cool, thanks! -- Wiki participants are, by nature, a pedantic, ornery, and unreasonable bunch. So there's a camaraderie here we seldom see outside of our professional contacts. http://www.c2.com/cgi/wiki?WhyWikiWorks 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 akseli.salovaara at qt.io Mon Jun 26 17:28:26 2017 From: akseli.salovaara at qt.io (Akseli Salovaara) Date: Mon, 26 Jun 2017 15:28:26 +0000 Subject: [Development] New Qt 5.9.1 snapshot available Message-ID: Hi all, We have a new Qt 5.9.1 snapshot available via online installer. It is a separate Qt 5.9.1 node, not as an update to Qt 5.9.0, but will overwrite previous Qt 5.9.1 snapshot. Instructions how to install it here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer Content of the snapshot is based on https://codereview.qt-project.org/197790, delta to Qt 5.9.0 as an attachment. RTA testing is ongoing and excluding fix for https://bugreports.qt.io/browse/QTBUG-61635 Android deployment issue this should be the final Qt 5.9.1 content. So please test the snapshot & report your effort via https://wiki.qt.io/Qt59_release_testing Br, Akseli -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Qt5.9.1-delta-Qt5.9.0.txt URL: From Gabriel.deDietrich at qt.io Mon Jun 26 22:35:54 2017 From: Gabriel.deDietrich at qt.io (Gabriel de Dietrich) Date: Mon, 26 Jun 2017 20:35:54 +0000 Subject: [Development] right-to-left mode on Mac In-Reply-To: <44151223.1XmRvHF6NA@portia.local> References: <44151223.1XmRvHF6NA@portia.local> Message-ID: <3216C7CF-CF9E-4E9C-8C8F-44D056A27802@qt.io> Hi René, Are you referring to context menus or menubar menus? We fully layout the former, but the latter are entirely delegated to macOS. I don’t see anything in the Mac HIG documents, and there’s limited information in the internationalization guide (https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPInternational/SupportingRight-To-LeftLanguages/SupportingRight-To-LeftLanguages.html#//apple_ref/doc/uid/10000171i-CH17-SW1). Here are a couple screenshots from Notes in Arabic locale, a context menu and a menubar menu, and so that we have something to refer to. [cid:E5D16D35-4079-4EDB-A965-EA2C710BCD95] [cid:F980463C-3B1F-435E-90F3-0D33E987A348] In any case, yes, we should expect something similar from Qt applications, at least if the appropriate translation file is provided. Also, notice the shortcuts in the menubar menu. Best regards, Dr. Gabriel de Dietrich Senior Software Developer The Qt Company — www.qt.io On Jun 25, 2017, at 3:35 AM, René J.V. Bertin > wrote: Hello, I notice that most styles invert the menu design when you activate right-to-left layout mode, putting the shortcut hint to the left of the (right-aligned) menu item text (and right-aligning texted separators if those are supported and asymmetric). The Mac theme doesn't. Shortcut hints are displayed as "C" instead of "C" but they continue to be shown to the right of the (left-aligned) menu text. Is that what Apple's HIG dictate? Regards, R. _______________________________________________ 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: Screen Shot ٢٠١٧-٠٦-٢٦ at ١.٢٥.٣٠ م.png Type: image/png Size: 194968 bytes Desc: Screen Shot ٢٠١٧-٠٦-٢٦ at ١.٢٥.٣٠ م.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot ٢٠١٧-٠٦-٢٦ at ١.٢٥.٤٩ م.png Type: image/png Size: 161557 bytes Desc: Screen Shot ٢٠١٧-٠٦-٢٦ at ١.٢٥.٤٩ م.png URL: From rjvbertin at gmail.com Mon Jun 26 23:10:56 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Mon, 26 Jun 2017 23:10:56 +0200 Subject: [Development] right-to-left mode on Mac In-Reply-To: <3216C7CF-CF9E-4E9C-8C8F-44D056A27802@qt.io> References: <44151223.1XmRvHF6NA@portia.local> <3216C7CF-CF9E-4E9C-8C8F-44D056A27802@qt.io> Message-ID: <5664345.pAv1bh2JGI@portia.local> On Monday June 26 2017 20:35:54 Gabriel de Dietrich wrote: > Are you referring to context menus or menubar menus? We fully layout the former, but the latter are entirely delegated to macOS. Both, to some extent. I know Qt has very little control over how menus of the native menubar are rendered so R2L behaviour in those will have to be the result of an API call, or simply of selecting a language requiring it. But menubars can of course also be non-native and in that case they're drawn fully by Qt. > In any case, yes, we should expect something similar from Qt applications, at least if the appropriate translation file is provided. Oh joy :) I presume you mean that the translation file will take care of the item text - it cannot really do anything else, right? In any case I never saw text rendering being reversed when activating R2L mode. > Also, notice the shortcuts in the menubar menu. Yes, I noticed those. Does that actually make things easier? BTW, here's a curiosity I've been seeing for a while now in the KF5 oxygen demo application: ``` action = menu->addAction( i18n( "<- Check here" ) ); ``` After activating R2L mode, "Check here" still reads the same way, but something flipped and moved the ascii arrow. That still happens with the Macintosh style, but the menu tick remains on the left in that case, evidently. > > Best regards, > > Dr. Gabriel de Dietrich > Senior Software Developer > The Qt Company — www.qt.io > > On Jun 25, 2017, at 3:35 AM, René J.V. Bertin > wrote: > > Hello, > > > I notice that most styles invert the menu design when you activate right-to-left layout mode, putting the shortcut hint to the left of the (right-aligned) menu item text (and right-aligning texted separators if those are supported and asymmetric). > > The Mac theme doesn't. Shortcut hints are displayed as "C" instead of "C" but they continue to be shown to the right of the (left-aligned) menu text. > > Is that what Apple's HIG dictate? > > Regards, > R. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- A non-text attachment was scrubbed... Name: l2r-menu-fusion.png Type: image/png Size: 11824 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: r2l-menu-fusion.png Type: image/png Size: 10383 bytes Desc: not available URL: From thiago.macieira at intel.com Mon Jun 26 23:44:39 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 26 Jun 2017 14:44:39 -0700 Subject: [Development] right-to-left mode on Mac In-Reply-To: <5664345.pAv1bh2JGI@portia.local> References: <44151223.1XmRvHF6NA@portia.local> <3216C7CF-CF9E-4E9C-8C8F-44D056A27802@qt.io> <5664345.pAv1bh2JGI@portia.local> Message-ID: <1946040.vEJGYjC2tS@tjmaciei-mobl1> On segunda-feira, 26 de junho de 2017 14:10:56 PDT René J.V. Bertin wrote: > I presume you mean that the translation file will take care of the item text > - it cannot really do anything else, right? In any case I never saw text > rendering being reversed when activating R2L mode. Actually, it can. The Qt translation contains some extra information, like whether the language is R2L and the plural rules. If you don't load the .qm file for Qt itself (the qtbase one), you'll have problems. > Shortcut hints are displayed as "C" instead of "C" That looks like a Unicode BiDi issue. The  symbol is in the private use area, so it has no BiDi flow, but "C" does. It can be explained by the above problem too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From neel5481 at gmail.com Tue Jun 27 10:54:03 2017 From: neel5481 at gmail.com (neel patel) Date: Tue, 27 Jun 2017 14:24:03 +0530 Subject: [Development] ActiveQt Events Message-ID: Hi All, As I am using "QAxWidget". I took the "webbrowser" example as reference. As I am using "QTabWidget" as mainwindow widget and adding "QAxWidget" as tab widget. Below is the code for reference. m_tabWidget = new QTabWidget(mainwindow); m_mainGridLayout = new QGridLayout(m_tabWidget); m_mainGridLayout->setContentsMargins(0, 0, 0, 0); m_MainTab = new QWidget(m_tabWidget); m_tabGridLayout = new QGridLayout(m_MainTab); m_tabGridLayout->setContentsMargins(0, 0, 0, 0); m_activeX = new WebAxWidget(m_MainTab); m_activeX->setControl(QStringLiteral("{8856F961-340A-11D0-A96B-00C04FD705A2}")); m_activeX->setObjectName(QStringLiteral("WebBrowser")); m_activeX->setFocusPolicy(Qt::StrongFocus); m_tabGridLayout->addWidget(m_activeX, 0, 0, 1, 1); m_tabWidget->addTab(m_MainTab, QString()); mainwindow->setCentralWidget(m_tabWidget); class WebAxWidget : public QAxWidget { public: WebAxWidget(QWidget* parent = 0, Qt::WindowFlags f = 0) : QAxWidget(parent, f) { } } I want to receive events like NewWindow3, NewWindow2, BeforeNavigate2 with Qt. As such there is no signal available in "QAxWidget". How can we receive those signals from windows COM interface ? Let me know reference or pointers so that i can implement and suggest in above code. Thanks in Advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Liang.Qi at qt.io Tue Jun 27 11:38:41 2017 From: Liang.Qi at qt.io (Liang Qi) Date: Tue, 27 Jun 2017 09:38:41 +0000 Subject: [Development] qtbase dev is blocked in CI In-Reply-To: <5B45B01B-3566-42FF-80C7-7FF19B4FE8D0@qt.io> References: <5B45B01B-3566-42FF-80C7-7FF19B4FE8D0@qt.io> Message-ID: <0A9D7F9A-FF3A-4932-9E2E-9541CBA4A33C@qt.io> This issue was gone. qtbase dev is safe. —Liang > On 23 Jun 2017, at 09:27, Liang Qi wrote: > > Hi, > > There is an integration sucks from last night for qtbase dev branch. And we can’t restart coin to cancel it due to current 5.9.1 integrations. Hope we can fix the issue this afternoon or a bit later today. > > So please don’t stage changes in qtbase dev for now, thanks. > > Best Regards, > Liang From Liang.Qi at qt.io Tue Jun 27 11:43:12 2017 From: Liang.Qi at qt.io (Liang Qi) Date: Tue, 27 Jun 2017 09:43:12 +0000 Subject: [Development] qtbase 5.9 is in chaos mode now Message-ID: <2A74FB87-D50D-40AA-BA0E-3058AE30D3DA@qt.io> There is a gap in 6.19-6.26, only 2 changes are merged in qtbase 5.9. https://codereview.qt-project.org/#/q/project:qt/qtbase+branch:5.9+status:merged,n,z And now we have about 40 changes in staged mode, I don’t see much chance to get them in. https://codereview.qt-project.org/#/q/project:qt/qtbase+branch:5.9+status:open,n,z Perhaps I can try to be the stage monkey, but I need to know which batch/set of changes need to be staged together. Please report here or irc, thanks. Regards, Liang From fromqt at tungware.se Tue Jun 27 13:56:00 2017 From: fromqt at tungware.se (Henry Skoglund) Date: Tue, 27 Jun 2017 13:56:00 +0200 Subject: [Development] ActiveQt Events In-Reply-To: References: Message-ID: <908e990e-27cd-070a-9b02-3d1890a309dc@tungware.se> On 2017-06-27 10:54, neel patel wrote: > Hi All, > > As I am using "QAxWidget". I took the "webbrowser" example as reference. > As I am using "QTabWidget" as mainwindow widget and adding "QAxWidget" > as tab widget. Below is the code for reference. > > > m_tabWidget = new QTabWidget(mainwindow); > > m_mainGridLayout = new QGridLayout(m_tabWidget); > m_mainGridLayout->setContentsMargins(0, 0, 0, 0); > > m_MainTab = new QWidget(m_tabWidget); > m_tabGridLayout = new QGridLayout(m_MainTab); > m_tabGridLayout->setContentsMargins(0, 0, 0, 0); > > m_activeX = new WebAxWidget(m_MainTab); > > m_activeX->setControl(QStringLiteral("{8856F961-340A-11D0-A96B-00C04FD705A2}")); > m_activeX->setObjectName(QStringLiteral("WebBrowser")); > m_activeX->setFocusPolicy(Qt::StrongFocus); > > m_tabGridLayout->addWidget(m_activeX, 0, 0, 1, 1); > m_tabWidget->addTab(m_MainTab, QString()); > > mainwindow->setCentralWidget(m_tabWidget); > > class WebAxWidget : public QAxWidget > { > public: > > WebAxWidget(QWidget* parent = 0, Qt::WindowFlags f = 0) > : QAxWidget(parent, f) > { > } > } > > > > I want to receive events like NewWindow3, NewWindow2, BeforeNavigate2 > with Qt. As such there is no signal available in "QAxWidget". How can we > receive those signals from windows COM interface ? > > Let me know reference or pointers so that i can implement and suggest in > above code. > > Thanks in Advance. Hi, you can receive those events through the generic QAxBase::signal, see http://doc.qt.io/qt-5/qaxbase.html#signal In it, you'll see the example code for receiving "BeforeNavigate2", and all the other event flavors you retrieve the same way. So first, add the slot declaration to your MainWindow class: ... private slots: void slot(const QString& name,int argc, void* argv); ... then connect your m_activeX object to that signal, here is some sample code added after your " mainwindow->setCentralWidget(m_tabWidget);": ... connect(m_activeX,SIGNAL(signal(const QString&,int,void*)),this,SLOT(slot(const QString&,int,void*))); // connect(m_activeX,&QAxWidget::signal,this,&MainWindow::slot); // this is better syntax but alas will *not* compile :-( // setup a sample navigation QString url = "http://doc.qt.io/qt-5/qaxbase.html"; m_activeX->dynamicCall("Navigate(const QString&)",url); } // here's how to receive all of them // you'll have to check the name for the correct one, I'll give you 2 for free // just add the others you need... // note: the example in QAxBase::signal is too old to compile correctly, (changed below) // need this for the VARIANTARG chaps #include "windows.h" void MainWindow::slot(const QString &name, int argc, void *argv) { VARIANTARG *params = (VARIANTARG*)argv; if (name.startsWith("BeforeNavigate2(")) { // "BeforeNavigate2(IDispatch*,QVariant&,QVariant&,QVariant&,QVariant&,QVariant&,bool&)" IDispatch *pDisp = params[argc-1].pdispVal; VARIANTARG URL = *params[argc-2].pvarVal; VARIANTARG Flags = *params[argc-3].pvarVal; VARIANTARG TargetFrameName = *params[argc-4].pvarVal; VARIANTARG PostData = *params[argc-5].pvarVal; VARIANTARG Headers = *params[argc-6].pvarVal; VARIANT_BOOL *Cancel = params[argc-7].pboolVal; QString url = QString::fromStdWString(URL.bstrVal); qDebug() << "BeforeNavigate2, ur" << url; } if (name.startsWith("NewWindow3(")) { // NewWindow3(IDispatch**,bool&,uint,QString,QString)" IDispatch *pDisp = params[argc-1].pdispVal; VARIANT_BOOL* Cancel = params[argc-2].pboolVal; uint Flags = params[argc-3].uintVal; BSTR URLContext = params[argc-4].bstrVal; BSTR URL = params[argc-5].bstrVal; QString urlContext = QString::fromStdWString(URLContext); QString url = QString::fromStdWString(URL); qDebug() << "NewWindow3, opening" << url << "from" << urlContext; } } ... Good luck! Rgrds Henry From neel5481 at gmail.com Tue Jun 27 14:17:59 2017 From: neel5481 at gmail.com (neel patel) Date: Tue, 27 Jun 2017 17:47:59 +0530 Subject: [Development] ActiveQt Events In-Reply-To: <908e990e-27cd-070a-9b02-3d1890a309dc@tungware.se> References: <908e990e-27cd-070a-9b02-3d1890a309dc@tungware.se> Message-ID: Thank you Henry. I will check and keep you updated. On Tue, Jun 27, 2017 at 5:26 PM, Henry Skoglund wrote: > On 2017-06-27 10:54, neel patel wrote: > >> Hi All, >> >> As I am using "QAxWidget". I took the "webbrowser" example as reference. >> As I am using "QTabWidget" as mainwindow widget and adding "QAxWidget" as >> tab widget. Below is the code for reference. >> >> >> m_tabWidget = new QTabWidget(mainwindow); >> >> m_mainGridLayout = new QGridLayout(m_tabWidget); >> m_mainGridLayout->setContentsMargins(0, 0, 0, 0); >> >> m_MainTab = new QWidget(m_tabWidget); >> m_tabGridLayout = new QGridLayout(m_MainTab); >> m_tabGridLayout->setContentsMargins(0, 0, 0, 0); >> >> m_activeX = new WebAxWidget(m_MainTab); >> m_activeX->setControl(QStringLiteral("{8856F961-340A-11D0- >> A96B-00C04FD705A2}")); >> m_activeX->setObjectName(QStringLiteral("WebBrowser")); >> m_activeX->setFocusPolicy(Qt::StrongFocus); >> >> m_tabGridLayout->addWidget(m_activeX, 0, 0, 1, 1); >> m_tabWidget->addTab(m_MainTab, QString()); >> >> mainwindow->setCentralWidget(m_tabWidget); >> >> class WebAxWidget : public QAxWidget >> { >> public: >> >> WebAxWidget(QWidget* parent = 0, Qt::WindowFlags f = 0) >> : QAxWidget(parent, f) >> { >> } >> } >> >> >> >> I want to receive events like NewWindow3, NewWindow2, BeforeNavigate2 >> with Qt. As such there is no signal available in "QAxWidget". How can we >> receive those signals from windows COM interface ? >> >> Let me know reference or pointers so that i can implement and suggest in >> above code. >> >> Thanks in Advance. >> > > Hi, you can receive those events through the generic QAxBase::signal, see > http://doc.qt.io/qt-5/qaxbase.html#signal > In it, you'll see the example code for receiving "BeforeNavigate2", and > all the other event flavors you retrieve the same way. > > So first, add the slot declaration to your MainWindow class: > ... > private slots: > void slot(const QString& name,int argc, void* argv); > ... > > then connect your m_activeX object to that signal, here is some sample > code added after your " mainwindow->setCentralWidget(m_tabWidget);": > > ... > connect(m_activeX,SIGNAL(signal(const QString&,int,void*)),this,SLOT(slot(const > QString&,int,void*))); > // connect(m_activeX,&QAxWidget::signal,this,&MainWindow::slot); // > this is better syntax but alas will *not* compile :-( > > // setup a sample navigation > QString url = "http://doc.qt.io/qt-5/qaxbase.html"; > m_activeX->dynamicCall("Navigate(const QString&)",url); > } > > // here's how to receive all of them > // you'll have to check the name for the correct one, I'll give you 2 for > free > // just add the others you need... > // note: the example in QAxBase::signal is too old to compile correctly, > (changed below) > > // need this for the VARIANTARG chaps > #include "windows.h" > > void MainWindow::slot(const QString &name, int argc, void *argv) > { > VARIANTARG *params = (VARIANTARG*)argv; > if (name.startsWith("BeforeNavigate2(")) > { > // "BeforeNavigate2(IDispatch*,QVariant&,QVariant&,QVariant&,QV > ariant&,QVariant&,bool&)" > IDispatch *pDisp = params[argc-1].pdispVal; > VARIANTARG URL = *params[argc-2].pvarVal; > VARIANTARG Flags = *params[argc-3].pvarVal; > VARIANTARG TargetFrameName = *params[argc-4].pvarVal; > VARIANTARG PostData = *params[argc-5].pvarVal; > VARIANTARG Headers = *params[argc-6].pvarVal; > VARIANT_BOOL *Cancel = params[argc-7].pboolVal; > > QString url = QString::fromStdWString(URL.bstrVal); > qDebug() << "BeforeNavigate2, ur" << url; > } > > if (name.startsWith("NewWindow3(")) > { > // NewWindow3(IDispatch**,bool&,uint,QString,QString)" > IDispatch *pDisp = params[argc-1].pdispVal; > VARIANT_BOOL* Cancel = params[argc-2].pboolVal; > uint Flags = params[argc-3].uintVal; > BSTR URLContext = params[argc-4].bstrVal; > BSTR URL = params[argc-5].bstrVal; > > QString urlContext = QString::fromStdWString(URLContext); > QString url = QString::fromStdWString(URL); > qDebug() << "NewWindow3, opening" << url << "from" << urlContext; > } > } > ... > > Good luck! Rgrds Henry > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Wed Jun 28 01:42:59 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 28 Jun 2017 01:42:59 +0200 Subject: [Development] right-to-left mode on Mac In-Reply-To: <3216C7CF-CF9E-4E9C-8C8F-44D056A27802@qt.io> References: <44151223.1XmRvHF6NA@portia.local> <3216C7CF-CF9E-4E9C-8C8F-44D056A27802@qt.io> Message-ID: <4613324.2kQtbtyOtz@portia.local> Hi Gabriel, I've taken a quick first look at implementing right-to-left support in contextmenus and think it's going to be quite tricky getting the alignment right - a process of educated trial and educating error :) Adding R2L support to my code rendering texted separators was trivial (https://github.com/RJVB/osx-integration/commit/a6ca7482e2ffe3c25a82f80312e7b8326b167a1f), but for other menu items the point relative to which right-alignment takes place depends on factors I haven't yet understood. The shortcut mnemonics are a different problem, they're drawn as a string, and the drawing routine will print them in reverse when R2L mode is selected. Probably not the aspect to focus on first and maybe not even that big a deal to leave "as is" (in fact, I don't understand why Apple doesn't invert shortcut representations, obliging users to change their reading direction to parse the indication in the order they'd be entering it. Cheers, René From vincenthk007 at gmail.com Wed Jun 28 03:07:17 2017 From: vincenthk007 at gmail.com (Vincent Hui) Date: Wed, 28 Jun 2017 09:07:17 +0800 Subject: [Development] New Qt 5.9.1 snapshot available In-Reply-To: References: Message-ID: Hi Akseli, Why Qt 5.9.1 for MSVC2015 version on Windows is label as "Qt 5.9.1 MSVC2015 64bit2"? That makes me think Qt 5.9.1 is built by MSVC2015 with update 2 not update 3. Qt 5.9.0 for MSVC2015 version on Windows is label as "Qt 5.9.0 MSVC2015 64bit3". By the number 3 after "64bit", I think Qt 5.9.0 is built by MSVC2015 with update 3. Is Qt 5.9.1 not built by MSVC2015 with update 3? Br, Vincent On Mon, Jun 26, 2017 at 11:28 PM, Akseli Salovaara wrote: > Hi all, > > We have a new Qt 5.9.1 snapshot available via online installer. It is a > separate Qt 5.9.1 node, not as an update to Qt 5.9.0, but will overwrite > previous Qt 5.9.1 snapshot. Instructions how to install it here: > https://wiki.qt.io/How_to_get_snapshot_via_online_installer > > Content of the snapshot is based on https://codereview.qt-project. > org/197790, delta to Qt 5.9.0 as an attachment. > > RTA testing is ongoing and excluding fix for https://bugreports.qt.io/ > browse/QTBUG-61635 Android deployment issue this should be the final Qt > 5.9.1 content. So please test the snapshot & report your effort via > https://wiki.qt.io/Qt59_release_testing > > Br, > Akseli > > > _______________________________________________ > 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 kari.oikarinen at qt.io Wed Jun 28 07:57:03 2017 From: kari.oikarinen at qt.io (Kari Oikarinen) Date: Wed, 28 Jun 2017 08:57:03 +0300 Subject: [Development] New Qt 5.9.1 snapshot available In-Reply-To: References: Message-ID: I believe this is https://bugreports.qt.io/browse/QTCREATORBUG-17909 -- Kari On 28.06.2017 04:07, Vincent Hui wrote: > Hi Akseli, > > Why Qt 5.9.1 for MSVC2015 version on Windows is label as "Qt 5.9.1 > MSVC2015 64bit2"? That makes me think Qt 5.9.1 is built by MSVC2015 with > update 2 not update 3. Qt 5.9.0 for MSVC2015 version on Windows is label > as "Qt 5.9.0 MSVC2015 64bit3". By the number 3 after "64bit", I think Qt > 5.9.0 is built by MSVC2015 with update 3. > > Is Qt 5.9.1 not built by MSVC2015 with update 3? > > Br, > Vincent > > > On Mon, Jun 26, 2017 at 11:28 PM, Akseli Salovaara > > wrote: > > Hi all, > > We have a new Qt 5.9.1 snapshot available via online installer. It > is a separate Qt 5.9.1 node, not as an update to Qt 5.9.0, but will > overwrite previous Qt 5.9.1 snapshot. Instructions how to install it > here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer > > > Content of the snapshot is based on > https://codereview.qt-project.org/197790 > , delta to Qt 5.9.0 as an > attachment. > > RTA testing is ongoing and excluding fix for > https://bugreports.qt.io/browse/QTBUG-61635 > Android deployment > issue this should be the final Qt 5.9.1 content. So please test the > snapshot & report your effort via > https://wiki.qt.io/Qt59_release_testing > > > Br, > Akseli > > > _______________________________________________ > 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 > -- --- Kari Oikarinen Software Engineer The Qt Company Elektroniikkatie 13 90590, Oulu, Finland kari.oikarinen at qt.io +358 50 5281010 http://qt.io --- From akseli.salovaara at qt.io Wed Jun 28 09:00:21 2017 From: akseli.salovaara at qt.io (Akseli Salovaara) Date: Wed, 28 Jun 2017 07:00:21 +0000 Subject: [Development] New Qt 5.9.1 snapshot available In-Reply-To: References: Message-ID: > -----Original Message----- > From: Kari Oikarinen > Sent: keskiviikko 28. kesäkuuta 2017 08:57 > To: Vincent Hui ; Akseli Salovaara > > Cc: development at qt-project.org; releasing at qt-project.org > Subject: Re: [Development] New Qt 5.9.1 snapshot available > > I believe this is https://bugreports.qt.io/browse/QTCREATORBUG-17909 > Correct. The index "2" or "3" on Qt Creator "Kits" or "Qt Versions" auto-detected labels has nothing to do with MSVC 2015 Update version. Qt 5.9.1 is built by MSVC2015 with Update 3. > -- > Kari > > On 28.06.2017 04:07, Vincent Hui wrote: > > Hi Akseli, > > > > Why Qt 5.9.1 for MSVC2015 version on Windows is label as "Qt 5.9.1 > > MSVC2015 64bit2"? That makes me think Qt 5.9.1 is built by MSVC2015 > > with update 2 not update 3. Qt 5.9.0 for MSVC2015 version on Windows > > is label as "Qt 5.9.0 MSVC2015 64bit3". By the number 3 after "64bit", > > I think Qt > > 5.9.0 is built by MSVC2015 with update 3. > > > > Is Qt 5.9.1 not built by MSVC2015 with update 3? > > > > Br, > > Vincent > > > > > > On Mon, Jun 26, 2017 at 11:28 PM, Akseli Salovaara > > > wrote: > > > > Hi all, > > > > We have a new Qt 5.9.1 snapshot available via online installer. It > > is a separate Qt 5.9.1 node, not as an update to Qt 5.9.0, but will > > overwrite previous Qt 5.9.1 snapshot. Instructions how to install it > > here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer > > > > > > Content of the snapshot is based on > > https://codereview.qt-project.org/197790 > > , delta to Qt 5.9.0 as an > > attachment. > > > > RTA testing is ongoing and excluding fix for > > https://bugreports.qt.io/browse/QTBUG-61635 > > Android deployment > > issue this should be the final Qt 5.9.1 content. So please test the > > snapshot & report your effort via > > https://wiki.qt.io/Qt59_release_testing > > > > > > Br, > > Akseli > > > > > > _______________________________________________ > > 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 > > > > -- > --- > Kari Oikarinen > Software Engineer > > The Qt Company > Elektroniikkatie 13 > 90590, Oulu, Finland > kari.oikarinen at qt.io > +358 50 5281010 > http://qt.io > --- From rjvbertin at gmail.com Wed Jun 28 10:24:09 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Wed, 28 Jun 2017 10:24:09 +0200 Subject: [Development] right-to-left mode on Mac References: <44151223.1XmRvHF6NA@portia.local> <3216C7CF-CF9E-4E9C-8C8F-44D056A27802@qt.io> <5664345.pAv1bh2JGI@portia.local> <1946040.vEJGYjC2tS@tjmaciei-mobl1> Message-ID: <5397767.yLn9bOyxmR@patux.local> Thiago Macieira wrote: > Actually, it can. The Qt translation contains some extra information, like > whether the language is R2L and the plural rules. If you don't load the .qm > file for Qt itself (the qtbase one), you'll have problems. Yeah, I installed the Hebrew translations and can confirm that launching a Qt app with the LANGUAGE and LANG variables set accordingly does the trick, at least for menus Qt renders entirely itself. The good news is that means one doesn't have to set one's desktop to become incomprehensible, but it'd still be nice to have a set of en_Mirror translation files :) >> Shortcut hints are displayed as "C" instead of "C" > > That looks like a Unicode BiDi issue. The  symbol is in the private use area, > so it has no BiDi flow, but "C" does. You mean that the text drawing routine would normally obtain additional information from the text itself whether it should be rendered differently from the global layout direction? Wouldn't that affect native Mac apps to? R. From rjvbertin at gmail.com Wed Jun 28 10:38:18 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Wed, 28 Jun 2017 10:38:18 +0200 Subject: [Development] right-to-left mode on Mac References: <44151223.1XmRvHF6NA@portia.local> <3216C7CF-CF9E-4E9C-8C8F-44D056A27802@qt.io> <5664345.pAv1bh2JGI@portia.local> <1946040.vEJGYjC2tS@tjmaciei-mobl1> Message-ID: <499553260.6BCssyWj3I@patux.local> Thiago Macieira wrote: >> Shortcut hints are displayed as "C" instead of "C" > > That looks like a Unicode BiDi issue. The  symbol is in the private use area, > so it has no BiDi flow, but "C" does. Note (to self): Konsole does the following to force QPainter::drawText to do L2R rendering; will probably work for the shortcut rendering too. // we use this to force QPainter to display text in LTR mode // more information can be found in: http://unicode.org/reports/tr9/ const QChar LTR_OVERRIDE_CHAR(0x202D); if (_bidiEnabled) { painter.drawText(rect.x(), rect.y() + _fontAscent + _lineSpacing, text); } else { painter.drawText(rect.x(), rect.y() + _fontAscent + _lineSpacing, LTR_OVERRIDE_CHAR + text); } R. From neel5481 at gmail.com Wed Jun 28 11:23:36 2017 From: neel5481 at gmail.com (neel patel) Date: Wed, 28 Jun 2017 14:53:36 +0530 Subject: [Development] ActiveQt Events In-Reply-To: References: <908e990e-27cd-070a-9b02-3d1890a309dc@tungware.se> Message-ID: Hi, I tried the steps provided by you and it is working nicely.. Thank you Henry for your support. Couple of queries regarding same:- 1) As I have QTabWidget and i am opening another URL in new window with custom Back/Forward button. When user navigate to URL and again come back then we are using below code for Back and Forward button click signal. m_activeX->dynamicCall("GoBack()"); m_activeX->dynamicCall("GoForward()"); Above will work fine but how can we know wether we can go back or not and depending on that enable/disable Back/Forward buttons. As of now when we come to first page and call "GoBack" then it gives exception. I want to know before click on buttons. Is there anyway ? 2) I am using "window.load" at JS side and we are getting "NewWindow3" signal which is fine but after that below code fails which gives script error on Qt side saying "Unable to get property addEventListener of undefined or null reference. Do you want to continue execute script ?" window.addEventListener("load", function() { } -- Should we change IE browser version used in QAxWidget to resolve this issue Or any other work around to stop giving this message ? Thanks in Advance. On Tue, Jun 27, 2017 at 5:47 PM, neel patel wrote: > Thank you Henry. I will check and keep you updated. > > > On Tue, Jun 27, 2017 at 5:26 PM, Henry Skoglund > wrote: > >> On 2017-06-27 10:54, neel patel wrote: >> >>> Hi All, >>> >>> As I am using "QAxWidget". I took the "webbrowser" example as reference. >>> As I am using "QTabWidget" as mainwindow widget and adding "QAxWidget" >>> as tab widget. Below is the code for reference. >>> >>> >>> m_tabWidget = new QTabWidget(mainwindow); >>> >>> m_mainGridLayout = new QGridLayout(m_tabWidget); >>> m_mainGridLayout->setContentsMargins(0, 0, 0, 0); >>> >>> m_MainTab = new QWidget(m_tabWidget); >>> m_tabGridLayout = new QGridLayout(m_MainTab); >>> m_tabGridLayout->setContentsMargins(0, 0, 0, 0); >>> >>> m_activeX = new WebAxWidget(m_MainTab); >>> m_activeX->setControl(QStringLiteral("{8856F961-340A-11D0-A >>> 96B-00C04FD705A2}")); >>> m_activeX->setObjectName(QStringLiteral("WebBrowser")); >>> m_activeX->setFocusPolicy(Qt::StrongFocus); >>> >>> m_tabGridLayout->addWidget(m_activeX, 0, 0, 1, 1); >>> m_tabWidget->addTab(m_MainTab, QString()); >>> >>> mainwindow->setCentralWidget(m_tabWidget); >>> >>> class WebAxWidget : public QAxWidget >>> { >>> public: >>> >>> WebAxWidget(QWidget* parent = 0, Qt::WindowFlags f = 0) >>> : QAxWidget(parent, f) >>> { >>> } >>> } >>> >>> >>> >>> I want to receive events like NewWindow3, NewWindow2, BeforeNavigate2 >>> with Qt. As such there is no signal available in "QAxWidget". How can we >>> receive those signals from windows COM interface ? >>> >>> Let me know reference or pointers so that i can implement and suggest in >>> above code. >>> >>> Thanks in Advance. >>> >> >> Hi, you can receive those events through the generic QAxBase::signal, see >> http://doc.qt.io/qt-5/qaxbase.html#signal >> In it, you'll see the example code for receiving "BeforeNavigate2", and >> all the other event flavors you retrieve the same way. >> >> So first, add the slot declaration to your MainWindow class: >> ... >> private slots: >> void slot(const QString& name,int argc, void* argv); >> ... >> >> then connect your m_activeX object to that signal, here is some sample >> code added after your " mainwindow->setCentralWidget(m_tabWidget);": >> >> ... >> connect(m_activeX,SIGNAL(signal(const QString&,int,void*)),this,SLOT(slot(const >> QString&,int,void*))); >> // connect(m_activeX,&QAxWidget::signal,this,&MainWindow::slot); // >> this is better syntax but alas will *not* compile :-( >> >> // setup a sample navigation >> QString url = "http://doc.qt.io/qt-5/qaxbase.html"; >> m_activeX->dynamicCall("Navigate(const QString&)",url); >> } >> >> // here's how to receive all of them >> // you'll have to check the name for the correct one, I'll give you 2 for >> free >> // just add the others you need... >> // note: the example in QAxBase::signal is too old to compile correctly, >> (changed below) >> >> // need this for the VARIANTARG chaps >> #include "windows.h" >> >> void MainWindow::slot(const QString &name, int argc, void *argv) >> { >> VARIANTARG *params = (VARIANTARG*)argv; >> if (name.startsWith("BeforeNavigate2(")) >> { >> // "BeforeNavigate2(IDispatch*,QVariant&,QVariant&,QVariant&,QV >> ariant&,QVariant&,bool&)" >> IDispatch *pDisp = params[argc-1].pdispVal; >> VARIANTARG URL = *params[argc-2].pvarVal; >> VARIANTARG Flags = *params[argc-3].pvarVal; >> VARIANTARG TargetFrameName = *params[argc-4].pvarVal; >> VARIANTARG PostData = *params[argc-5].pvarVal; >> VARIANTARG Headers = *params[argc-6].pvarVal; >> VARIANT_BOOL *Cancel = params[argc-7].pboolVal; >> >> QString url = QString::fromStdWString(URL.bstrVal); >> qDebug() << "BeforeNavigate2, ur" << url; >> } >> >> if (name.startsWith("NewWindow3(")) >> { >> // NewWindow3(IDispatch**,bool&,uint,QString,QString)" >> IDispatch *pDisp = params[argc-1].pdispVal; >> VARIANT_BOOL* Cancel = params[argc-2].pboolVal; >> uint Flags = params[argc-3].uintVal; >> BSTR URLContext = params[argc-4].bstrVal; >> BSTR URL = params[argc-5].bstrVal; >> >> QString urlContext = QString::fromStdWString(URLContext); >> QString url = QString::fromStdWString(URL); >> qDebug() << "NewWindow3, opening" << url << "from" << urlContext; >> } >> } >> ... >> >> Good luck! Rgrds Henry >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Wed Jun 28 12:51:34 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 28 Jun 2017 12:51:34 +0200 Subject: [Development] [FYI] me & reviews & retargeting requests Message-ID: <20170628105134.GJ18408@troll08> moin, as the situation has developed to a point where i often literally don't get anything else done after handling mails, incoming bug reports, and reviews, i'm now trying to stick to a cycle where i do reviews only every other working day (monday-wednesday-friday in first approximation). for you this means: - if you have something urgent, in particular retargeting requests, use a lower-latency medium, i.e., irc (usually instant response) or a separate email (up to half a working day latency, assuming you're in my time zone). *don't* just add me to the review and give up if i don't respond within a few hours. also, fregl can handle retargeting requests as well. - in accordance with https://wiki.qt.io/Review_Policy point 2, you are expected to give me (and everyone else) enough time to follow up. if something is too urgent to just wait, see above. on a related note, i'd like to repeat my request to be added to all reviews that involve the build system to a non-trivial degree (i'm watching some stuff in qtbase, but i can't realistically watch everything). you know exactly what reaction to expect when i get to fix your mess ... From rjvbertin at gmail.com Wed Jun 28 13:15:57 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Wed, 28 Jun 2017 13:15:57 +0200 Subject: [Development] right-to-left mode on Mac References: <44151223.1XmRvHF6NA@portia.local> <3216C7CF-CF9E-4E9C-8C8F-44D056A27802@qt.io> <5664345.pAv1bh2JGI@portia.local> <1946040.vEJGYjC2tS@tjmaciei-mobl1> Message-ID: <3122682.p9mudjAZB7@patux.local> This is side-ways related: among the few bundled *applications* that have a Hebrew (R2l) translation there's a qmlviewer application, for which I cannot seem to find the source. Just trying to find a suitable application with a sufficient UI complexity to test the layout ("pure Qt", otherwise I can use the oxygen-demo application). R. From rjvbertin at gmail.com Wed Jun 28 14:02:19 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Wed, 28 Jun 2017 14:02:19 +0200 Subject: [Development] right-to-left mode on Mac References: <44151223.1XmRvHF6NA@portia.local> <3216C7CF-CF9E-4E9C-8C8F-44D056A27802@qt.io> <5664345.pAv1bh2JGI@portia.local> <1946040.vEJGYjC2tS@tjmaciei-mobl1> <499553260.6BCssyWj3I@patux.local> Message-ID: <2351796.U7ALgaDZEf@portia.local> René J. V. Bertin wrote: > Note (to self): Konsole does the following to force QPainter::drawText to do > L2R rendering; will probably work for the shortcut rendering too. Indeed it does: https://github.com/RJVB/osx-integration/commit/b0c5c13d1f211f664e4d29bf0c29146ef62687d6 From thiago.macieira at intel.com Wed Jun 28 17:54:37 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 28 Jun 2017 08:54:37 -0700 Subject: [Development] right-to-left mode on Mac In-Reply-To: <5397767.yLn9bOyxmR@patux.local> References: <44151223.1XmRvHF6NA@portia.local> <1946040.vEJGYjC2tS@tjmaciei-mobl1> <5397767.yLn9bOyxmR@patux.local> Message-ID: <3310754.CVMKYrOGES@tjmaciei-mobl1> On quarta-feira, 28 de junho de 2017 01:24:09 PDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > Actually, it can. The Qt translation contains some extra information, like > > whether the language is R2L and the plural rules. If you don't load the > > .qm > > file for Qt itself (the qtbase one), you'll have problems. > > Yeah, I installed the Hebrew translations and can confirm that launching a > Qt app with the LANGUAGE and LANG variables set accordingly does the trick, > at least for menus Qt renders entirely itself. > The good news is that means one doesn't have to set one's desktop to become > incomprehensible, but it'd still be nice to have a set of en_Mirror > translation files :) Except I want to change that. I personally think it's wrong to require the translators to supply that information. Instead, we should extract from CLDR and store it in QLocale. > >> Shortcut hints are displayed as "C" instead of "C" > > > > That looks like a Unicode BiDi issue. The  symbol is in the private use > > area, so it has no BiDi flow, but "C" does. > > You mean that the text drawing routine would normally obtain additional > information from the text itself whether it should be rendered differently > from the global layout direction? Wouldn't that affect native Mac apps to? There's a whole set of rules for doing BiDi, which I have never read. I just know they exist and a bit of details. Curiosity: what is that (t) symbol? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Wed Jun 28 19:04:56 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Wed, 28 Jun 2017 19:04:56 +0200 Subject: [Development] right-to-left mode on Mac References: <44151223.1XmRvHF6NA@portia.local> <1946040.vEJGYjC2tS@tjmaciei-mobl1> <5397767.yLn9bOyxmR@patux.local> <3310754.CVMKYrOGES@tjmaciei-mobl1> Message-ID: <1989356.ZhWNQs9Isg@patux.local> Thiago Macieira wrote: > Except I want to change that. I personally think it's wrong to require the > translators to supply that information. Instead, we should extract from CLDR > and store it in QLocale. I don't see anything in the .ts files that carries this kind of instruction. Instead it would seem it's contained in the font, at least for languages like Hebrew and Arab. Even my terminal (Konsole) renders those strings right-to-left unless I disable R2L support, or when I use a hex editor. I don't care for the rest where the info is obtained from. As long as it remains (easily) possible to start individual applications using a different locale than the one configured on the desktop or for the shell. > Curiosity: what is that (t) symbol? ? That's a symbol I get with Alt-Shift-K on a Mac keyboard (or Command-Alt-K, I never remember and am not at my Mac right now). It's been under that shortcut for ages (early 90s) and once corresponded to the symbol on the right Command key. No idea what its Unicode name is. R. From thiago.macieira at intel.com Wed Jun 28 19:56:40 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 28 Jun 2017 10:56:40 -0700 Subject: [Development] right-to-left mode on Mac In-Reply-To: <1989356.ZhWNQs9Isg@patux.local> References: <44151223.1XmRvHF6NA@portia.local> <3310754.CVMKYrOGES@tjmaciei-mobl1> <1989356.ZhWNQs9Isg@patux.local> Message-ID: <12815937.kk6PB6BtV3@tjmaciei-mobl1> On Wednesday, 28 June 2017 10:04:56 PDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > Except I want to change that. I personally think it's wrong to require the > > translators to supply that information. Instead, we should extract from > > CLDR and store it in QLocale. > > I don't see anything in the .ts files that carries this kind of instruction. > Instead it would seem it's contained in the font, at least for languages > like Hebrew and Arab. Even my terminal (Konsole) renders those strings > right-to-left unless I disable R2L support, or when I use a hex editor. Ah, sorry, my bad. The information is in the .qm file, but not in the .ts one. The information is added by lrelease from a static table. See https://code.woboq.org/qt5/qttools/src/linguist/shared/ numerus.cpp.html#_Z14getNumerusInfoN7QLocale8LanguageENS_7CountryEP10QByteArrayP11QStringListPPKc The array is right above. As I said, I'd like to move that from stored in the .qm file to stored in QtCore. > I don't care for the rest where the info is obtained from. As long as it > remains (easily) possible to start individual applications using a > different locale than the one configured on the desktop or for the shell. Right, that wouldn't change. > > Curiosity: what is that (t) symbol? > > ? That's a symbol I get with Alt-Shift-K on a Mac keyboard (or > Command-Alt-K, I never remember and am not at my Mac right now). It's been > under that shortcut for ages (early 90s) and once corresponded to the > symbol on the right Command key. No idea what its Unicode name is. Command is ⌘. That's U+2318 "PLACE OF INTEREST SIGN" and is Unicode category So (Symbol, other). Its direction is ON (other, neutral)  is U+F8FF, category Co (Other, private use) and hence has no name. That's probably why I see it as a bold, small "t" in parentheses and you see something else. Its direction is L. There's a huge difference in the text flow which one you choose. See https://en.wikipedia.org/wiki/Bi-directional_text -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From neel5481 at gmail.com Thu Jun 29 08:50:16 2017 From: neel5481 at gmail.com (neel patel) Date: Thu, 29 Jun 2017 12:20:16 +0530 Subject: [Development] Drag and drop Event with QAxWidget issue Message-ID: Hi, I have subclass QAxWidget and re-implemented drag/drop Events as below but wherever we drag some widget to this area then no events are coming. class WebAxWidget : public QAxWidget { public: WebAxWidget(QWidget* parent = 0, Qt::WindowFlags f = 0) : QAxWidget(parent, f) { } protected: void dragEnterEvent(QDragEnterEvent *event) { qDebug() << "Drag Event started ActiveX widget"; event->accept(); } void dragMoveEvent(QDragMoveEvent *event) { qDebug() << "Drag Move started ActiveX widget"; event->acceptProposedAction(); } void dropEvent(QDropEvent *event) { qDebug() << "Drop Event for ActiveX widget"; } } No drag/drop events are coming. Can someone suggest how to receive those events ? Thanks in Advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Thu Jun 29 10:28:52 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 29 Jun 2017 10:28:52 +0200 Subject: [Development] right-to-left mode on Mac References: <44151223.1XmRvHF6NA@portia.local> <3310754.CVMKYrOGES@tjmaciei-mobl1> <1989356.ZhWNQs9Isg@patux.local> <12815937.kk6PB6BtV3@tjmaciei-mobl1> Message-ID: <6687122.sqDZ6cJayS@patux.local> Thiago Macieira wrote: > Ah, sorry, my bad. The information is in the .qm file, but not in the .ts one. And there are none of those in qttranslations (5.8.0) itself which explains why I didn't see it. > The array is right above. As I said, I'd like to move that from stored in the > .qm file to stored in QtCore. That makes sense, I don't think it'll be a huge additional resource. > Command is ⌘. That's U+2318 "PLACE OF INTEREST SIGN" and is Unicode category > So (Symbol, other). Its direction is ON (other, neutral) Ew, yes. I need to dust off my memory... - the filled apple symbol was never used on a Mac keyboard (according to Google Images at least) - legacy keyboards had both the current clover-like symbol and an outline apple symbol on the command key (e.g. http://www.geektechnique.org/images/854.jpg). I think we can presume that the former was chosen to indicate a "key of interest", (or else as a rare gesture to 3rd party keyboard makers to label the key without having to pay licensing 8-)) I still tend to think of the Command key as "the Apple key". What I do remember correctly is that I've never known how to generate the outline apple symbol on a keyboard - it might not even have a Unicode representation. Either way, I've been using it to represent Command-? shortcuts for ages, and it's only now that I realise that hasn't been appropriate for most of that time... >  is U+F8FF, category Co (Other, private use) and hence has no name. That's > probably why I see it as a bold, small "t" in parentheses and you see > something else. Its direction is L. I see it as a small, solid Apple logo, complete with the bite mark. The reason you see something else might simply be because your font doesn't have the glyph. I'm seeing it just fine on Linux, but I'm using a Monaco TTF font borrowed from OS X. > There's a huge difference in the text flow which one you choose. See > https://en.wikipedia.org/wiki/Bi-directional_text Undoubtedly, but that's moot here. As posted earlier it was trivial to get the shortcut mnemonics displayed correctly by using the L2R override character. From rjvbertin at gmail.com Thu Jun 29 11:13:29 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 29 Jun 2017 11:13:29 +0200 Subject: [Development] menu item right-to-left mode on Mac (WIP) References: <44151223.1XmRvHF6NA@portia.local> Message-ID: <2073567.Gj1UYIC7Zu@patux.local> I've been working on getting R2L rendering in context menus and menus belonging to non-native menubars. I think I'm getting close, there may be only a single thing left to tackle: aligning the actual menu item text. That's the main point of the whole exercise and until now it has proven to be far less trivial than the other modifications... My assumption has been that the menuitem dimensions shouldn't change depending on rendering direction: we're basically flipping the contents horizontally. What does work is the alignment and placement of the checkmark, optional icon and the shortcut mnemonic. I think those are at a reasonable and acceptable location for a draft/PoC version, as far as one can judge that without having the item text placed reliably. What also works is the placement of the submenu indicator and the submenu itself. That's not my doing which suggests hierarchical context menus might look really weird in stock R2L mode on Mac. I cannot get my finger around the placement of that item text. With the current code it seems appropriate in some menus (at least when there's no icon), but it's almost as if it gets misaligned towards the left the further left in the (R2L) menubar you get. IOW, something unknown adds a dependency on an equally unidentified property. That almost has to come from the contentRect data, but how? I'm using 2 test apps: * https://github.com/RJVB/shortcut-test-qt5 * the oxygen-demo application from the KF5 Oxygen widget style with a few tweaks. Caveat: I'm doing this in a personalised version of the Macintosh widget style (from Qt 5.9.0) that also adds support for texted separators. Evidently there's overlap between that feature and R2L support in menus; I'm hoping we can ignore that for now. The code: - the R2L changes: https://github.com/RJVB/osx-integration/compare/1383c293a8ca40936b870c3c95afbfaa0b9abd8f...qt590-r2l#diff-8646d85d4040801efefec9e4a234bb65 - current WIP source: https://github.com/RJVB/osx-integration/blob/qt590-r2l/src/qmacstyle/qmacstyle_mac.mm Maybe we can use the github issue tracker until we come up with something that works well enough to put it up for submission? From rjvbertin at gmail.com Thu Jun 29 22:27:21 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 29 Jun 2017 22:27:21 +0200 Subject: [Development] menu item right-to-left mode on Mac (WIP) References: <44151223.1XmRvHF6NA@portia.local> <2073567.Gj1UYIC7Zu@patux.local> Message-ID: <4149253.LlZJfuOrrR@portia.local> https://github.com/RJVB/osx-integration/issues/1 From announce at qt-project.org Fri Jun 30 12:56:05 2017 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Fri, 30 Jun 2017 10:56:05 +0000 Subject: [Development] [Announce] Qt 5.9.1 and Qt Creator 4.3.1 released Message-ID: Hi, I am happy to inform that Qt 5.9.1 and Qt Creator 4.3.1 are released today, see more info from http://blog.qt.io/blog/2017/06/30/qt-5-9-1-released/ and http://blog.qt.io/blog/2017/06/30/qt-creator-4-3-1-released/ Big thanks to everyone involved! Br, Akseli Salovaara _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From cfeck at kde.org Fri Jun 30 18:08:32 2017 From: cfeck at kde.org (Christoph Feck) Date: Fri, 30 Jun 2017 18:08:32 +0200 Subject: [Development] [Interest] QT expert's help required for mentoring Linux Foundation GSoC project. In-Reply-To: References: Message-ID: On 09.06.2017 17:17, Aveek Basu wrote: > This is Aveek from Linux Foundation. Currently myself and Till Kempeter, > are working as the org admins of the LF GSoC project. This year have > undertaken a project of developing the Common Print Dialog for Linux ( > https://wiki.linuxfoundation.org/gsoc/google-summer-code-20 > 17-openprinting-projects). This project will for sure improve the user > experience on how we all print in Linux today. > > The project involves development of the complex Common Print dialogs in QT. > We are badly in need of someone who has development experience in QT > upstream to guide our students. It will be of great help if someone from > the community could could show interest. Is the aim to merge this printing dialog into Qt sources to replace the current Qt print dialog? http://doc.qt.io/qt-5/qprintdialog.html If yes, then the GSoC students should contact Qt developers at the Qt development mailing list, and discuss their plans. Unfortunately, the former QPrinter maintainer is busy with his paid job, so I see difficulties here. If not, then I suggest that the GSoC students just post questions to the Qt interest mailing list, #qt IRC channel, or official Qt forum at https://forum.qt.io/ Please do not use any other Qt mailing list. From thiago.macieira at intel.com Fri Jun 30 19:12:45 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 30 Jun 2017 10:12:45 -0700 Subject: [Development] [Interest] QT expert's help required for mentoring Linux Foundation GSoC project. In-Reply-To: References: Message-ID: <4219188.EaOVMLIBsW@tjmaciei-mobl1> [dropping interest@, keeping development@] On Friday, 30 June 2017 09:08:32 PDT Christoph Feck wrote: > > The project involves development of the complex Common Print dialogs in > > QT. > > We are badly in need of someone who has development experience in QT > > upstream to guide our students. It will be of great help if someone from > > the community could could show interest. Hello Aveek, Till Glad to see the interest. The Qt Project will gladly help, though the extent of how much we can do is unknown at this time. > Is the aim to merge this printing dialog into Qt sources to replace the > current Qt print dialog? http://doc.qt.io/qt-5/qprintdialog.html > > If yes, then the GSoC students should contact Qt developers at the Qt > development mailing list, and discuss their plans. Unfortunately, the > former QPrinter maintainer is busy with his paid job, so I see > difficulties here. >From the linked GSoC pages, it appears that this is about the print dialog itself. So what Christoph said about not having a maintainer is a valid concern. We can't help much with the current code organisation, as none of us is familiar with it. But I don't expect too much difficulty getting to learn it together, provided the student is dedicated as we can't do a lot of handholding. For the reviews themselves, I believe we can manage. I would advise an architectural review on this mailing list so we get more eyes on it, to compensate from John's absence. Finally, the IRC channel for discussing Qt's own development is #qt-labs on Freenode. More active during European daytime. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center