From thiago.macieira at intel.com Tue Dec 1 01:50:08 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 30 Nov 2015 16:50:08 -0800 Subject: [Development] https://bugreports.qt.io/browse/QTBUG-48717 - need help In-Reply-To: <26397150.qWdG1MjIGc@tjmaciei-mobl4> References: <26397150.qWdG1MjIGc@tjmaciei-mobl4> Message-ID: <34500646.9zIcdcJmmU@tjmaciei-mobl4> On Monday 30 November 2015 09:02:55 Thiago Macieira wrote: > I need someone with an ARM board to reproduce the issue and pinpoint where > the event delivery problem might be. My gut feeling was that it was caused > by the different platform plugins, my the reporter says that the problem > happens with XCB too. > > There should be no platform-specific code in the event processing code, so > this sounds like either miscompilation (compiler bug), undefined behaviour > (Qt's bug) or something as simple as the fact that chars are unsigned on > ARM (also Qt's bug). Thanks to Sergio, we figured out that the problem isn't ARM vs non-ARM. It's Glib vs non-Glib event loop. To QPA folks: in 8 of 9 event possible dispatchers in Qt source code, the flush() function is empty. The odd man out is: void QUnixEventDispatcherQPA::flush() { if(qApp) qApp->sendPostedEvents(); } Why? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Tue Dec 1 10:00:29 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 1 Dec 2015 10:00:29 +0100 Subject: [Development] QtCS: Notes from Modern C++ session In-Reply-To: <1610485.DRlUVlzX5v@tjmaciei-mobl4> References: <557A7773.3050903@familiesomers.nl> <1610485.DRlUVlzX5v@tjmaciei-mobl4> Message-ID: <201512011000.29583.marc.mutz@kdab.com> On Tuesday 16 June 2015 22:31:51 Thiago Macieira wrote: > MSVC 2012 and 2013 have a parsing bug with them, so you need to > compile your code with one of those two versions if you're introducing new > range fors. Do you have specifics here? IIRC, it was something like while (...) for (... : .... ) { } which is excluded by our coding standard (missing braces), so it can never happen. TIA, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From rjvbertin at gmail.com Tue Dec 1 10:52:46 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 01 Dec 2015 10:52:46 +0100 Subject: [Development] extending the cocoa native style via a plugin: feasible? Message-ID: <6583643.cl3AgiAZiG@patux> Hi, I'd hoped to make this a shorter message, so please bear with me... I'm currently working to facilitate deployment of the KF5 Frameworks (and dependent applications) on OS X, and looking to provide the best possible experience by supporting as much as possible of the KDE feature set. To me, that clearly includes supporting the different font roles used throughout KDE. Even if we ignore the question whether applications should allow the user to configure a different typeface than what the system would use, an interface will evidently look (and possible work) better if it is displayed with the relative sizes and weights for which it was designed. It would thus be interesting to have an extended native theme that supports the use of different font sizes and/or weights, but also (why not) font families, icon sets and even colour palettes. How feasible would it be to write a plugin that extends the current native theme, i.e. that calls the existing code where possible rather than duplicating that code completely and modifying it where required? If we forget about the native aspect for now: Simply using `-style kde` or `QT_STYLE_OVERRIDE=kde` switches to the graphical look/design of the active KDE theme, but does not changes the fonts (or colour palette or anything else). Therefore, my initial approach in this matter has been to enable the use of KDE's platform theme plugin (through a few small patches to Qt 5.5) and to patch it so it initialises the native theme and uses it where KDE's platform theme plugin does not provide a feature (menus...) or should not be used (e.g. keyboard shortcuts). This works perfectly and allows users to run KDE applications with the KDE theme of their choice, after installing the platform theme plugin and setting an env. variable. This works perfectly ... but it isn't the native theme and thus doesn't provide an improved native look. Experience with KDE4/Qt4 and initial testing with KF5/Qt5 suggests that it won't suffice to set the KDE theme to"Macintosh (aqua)". Hence the question above. Subsidiary question: suppose such an extended theme is developed, how (un)likely is it that the necessary changes to Qt itself (hopefully only QCocoaTheme::themeNames()) would be accepted for incorporation so that automatic selection of the KDE platform theme becomes possible on OS X under similar conditions as those on other Unix versions (for instance, KDE_SESSION_VERSION set in the environment)? If we look at the big picture: more and more applications nowadays provide a user experience (including look and feel) that is identical across platforms, either because they're web-based or because they don't use the full host widget set (or theme it). There's evidently a lot to say for making applications blend in with native applications, but there's also a lot to say for cross-platform applications to hide platform differences by looking as identical as possible wherever they're run. With the technology of the last couple of years any performance advantage of using native GUI APIs has become either insignificant or even a disadvantage (running the latest OS on not-so-recent hardware). Thanks, René Bertin From olivier at woboq.com Tue Dec 1 11:11:37 2015 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 01 Dec 2015 11:11:37 +0100 Subject: [Development] extending the cocoa native style via a plugin: feasible? In-Reply-To: <6583643.cl3AgiAZiG@patux> References: <6583643.cl3AgiAZiG@patux> Message-ID: <5988758.QB4JXtEdWi@finn> On Tuesday 1. December 2015 10:52:46 René J.V. Bertin wrote: > Hi, > > I'd hoped to make this a shorter message, so please bear with me... > > I'm currently working to facilitate deployment of the KF5 Frameworks (and > dependent applications) on OS X, and looking to provide the best possible > experience by supporting as much as possible of the KDE feature set. > > To me, that clearly includes supporting the different font roles used > throughout KDE. Even if we ignore the question whether applications should > allow the user to configure a different typeface than what the system would > use, an interface will evidently look (and possible work) better if it is > displayed with the relative sizes and weights for which it was designed. > > It would thus be interesting to have an extended native theme that supports > the use of different font sizes and/or weights, but also (why not) font > families, icon sets and even colour palettes. How feasible would it be to > write a plugin that extends the current native theme, i.e. that calls the > existing code where possible rather than duplicating that code completely > and modifying it where required? > > If we forget about the native aspect for now: Simply using `-style kde` or > `QT_STYLE_OVERRIDE=kde` switches to the graphical look/design of the active > KDE theme, but does not changes the fonts (or colour palette or anything > else). Therefore, my initial approach in this matter has been to enable the > use of KDE's platform theme plugin (through a few small patches to Qt 5.5) > and to patch it so it initialises the native theme and uses it where KDE's > platform theme plugin does not provide a feature (menus...) or should not > be used (e.g. keyboard shortcuts). This works perfectly and allows users to > run KDE applications with the KDE theme of their choice, after installing > the platform theme plugin and setting an env. variable. > > This works perfectly ... but it isn't the native theme and thus doesn't > provide an improved native look. Experience with KDE4/Qt4 and initial > testing with KF5/Qt5 suggests that it won't suffice to set the KDE theme > to"Macintosh (aqua)". Hence the question above. > > Subsidiary question: suppose such an extended theme is developed, how > (un)likely is it that the necessary changes to Qt itself (hopefully only > QCocoaTheme::themeNames()) would be accepted for incorporation so that > automatic selection of the KDE platform theme becomes possible on OS X > under similar conditions as those on other Unix versions (for instance, > KDE_SESSION_VERSION set in the environment)? > > If we look at the big picture: more and more applications nowadays provide a > user experience (including look and feel) that is identical across > platforms, either because they're web-based or because they don't use the > full host widget set (or theme it). There's evidently a lot to say for > making applications blend in with native applications, but there's also a > lot to say for cross-platform applications to hide platform differences by > looking as identical as possible wherever they're run. With the technology > of the last couple of years any performance advantage of using native GUI > APIs has become either insignificant or even a disadvantage (running the > latest OS on not-so-recent hardware). I don't understand why you need such plugins. Why would KF5 applications be any different than normal Qt5-only applications? The idea is that a KDE applications running on OS X would try to integrate as much as possible within the native style. If an application whishes to do differently, it can still override the default palette or font at the application level, and there is no need for a plugin to do that. (and one of the KF5 libraries could do that.) Or are you trying to run Plasma on OS X? -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From rjvbertin at gmail.com Tue Dec 1 13:00:44 2015 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Tue, 01 Dec 2015 13:00:44 +0100 Subject: [Development] extending the cocoa native style via a plugin: feasible? References: <6583643.cl3AgiAZiG@patux> <5988758.QB4JXtEdWi@finn> Message-ID: <6384558.Y0NSbAmIif@portia.local> Olivier Goffart wrote: > I don't understand why you need such plugins. I had hoped to make that clear... I had also hoped to avoid this turn in the discussion, at least not at once ... > Why would KF5 applications be any different than normal Qt5-only applications? Because they are? KF5 provides facilitates that allow applications to elaborate on Qt features -- that's a bit the whole idea of the KDE 5 frameworks, right? I think it's perfectly understandable that Qt itself provides a more or less minimum, common denominator set of widgets and UI design features that provide a reasonable, working experience across all platforms. That doesn't mean you get an optimal UI out of the box, on all platforms. I'm pretty sure that if you look at applications that do provide a more streamlined, non-standard look (like VirtualBox or Parallel Desktop, or even Qt Creator) you'll find that they either use platform-specific code, or they implement their own style plugin. Which wouldn't be much different from KDE's platform plugin, except for a single style and only a single, standalone application. > The idea is that a KDE applications running on OS X would try to integrate as > much as possible within the native style. Yes, but except for a few very strict environments, OS X does not impose the use of only a single font family, style and size, to name just one aspect of the native style. On the contrary, if you look at the native toolbox, you find a comparable set of predefined font roles and corresponding settings (plus the possibility to do something different), and native applications do indeed make use of them. At the very least that leads to applications that provide much more compact interfaces that waste much less space (and quite frankly, look more professional, less like they were thrown together by someone who doesn't know what s/he was doing ... or couldn't care). I also do think it is perfectly justifiable to allow application suites to provide a coherent experience, and even one that is as coherent as possible across platforms if the developers or even (advanced?) users decide that works best for them. Current trends seem to go that way (look at Google Chrome...) but I am *not* saying this should be the default behaviour, nor that Qt should provide everything required for that. The key concept here is "allowing". > If an application whishes to do differently, it can still override the default > palette or font at the application level, and there is no need for a plugin to > do that. (and one of the KF5 libraries could do that.) To put that in perspective: we're not talking about individual applications here, but about a whole *cross-platform* family of applications that are already "prewired" to select specific fonts, icons, palettes etc. Yes, a KF5 library could provide the theme in question, and basically the "frameworkintegration" framework already does. Except that it's platform theme plugin ("KDEPlatformTheme") doesn't load on OS X without patching Qt. As I said, just using QT_STYLE_OVERRIDE or the -style option does only part of the work, and in a sense the wrong part, the one that applies the (non-native) look from the active KDE "widgetStyle". So Qt would still have to allow that "KDEPlatformTheme" to be loaded, like it does on other Unix variants, under certain conditions that I think are highly unlikely to occur by chance (= for the average unsavvy "Joe User"). Disambiguation: there a source of confusion between the active KDE theme ("widgetStyle"), and the KDEPlatformTheme plugin. The latter is the theme that, when available, is loaded by Qt (in init_platform(), through the theme factory), under a Plasma session on Linux (and on OS X with a small modification). It does not itself provide any theming, but provides the glue required for the "widgetStyle" full feature set. It loads those settings, for instance that are not specific to the selected widgetStyle. I have not found a way to request the KDEPlatformTheme plugin via a commandline or env.var. control; QT_STYLE_OVERRIDE and "-style" both load only a widgetStyle ("-style kde" loads the active widgetStyle, "-style QtCurve" loads a specific style). Mind you though, there are a few vocal/opinionated KDE developers who feel that KDE should not allow anything that's "not native". And that if KDE users on OS X are unhappy with the way that makes things look, they just have to improve Qt ... I don't condone that view (esp. not from people who don't use OS X themselves), but also don't think it's possible to put the whole burden in the KDE camp. > Or are you trying to run Plasma on OS X? No, I'm not trying to run a full Plasma session on OS X. I realise this confusion can arise because what I am currently using is based on something that's supposed to integrate Qt with a Plasma environment. The term "integration" is an appropriate one though, except I take it in a much broader sense. Note that OS X actually does have a hidden feature (exposed by utilities like TinkerTool) to define different fonts (or sizes/styles/weights) for specific roles. Not as many as KDE provides, but those that do exist at least should be accessible via one of the SDKs, and if so should probably be applied by the current native theme in situations where the corresponding roles are known to apply. R. From rjvbertin at gmail.com Tue Dec 1 14:21:54 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 01 Dec 2015 14:21:54 +0100 Subject: [Development] extending the cocoa native style via a plugin: feasible? In-Reply-To: <5988758.QB4JXtEdWi@finn> References: <6583643.cl3AgiAZiG@patux> <5988758.QB4JXtEdWi@finn> Message-ID: <8416113.K6KzbgYDOH@portia.local> A few images to replace a few thousands words more ;) I'm not yet at the point where I can build more complex KF5 applications, so I'm using Qt Creator as a source of examples; it's actually one of the Qt applications that I feel would benefit from a more compact design. The pure, native OS X theme/style: https://git.reviewboard.kde.org/media/uploaded/files/2015/11/30/650d0da7-52b3-40d1-a1f9-cb610494cf77__Screen_Shot_2015-11-30_at_15.42.31.png Same dialog and part of the main UI using the KDEPlatformPlugin and the QtCurve theme+palette hand-tuned for best integration with native applications. This serves as a reference for the selected fonts and colours that should be used. https://git.reviewboard.kde.org/media/uploaded/files/2015/11/30/309e5995-74fa-42fb-a6f3-936cedbf5246__Screen_Shot_2015-11-30_at_15.43.31.png Same dialog using the KDEPlatformPlugin and the native "macintosh" theme: https://git.reviewboard.kde.org/media/uploaded/files/2015/12/01/de55a91f-3500-4db8-8a3b-d252fd7ea169__Screen_Shot_2015-12-01_at_13.52.35.png That 3rd image is of course representative of what a user would get who installs KF5 for the first time, and doesn't use systemsettings5 (nor a kdeglobals file from his/her Linux desktop). It's almost what I would expect from a plugin that extends the native plugin with support for different fonts/font roles, palettes and icon sets without otherwise changing widget appearance. The interface doesn't become noticeably more compact, but that's because the application itself imposes a minimum size on certain of its elements without taking the actual content dimensions into account. There are a couple of clear errors that can be seen: - Frame headings ("Tabs and Indentation", "Typing" etc) use a small, regular version of what appears to be Lucida Grande. Idem in the 1st screenshot. That is *not* hardcoded in Qt Creator, because the 2nd screenshot shows what really ought to be used here. - The tab sheet selection widget uses the system default font in tabs that are not selected, but apparently uses the requested font to determine the widget widths. This widget also is really showing its age, but that's a different topic (Xcode uses a version that looks like a simple toolbars with just the text, no shapes). This would be issues to address in Qt's code, because that's the code being used... Yeah, those fonts are way different from the usual Lucida Grande :) I actually prefer a moderate serif font like this (in "Medium") but its main function in these images is to make it easy to see when the default system font (or style or weight) is used instead of the requested font. R From rjvbertin at gmail.com Tue Dec 1 14:33:55 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 01 Dec 2015 14:33:55 +0100 Subject: [Development] extending the cocoa native style via a plugin: feasible? In-Reply-To: References: <6583643.cl3AgiAZiG@patux> Message-ID: <29020065.C3SydHySPL@portia.local> On Tuesday December 01 2015 11:54:44 Aleix Pol wrote: > I don't really understand what you're asking for either. And I why you were replying to me only and not the list? > Why can't the QPlatformTheme implementation in Qt be extended? This you'd have to ask yourself somewhere where people who are entitled to answer can do so. My guess is that it can be, but that it'd be something that would be considered, if ever, for a next major version. It is like other functionality that was moved from KDE4 into Qt because it had a proven added value. IMHO, such added value will be more apparent if it can be demonstrated on more than a single platform ("Plasma" in this case). > Why does it have anything to do with KDE? Because were talking about font role presets, colour palettes (and icon themes) that are defined by KDE? Evidently it's possible for any application that wishes to do so to use whatever they please even in pure Qt applications. That already happens; cf. VirtualBox or Parallel Desktop or even Qt Creator. Actually, I think I ought to answer with a question: what makes KDE so special that it needs font role presets, colour palettes etc., why didn't it extend the QPlatformTheme in Qt itself? > QPlatformTheme and QStyle aren't tied and it should stay this way. I wonder if that isn't exactly what I'm getting at ... that they should be untied to a further extent on OS X. R From rjvbertin at gmail.com Tue Dec 1 14:40:20 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 01 Dec 2015 14:40:20 +0100 Subject: [Development] extending the cocoa native style via a plugin: feasible? In-Reply-To: <29020065.C3SydHySPL@portia.local> References: <6583643.cl3AgiAZiG@patux> <29020065.C3SydHySPL@portia.local> Message-ID: <1575462.9YVcA1JKxi@portia.local> On Tuesday December 01 2015 14:33:55 René J.V. Bertin wrote: Sorry, this got out before I was done typing > Actually, I think I ought to answer with a question: > what makes KDE so special that it needs font role presets, colour palettes etc., why didn't it extend the QPlatformTheme in Qt itself? It's unnerving to see that on KDE MLs I'm told to "take this up with Qt", and when I do, some of the same people come to suggest that I shouldn't even be pursuing it at all. How can this not come across as a way of saying that the optimal KDE experience is off-limits to OS X and other platforms that cannot run a Plasma DE? R. From olivier at woboq.com Tue Dec 1 15:03:02 2015 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 01 Dec 2015 15:03:02 +0100 Subject: [Development] extending the cocoa native style via a plugin: feasible? In-Reply-To: <1575462.9YVcA1JKxi@portia.local> References: <6583643.cl3AgiAZiG@patux> <29020065.C3SydHySPL@portia.local> <1575462.9YVcA1JKxi@portia.local> Message-ID: <3844745.DT3MhThfOz@finn> On Tuesday 1. December 2015 14:40:20 René J.V. Bertin wrote: > On Tuesday December 01 2015 14:33:55 René J.V. Bertin wrote: > > Sorry, this got out before I was done typing > > > Actually, I think I ought to answer with a question: > > what makes KDE so special that it needs font role presets, colour palettes > > etc., why didn't it extend the QPlatformTheme in Qt itself? > It's unnerving to see that on KDE MLs I'm told to "take this up with Qt", > and when I do, some of the same people come to suggest that I shouldn't > even be pursuing it at all. > > How can this not come across as a way of saying that the optimal KDE > experience is off-limits to OS X and other platforms that cannot run a > Plasma DE? I'm missing some context. Are you talking about the additional roles in KColorScheme? Then I guess the solution is to add them to QPalette. And I don't know which other font roles you are talking about. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From mwoehlke.floss at gmail.com Tue Dec 1 16:43:59 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 01 Dec 2015 10:43:59 -0500 Subject: [Development] extending the cocoa native style via a plugin: feasible? In-Reply-To: <3844745.DT3MhThfOz@finn> References: <6583643.cl3AgiAZiG@patux> <29020065.C3SydHySPL@portia.local> <1575462.9YVcA1JKxi@portia.local> <3844745.DT3MhThfOz@finn> Message-ID: On 2015-12-01 09:03, Olivier Goffart wrote: > Are you talking about the additional roles in KColorScheme? Then I guess the > solution is to add them to QPalette. Yes, please :-). I was disappointed that QPalette didn't get to looking more like KColorScheme in Qt5. It's really useful to have themed colors for more than just "basic text" and "basic background". There are many places that could make use of these, if only they were available. (I cringe inside whenever I make text "red", because I know that someone, somewhere, has red as their default text color, or worse, default background color. With KColorScheme I can use "negative foreground" instead and be confident that it will appear as the user wants.) -- Matthew From thiago.macieira at intel.com Tue Dec 1 17:04:39 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 01 Dec 2015 08:04:39 -0800 Subject: [Development] QtCS: Notes from Modern C++ session In-Reply-To: <201512011000.29583.marc.mutz@kdab.com> References: <557A7773.3050903@familiesomers.nl> <1610485.DRlUVlzX5v@tjmaciei-mobl4> <201512011000.29583.marc.mutz@kdab.com> Message-ID: <1521142.K6FdhQiv6g@tjmaciei-mobl4> On Tuesday 01 December 2015 10:00:29 Marc Mutz wrote: > On Tuesday 16 June 2015 22:31:51 Thiago Macieira wrote: > > MSVC 2012 and 2013 have a parsing bug with them, so you need to > > > > compile your code with one of those two versions if you're introducing new > > range fors. > > Do you have specifics here? IIRC, it was something like > > while (...) > for (... : .... ) { > } > > which is excluded by our coding standard (missing braces), so it can never > happen. It fails to compile tst_compiler.cpp's cxx11_range_for. for (int i : l) QCOMPARE(i, 1); The reduced testcase, which I sent to Microsoft but can no longer find, is when you have a while inside a for. I don't remember whether the braces are required or must be absent or not. This one is reported to still have a problem with 2015: https://connect.microsoft.com/VisualStudio/feedback/details/1513773/cannot-use-lambda-in-the-single-statement-of-the-range-for-loop There's another one with try/catch, but I can't find my log in to read the details: https://connect.microsoft.com/VisualStudio/feedbackdetail/view/874705 See also this still open report: https://connect.microsoft.com/VisualStudio/feedback/details/2036654/c-compiler-bug-range-based-for for (const auto &outer : v) for (const auto &item : outer) do {} while (false); Anyway, the rule for Qt 5.7 is that you can use range fors, as long as you first compile your code with VS 2012 or 2013 due to their various parsing bugs. Don't submit to the CI until you have tested yourself or someone has on your behalf. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From joerg.bornemann at theqtcompany.com Wed Dec 2 10:17:57 2015 From: joerg.bornemann at theqtcompany.com (Joerg Bornemann) Date: Wed, 2 Dec 2015 10:17:57 +0100 Subject: [Development] buildsystem now needs to keep behaviour compatibility In-Reply-To: <2394178.nH4WTEmeSG@tjmaciei-mobl4> References: <2394178.nH4WTEmeSG@tjmaciei-mobl4> Message-ID: <565EB745.8080507@theqtcompany.com> On 30-Nov-15 18:29, Thiago Macieira wrote: > Now that we will no longer include qtwebkit, qtquick1 and qtscript in the main > releases, we are asking people to continue building the last released version > of some of those modules against newer Qt versions. We should then keep build tests for these modules in the CI. Otherwise we won't notice breakages. BR, Joerg From olivier at woboq.com Wed Dec 2 13:04:40 2015 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 02 Dec 2015 13:04:40 +0100 Subject: [Development] buildsystem now needs to keep behaviour compatibility In-Reply-To: <565EB745.8080507@theqtcompany.com> References: <2394178.nH4WTEmeSG@tjmaciei-mobl4> <565EB745.8080507@theqtcompany.com> Message-ID: <22298513.hvfALFAysn@finn> On Wednesday 2. December 2015 10:17:57 Joerg Bornemann wrote: > On 30-Nov-15 18:29, Thiago Macieira wrote: > > Now that we will no longer include qtwebkit, qtquick1 and qtscript in the > > main releases, we are asking people to continue building the last > > released version of some of those modules against newer Qt versions. I suppose this also applies to all the private API used by these modules? (and qtquick1 uses a lot of private APIs) > We should then keep build tests for these modules in the CI. > Otherwise we won't notice breakages. I agree. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From marc.mutz at kdab.com Wed Dec 2 15:45:55 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 2 Dec 2015 15:45:55 +0100 Subject: [Development] Qt LTS & C++11 plans In-Reply-To: <14071234.PvcYbKEM6S@finn> References: <2179031.L5GMPoFkkI@tjmaciei-mobl4> <14071234.PvcYbKEM6S@finn> Message-ID: <201512021545.56041.marc.mutz@kdab.com> On Monday 23 November 2015 09:59:43 Olivier Goffart wrote: > Anyway, i'd like to start the white list with std::enable_if https://codereview.qt-project.org/142782 proposal to add std::hash, too: https://codereview.qt-project.org/142791 -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From laszlo.agocs at theqtcompany.com Wed Dec 2 15:13:05 2015 From: laszlo.agocs at theqtcompany.com (Agocs Laszlo) Date: Wed, 2 Dec 2015 14:13:05 +0000 Subject: [Development] Nominating Samuli Pippo for Approver status Message-ID: Hello, I would like to nominate Samuli Piippo for Approver status in the Qt Project. Samuli has been working on Qt's Embedded Linux support and Qt for Device Creation during the past few years. He is our resident Yocto expert and is contributing to meta-qt5 as well. Public Gerrit dashboard: https://codereview.qt-project.org/#/q/owner:samuli.piippo,n,z meta-qt5 contributions: https://github.com/meta-qt5/meta-qt5/commits/master?author=sapiippo Best regards, Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Dec 2 16:45:04 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Dec 2015 07:45:04 -0800 Subject: [Development] buildsystem now needs to keep behaviour compatibility In-Reply-To: <565EB745.8080507@theqtcompany.com> References: <2394178.nH4WTEmeSG@tjmaciei-mobl4> <565EB745.8080507@theqtcompany.com> Message-ID: <6302468.0hiC1ALmzD@tjmaciei-mobl4> On Wednesday 02 December 2015 10:17:57 Joerg Bornemann wrote: > On 30-Nov-15 18:29, Thiago Macieira wrote: > > Now that we will no longer include qtwebkit, qtquick1 and qtscript in the > > main releases, we are asking people to continue building the last > > released version of some of those modules against newer Qt versions. > > We should then keep build tests for these modules in the CI. > Otherwise we won't notice breakages. We don't need that frequent testing. It's enough that we test (and fix issues) before the releases. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Dec 2 16:46:24 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Dec 2015 07:46:24 -0800 Subject: [Development] buildsystem now needs to keep behaviour compatibility In-Reply-To: <22298513.hvfALFAysn@finn> References: <2394178.nH4WTEmeSG@tjmaciei-mobl4> <565EB745.8080507@theqtcompany.com> <22298513.hvfALFAysn@finn> Message-ID: <2111432.7RNJ2xkWLk@tjmaciei-mobl4> On Wednesday 02 December 2015 13:04:40 Olivier Goffart wrote: > On Wednesday 2. December 2015 10:17:57 Joerg Bornemann wrote: > > On 30-Nov-15 18:29, Thiago Macieira wrote: > > > Now that we will no longer include qtwebkit, qtquick1 and qtscript in > > > the > > > main releases, we are asking people to continue building the last > > > released version of some of those modules against newer Qt versions. > > I suppose this also applies to all the private API used by these modules? > (and qtquick1 uses a lot of private APIs) They must be kept working for qtscript and qtwebkit. They don't need to keep binary compatibility. qtquick1 is marked as "will not work anymore". So qtquick1 is moving from Deprecated to Removed+StopUsingItNow. > > We should then keep build tests for these modules in the CI. > > Otherwise we won't notice breakages. > > I agree. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sahumada at texla.cl Wed Dec 2 18:31:03 2015 From: sahumada at texla.cl (Sergio Ahumada) Date: Wed, 2 Dec 2015 18:31:03 +0100 Subject: [Development] Nominating Samuli Pippo for Approver status In-Reply-To: References: Message-ID: <565F2AD7.5030102@texla.cl> On 02.12.2015 15:13, Agocs Laszlo wrote: > Hello, > > I would like to nominate Samuli Piippo for Approver status in the Qt > Project. Samuli has been working on Qt's Embedded Linux support and Qt > for Device Creation during the past few years. He is our resident Yocto > expert and is contributing to meta-qt5 as well. > > Public Gerrit dashboard: > https://codereview.qt-project.org/#/q/owner:samuli.piippo,n,z > > meta-qt5 contributions: > https://github.com/meta-qt5/meta-qt5/commits/master?author=sapiippo > > Best regards, > Laszlo +1 From Andy.Nichols at theqtcompany.com Wed Dec 2 18:57:07 2015 From: Andy.Nichols at theqtcompany.com (Nichols Andy) Date: Wed, 2 Dec 2015 17:57:07 +0000 Subject: [Development] Nominating Samuli Pippo for Approver status In-Reply-To: References: Message-ID: <6F272515-1756-4074-9631-594EF7BD4DEF@theqtcompany.com> +1 from me as well Andy Nichols On 02 Dec 2015, at 15:13, Agocs Laszlo > wrote: Hello, I would like to nominate Samuli Piippo for Approver status in the Qt Project. Samuli has been working on Qt's Embedded Linux support and Qt for Device Creation during the past few years. He is our resident Yocto expert and is contributing to meta-qt5 as well. Public Gerrit dashboard: https://codereview.qt-project.org/#/q/owner:samuli.piippo,n,z meta-qt5 contributions: https://github.com/meta-qt5/meta-qt5/commits/master?author=sapiippo Best regards, Laszlo _______________________________________________ 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 louis.meadows at theqtcompany.com Wed Dec 2 23:01:42 2015 From: louis.meadows at theqtcompany.com (Meadows Louis) Date: Wed, 2 Dec 2015 22:01:42 +0000 Subject: [Development] Nominating Samuli Pippo for Approver status In-Reply-To: References: Message-ID: +1 from me as well From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Agocs Laszlo Sent: Wednesday, December 02, 2015 6:13 AM To: development at qt-project.org Subject: [Development] Nominating Samuli Pippo for Approver status Hello, I would like to nominate Samuli Piippo for Approver status in the Qt Project. Samuli has been working on Qt's Embedded Linux support and Qt for Device Creation during the past few years. He is our resident Yocto expert and is contributing to meta-qt5 as well. Public Gerrit dashboard: https://codereview.qt-project.org/#/q/owner:samuli.piippo,n,z meta-qt5 contributions: https://github.com/meta-qt5/meta-qt5/commits/master?author=sapiippo Best regards, Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.dewit at iesve.com Thu Dec 3 12:18:24 2015 From: mark.dewit at iesve.com (Mark De Wit) Date: Thu, 3 Dec 2015 11:18:24 +0000 Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries Message-ID: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> Hi all, QtWebEngine does not yet have feature parity with QtWebkit. For instance, print support (especially export to PDF) is a critical requirement for my use of Webkit. This missing feature prevents me from migrating to WebEngine. Removing webkit from the official distribution will prevent me (and surely others) from upgrading to 5.6. Thanks, Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre at familiesomers.nl Thu Dec 3 12:26:20 2015 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 3 Dec 2015 12:26:20 +0100 Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> References: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> Message-ID: <566026DC.9060508@familiesomers.nl> Op 03/12/2015 om 12:18 schreef Mark De Wit: > > Hi all, > > QtWebEngine does not yet have feature parity with QtWebkit. For > instance, print support (especially export to PDF) is a critical > requirement for my use of Webkit. This missing feature prevents me > from migrating to WebEngine. > > Removing webkit from the official distribution will prevent me (and > surely others) from upgrading to 5.6. > > You should still be able to build QtWebkit against 5.6 if I understand it correctly, so you can still upgrade if you want. It does take more effort though. André -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at theqtcompany.com Thu Dec 3 13:29:47 2015 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Thu, 3 Dec 2015 12:29:47 +0000 Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> References: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> Message-ID: Hi Mark, If you need to use Qt Webkit, then it is probably better to stay with Qt 5.5. There is nothing that makes Qt 5.5 bad overnight, if it works for you now. Qt WebEngine is in many aspects already much better in features than Qt Webkit. Qt WebEngine is also better maintained, and does receive much more improvements and security fixes than Qt Webkit. Even though some features of Qt WebKit are not in same way available with Qt WebEngine, it is overall a better choice. Qt Webkit is removed from Qt 5.6 because it is no longer maintained well enough to be part of an official Qt release. We are also not developing and testing it to work with Qt 5.6. Yours, Tuukka From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Mark De Wit Sent: torstaina 3. joulukuuta 2015 13.18 To: development at qt-project.org Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries Hi all, QtWebEngine does not yet have feature parity with QtWebkit. For instance, print support (especially export to PDF) is a critical requirement for my use of Webkit. This missing feature prevents me from migrating to WebEngine. Removing webkit from the official distribution will prevent me (and surely others) from upgrading to 5.6. Thanks, Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From kde at carewolf.com Thu Dec 3 13:41:45 2015 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Thu, 3 Dec 2015 13:41:45 +0100 Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> References: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> Message-ID: <201512031341.46039.kde@carewolf.com> On Thursday 03 December 2015, Mark De Wit wrote: > Hi all, > > QtWebEngine does not yet have feature parity with QtWebkit. For instance, > print support (especially export to PDF) is a critical requirement for my > use of Webkit. This missing feature prevents me from migrating to > WebEngine. > > Removing webkit from the official distribution will prevent me (and surely > others) from upgrading to 5.6. > Besides being possible to use QtWebKit from 5.5 with Qt 5.6, there are also QtWebKit 5.6.0 sources in git, they are just not part of the official release. Regards `Allan From annulen at yandex.ru Thu Dec 3 13:54:42 2015 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 03 Dec 2015 15:54:42 +0300 Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <201512031341.46039.kde@carewolf.com> References: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> <201512031341.46039.kde@carewolf.com> Message-ID: <2595991449147282@web15j.yandex.ru> 03.12.2015, 15:41, "Allan Sandfeld Jensen" : > On Thursday 03 December 2015, Mark De Wit wrote: >>  Hi all, >> >>  QtWebEngine does not yet have feature parity with QtWebkit. For instance, >>  print support (especially export to PDF) is a critical requirement for my >>  use of Webkit. This missing feature prevents me from migrating to >>  WebEngine. >> >>  Removing webkit from the official distribution will prevent me (and surely >>  others) from upgrading to 5.6. > > Besides being possible to use QtWebKit from 5.5 with Qt 5.6, there are also > QtWebKit 5.6.0 sources in git, they are just not part of the official release. Why not at least package its sources them same way as are sources of Qt add-ons? -- Regards, Konstantin From mark.dewit at iesve.com Thu Dec 3 14:37:33 2015 From: mark.dewit at iesve.com (Mark De Wit) Date: Thu, 3 Dec 2015 13:37:33 +0000 Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: References: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> Message-ID: <3709A7D425EE8C45991DB29EC2FACA8827203A31@GL-EXC-01.iesve.com> Thanks for all the feedback everyone. We are excited about the 5.6 release because we are looking closely at the new Qt3D module, as well as migrating to VS 2015. Sadly, PDF export of HTML content is a critical feature for our product (in general I'm happy to move to WebEngine, but we cannot remove output functionality from our software). Building from source would be an option, I guess. We have done it in the past, but the build process / flags (for distribution) is not sufficiently well documented, and starting with 5.5.1 we were excited to be able to use official binaries. Kind regards, Mark From: Turunen Tuukka [mailto:tuukka.turunen at theqtcompany.com] Sent: 03 December 2015 12:30 To: Mark De Wit ; development at qt-project.org Subject: RE: [Development] Please do not remove QtWebkit from 5.6 official binaries Hi Mark, If you need to use Qt Webkit, then it is probably better to stay with Qt 5.5. There is nothing that makes Qt 5.5 bad overnight, if it works for you now. Qt WebEngine is in many aspects already much better in features than Qt Webkit. Qt WebEngine is also better maintained, and does receive much more improvements and security fixes than Qt Webkit. Even though some features of Qt WebKit are not in same way available with Qt WebEngine, it is overall a better choice. Qt Webkit is removed from Qt 5.6 because it is no longer maintained well enough to be part of an official Qt release. We are also not developing and testing it to work with Qt 5.6. Yours, Tuukka From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Mark De Wit Sent: torstaina 3. joulukuuta 2015 13.18 To: development at qt-project.org Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries Hi all, QtWebEngine does not yet have feature parity with QtWebkit. For instance, print support (especially export to PDF) is a critical requirement for my use of Webkit. This missing feature prevents me from migrating to WebEngine. Removing webkit from the official distribution will prevent me (and surely others) from upgrading to 5.6. Thanks, Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.sutton at subsite.com Thu Dec 3 15:09:20 2015 From: edward.sutton at subsite.com (Edward Sutton) Date: Thu, 3 Dec 2015 14:09:20 +0000 Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <3709A7D425EE8C45991DB29EC2FACA8827203A31@GL-EXC-01.iesve.com> References: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> <3709A7D425EE8C45991DB29EC2FACA8827203A31@GL-EXC-01.iesve.com> Message-ID: <4C163E56-0A16-4C53-A48E-2EA3D6ACBFF7@subsite.com> Will Qt 5.6 have alternative methods to export HTML to PDF that support major platforms of Android, iOS, Linux, OS X, and Windows? On iOS a Qt developer must resort to native code to generate PDF files. Unfortunately Qt 5.5 PDF export is dependent on QPrinter which is not supported on iOS. While iOS can create and displays PDF’s just fine, iOS has no printer support. In the future, Is it possible the PDF creation dependency could be separated from QPrinter? So that Qt PDF generation would have better cross-platform support? QPrinter printer(QPrinter::ScreenResolution); // QPrinter not supported on iOS printer.setOutputFormat(QPrinter::PdfFormat); printer.setOutputFileName(pdfFileName); drawReport(printer); m_painter.end(); Without understanding internals of PDF file creation, it feels like PDF creation should not be dependent on QPrinter? -Ed On Dec 3, 2015, at 7:37 AM, Mark De Wit > wrote: Thanks for all the feedback everyone. We are excited about the 5.6 release because we are looking closely at the new Qt3D module, as well as migrating to VS 2015. Sadly, PDF export of HTML content is a critical feature for our product (in general I’m happy to move to WebEngine, but we cannot remove output functionality from our software). Building from source would be an option, I guess. We have done it in the past, but the build process / flags (for distribution) is not sufficiently well documented, and starting with 5.5.1 we were excited to be able to use official binaries. Kind regards, Mark From: Turunen Tuukka [mailto:tuukka.turunen at theqtcompany.com] Sent: 03 December 2015 12:30 To: Mark De Wit >; development at qt-project.org Subject: RE: [Development] Please do not remove QtWebkit from 5.6 official binaries Hi Mark, If you need to use Qt Webkit, then it is probably better to stay with Qt 5.5. There is nothing that makes Qt 5.5 bad overnight, if it works for you now. Qt WebEngine is in many aspects already much better in features than Qt Webkit. Qt WebEngine is also better maintained, and does receive much more improvements and security fixes than Qt Webkit. Even though some features of Qt WebKit are not in same way available with Qt WebEngine, it is overall a better choice. Qt Webkit is removed from Qt 5.6 because it is no longer maintained well enough to be part of an official Qt release. We are also not developing and testing it to work with Qt 5.6. Yours, Tuukka From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Mark De Wit Sent: torstaina 3. joulukuuta 2015 13.18 To: development at qt-project.org Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries Hi all, QtWebEngine does not yet have feature parity with QtWebkit. For instance, print support (especially export to PDF) is a critical requirement for my use of Webkit. This missing feature prevents me from migrating to WebEngine. Removing webkit from the official distribution will prevent me (and surely others) from upgrading to 5.6. Thanks, Mark _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.shaw at theqtcompany.com Thu Dec 3 15:31:39 2015 From: andy.shaw at theqtcompany.com (Shaw Andy) Date: Thu, 3 Dec 2015 14:31:39 +0000 Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <4C163E56-0A16-4C53-A48E-2EA3D6ACBFF7@subsite.com> References: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> <3709A7D425EE8C45991DB29EC2FACA8827203A31@GL-EXC-01.iesve.com> <4C163E56-0A16-4C53-A48E-2EA3D6ACBFF7@subsite.com> Message-ID: There is QPdfWriter at least which is a paint device, so you could use that for generating PDFs as that is available iOS from what I can see. Andy From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Edward Sutton Sent: 3. desember 2015 15:09 To: Mark De Wit Cc: development at qt-project.org Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official binaries Will Qt 5.6 have alternative methods to export HTML to PDF that support major platforms of Android, iOS, Linux, OS X, and Windows? On iOS a Qt developer must resort to native code to generate PDF files. Unfortunately Qt 5.5 PDF export is dependent on QPrinter which is not supported on iOS. While iOS can create and displays PDF’s just fine, iOS has no printer support. In the future, Is it possible the PDF creation dependency could be separated from QPrinter? So that Qt PDF generation would have better cross-platform support? QPrinter printer(QPrinter::ScreenResolution); // QPrinter not supported on iOS printer.setOutputFormat(QPrinter::PdfFormat); printer.setOutputFileName(pdfFileName); drawReport(printer); m_painter.end(); Without understanding internals of PDF file creation, it feels like PDF creation should not be dependent on QPrinter? -Ed On Dec 3, 2015, at 7:37 AM, Mark De Wit > wrote: Thanks for all the feedback everyone. We are excited about the 5.6 release because we are looking closely at the new Qt3D module, as well as migrating to VS 2015. Sadly, PDF export of HTML content is a critical feature for our product (in general I’m happy to move to WebEngine, but we cannot remove output functionality from our software). Building from source would be an option, I guess. We have done it in the past, but the build process / flags (for distribution) is not sufficiently well documented, and starting with 5.5.1 we were excited to be able to use official binaries. Kind regards, Mark From: Turunen Tuukka [mailto:tuukka.turunen at theqtcompany.com] Sent: 03 December 2015 12:30 To: Mark De Wit >; development at qt-project.org Subject: RE: [Development] Please do not remove QtWebkit from 5.6 official binaries Hi Mark, If you need to use Qt Webkit, then it is probably better to stay with Qt 5.5. There is nothing that makes Qt 5.5 bad overnight, if it works for you now. Qt WebEngine is in many aspects already much better in features than Qt Webkit. Qt WebEngine is also better maintained, and does receive much more improvements and security fixes than Qt Webkit. Even though some features of Qt WebKit are not in same way available with Qt WebEngine, it is overall a better choice. Qt Webkit is removed from Qt 5.6 because it is no longer maintained well enough to be part of an official Qt release. We are also not developing and testing it to work with Qt 5.6. Yours, Tuukka From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Mark De Wit Sent: torstaina 3. joulukuuta 2015 13.18 To: development at qt-project.org Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries Hi all, QtWebEngine does not yet have feature parity with QtWebkit. For instance, print support (especially export to PDF) is a critical requirement for my use of Webkit. This missing feature prevents me from migrating to WebEngine. Removing webkit from the official distribution will prevent me (and surely others) from upgrading to 5.6. Thanks, Mark _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Dec 3 16:05:09 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Dec 2015 07:05:09 -0800 Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <2595991449147282@web15j.yandex.ru> References: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> <201512031341.46039.kde@carewolf.com> <2595991449147282@web15j.yandex.ru> Message-ID: <6589227.2FNfxb9jyO@tjmaciei-mobl4> On Thursday 03 December 2015 15:54:42 Konstantin Tokarev wrote: > > Besides being possible to use QtWebKit from 5.5 with Qt 5.6, there are > > also > > QtWebKit 5.6.0 sources in git, they are just not part of the official > > release. > Why not at least package its sources them same way as are sources of Qt > add-ons? Because we decided not to. We should not even have created the 5.6 branch on that repository, because there will be no 5.6.0 release. The changes that landed on that branch will remain forever unreleased. Instead, you should build this: http://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/qtwebkit-opensource-src-5.5.1.zip http://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/qtwebkit-opensource-src-5.5.1.tar.gz -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Thu Dec 3 16:13:58 2015 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 03 Dec 2015 18:13:58 +0300 Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <6589227.2FNfxb9jyO@tjmaciei-mobl4> References: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> <201512031341.46039.kde@carewolf.com> <2595991449147282@web15j.yandex.ru> <6589227.2FNfxb9jyO@tjmaciei-mobl4> Message-ID: <2259071449155638@web15o.yandex.ru> 03.12.2015, 18:05, "Thiago Macieira" : > On Thursday 03 December 2015 15:54:42 Konstantin Tokarev wrote: >>  > Besides being possible to use QtWebKit from 5.5 with Qt 5.6, there are >>  > also >>  > QtWebKit 5.6.0 sources in git, they are just not part of the official >>  > release. >>  Why not at least package its sources them same way as are sources of Qt >>  add-ons? > > Because we decided not to. We should not even have created the 5.6 branch on > that repository, because there will be no 5.6.0 release. The changes that > landed on that branch will remain forever unreleased. > > Instead, you should build this: > http://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/qtwebkit-opensource-src-5.5.1.zip > http://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/qtwebkit-opensource-src-5.5.1.tar.gz No, thanks, I need features which I've contributed to 5.6 branch. -- Regards, Konstantin From thiago.macieira at intel.com Thu Dec 3 18:18:57 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Dec 2015 09:18:57 -0800 Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <2259071449155638@web15o.yandex.ru> References: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> <6589227.2FNfxb9jyO@tjmaciei-mobl4> <2259071449155638@web15o.yandex.ru> Message-ID: <1752356.AuBfOxgGgX@tjmaciei-mobl4> On Thursday 03 December 2015 18:13:58 Konstantin Tokarev wrote: > > Instead, you should build this: > > http://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/qtwebkit-o > > pensource-src-5.5.1.zip > > http://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/qtwebkit-> > opensource-src-5.5.1.tar.gz > No, thanks, I need features which I've contributed to 5.6 branch. You can compile your own version of qtwebkit, no problem. I have my own patches to it. That doesn't mean they will be released. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Thu Dec 3 19:49:46 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 3 Dec 2015 19:49:46 +0100 Subject: [Development] RFC: more liberal 'auto' rules? Message-ID: <201512031949.46920.marc.mutz@kdab.com> Hi, The wiki[1] currently contains some rules for how to use automatic type deduction for variables (Q_C_AUTO_TYPE) that are very restrictive. [1] I get an ERROR: state not found when trying to log in, btw. And pointless. The remainder of the C++ world is moving towards an "always auto" scheme. We don't need to go there, but I'd at least like to propose, for new code and as a drive-by, the *required* use of auto for: - template code (esp., but not necessarily only, when the type name would require the use of 'typename') - all loop variables (both index and iterators) the reason being that spelling out the name is usually wrong: size_t i = stdVector.size() // wrong, should be std::vector::size_type... also helps when porting from Qt containers to STL ones - all references to elements in a collection (same problem - way too easy to misspell std::pair for std::pair...) Optional use of auto: whereever it makes sense. Use your own judgement, but remember: fear is a bad advisor. For range-for, I'd suggest the following patterns: - loop variable: singular name of collection name (foo : foos) - otherwise: 'e' (for element) or first letter (r : rects) - for (auto e : collection) // (for pass-by-value types, or if you modify) - for (const auto &e : collection) // for pass-by-reference types - for (auto &e : collection) // mutating (also: pointer variables/no auto *&e) - for (const auto *e : collection) // const pointers - for (auto *e : collection) // non-const pointer - explicit type name should be the exception This is covering a large part of the usefulness of auto. I don't really like to add anything more detailed to the "rules". Scott Meyers' books do a much better job at explaining than we ever could. Opinions? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Thu Dec 3 19:02:44 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Dec 2015 10:02:44 -0800 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512031949.46920.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> Message-ID: <4676887.dAJuEMoJXc@tjmaciei-mobl4> On Thursday 03 December 2015 19:49:46 Marc Mutz wrote: > The remainder of the C++ world is moving towards an "always auto" scheme. We > don't need to go there, but I'd at least like to propose, for new code and > as a drive-by, the *required* use of auto for: The remainder of the C++ world is no indication for us. Also remember that, for us, the source code is a product. We need to have readable source code, so we have two ground rules that must be respected: 1) the use of auto must make the code more readable, not less 2) Qt Creator must be able to parse and deduce the correct type #2 is, of course, a transient issue, because Creator will get better over time. As for #1, it's subjective. "More readable" does not mean "fewer characters". If someone reading the code cannot understand what that variable is doing, then it's less readable. Thankfully, Qt API is well designed so you can usually tell from the function name what it does, without having to know the class it is defined in. But it follows that if you're interfacing with non-Qt API, then their API may be worse and this less readable. For example, the "is" prefix for boolean properties helps a lot, since you won't have to decide whether a plain word in English is a state or a an action, as in "empty". > - template code (esp., but not necessarily only, when the type name would > require the use of 'typename') Agreed, except when in violation of the ground rules. > - all loop variables (both index and iterators) Except for primitives, because "int" is shorter than "auto". > the reason being that spelling out the name is usually wrong: > size_t i = stdVector.size() // wrong, should be std::vector::size_type... > also helps when porting from Qt containers to STL ones I disagree. We'll use int, thank you. You know I disagree about porting from Qt containers to Standard Library ones. Therefore, that is not an argument to convince me to write uglier code with auto. > - all references to elements in a collection (same problem - way too easy to > misspell std::pair for std::pair...) Example? > Optional use of auto: whereever it makes sense. Use your own judgement, but > remember: fear is a bad advisor. > > For range-for, I'd suggest the following patterns: > > - loop variable: singular name of collection name (foo : foos) > - otherwise: 'e' (for element) or first letter (r : rects) > - for (auto e : collection) // (for pass-by-value types, or if you modify) > - for (const auto &e : collection) // for pass-by-reference types > - for (auto &e : collection) // mutating (also: pointer variables/no auto > *&e) Agreed. > - for (const auto *e : collection) // const pointers > - for (auto *e : collection) // non-const pointer Why? Why not allow "auto e" and e is a pointer? > - explicit type name should be the exception Agreed. > This is covering a large part of the usefulness of auto. > > I don't really like to add anything more detailed to the "rules". Scott > Meyers' books do a much better job at explaining than we ever could. Qt has never and will never build without warnings from -Weffc++. Some of Scott's rules are good, but we do not have to adopt them all. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mwoehlke.floss at gmail.com Thu Dec 3 19:35:00 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Thu, 03 Dec 2015 13:35:00 -0500 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512031949.46920.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> Message-ID: On 2015-12-03 13:02, Thiago Macieira wrote: > On 2015-12-03 13:49, Marc Mutz wrote: > I'd at least like to propose, for new code and as >> a drive-by, the *required* use of auto for: >> >> - all loop variables (both index and iterators) >> the reason being that spelling out the name is usually wrong: >> size_t i = stdVector.size() // wrong, should be std::vector::size_type... >> also helps when porting from Qt containers to STL ones You probably want my index range helper¹ for index iteration... otherwise you need ugly work-arounds to use type deduction. The enumerate helper is also useful for iterating over (Qt) associative containers. (Needs to change to make a copy of the container, though, so that it doesn't have dangling references in case of temporaries. That's a trivial change though.) (¹ http://permalink.gmane.org/gmane.comp.lib.qt.devel/21327) > Except for primitives, because "int" is shorter than "auto". Automatic matching of the index type to the type that the container *actually uses for indices* is preferable to a shorter name. Even if you "know" that the type is int. Whether or not uses of Qt containers are ever replaced with use of STL containers, it's just good habit. Maybe less important in Qt itself, but I still submit that it would be good for Qt to demonstrate the "right" way to do things. Because for your users, it *does* matter. (I have a code base that is absolutely rife with index type mismatches because it predates auto and qtIndexRange. With proper use of those, such errors are avoided.) MHO: don't use a possible type conversion if you can avoid it, and if you do, use uniform initialization so that the compiler will reject a narrowing conversion. -- Matthew From suy at badopi.org Thu Dec 3 20:08:02 2015 From: suy at badopi.org (Alejandro Exojo) Date: Thu, 3 Dec 2015 20:08:02 +0100 Subject: [Development] =?iso-8859-15?q?Please_do_not_remove_QtWebkit_from_?= =?iso-8859-15?q?5=2E6_official=09binaries?= In-Reply-To: <3709A7D425EE8C45991DB29EC2FACA8827203A31@GL-EXC-01.iesve.com> References: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> <3709A7D425EE8C45991DB29EC2FACA8827203A31@GL-EXC-01.iesve.com> Message-ID: <201512032008.02198.suy@badopi.org> El Thursday 03 December 2015, Mark De Wit escribió: > Building from source would be an option, I guess. We have done it in the > past, but the build process / flags (for distribution) is not sufficiently > well documented, and starting with 5.5.1 we were excited to be able to use > official binaries. When reproducing a build, I always start with the flags in this repository: http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net From suy at badopi.org Thu Dec 3 20:17:21 2015 From: suy at badopi.org (Alejandro Exojo) Date: Thu, 3 Dec 2015 20:17:21 +0100 Subject: [Development] QFutureInterface In-Reply-To: <54B0CAFD8875674EAD2C2C03BA3652F00184A591@DENBGAT9EI5MSX.ww902.siemens.net> References: <54B0CAFD8875674EAD2C2C03BA3652F001849F66@DENBGAT9EI5MSX.ww902.siemens.net> <201511261332.54740.marc.mutz@kdab.com> <54B0CAFD8875674EAD2C2C03BA3652F00184A591@DENBGAT9EI5MSX.ww902.siemens.net> Message-ID: <201512032017.21551.suy@badopi.org> El Friday 27 November 2015, Bauer, Christian escribió: > Our (simplified) problem is: this function does not return a value but > feeds an asynchronous pipeline. When the pipeline processing is done it > will call promise.SetResult(); promise.reportResult(); > and only then the future should be notified of the result. I would not mind see your patch in code review, and read what others have to say for or against. Having a QPromise or some other public API for QFuture would be nice, as you could attach a QFutureWatcher to it. -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net From Marco.Bubke at theqtcompany.com Thu Dec 3 22:15:42 2015 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Thu, 3 Dec 2015 21:15:42 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <4676887.dAJuEMoJXc@tjmaciei-mobl4> References: <201512031949.46920.marc.mutz@kdab.com> <4676887.dAJuEMoJXc@tjmaciei-mobl4> Message-ID: On December 3, 2015 19:06:17 Thiago Macieira wrote: > On Thursday 03 December 2015 19:49:46 Marc Mutz wrote: >> The remainder of the C++ world is moving towards an "always auto" scheme. We >> don't need to go there, but I'd at least like to propose, for new code and >> as a drive-by, the *required* use of auto for: > > The remainder of the C++ world is no indication for us. Actually I think it is. If Qt is to different we loosing mind share. > Also remember that, for us, the source code is a product. We need to have > readable source code, so we have two ground rules that must be respected: > > 1) the use of auto must make the code more readable, not less > 2) Qt Creator must be able to parse and deduce the correct type They Clang code model is doing it already and we working hard on building up a infrastructure on țop of clang to exchange the old code model with the new clang version completely. > #2 is, of course, a transient issue, because Creator will get better over > time. > > As for #1, it's subjective. "More readable" does not mean "fewer characters". > If someone reading the code cannot understand what that variable is doing, > then it's less readable. Thankfully, Qt API is well designed so you can > usually tell from the function name what it does, without having to know the > class it is defined in. But it follows that if you're interfacing with non-Qt > API, then their API may be worse and this less readable. For example, the "is" > prefix for boolean properties helps a lot, since you won't have to decide > whether a plain word in English is a state or a an action, as in "empty". > >> - template code (esp., but not necessarily only, when the type name would >> require the use of 'typename') > > Agreed, except when in violation of the ground rules. > >> - all loop variables (both index and iterators) > > Except for primitives, because "int" is shorter than "auto". > >> the reason being that spelling out the name is usually wrong: >> size_t i = stdVector.size() // wrong, should be std::vector::size_type... >> also helps when porting from Qt containers to STL ones > > I disagree. We'll use int, thank you. You know I disagree about porting from > Qt containers to Standard Library ones. Therefore, that is not an argument to > convince me to write uglier code with auto. > >> - all references to elements in a collection (same problem - way too easy to >> misspell std::pair for std::pair...) > > Example? > >> Optional use of auto: whereever it makes sense. Use your own judgement, but >> remember: fear is a bad advisor. >> >> For range-for, I'd suggest the following patterns: >> >> - loop variable: singular name of collection name (foo : foos) >> - otherwise: 'e' (for element) or first letter (r : rects) >> - for (auto e : collection) // (for pass-by-value types, or if you modify) >> - for (const auto &e : collection) // for pass-by-reference types >> - for (auto &e : collection) // mutating (also: pointer variables/no auto >> *&e) > > Agreed. > >> - for (const auto *e : collection) // const pointers >> - for (auto *e : collection) // non-const pointer > > Why? Why not allow "auto e" and e is a pointer? > >> - explicit type name should be the exception > > Agreed. > >> This is covering a large part of the usefulness of auto. >> >> I don't really like to add anything more detailed to the "rules". Scott >> Meyers' books do a much better job at explaining than we ever could. > > Qt has never and will never build without warnings from -Weffc++. Some of > Scott's rules are good, but we do not have to adopt them all. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Sent from cellphone From thiago.macieira at intel.com Thu Dec 3 23:14:19 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Dec 2015 14:14:19 -0800 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <4676887.dAJuEMoJXc@tjmaciei-mobl4> Message-ID: <1729430.TSdWn3pEBt@tjmaciei-mobl4> On Thursday 03 December 2015 21:15:42 Bubke Marco wrote: > On December 3, 2015 19:06:17 Thiago Macieira wrote: > > On Thursday 03 December 2015 19:49:46 Marc Mutz wrote: > >> The remainder of the C++ world is moving towards an "always auto" scheme. > >> We don't need to go there, but I'd at least like to propose, for new > >> code and> > >> as a drive-by, the *required* use of auto for: > > The remainder of the C++ world is no indication for us. > > Actually I think it is. If Qt is to different we loosing mind share. That depends on how big the remainder is. I argue that we're relevant enough that our own direction is big enough to be of relevance. For example, we don't use exceptions and underscores. > > Also remember that, for us, the source code is a product. We need to have > > > > readable source code, so we have two ground rules that must be respected: > > 1) the use of auto must make the code more readable, not less > > 2) Qt Creator must be able to parse and deduce the correct type > > They Clang code model is doing it already and we working hard on building up > a infrastructure on țop of clang to exchange the old code model with the > new clang version completely. > > #2 is, of course, a transient issue, because Creator will get better over > > time. Good to know! And since we're talking about it... when will Creator get support for concepts? :-P That way, even in template code, it will be able to complete some things that the concept guarantees. Example: template concept bool IsNullable() { return requires(T type) { {type.isNull()} -> bool; } } template bool isNull(T t) { return t. // <--- should offer "isNull" here -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From b.terrier at gmail.com Fri Dec 4 00:05:19 2015 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Fri, 4 Dec 2015 00:05:19 +0100 Subject: [Development] Proposal to change connectSlotsByName behavior Message-ID: Hi everyone, This message follows an exchange I've had with Thiago on a bug report: https://bugreports.qt.io/browse/QTBUG-49749 In the current state, QMetaObject::connectSlotsByName() tries to find, for each slot named "on__" in a given object, a child object named " and connect the signal to the slot. Moreover the documentation says that the search is recursive so any descendant QObject is looked up (not only direct children). My issue here is that the search is done by instantiation order (depth-first search) which means that if 2 (or more) children have the same name one has to know which one is instantiated first to know which one will be connected. And of course imposing on the developer to use unique names throughout a QObject hierarchy is not feasible in particular if he/she is using a third-party library and might not know the object names used internally. This can lead to various hazardous situation, for instance, in a perfectly working software, one can break the behavior of the main window by simply adding a widget in a grand-grand-child widget. Or worse if the UI is made using Qt Designer, the behavior of the application can be changed by simply reordering the widgets in the layout as it will also change their creation order. An application could even break at runtime if a user enables a plugin or set an HMI element visible. In my opinion it also breaks encapsulation as the naming in a widget can alter the signal/slot connections in another widget. My proposal is to change the behavior of connectSlotsByName to do a breadth-first search. In this case, if a direct child is a match it will be used for the connection regardless of possible matches deeper in the hierarchy. Doing so would solve the situations stated above and restore encapsulation. It seems that Thiago's opinion is that it can not be changed as this behavior has been here since Qt 4 and it might break existing applications. On my side I think it's at least a buggy and error prone behavior or even a flawed design and that it must be changed as soon as possible. About the risk of breaking existing applications, I think making the change is less risky for Qt users as in the current state every Qt software can break with any change to an object name or instantiation order. Also as Qt Designer does push the users to use the connectSlotsByName mechanism, it is even possible to generate an example of this "unwanted" behavior without writing a single line of code (see attached zip in the bug report). Regards, Benjamin From olivier at woboq.com Fri Dec 4 00:27:09 2015 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 04 Dec 2015 00:27:09 +0100 Subject: [Development] Proposal to change connectSlotsByName behavior In-Reply-To: References: Message-ID: <3011923.t5x8PH1YQe@finn> On Friday 4. December 2015 00:05:19 Benjamin TERRIER wrote: > Hi everyone, > > This message follows an exchange I've had with Thiago on a bug report: > https://bugreports.qt.io/browse/QTBUG-49749 > > > In the current state, QMetaObject::connectSlotsByName() tries to find, > for each slot named "on__" in a given > object, > a child object named " and connect the signal to the > slot. Moreover the documentation says that the search is recursive so > any > descendant QObject is looked up (not only direct children). > > My issue here is that the search is done by instantiation order > (depth-first search) which means that if 2 (or more) children have the > same name one has > to know which one is instantiated first to know which one will be > connected. And of course imposing on the developer to use unique names > throughout > a QObject hierarchy is not feasible in particular if he/she is using a > third-party library and might not know the object names used > internally. > > This can lead to various hazardous situation, for instance, in a > perfectly working software, one can break the behavior of the main > window by simply adding > a widget in a grand-grand-child widget. > Or worse if the UI is made using Qt Designer, the behavior of the > application can be changed by simply reordering the widgets in the > layout as it will also > change their creation order. > An application could even break at runtime if a user enables a plugin > or set an HMI element visible. > > In my opinion it also breaks encapsulation as the naming in a widget > can alter the signal/slot connections in another widget. > > > > My proposal is to change the behavior of connectSlotsByName to do a > breadth-first search. In this case, if a direct child is a match it > will be used > for the connection regardless of possible matches deeper in the > hierarchy. Doing so would solve the situations stated above and > restore encapsulation. > > > It seems that Thiago's opinion is that it can not be changed as this > behavior has been here since Qt 4 and it might break existing > applications. > > On my side I think it's at least a buggy and error prone behavior or > even a flawed design and that it must be changed as soon as possible. > About the risk of breaking existing applications, > I think making the change is less risky for Qt users as in the current > state every Qt software can break with any change to an object name or > instantiation order. > Also as Qt Designer does push the users to use the connectSlotsByName > mechanism, it is even possible to generate an example of this > "unwanted" behavior > without writing a single line of code (see attached zip in the bug report). > I tend to agree with your proposal. I don't think it will break too many applications because anyone who was relying on the order of instentiation for that has just its application working out of pure luck. (And i'm pretty sure that your proposal is always the intended behaviour) Other possibilities may include: - Connect signals of both objects. (Probably not a good idea since it does make it even more confusing) - Throw a warning if there are two objects with the same name. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From thiago.macieira at intel.com Fri Dec 4 02:56:11 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Dec 2015 17:56:11 -0800 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <1729430.TSdWn3pEBt@tjmaciei-mobl4> References: <201512031949.46920.marc.mutz@kdab.com> <1729430.TSdWn3pEBt@tjmaciei-mobl4> Message-ID: <2218052.Skem11HUDW@tjmaciei-mobl4> On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote: > That depends on how big the remainder is. I argue that we're relevant > enough that our own direction is big enough to be of relevance. That didn't come out right. Rephrasing: Qt has enough market share by itself that we can choose our own direction and still be relevant. We are allowed to disagree with what others do. > For example, we don't use exceptions and underscores. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Dec 4 03:00:15 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Dec 2015 18:00:15 -0800 Subject: [Development] Proposal to change connectSlotsByName behavior In-Reply-To: <3011923.t5x8PH1YQe@finn> References: <3011923.t5x8PH1YQe@finn> Message-ID: <2767797.eYyfFsSCxr@tjmaciei-mobl4> On Friday 04 December 2015 00:27:09 Olivier Goffart wrote: > I don't think it will break too many applications because anyone who was > relying on the order of instentiation for that has just its application > working out of pure luck. (And i'm pretty sure that your proposal is always > the intended behaviour) Note that for widgets, the order is not pure luck. The order of children of a QWidget implies the tabbing order. Therefore, it is usually well-defined. I don't mind changing the order, as long as there's a consensus in the mailing list. If we do decide to change the order, I have a follow-up question: do we change it only in connectSlotsByName, or do we change QObject::findChildren to reflect the new order? Right now, connectSlotsByName simply uses findChildren's order. If we decide to change the order in one but not the order, I'd like to hear a compelling reason why it's ok for them be different. > Other possibilities may include: > - Connect signals of both objects. (Probably not a good idea since it does > make it even more confusing) Agreed that this is not a good idea. Let's discard it. > - Throw a warning if there are two objects with the same name. This is orthogonal. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Fri Dec 4 08:49:14 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 4 Dec 2015 08:49:14 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <2218052.Skem11HUDW@tjmaciei-mobl4> References: <201512031949.46920.marc.mutz@kdab.com> <1729430.TSdWn3pEBt@tjmaciei-mobl4> <2218052.Skem11HUDW@tjmaciei-mobl4> Message-ID: <201512040849.14542.marc.mutz@kdab.com> On Friday 04 December 2015 02:56:11 Thiago Macieira wrote: > On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote: > > That depends on how big the remainder is. I argue that we're relevant > > enough that our own direction is big enough to be of relevance. > > That didn't come out right. Rephrasing: > > Qt has enough market share by itself that we can choose our own direction > and still be relevant. We are allowed to disagree with what others do. Yes, but only if we know *better*. I very much doubt that more than very few people in Qt development have the knowledge to objectively overrule the accepted C++ authorities. I myself have seen over and over again that how I thought a feature should be used was blown to smithereens by members of the committee, usually rightfully so. So the default should be to follow what the greater C++ community is doing, while *divergence* from that needs to be argued for. Everything else is approaching hubris, imo. > we don't use exceptions ...and look at the sorry state of error handling in Qt - every class does it differently... It's ok not to use exceptions, but not having a consistent error handling strategy doesn't put us into a position to throw that stone. > we don't use underscores ... except we do (grep "qt_"). And there's *nothing* wrong with that! Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From randy.oreilly at Colorado.EDU Fri Dec 4 08:35:05 2015 From: randy.oreilly at Colorado.EDU (Randall O'Reilly) Date: Fri, 4 Dec 2015 00:35:05 -0700 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512040849.14542.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> <1729430.TSdWn3pEBt@tjmaciei-mobl4> <2218052.Skem11HUDW@tjmaciei-mobl4> <201512040849.14542.marc.mutz@kdab.com> Message-ID: <60842AF0-5A0F-4639-9386-B33FF0A3861E@colorado.edu> This debate between the std:: lib and wider C++ community vs. the Qt traditions seems never-ending :) At the risk of perpetuating the inevitable flame war, my perspective is well captured in this article: http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/ C++ is WAY too complex of a language, and other alternatives are rapidly gaining users (particularly Python in the domain of scientific computing). The STL and its sea of recursive templates has in particular been incredibly daunting. C++11 helps, but the complexity remains.. Of course, there is no “right” answer in any of these language debates: only different people optimizing different ends of many different fundamental tradeoffs. C and C++ in general tend to attract people who favor optimization over simplicity / usability of the language. Marc is clearly in that camp, advocating many ways of optimizing performance.. With all the new language options, presumably those that stick with C++ are even more apt to be obsessed with performance.. But Qt is beloved by many (myself included) because it provides a *simple*, elegant, well-designed, well-named API, that does a lot of stuff.. Not because of its optimal performance or cutting-edge language features and adherence to the C++ standard.. I got “stuck” in C++ for historical reasons: it was the only viable option for object-oriented programming in the 1990’s. Sure, I care about optimization for my critical inner loops. But for everything else, I really wish it was a lot simpler. And again, I value Qt for making it so in the GUI, which consumes a huge amount of my code, and has minimal performance demands, because it is a GUI and the human in the loop is almost always the rate limiting factor. Of course we don’t want exponential slowdowns with large numbers of Widgets etc, but I’ve never found that to be a problem in Qt. So anyway, this is just a vote to keep with the solid tradition of favoring simplicity, clarity, usability, readability, etc, instead of just following the std:: C++ crowd! Without Qt, I would have to suck it up and rewrite everything in Go or Python or something.. :) - Randy > On Dec 4, 2015, at 12:49 AM, Marc Mutz wrote: > > On Friday 04 December 2015 02:56:11 Thiago Macieira wrote: >> On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote: >>> That depends on how big the remainder is. I argue that we're relevant >>> enough that our own direction is big enough to be of relevance. >> >> That didn't come out right. Rephrasing: >> >> Qt has enough market share by itself that we can choose our own direction >> and still be relevant. We are allowed to disagree with what others do. > > Yes, but only if we know *better*. > > I very much doubt that more than very few people in Qt development have the > knowledge to objectively overrule the accepted C++ authorities. I myself have > seen over and over again that how I thought a feature should be used was blown > to smithereens by members of the committee, usually rightfully so. > > So the default should be to follow what the greater C++ community is doing, > while *divergence* from that needs to be argued for. > > Everything else is approaching hubris, imo. > >> we don't use exceptions > > ...and look at the sorry state of error handling in Qt - every class does it > differently... It's ok not to use exceptions, but not having a consistent error > handling strategy doesn't put us into a position to throw that stone. > >> we don't use underscores > > ... except we do (grep "qt_"). And there's *nothing* wrong with that! > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Petri.Jarvenpaa at digia.com Fri Dec 4 08:38:26 2015 From: Petri.Jarvenpaa at digia.com (=?iso-8859-1?Q?J=E4rvenp=E4=E4_Petri?=) Date: Fri, 4 Dec 2015 07:38:26 +0000 Subject: [Development] Short downtime on mailing list services Message-ID: Due to some hardware migration mailing list services will experience a short downtime during the weekend. Apologies for any delays caused in mail delivery. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Fri Dec 4 08:39:55 2015 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 04 Dec 2015 08:39:55 +0100 Subject: [Development] Proposal to change connectSlotsByName behavior In-Reply-To: <2767797.eYyfFsSCxr@tjmaciei-mobl4> References: <3011923.t5x8PH1YQe@finn> <2767797.eYyfFsSCxr@tjmaciei-mobl4> Message-ID: <2420672.yMT5AT8xpZ@finn> On Thursday 3. December 2015 18:00:15 Thiago Macieira wrote: > On Friday 04 December 2015 00:27:09 Olivier Goffart wrote: > > I don't think it will break too many applications because anyone who was > > relying on the order of instentiation for that has just its application > > working out of pure luck. (And i'm pretty sure that your proposal is > > always > > the intended behaviour) > > Note that for widgets, the order is not pure luck. The order of children of > a QWidget implies the tabbing order. Therefore, it is usually well-defined. The tab order is set with QWidget::setTabOrder and does not depends on the order of the children. > I don't mind changing the order, as long as there's a consensus in the > mailing list. > > If we do decide to change the order, I have a follow-up question: > do we change it only in connectSlotsByName, or do we change > QObject::findChildren to reflect the new order? > > Right now, connectSlotsByName simply uses findChildren's order. If we decide > to change the order in one but not the order, I'd like to hear a compelling > reason why it's ok for them be different. The documentation of findChild says: If there is more than one child matching the search, the most direct ancestor is returned. If there are several direct ancestors, it is undefined which one will be returned. In that case, findChildren() should be used. This would be the expected behaviour, unfortunately, the implementation does not follow that. FindChildren does not document the order. So the order is then unspecified. Changing the order of findChildren would make the function slower. Changing the order in connectSlotsByName would only make that function slightly slower. I do not have strog opinion if the two functions must follow the same order. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From Eike.Ziller at theqtcompany.com Fri Dec 4 08:57:10 2015 From: Eike.Ziller at theqtcompany.com (Ziller Eike) Date: Fri, 4 Dec 2015 07:57:10 +0000 Subject: [Development] Proposal to change connectSlotsByName behavior In-Reply-To: References: Message-ID: <85A8CB5F-5D99-429D-8CCA-CA034AD6D5F8@digia.com> > On Dec 4, 2015, at 00:05, Benjamin TERRIER wrote: > > Hi everyone, > > This message follows an exchange I've had with Thiago on a bug report: > https://bugreports.qt.io/browse/QTBUG-49749 > > > In the current state, QMetaObject::connectSlotsByName() tries to find, > for each slot named "on__" in a given > object, > a child object named " and connect the signal to the > slot. Moreover the documentation says that the search is recursive so > any > descendant QObject is looked up (not only direct children). > > My issue here is that the search is done by instantiation order > (depth-first search) which means that if 2 (or more) children have the > same name one has > to know which one is instantiated first to know which one will be > connected. And of course imposing on the developer to use unique names > throughout > a QObject hierarchy is not feasible in particular if he/she is using a > third-party library and might not know the object names used > internally. > > This can lead to various hazardous situation, for instance, in a > perfectly working software, one can break the behavior of the main > window by simply adding > a widget in a grand-grand-child widget. > Or worse if the UI is made using Qt Designer, the behavior of the > application can be changed by simply reordering the widgets in the > layout as it will also > change their creation order. > An application could even break at runtime if a user enables a plugin > or set an HMI element visible. > > In my opinion it also breaks encapsulation as the naming in a widget > can alter the signal/slot connections in another widget. That is inherent to the “feature”, independent of how the search order is. > My proposal is to change the behavior of connectSlotsByName to do a > breadth-first search. In this case, if a direct child is a match it > will be used > for the connection regardless of possible matches deeper in the > hierarchy. Doing so would solve the situations stated above and > restore encapsulation. Even though your suggestion would make the issue less prominent, it would not actually solve it. It still highly depends on how the different UI parts are combined. UI from e.g. a plugin does not necessarily end up further down in the hierarchy than the widget that you wanted to connect to originally. main - group box - - some other widget that is used for grouping - - - some button (a) that you want to connect to - plugin specific widget - - some button with same object name as (a) Aside from not being able to guard against things like myWidget->setParent(window()) anyhow. IMO: 1. connectSlotsByName is a misfeature. Try not to use it at all. 2. If you really must use it (for what?), use _unique_ object names. E.g. by pre- or appending a random sequence of characters, or by using long object names that describe where they are used (choosePathForSpecificSettingInMainApplicationButton). 3. I don’t see why the risk of breaking existing applications would be worth it for a behavior change that does not really fix the issue. Even with your proposed change you must do (1) or (2), but then you don’t need the proposed change. Br, Eike > It seems that Thiago's opinion is that it can not be changed as this > behavior has been here since Qt 4 and it might break existing > applications. > > On my side I think it's at least a buggy and error prone behavior or > even a flawed design and that it must be changed as soon as possible. > About the risk of breaking existing applications, > I think making the change is less risky for Qt users as in the current > state every Qt software can break with any change to an object name or > instantiation order. > Also as Qt Designer does push the users to use the connectSlotsByName > mechanism, it is even possible to generate an example of this > "unwanted" behavior > without writing a single line of code (see attached zip in the bug report). > > > Regards, > > Benjamin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Senior Software Engineer | The Qt Company Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Martin.Smith at theqtcompany.com Fri Dec 4 08:58:19 2015 From: Martin.Smith at theqtcompany.com (Smith Martin) Date: Fri, 4 Dec 2015 07:58:19 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <60842AF0-5A0F-4639-9386-B33FF0A3861E@colorado.edu> References: <201512031949.46920.marc.mutz@kdab.com> <1729430.TSdWn3pEBt@tjmaciei-mobl4> <2218052.Skem11HUDW@tjmaciei-mobl4> <201512040849.14542.marc.mutz@kdab.com>, <60842AF0-5A0F-4639-9386-B33FF0A3861E@colorado.edu> Message-ID: +1 martin ________________________________________ From: Development on behalf of Randall O'Reilly Sent: Friday, December 04, 2015 8:35 AM To: Marc Mutz Cc: development at qt-project.org Subject: Re: [Development] RFC: more liberal 'auto' rules? This debate between the std:: lib and wider C++ community vs. the Qt traditions seems never-ending :) At the risk of perpetuating the inevitable flame war, my perspective is well captured in this article: http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/ C++ is WAY too complex of a language, and other alternatives are rapidly gaining users (particularly Python in the domain of scientific computing). The STL and its sea of recursive templates has in particular been incredibly daunting. C++11 helps, but the complexity remains.. Of course, there is no “right” answer in any of these language debates: only different people optimizing different ends of many different fundamental tradeoffs. C and C++ in general tend to attract people who favor optimization over simplicity / usability of the language. Marc is clearly in that camp, advocating many ways of optimizing performance.. With all the new language options, presumably those that stick with C++ are even more apt to be obsessed with performance.. But Qt is beloved by many (myself included) because it provides a *simple*, elegant, well-designed, well-named API, that does a lot of stuff.. Not because of its optimal performance or cutting-edge language features and adherence to the C++ standard.. I got “stuck” in C++ for historical reasons: it was the only viable option for object-oriented programming in the 1990’s. Sure, I care about optimization for my critical inner loops. But for everything else, I really wish it was a lot simpler. And again, I value Qt for making it so in the GUI, which consumes a huge amount of my code, and has minimal performance demands, because it is a GUI and the human in the loop is almost always the rate limiting factor. Of course we don’t want exponential slowdowns with large numbers of Widgets etc, but I’ve never found that to be a problem in Qt. So anyway, this is just a vote to keep with the solid tradition of favoring simplicity, clarity, usability, readability, etc, instead of just following the std:: C++ crowd! Without Qt, I would have to suck it up and rewrite everything in Go or Python or something.. :) - Randy > On Dec 4, 2015, at 12:49 AM, Marc Mutz wrote: > > On Friday 04 December 2015 02:56:11 Thiago Macieira wrote: >> On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote: >>> That depends on how big the remainder is. I argue that we're relevant >>> enough that our own direction is big enough to be of relevance. >> >> That didn't come out right. Rephrasing: >> >> Qt has enough market share by itself that we can choose our own direction >> and still be relevant. We are allowed to disagree with what others do. > > Yes, but only if we know *better*. > > I very much doubt that more than very few people in Qt development have the > knowledge to objectively overrule the accepted C++ authorities. I myself have > seen over and over again that how I thought a feature should be used was blown > to smithereens by members of the committee, usually rightfully so. > > So the default should be to follow what the greater C++ community is doing, > while *divergence* from that needs to be argued for. > > Everything else is approaching hubris, imo. > >> we don't use exceptions > > ...and look at the sorry state of error handling in Qt - every class does it > differently... It's ok not to use exceptions, but not having a consistent error > handling strategy doesn't put us into a position to throw that stone. > >> we don't use underscores > > ... except we do (grep "qt_"). And there's *nothing* wrong with that! > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From andre at familiesomers.nl Fri Dec 4 09:01:26 2015 From: andre at familiesomers.nl (=?utf-8?q?Andr=c3=a9=20Somers?=) Date: Fri, 04 Dec 2015 08:01:26 +0000 Subject: [Development] Proposal to change connectSlotsByName behavior In-Reply-To: <2767797.eYyfFsSCxr@tjmaciei-mobl4> Message-ID: ------ Original Message ------ From: "Thiago Macieira" To: development at qt-project.org Sent: 04/12/2015 03:00:15 Subject: Re: [Development] Proposal to change connectSlotsByName behavior >On Friday 04 December 2015 00:27:09 Olivier Goffart wrote: >> I don't think it will break too many applications because anyone who >>was >> relying on the order of instentiation for that has just its >>application >> working out of pure luck. (And i'm pretty sure that your proposal is >>always >> the intended behaviour) > >Note that for widgets, the order is not pure luck. The order of >children of a >QWidget implies the tabbing order. Therefore, it is usually >well-defined. There are explicit methods for setting the tab order. Relying of the order of creation (which may be the default tab order - I did not check) is also pure luck, especially with designer-created UI's. I would think the connect-by-name is more used with designer created UI's than with hand-crafted UI. > >I don't mind changing the order, as long as there's a consensus in the >mailing >list. > I am for it. I think it makes more sense than the current behaviour. >If we do decide to change the order, I have a follow-up question: > do we change it only in connectSlotsByName, or do we change > QObject::findChildren to reflect the new order? Both. A breath first search makes sense there as well. I don't think the order of the children is specified there so one should not rely on it anyway. > >Right now, connectSlotsByName simply uses findChildren's order. If we >decide to >change the order in one but not the order, I'd like to hear a >compelling >reason why it's ok for them be different. > Because that is an implementation detail. That the one uses the other makes it convenient for them to be the same, but the one does not _need_ to use the other. But in this case I think it makes sense for both to change. If changing findChildren is regarded as too risky though, I don't think that that is an argument to not change connectSlotsByName either. >> Other possibilities may include: >> - Connect signals of both objects. (Probably not a good idea since >>it does >> make it even more confusing) > >Agreed that this is not a good idea. Let's discard it. > >> - Throw a warning if there are two objects with the same name. > >This is orthogonal. > I'd like to add a new alternative (though it does not exclude a change now either): - Deprecate the behaviour and remove in Qt 6. I have never thought this feature to lead to good design. It makes for "magic" in the sense that it is tricky to trace what happened. It leads to un-Qt-ish naming of methods, and it leads to naming methods based on when they are triggered instead of what they do. I find the latter usually leads to more readable code, more so if there is more than one way to trigger the behaviour encoded in the method. Last, I think private slots (for which this would be most used) are largely on the way out anyway. Trivial slots can be replaced by lambda's and non-trivial ones need a good function name anyway. André > From thiago.macieira at intel.com Fri Dec 4 09:04:18 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 04 Dec 2015 00:04:18 -0800 Subject: [Development] Proposal to change connectSlotsByName behavior In-Reply-To: <2420672.yMT5AT8xpZ@finn> References: <2767797.eYyfFsSCxr@tjmaciei-mobl4> <2420672.yMT5AT8xpZ@finn> Message-ID: <1911602.51Hk0kplpl@tjmaciei-mobl4> On Friday 04 December 2015 08:39:55 Olivier Goffart wrote: > > Note that for widgets, the order is not pure luck. The order of children > > of > > a QWidget implies the tabbing order. Therefore, it is usually > > well-defined. > > The tab order is set with QWidget::setTabOrder and does not depends on the > order of the children. You're right. I seem to remember the order being important for tabbing, but I guess it's something from before Qt 4 then. Ok, that argument is gone. > > Right now, connectSlotsByName simply uses findChildren's order. If we > > decide to change the order in one but not the order, I'd like to hear a > > compelling reason why it's ok for them be different. [cut part about findChild, which is not relevant] > FindChildren does not document the order. > So the order is then unspecified. > > Changing the order of findChildren would make the function slower. > Changing the order in connectSlotsByName would only make that function > slightly slower. > > I do not have strog opinion if the two functions must follow the same order. For cleanliness purposes, I would prefer both functions get changed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Fri Dec 4 10:18:08 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 4 Dec 2015 10:18:08 +0100 Subject: [Development] QFutureInterface In-Reply-To: <54B0CAFD8875674EAD2C2C03BA3652F00184A591@DENBGAT9EI5MSX.ww902.siemens.net> References: <54B0CAFD8875674EAD2C2C03BA3652F001849F66@DENBGAT9EI5MSX.ww902.siemens.net> <201511261332.54740.marc.mutz@kdab.com> <54B0CAFD8875674EAD2C2C03BA3652F00184A591@DENBGAT9EI5MSX.ww902.siemens.net> Message-ID: <201512041018.08201.marc.mutz@kdab.com> On Friday 27 November 2015 13:45:28 Bauer, Christian wrote: > Hi Marc, > > > You should be able to develop a QPromise/QPackagedTask with the current > > QFutureInterface already. At least as long as it's attached to some > > > QThreadPool. > > What, exactly, are you trying to do that requires a patch to QFI? > > I am not aware of any QPackagedTask in Qt, only of packaged_task in C++11. > Or do you mean RunFunctionTaskBase? I said "you can develop one", not that there _is_ one already :) [...] > Our (simplified) problem is: this function does not return a value but > feeds an asynchronous pipeline. When the pipeline processing is done it > will call promise.SetResult(); promise.reportResult(); > and only then the future should be notified of the result. 1. Inherit your runnable from QRunnable and QFutureInterface In the ctor, call QFI::setRunnable(this). 2. Create an instance of your runnable, call runnable.future() to get the QFuture end 3. Schedule the runnable on a thread pool (cf. QConcurrent::run(QThreadPool* for how to implant that into the QFutureInterface so work stealing works). 4. From within runnable::run() operate the QFutureInterface API 5. Use the QFuture obtained in (2) as you'd use an other future. > We can achieve this by using a custom waitForFinished() in our future > wrapper, instead of using the QFuture waitForFinished. But this requires > access to the QWaitCondition of the QFutureInterface. Don't understand this, but maybe I don't need to. Just tell me where your use- case fails in the recipe above. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From mark.dewit at iesve.com Fri Dec 4 09:10:08 2015 From: mark.dewit at iesve.com (Mark De Wit) Date: Fri, 4 Dec 2015 08:10:08 +0000 Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <201512032008.02198.suy@badopi.org> References: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> <3709A7D425EE8C45991DB29EC2FACA8827203A31@GL-EXC-01.iesve.com> <201512032008.02198.suy@badopi.org> Message-ID: <3709A7D425EE8C45991DB29EC2FACA8827203CBB@GL-EXC-01.iesve.com> Hmm, interesting, I wasn't aware of that location. However, I don't think those flags are right, hasn't OpenGL switched to be Dynamic instead of Desktop, for instance? Having looked around further, I'm liking the look of this: http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/releases Mark -----Original Message----- From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Alejandro Exojo Sent: 03 December 2015 19:08 To: development at qt-project.org Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official binaries El Thursday 03 December 2015, Mark De Wit escribió: > Building from source would be an option, I guess. We have done it in > the past, but the build process / flags (for distribution) is not > sufficiently well documented, and starting with 5.5.1 we were excited > to be able to use official binaries. When reproducing a build, I always start with the flags in this repository: http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Fri Dec 4 09:13:33 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 04 Dec 2015 00:13:33 -0800 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512040849.14542.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> <2218052.Skem11HUDW@tjmaciei-mobl4> <201512040849.14542.marc.mutz@kdab.com> Message-ID: <4931535.sUSLPcB9xs@tjmaciei-mobl4> On Friday 04 December 2015 08:49:14 Marc Mutz wrote: > > Qt has enough market share by itself that we can choose our own direction > > and still be relevant. We are allowed to disagree with what others do. > > Yes, but only if we know *better*. > > I very much doubt that more than very few people in Qt development have the > knowledge to objectively overrule the accepted C++ authorities. That's why we use the mailing list and discuss the issue. Our collective minds together are quite powerful. > So the default should be to follow what the greater C++ community is doing, > while *divergence* from that needs to be argued for. You're calling for "opt-in by default" approach, while I am calling for an "opt-out by default" approach. Since we need to decide which C++ features to use in the first place due to old compilers we need to support, I think we're effectively "opt-out by default". But either way, the end result is the same. > > we don't use underscores > > ... except we do (grep "qt_"). And there's *nothing* wrong with that! Not in our API. Those qt_ functions are private API. The underscore is, in fact, the marker that it is private. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Fri Dec 4 10:22:35 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 4 Dec 2015 10:22:35 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <60842AF0-5A0F-4639-9386-B33FF0A3861E@colorado.edu> References: <201512031949.46920.marc.mutz@kdab.com> <201512040849.14542.marc.mutz@kdab.com> <60842AF0-5A0F-4639-9386-B33FF0A3861E@colorado.edu> Message-ID: <201512041022.35871.marc.mutz@kdab.com> On Friday 04 December 2015 08:35:05 Randall O'Reilly wrote: > So anyway, this is just a vote to keep with the solid tradition of favoring > simplicity, clarity, usability, readability, etc, instead of just > following the std:: C++ crowd! Without Qt, I would have to suck it up and > rewrite everything in Go or Python or something.. :) You should be monitoring the community you are so quick to judge. Google GSL. Just because something has been done that way for decades doesn't mean it's best, for any definiton of the word. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From andre at familiesomers.nl Fri Dec 4 09:16:43 2015 From: andre at familiesomers.nl (=?utf-8?q?Andr=c3=a9=20Somers?=) Date: Fri, 04 Dec 2015 08:16:43 +0000 Subject: [Development] Proposal to change connectSlotsByName behavior In-Reply-To: <2130298.M0G6p1vMnn@tjmaciei-mobl4> Message-ID: >> >If we do decide to change the order, I have a follow-up question: >> > do we change it only in connectSlotsByName, or do we change >> > QObject::findChildren to reflect the new order? >> >> Both. A breath first search makes sense there as well. I don't think >>the >> order of the children is specified there so one should not rely on it >> anyway. > >It isn't specified, so we can change. > >But I'd expect that the flattening of the tree produces depth-first. >Breadth- >first could result in a violation of the principle of least surprise. Why? That is not my expectation at all. If you ask somebody if he has a child named Maria, is he most likely to first name his second daughter or the granddaughter by his first child you think? > >> I'd like to add a new alternative (though it does not exclude a >>change >> now either): >> >> - Deprecate the behaviour and remove in Qt 6. > >What behaviour would you want to be removed? The whole >connectSlotsByName()? Yes, the whole feature. IMnsHO it is indeed a misfeature as Eike called it. There are a few more in Qt, but this certainly is one. André From marc.mutz at kdab.com Fri Dec 4 10:26:21 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 4 Dec 2015 10:26:21 +0100 Subject: [Development] Proposal to change connectSlotsByName behavior In-Reply-To: <1911602.51Hk0kplpl@tjmaciei-mobl4> References: <2420672.yMT5AT8xpZ@finn> <1911602.51Hk0kplpl@tjmaciei-mobl4> Message-ID: <201512041026.21170.marc.mutz@kdab.com> On Friday 04 December 2015 09:04:18 Thiago Macieira wrote: > > The tab order is set with QWidget::setTabOrder and does not depends on > > the order of the children. > > You're right. I seem to remember the order being important for tabbing, but > I guess it's something from before Qt 4 then. > > Ok, th Construction order is the _default_ tab order. Using setTabOrder is bad style. So yes, construction order of widgets is still important. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Fri Dec 4 10:30:36 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 4 Dec 2015 10:30:36 +0100 Subject: [Development] Proposal to change connectSlotsByName behavior In-Reply-To: References: Message-ID: <201512041030.36299.marc.mutz@kdab.com> On Friday 04 December 2015 00:05:19 Benjamin TERRIER wrote: > In my opinion it also breaks encapsulation as the naming in a widget > can alter the signal/slot connections in another widget. This is precisely the reason why connectSlotsByName is a bad idea in the first place; changing the name of a widget breaks connections (at runtime, not at compile time as with QObject::connect()). Just don't use it. Then we can let the function r.i.p. come Qt 6... :) Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From olivier at woboq.com Fri Dec 4 09:29:55 2015 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 04 Dec 2015 09:29:55 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <4931535.sUSLPcB9xs@tjmaciei-mobl4> References: <201512031949.46920.marc.mutz@kdab.com> <201512040849.14542.marc.mutz@kdab.com> <4931535.sUSLPcB9xs@tjmaciei-mobl4> Message-ID: <2921246.NavCToGX0d@finn> On Friday 4. December 2015 00:13:33 Thiago Macieira wrote: > On Friday 04 December 2015 08:49:14 Marc Mutz wrote: > > > we don't use underscores > > > > ... except we do (grep "qt_"). And there's *nothing* wrong with that! > > Not in our API. Those qt_ functions are private API. The underscore is, in > fact, the marker that it is private. Except in macros. (Ok, this is going too far :-)) From thiago.macieira at intel.com Fri Dec 4 09:33:03 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 04 Dec 2015 00:33:03 -0800 Subject: [Development] Proposal to change connectSlotsByName behavior In-Reply-To: References: Message-ID: <4881748.5BR6gS6uD2@tjmaciei-mobl4> On Friday 04 December 2015 08:16:43 André Somers wrote: > >But I'd expect that the flattening of the tree produces depth-first. > >Breadth- > >first could result in a violation of the principle of least surprise. > > Why? That is not my expectation at all. If you ask somebody if he has a > child named Maria, is he most likely to first name his second daughter > or the granddaughter by his first child you think? I agree and disagree. The listing people may use in their heads may look like breadth first, but it's actually more chaotic. If you asked someone to name all the descendants of a grandparent, they will probably group siblings, and the groups may be sorted by generation, but within each generation the groups may be out of order. Nana Alice Bob Charlie Dave Elsa, Frank Gerald, Hector, Isabel Joey,Kevin Lisa If you ask for someone to list that, it may come out as "Alice, Bob, Dave, Charlie, Gerald, Hector, Isabel, Lisa, Elsa, Frank, Kevin, Joey" However, when talking about computer programming, I'd wager that people expect depth-first, if not for the simple reason that this is how they'd implement it if they were asked to. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andre at familiesomers.nl Fri Dec 4 09:52:35 2015 From: andre at familiesomers.nl (=?utf-8?q?Andr=c3=a9=20Somers?=) Date: Fri, 04 Dec 2015 08:52:35 +0000 Subject: [Development] Explicit tree data structure in Qt (was: Re[2]: Proposal to change connectSlotsByName behavior) In-Reply-To: <4881748.5BR6gS6uD2@tjmaciei-mobl4> Message-ID: ------ Original Message ------ From: "Thiago Macieira" To: development at qt-project.org Sent: 04/12/2015 09:33:03 Subject: Re: [Development] Proposal to change connectSlotsByName behavior >On Friday 04 December 2015 08:16:43 André Somers wrote: >> >But I'd expect that the flattening of the tree produces depth-first. >> >Breadth- >> >first could result in a violation of the principle of least >>surprise. >> >> Why? That is not my expectation at all. If you ask somebody if he has >>a >> child named Maria, is he most likely to first name his second >>daughter >> or the granddaughter by his first child you think? > >I agree and disagree. The listing people may use in their heads may >look like >breadth first, but it's actually more chaotic. If you asked someone to >name all >the descendants of a grandparent, they will probably group siblings, >and the >groups may be sorted by generation, but within each generation the >groups may >be out of order. > > Nana > Alice Bob Charlie Dave >Elsa, Frank Gerald, Hector, Isabel Joey,Kevin Lisa > >If you ask for someone to list that, it may come out as "Alice, Bob, >Dave, >Charlie, Gerald, Hector, Isabel, Lisa, Elsa, Frank, Kevin, Joey" Well, indeed you are right. If I am to name or even count descendants, I'd probably go depth-first. > >However, when talking about computer programming, I'd wager that people >expect >depth-first, if not for the simple reason that this is how they'd >implement it >if they were asked to. > This is getting off topic, but this discussion does make me wonder - again - if we shouldn't move away from this intrusive parent-children data structure completely. We are not using intrusive data structures any more to create (linked) lists, why do we still do that for trees/forests? Then, you would just get the iterator with the behaviour you need (depth first or breath first or some other access pattern) and run whatever algorithm you need on that. And yes, that would be a very, very intrusive change. André From alexander.blasche at theqtcompany.com Fri Dec 4 10:45:06 2015 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Fri, 4 Dec 2015 09:45:06 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <4931535.sUSLPcB9xs@tjmaciei-mobl4> References: <201512031949.46920.marc.mutz@kdab.com> <2218052.Skem11HUDW@tjmaciei-mobl4> <201512040849.14542.marc.mutz@kdab.com> <4931535.sUSLPcB9xs@tjmaciei-mobl4> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On Behalf > Of Thiago Macieira > Sent: Friday, 4 December 2015 9:14 > To: development at qt-project.org > Subject: Re: [Development] RFC: more liberal 'auto' rules? > > On Friday 04 December 2015 08:49:14 Marc Mutz wrote: > > > Qt has enough market share by itself that we can choose our own direction > > > and still be relevant. We are allowed to disagree with what others do. > > > > Yes, but only if we know *better*. > > > > I very much doubt that more than very few people in Qt development have the > > knowledge to objectively overrule the accepted C++ authorities. > > That's why we use the mailing list and discuss the issue. Our collective minds > together are quite powerful. First of all I'd like to point out that I agree with Thiago and Randall. In fact, I added the auto policy to the Qt coding conventions. This policy has been in place for much longer in Qt Creator (and therefore the Qt version just an adoption). I had my fair share of arguing over what is better or worse readability wise. At the end of the day it's subjective which makes argumentation about right or wrong harder. For me the point is that if I have to look up a function signature to figure out what type is behind the return values auto type then that's bad. An always auto policy is just asking for such situations. > You're calling for "opt-in by default" approach, while I am calling for an > "opt-out by default" approach. +1 -- Alex From christianbauer at siemens.com Fri Dec 4 10:49:04 2015 From: christianbauer at siemens.com (Bauer, Christian) Date: Fri, 4 Dec 2015 09:49:04 +0000 Subject: [Development] QFutureInterface References: <54B0CAFD8875674EAD2C2C03BA3652F001849F66@DENBGAT9EI5MSX.ww902.siemens.net> <201511261332.54740.marc.mutz@kdab.com> <54B0CAFD8875674EAD2C2C03BA3652F00184A591@DENBGAT9EI5MSX.ww902.siemens.net> <201512041018.08201.marc.mutz@kdab.com> Message-ID: <54B0CAFD8875674EAD2C2C03BA3652F001855F85@DENBGAT9EI5MSX.ww902.siemens.net> Hi Marc, First: thanks for your suggestions. > 1. Inherit your runnable from QRunnable and QFutureInterface > In the ctor, call QFI::setRunnable(this). >2. Create an instance of your runnable, call runnable.future() to get the > QFuture end > 3. Schedule the runnable on a thread pool (cf. QConcurrent::run(QThreadPool* > for how to implant that into the QFutureInterface so work stealing works). > 4. From within runnable::run() operate the QFutureInterface API 5. Use >the QFuture obtained in (2) as you'd use an other future. So the QPackagedTask would be a Runnable that you run on the thread pool, and that runnable represents a QPromise at the same time. Maybe I am missing something here, but I don't think this solves my problem. In my scenario, the QPackagedTask does not produce the result. The task only triggers something else that will - in some point in the future - produce the actual result. By the time the result is produced, the original QPackagedTask does not even exist anymore. The idea of the patch is to support decoupling the Promise (QFI) from the task that I schedule via QConcurrent::run(). Some task will call the promise and set the result, instead of the promise receiving the return value of the task. I could provide a code example if this helps... Thanks Christian From jani.heikkinen at theqtcompany.com Fri Dec 4 11:42:39 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Fri, 4 Dec 2015 10:42:39 +0000 Subject: [Development] New Qt5.6 Beta snapshot available Message-ID: Hi all, We have finally new qt5.6 beta snapshot available Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/278/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/287/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/221/ Src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ Unfortunately it seems these aren't yet final beta packages, in mac package creator seems to be unusable because of QTBUG-49676 [Reg 5.5->5.6]: Painting of widgets broken when embedding QQuickWidget Please test the packages & report all findings in Jira. We are trying to get beta out as soon as possible so please inform all new beta blockers to me immediately. br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Fri Dec 4 12:10:10 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 04 Dec 2015 12:10:10 +0100 Subject: [Development] [OS X]: native classes (widgets) used for QTabBar and QTabWidget? Message-ID: <2063068.e6xtoLpgx3@portia.local> Hi, What are the native classes (widgets) used to implement QTabBar and QTabWidget widgets on OS X? I was expecting NSTabView and family, but can find no occurrence of anything related in the source. Cf: https://bugreports.qt.io/browse/QTBUG-49758 Thanks, René From marc.mutz at kdab.com Fri Dec 4 14:01:25 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 4 Dec 2015 14:01:25 +0100 Subject: [Development] QFutureInterface In-Reply-To: <54B0CAFD8875674EAD2C2C03BA3652F001855F85@DENBGAT9EI5MSX.ww902.siemens.net> References: <54B0CAFD8875674EAD2C2C03BA3652F001849F66@DENBGAT9EI5MSX.ww902.siemens.net> <201512041018.08201.marc.mutz@kdab.com> <54B0CAFD8875674EAD2C2C03BA3652F001855F85@DENBGAT9EI5MSX.ww902.siemens.net> Message-ID: <201512041401.25747.marc.mutz@kdab.com> On Friday 04 December 2015 10:49:04 Bauer, Christian wrote: > I could provide a code example if this helps... Yes, please provide a short example with std::promise, which, afaiu, works for your use-case. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Fri Dec 4 14:07:10 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 4 Dec 2015 14:07:10 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <4931535.sUSLPcB9xs@tjmaciei-mobl4> References: <201512031949.46920.marc.mutz@kdab.com> <201512040849.14542.marc.mutz@kdab.com> <4931535.sUSLPcB9xs@tjmaciei-mobl4> Message-ID: <201512041407.10761.marc.mutz@kdab.com> On Friday 04 December 2015 09:13:33 Thiago Macieira wrote: > You're calling for "opt-in by default" approach, while I am calling for an > "opt-out by default" approach. Since we need to decide which C++ features > to use in the first place due to old compilers we need to support, I > think we're effectively "opt-out by default". Opt-in for _which_ C++ features to use, sure. But opt-out of _how_ to use them, vis a vis the greater C++ community. The guidelines on lambdas in the coding standard are pretty good in that regard. They point out specific compiler bugs (some of which may no longer play a role in 5.7, e.g. MSVC 2010), and mandate certain workarounds, but do not further restrict the use of lambdas. The guideline for auto is not at all like that, though. Given a (beautiful) auto variable and an (ugly) lambda, I'd say that it's lambdas which make the code less readable, not auto. But if readability is only defined as "I can see all types", then the reverse it true, yes. On Friday 04 December 2015 10:45:06 Blasche Alexander wrote: > For me the point is that if I have to look up a function signature to > figure out what type is behind the return values auto type then that's > bad. Playing the devil's advocate here, I wonder how we could have accepted code like this before: le->setText(foo.description()); after all, you have to "look up the description() signature to figure out which type" is being passed to setText(), as defined above. We all write code like the above. And not only if the involved functions scream "it's QString, stupid". But now people (not saying 'you') will be vehemently -1'ing the completely equivalent code const auto desc = foo.description(); le->setText(desc); on grounds of reduced readbility compared to const QString desc = foo.description(); le->setText(desc); That makes no sense. And as an aside, since it has been mentioned in this thread: in Python _all_ variables are 'auto'. All. Without exception. Are Python programmers more intelligent? Or do they just tolerate more pain? :) Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Kai.Koehne at theqtcompany.com Fri Dec 4 13:38:13 2015 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Fri, 4 Dec 2015 12:38:13 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512031949.46920.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On Behalf > Subject: [Development] RFC: more liberal 'auto' rules? > >[..] > The remainder of the C++ world is moving towards an "always auto" scheme. > We don't need to go there, but I'd at least like to propose, for new code and as > a drive-by, the *required* use of auto for: > Just want to comment on this argument ... I know that some influential members are suggesting the AAA (almost always auto), but I think it's a bit overboard to claim that this is "the C++ world". Take for instance the coding guidelines of Clang: http://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable Or google: https://google.github.io/styleguide/cppguide.html#auto Even the C++ core guidelines don't explicitly say 'use auto always', but only to avoid redundant repetition of type names: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Res-auto So I think the ruling is still out whether the "AAA style" is really picked up by a lot of projects. Regards Kai From oswald.buddenhagen at theqtcompany.com Fri Dec 4 14:11:48 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Fri, 4 Dec 2015 14:11:48 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512041407.10761.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> <201512040849.14542.marc.mutz@kdab.com> <4931535.sUSLPcB9xs@tjmaciei-mobl4> <201512041407.10761.marc.mutz@kdab.com> Message-ID: <20151204131148.GB1818@troll08.it.local> On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote: > And as an aside, since it has been mentioned in this thread: in Python _all_ > variables are 'auto'. All. Without exception. Are Python programmers more > intelligent? Or do they just tolerate more pain? :) > i'd suggest the latter. no, really. people use external static checkers because the language lacks the feature. the lack of static typing is a common feature of scripting languages and makes them convenient to a degree, but it is an utter nightmare for any "real" software development. i really wouldn't want to go there. From olivier at woboq.com Fri Dec 4 14:25:14 2015 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 04 Dec 2015 14:25:14 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <20151204131148.GB1818@troll08.it.local> References: <201512031949.46920.marc.mutz@kdab.com> <201512041407.10761.marc.mutz@kdab.com> <20151204131148.GB1818@troll08.it.local> Message-ID: <4076201.l6MBBoA0kT@finn> On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote: > On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote: > > And as an aside, since it has been mentioned in this thread: in Python > > _all_ variables are 'auto'. All. Without exception. Are Python > > programmers more intelligent? Or do they just tolerate more pain? :) > > i'd suggest the latter. > no, really. people use external static checkers because the language > lacks the feature. > the lack of static typing is a common feature of scripting languages and > makes them convenient to a degree, but it is an utter nightmare for any > "real" software development. i really wouldn't want to go there. But auto is still staticaly typed. When you have code like foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type())); You don't see any type. This code that use auto is not less readable. Even if you don't know what's the type of bar without looking it up. auto *bar = foo->bar(); bar->setFaz(m_factory->createFaz(bar->type())); From dangelog at gmail.com Fri Dec 4 14:27:04 2015 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Fri, 4 Dec 2015 14:27:04 +0100 Subject: [Development] Proposal to change connectSlotsByName behavior In-Reply-To: References: Message-ID: On Fri, Dec 4, 2015 at 12:05 AM, Benjamin TERRIER wrote: > > My proposal is to change the behavior of connectSlotsByName to do a > breadth-first search. In this case, if a direct child is a match it > will be used > for the connection regardless of possible matches deeper in the > hierarchy. Doing so would solve the situations stated above and > restore encapsulation. I don't like the idea of changing a behaviour which is now more than 10 years old. If so, it must happen for Qt 6, and the best we can do in Qt 5 is add warnings (in debug builds of Qt?) that connectSlotsByName with multiple children matching the name leads to undefined results and can change at any time... About findChild(ren) ordering, I would say to fix the documentation (once more because people using it are relying on the behaviour). My 2 c, -- Giuseppe D'Angelo From edward.sutton at subsite.com Fri Dec 4 14:30:35 2015 From: edward.sutton at subsite.com (Edward Sutton) Date: Fri, 4 Dec 2015 13:30:35 +0000 Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: References: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> <3709A7D425EE8C45991DB29EC2FACA8827203A31@GL-EXC-01.iesve.com> <4C163E56-0A16-4C53-A48E-2EA3D6ACBFF7@subsite.com> Message-ID: <4062674A-2C66-441D-A676-E7D107C1A1D7@subsite.com> On Dec 3, 2015, at 8:31 AM, Shaw Andy > wrote: >There is QPdfWriter at least which is a paint device, so you could use that for generating PDFs as that is available iOS from what I can see. I *really* need to spend some time browsing All Classes ! http://doc.qt.io/qt-5/classes.html Thanks again Andy! -Ed Andy From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Edward Sutton Sent: 3. desember 2015 15:09 To: Mark De Wit Cc: development at qt-project.org Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official binaries Will Qt 5.6 have alternative methods to export HTML to PDF that support major platforms of Android, iOS, Linux, OS X, and Windows? On iOS a Qt developer must resort to native code to generate PDF files. Unfortunately Qt 5.5 PDF export is dependent on QPrinter which is not supported on iOS. While iOS can create and displays PDF’s just fine, iOS has no printer support. In the future, Is it possible the PDF creation dependency could be separated from QPrinter? So that Qt PDF generation would have better cross-platform support? QPrinter printer(QPrinter::ScreenResolution); // QPrinter not supported on iOS printer.setOutputFormat(QPrinter::PdfFormat); printer.setOutputFileName(pdfFileName); drawReport(printer); m_painter.end(); Without understanding internals of PDF file creation, it feels like PDF creation should not be dependent on QPrinter? -Ed On Dec 3, 2015, at 7:37 AM, Mark De Wit > wrote: Thanks for all the feedback everyone. We are excited about the 5.6 release because we are looking closely at the new Qt3D module, as well as migrating to VS 2015. Sadly, PDF export of HTML content is a critical feature for our product (in general I’m happy to move to WebEngine, but we cannot remove output functionality from our software). Building from source would be an option, I guess. We have done it in the past, but the build process / flags (for distribution) is not sufficiently well documented, and starting with 5.5.1 we were excited to be able to use official binaries. Kind regards, Mark From: Turunen Tuukka [mailto:tuukka.turunen at theqtcompany.com] Sent: 03 December 2015 12:30 To: Mark De Wit >; development at qt-project.org Subject: RE: [Development] Please do not remove QtWebkit from 5.6 official binaries Hi Mark, If you need to use Qt Webkit, then it is probably better to stay with Qt 5.5. There is nothing that makes Qt 5.5 bad overnight, if it works for you now. Qt WebEngine is in many aspects already much better in features than Qt Webkit. Qt WebEngine is also better maintained, and does receive much more improvements and security fixes than Qt Webkit. Even though some features of Qt WebKit are not in same way available with Qt WebEngine, it is overall a better choice. Qt Webkit is removed from Qt 5.6 because it is no longer maintained well enough to be part of an official Qt release. We are also not developing and testing it to work with Qt 5.6. Yours, Tuukka From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Mark De Wit Sent: torstaina 3. joulukuuta 2015 13.18 To: development at qt-project.org Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries Hi all, QtWebEngine does not yet have feature parity with QtWebkit. For instance, print support (especially export to PDF) is a critical requirement for my use of Webkit. This missing feature prevents me from migrating to WebEngine. Removing webkit from the official distribution will prevent me (and surely others) from upgrading to 5.6. Thanks, Mark _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Fri Dec 4 14:32:19 2015 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 04 Dec 2015 14:32:19 +0100 Subject: [Development] [OS X]: native classes (widgets) used for QTabBar and QTabWidget? In-Reply-To: <2063068.e6xtoLpgx3@portia.local> References: <2063068.e6xtoLpgx3@portia.local> Message-ID: <1514935.9Q06xFpApu@finn> On Friday 4. December 2015 12:10:10 René J.V. Bertin wrote: > Hi, > > What are the native classes (widgets) used to implement QTabBar and > QTabWidget widgets on OS X? I was expecting NSTabView and family, but can > find no occurrence of anything related in the source. QWidgets (and QML) don't use native UI views. They draw everything themself. The drawing is done in the style (qmacstyle_mac.mm in this case) So to repeat: QTabBar::paintEvent asks the style to paint the tabs QMacStyle::drawControl (see the case CE_TabBarTabShape) draws it. Apparently it's using HIThemeTabDrawInfo and HIThemeDrawTab. I hope this answer your question. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From oswald.buddenhagen at theqtcompany.com Fri Dec 4 14:32:22 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Fri, 4 Dec 2015 14:32:22 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <4076201.l6MBBoA0kT@finn> References: <201512031949.46920.marc.mutz@kdab.com> <201512041407.10761.marc.mutz@kdab.com> <20151204131148.GB1818@troll08.it.local> <4076201.l6MBBoA0kT@finn> Message-ID: <20151204133222.GA7457@troll08.it.local> On Fri, Dec 04, 2015 at 02:25:14PM +0100, Olivier Goffart wrote: > On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote: > > On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote: > > > And as an aside, since it has been mentioned in this thread: in Python > > > _all_ variables are 'auto'. All. Without exception. Are Python > > > programmers more intelligent? Or do they just tolerate more pain? :) > > > > i'd suggest the latter. > > no, really. people use external static checkers because the language > > lacks the feature. > > the lack of static typing is a common feature of scripting languages and > > makes them convenient to a degree, but it is an utter nightmare for any > > "real" software development. i really wouldn't want to go there. > > But auto is still staticaly typed. > that's why using a scripting language as a source of arguments wasn't a very wise move tactically, even as an aside. ;) From mark.dewit at iesve.com Fri Dec 4 14:53:18 2015 From: mark.dewit at iesve.com (Mark De Wit) Date: Fri, 4 Dec 2015 13:53:18 +0000 Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <4062674A-2C66-441D-A676-E7D107C1A1D7@subsite.com> References: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> <3709A7D425EE8C45991DB29EC2FACA8827203A31@GL-EXC-01.iesve.com> <4C163E56-0A16-4C53-A48E-2EA3D6ACBFF7@subsite.com> <4062674A-2C66-441D-A676-E7D107C1A1D7@subsite.com> Message-ID: <3709A7D425EE8C45991DB29EC2FACA8827203E9A@GL-EXC-01.iesve.com> We tried this solution already in combination with WebEngine. It draws a bitmap of the current view into the PDF. Even text gets rendered as bitmaps, it is a far cry from supporting our multi-page HTML documents. Mark From: Edward Sutton [mailto:edward.sutton at subsite.com] Sent: 04 December 2015 13:31 To: Shaw Andy Cc: Mark De Wit ; development at qt-project.org Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official binaries On Dec 3, 2015, at 8:31 AM, Shaw Andy > wrote: >There is QPdfWriter at least which is a paint device, so you could use that for generating PDFs as that is available iOS from what I can see. I *really* need to spend some time browsing All Classes ! http://doc.qt.io/qt-5/classes.html Thanks again Andy! -Ed Andy From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Edward Sutton Sent: 3. desember 2015 15:09 To: Mark De Wit Cc: development at qt-project.org Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official binaries Will Qt 5.6 have alternative methods to export HTML to PDF that support major platforms of Android, iOS, Linux, OS X, and Windows? On iOS a Qt developer must resort to native code to generate PDF files. Unfortunately Qt 5.5 PDF export is dependent on QPrinter which is not supported on iOS. While iOS can create and displays PDF’s just fine, iOS has no printer support. In the future, Is it possible the PDF creation dependency could be separated from QPrinter? So that Qt PDF generation would have better cross-platform support? QPrinter printer(QPrinter::ScreenResolution); // QPrinter not supported on iOS printer.setOutputFormat(QPrinter::PdfFormat); printer.setOutputFileName(pdfFileName); drawReport(printer); m_painter.end(); Without understanding internals of PDF file creation, it feels like PDF creation should not be dependent on QPrinter? -Ed On Dec 3, 2015, at 7:37 AM, Mark De Wit > wrote: Thanks for all the feedback everyone. We are excited about the 5.6 release because we are looking closely at the new Qt3D module, as well as migrating to VS 2015. Sadly, PDF export of HTML content is a critical feature for our product (in general I’m happy to move to WebEngine, but we cannot remove output functionality from our software). Building from source would be an option, I guess. We have done it in the past, but the build process / flags (for distribution) is not sufficiently well documented, and starting with 5.5.1 we were excited to be able to use official binaries. Kind regards, Mark From: Turunen Tuukka [mailto:tuukka.turunen at theqtcompany.com] Sent: 03 December 2015 12:30 To: Mark De Wit >; development at qt-project.org Subject: RE: [Development] Please do not remove QtWebkit from 5.6 official binaries Hi Mark, If you need to use Qt Webkit, then it is probably better to stay with Qt 5.5. There is nothing that makes Qt 5.5 bad overnight, if it works for you now. Qt WebEngine is in many aspects already much better in features than Qt Webkit. Qt WebEngine is also better maintained, and does receive much more improvements and security fixes than Qt Webkit. Even though some features of Qt WebKit are not in same way available with Qt WebEngine, it is overall a better choice. Qt Webkit is removed from Qt 5.6 because it is no longer maintained well enough to be part of an official Qt release. We are also not developing and testing it to work with Qt 5.6. Yours, Tuukka From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Mark De Wit Sent: torstaina 3. joulukuuta 2015 13.18 To: development at qt-project.org Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries Hi all, QtWebEngine does not yet have feature parity with QtWebkit. For instance, print support (especially export to PDF) is a critical requirement for my use of Webkit. This missing feature prevents me from migrating to WebEngine. Removing webkit from the official distribution will prevent me (and surely others) from upgrading to 5.6. Thanks, Mark _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.sutton at subsite.com Fri Dec 4 15:06:43 2015 From: edward.sutton at subsite.com (Edward Sutton) Date: Fri, 4 Dec 2015 14:06:43 +0000 Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <3709A7D425EE8C45991DB29EC2FACA8827203E9A@GL-EXC-01.iesve.com> References: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> <3709A7D425EE8C45991DB29EC2FACA8827203A31@GL-EXC-01.iesve.com> <4C163E56-0A16-4C53-A48E-2EA3D6ACBFF7@subsite.com> <4062674A-2C66-441D-A676-E7D107C1A1D7@subsite.com> <3709A7D425EE8C45991DB29EC2FACA8827203E9A@GL-EXC-01.iesve.com> Message-ID: <39E0AA6B-511D-45A7-B650-D726D80C388F@subsite.com> On Dec 4, 2015, at 7:53 AM, Mark De Wit > wrote: >We tried this solution already in combination with WebEngine. It draws a bitmap of the current view into the PDF. Even text gets rendered as bitmaps, it is a far cry from supporting our multi-page HTML documents. I may have tried QPdfWriter once as well and had issues with sizing and scaling. I know I spent a *lot* of time with cross-platform PDF generation development. Rendering PDF report text as bitmaps would not be acceptable to my customers either. Not good news for developers that must create PDFs on iOS. -Ed Mark From: Edward Sutton [mailto:edward.sutton at subsite.com] Sent: 04 December 2015 13:31 To: Shaw Andy > Cc: Mark De Wit >; development at qt-project.org Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official binaries On Dec 3, 2015, at 8:31 AM, Shaw Andy > wrote: >There is QPdfWriter at least which is a paint device, so you could use that for generating PDFs as that is available iOS from what I can see. I *really* need to spend some time browsing All Classes ! http://doc.qt.io/qt-5/classes.html Thanks again Andy! -Ed Andy From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Edward Sutton Sent: 3. desember 2015 15:09 To: Mark De Wit Cc: development at qt-project.org Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official binaries Will Qt 5.6 have alternative methods to export HTML to PDF that support major platforms of Android, iOS, Linux, OS X, and Windows? On iOS a Qt developer must resort to native code to generate PDF files. Unfortunately Qt 5.5 PDF export is dependent on QPrinter which is not supported on iOS. While iOS can create and displays PDF’s just fine, iOS has no printer support. In the future, Is it possible the PDF creation dependency could be separated from QPrinter? So that Qt PDF generation would have better cross-platform support? QPrinter printer(QPrinter::ScreenResolution); // QPrinter not supported on iOS printer.setOutputFormat(QPrinter::PdfFormat); printer.setOutputFileName(pdfFileName); drawReport(printer); m_painter.end(); Without understanding internals of PDF file creation, it feels like PDF creation should not be dependent on QPrinter? -Ed On Dec 3, 2015, at 7:37 AM, Mark De Wit > wrote: Thanks for all the feedback everyone. We are excited about the 5.6 release because we are looking closely at the new Qt3D module, as well as migrating to VS 2015. Sadly, PDF export of HTML content is a critical feature for our product (in general I’m happy to move to WebEngine, but we cannot remove output functionality from our software). Building from source would be an option, I guess. We have done it in the past, but the build process / flags (for distribution) is not sufficiently well documented, and starting with 5.5.1 we were excited to be able to use official binaries. Kind regards, Mark From: Turunen Tuukka [mailto:tuukka.turunen at theqtcompany.com] Sent: 03 December 2015 12:30 To: Mark De Wit >; development at qt-project.org Subject: RE: [Development] Please do not remove QtWebkit from 5.6 official binaries Hi Mark, If you need to use Qt Webkit, then it is probably better to stay with Qt 5.5. There is nothing that makes Qt 5.5 bad overnight, if it works for you now. Qt WebEngine is in many aspects already much better in features than Qt Webkit. Qt WebEngine is also better maintained, and does receive much more improvements and security fixes than Qt Webkit. Even though some features of Qt WebKit are not in same way available with Qt WebEngine, it is overall a better choice. Qt Webkit is removed from Qt 5.6 because it is no longer maintained well enough to be part of an official Qt release. We are also not developing and testing it to work with Qt 5.6. Yours, Tuukka From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Mark De Wit Sent: torstaina 3. joulukuuta 2015 13.18 To: development at qt-project.org Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries Hi all, QtWebEngine does not yet have feature parity with QtWebkit. For instance, print support (especially export to PDF) is a critical requirement for my use of Webkit. This missing feature prevents me from migrating to WebEngine. Removing webkit from the official distribution will prevent me (and surely others) from upgrading to 5.6. Thanks, Mark _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.shaw at theqtcompany.com Fri Dec 4 15:17:05 2015 From: andy.shaw at theqtcompany.com (Shaw Andy) Date: Fri, 4 Dec 2015 14:17:05 +0000 Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <39E0AA6B-511D-45A7-B650-D726D80C388F@subsite.com> References: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> <3709A7D425EE8C45991DB29EC2FACA8827203A31@GL-EXC-01.iesve.com> <4C163E56-0A16-4C53-A48E-2EA3D6ACBFF7@subsite.com> <4062674A-2C66-441D-A676-E7D107C1A1D7@subsite.com> <3709A7D425EE8C45991DB29EC2FACA8827203E9A@GL-EXC-01.iesve.com> <39E0AA6B-511D-45A7-B650-D726D80C388F@subsite.com> Message-ID: It wasn’t meant to be seen as a viable solution for rendering from QtWebEngine at least, but more for if you were already rending to a QPrinter with QPainter. If you use drawText() and so forth then that should work with QPdfWriter in a way that makes the text be rendered as text in the PDF. If this is not happening then please report it as it should be handled correctly in that instance. Andy From: Edward Sutton [mailto:edward.sutton at subsite.com] Sent: 4. desember 2015 15:07 To: Mark De Wit Cc: Shaw Andy; development at qt-project.org Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official binaries On Dec 4, 2015, at 7:53 AM, Mark De Wit > wrote: >We tried this solution already in combination with WebEngine. It draws a bitmap of the current view into the PDF. Even text gets rendered as bitmaps, it is a far cry from supporting our multi-page HTML documents. I may have tried QPdfWriter once as well and had issues with sizing and scaling. I know I spent a *lot* of time with cross-platform PDF generation development. Rendering PDF report text as bitmaps would not be acceptable to my customers either. Not good news for developers that must create PDFs on iOS. -Ed Mark From: Edward Sutton [mailto:edward.sutton at subsite.com] Sent: 04 December 2015 13:31 To: Shaw Andy > Cc: Mark De Wit >; development at qt-project.org Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official binaries On Dec 3, 2015, at 8:31 AM, Shaw Andy > wrote: >There is QPdfWriter at least which is a paint device, so you could use that for generating PDFs as that is available iOS from what I can see. I *really* need to spend some time browsing All Classes ! http://doc.qt.io/qt-5/classes.html Thanks again Andy! -Ed Andy From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Edward Sutton Sent: 3. desember 2015 15:09 To: Mark De Wit Cc: development at qt-project.org Subject: Re: [Development] Please do not remove QtWebkit from 5.6 official binaries Will Qt 5.6 have alternative methods to export HTML to PDF that support major platforms of Android, iOS, Linux, OS X, and Windows? On iOS a Qt developer must resort to native code to generate PDF files. Unfortunately Qt 5.5 PDF export is dependent on QPrinter which is not supported on iOS. While iOS can create and displays PDF’s just fine, iOS has no printer support. In the future, Is it possible the PDF creation dependency could be separated from QPrinter? So that Qt PDF generation would have better cross-platform support? QPrinter printer(QPrinter::ScreenResolution); // QPrinter not supported on iOS printer.setOutputFormat(QPrinter::PdfFormat); printer.setOutputFileName(pdfFileName); drawReport(printer); m_painter.end(); Without understanding internals of PDF file creation, it feels like PDF creation should not be dependent on QPrinter? -Ed On Dec 3, 2015, at 7:37 AM, Mark De Wit > wrote: Thanks for all the feedback everyone. We are excited about the 5.6 release because we are looking closely at the new Qt3D module, as well as migrating to VS 2015. Sadly, PDF export of HTML content is a critical feature for our product (in general I’m happy to move to WebEngine, but we cannot remove output functionality from our software). Building from source would be an option, I guess. We have done it in the past, but the build process / flags (for distribution) is not sufficiently well documented, and starting with 5.5.1 we were excited to be able to use official binaries. Kind regards, Mark From: Turunen Tuukka [mailto:tuukka.turunen at theqtcompany.com] Sent: 03 December 2015 12:30 To: Mark De Wit >; development at qt-project.org Subject: RE: [Development] Please do not remove QtWebkit from 5.6 official binaries Hi Mark, If you need to use Qt Webkit, then it is probably better to stay with Qt 5.5. There is nothing that makes Qt 5.5 bad overnight, if it works for you now. Qt WebEngine is in many aspects already much better in features than Qt Webkit. Qt WebEngine is also better maintained, and does receive much more improvements and security fixes than Qt Webkit. Even though some features of Qt WebKit are not in same way available with Qt WebEngine, it is overall a better choice. Qt Webkit is removed from Qt 5.6 because it is no longer maintained well enough to be part of an official Qt release. We are also not developing and testing it to work with Qt 5.6. Yours, Tuukka From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Mark De Wit Sent: torstaina 3. joulukuuta 2015 13.18 To: development at qt-project.org Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries Hi all, QtWebEngine does not yet have feature parity with QtWebkit. For instance, print support (especially export to PDF) is a critical requirement for my use of Webkit. This missing feature prevents me from migrating to WebEngine. Removing webkit from the official distribution will prevent me (and surely others) from upgrading to 5.6. Thanks, Mark _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olli.hirvonen at theqtcompany.com Fri Dec 4 15:27:12 2015 From: olli.hirvonen at theqtcompany.com (Hirvonen Olli) Date: Fri, 4 Dec 2015 14:27:12 +0000 Subject: [Development] Qt infra maintenance during weekend Message-ID: There will be downtime on some development servers on coming weekend 5.-6.12. This is due to virtualization platform organization. Maintenance starts on Saturday 5.12. at 08:00 CET and it might take until Sunday 16:00 CET. Estimation of the break is hard to estimate. Hopefully break is shorter. For example, CI does not work during that time. IT guys will inform Coin operators (Frederik, Simon and Jedrzej) after machines are up and running again. Sorry for the inconvenience caused. -Olli -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lars.Knoll at theqtcompany.com Fri Dec 4 16:01:07 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Fri, 4 Dec 2015 15:01:07 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <1729430.TSdWn3pEBt@tjmaciei-mobl4> <2218052.Skem11HUDW@tjmaciei-mobl4> <201512040849.14542.marc.mutz@kdab.com> <60842AF0-5A0F-4639-9386-B33FF0A3861E@colorado.edu> Message-ID: I think we all agree with the goal we have with Qt to make C++ development accessible and easy. This is something we will continue to do. But the question asked here was about how we use a certain c++11 feature in our *implementation*. This is clearly different from what we do with our APIs and what we ask our users to know. To implement Qt, we can and should use C++ in the most efficient way. If it makes sense to use certain features (and we can actually use them on all platforms), let's use them. But of course let's not force all of these upon our users. Cheers, Lars On 04/12/15 08:58, "Development on behalf of Smith Martin" wrote: >+1 > >martin > >________________________________________ >From: Development on behalf of Randall O'Reilly >Sent: Friday, December 04, 2015 8:35 AM >To: Marc Mutz >Cc: development at qt-project.org >Subject: Re: [Development] RFC: more liberal 'auto' rules? > >This debate between the std:: lib and wider C++ community vs. the Qt traditions seems never-ending :) At the risk of perpetuating the inevitable flame war, my perspective is well captured in this article: http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/ > >C++ is WAY too complex of a language, and other alternatives are rapidly gaining users (particularly Python in the domain of scientific computing). The STL and its sea of recursive templates has in particular been incredibly daunting. C++11 helps, but the complexity remains.. > >Of course, there is no “right” answer in any of these language debates: only different people optimizing different ends of many different fundamental tradeoffs. > >C and C++ in general tend to attract people who favor optimization over simplicity / usability of the language. Marc is clearly in that camp, advocating many ways of optimizing performance.. With all the new language options, presumably those that stick with C++ are even more apt to be obsessed with performance.. > >But Qt is beloved by many (myself included) because it provides a *simple*, elegant, well-designed, well-named API, that does a lot of stuff.. Not because of its optimal performance or cutting-edge language features and adherence to the C++ standard.. > >I got “stuck” in C++ for historical reasons: it was the only viable option for object-oriented programming in the 1990’s. Sure, I care about optimization for my critical inner loops. But for everything else, I really wish it was a lot simpler. And again, I value Qt for making it so in the GUI, which consumes a huge amount of my code, and has minimal performance demands, because it is a GUI and the human in the loop is almost always the rate limiting factor. Of course we don’t want exponential slowdowns with large numbers of Widgets etc, but I’ve never found that to be a problem in Qt. > >So anyway, this is just a vote to keep with the solid tradition of favoring simplicity, clarity, usability, readability, etc, instead of just following the std:: C++ crowd! Without Qt, I would have to suck it up and rewrite everything in Go or Python or something.. :) > >- Randy > >> On Dec 4, 2015, at 12:49 AM, Marc Mutz wrote: >> >> On Friday 04 December 2015 02:56:11 Thiago Macieira wrote: >>> On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote: >>>> That depends on how big the remainder is. I argue that we're relevant >>>> enough that our own direction is big enough to be of relevance. >>> >>> That didn't come out right. Rephrasing: >>> >>> Qt has enough market share by itself that we can choose our own direction >>> and still be relevant. We are allowed to disagree with what others do. >> >> Yes, but only if we know *better*. >> >> I very much doubt that more than very few people in Qt development have the >> knowledge to objectively overrule the accepted C++ authorities. I myself have >> seen over and over again that how I thought a feature should be used was blown >> to smithereens by members of the committee, usually rightfully so. >> >> So the default should be to follow what the greater C++ community is doing, >> while *divergence* from that needs to be argued for. >> >> Everything else is approaching hubris, imo. >> >>> we don't use exceptions >> >> ...and look at the sorry state of error handling in Qt - every class does it >> differently... It's ok not to use exceptions, but not having a consistent error >> handling strategy doesn't put us into a position to throw that stone. >> >>> we don't use underscores >> >> ... except we do (grep "qt_"). And there's *nothing* wrong with that! >> >> Thanks, >> Marc >> >> -- >> Marc Mutz | Senior Software Engineer >> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company >> Tel: +49-30-521325470 >> KDAB - The Qt Experts >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From rafael.roquetto at kdab.com Fri Dec 4 14:12:00 2015 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Fri, 4 Dec 2015 13:12:00 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <4076201.l6MBBoA0kT@finn> References: <201512031949.46920.marc.mutz@kdab.com> <201512041407.10761.marc.mutz@kdab.com> <20151204131148.GB1818@troll08.it.local> <4076201.l6MBBoA0kT@finn> Message-ID: <20151204131159.GA6577@polaris> On Fri, Dec 04, 2015 at 02:25:14PM +0100, Olivier Goffart wrote: > On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote: > > On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote: > > > And as an aside, since it has been mentioned in this thread: in Python > > > _all_ variables are 'auto'. All. Without exception. Are Python > > > programmers more intelligent? Or do they just tolerate more pain? :) > > > > i'd suggest the latter. > > no, really. people use external static checkers because the language > > lacks the feature. > > the lack of static typing is a common feature of scripting languages and > > makes them convenient to a degree, but it is an utter nightmare for any > > "real" software development. i really wouldn't want to go there. > > But auto is still staticaly typed. > > > When you have code like > > foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type())); > > You don't see any type. > > This code that use auto is not less readable. Even if you don't know what's > the type of bar without looking it up. > > auto *bar = foo->bar(); > bar->setFaz(m_factory->createFaz(bar->type())); Until you need to change your code and call any method of bar. Suppose I need to change the following code, to print the first item of the collection: auto *bar = foo->collection(); /*TODO: print first item here */ model->setCollection(bar); // we know bar is a collection, but of what kind? Choose the right alternative: a) qDebug() << bar->first(); b) qDebug() << bar->values().first(); c) qDebug() << bar[0] d) none of the above To answer this, you will need to find out the return type of Foo::collection(); The compiler knows it, but the reader does not. And the answer depends on whether it is a QList/QVector, QHash/QMap, etc... Had it been explicit, any programmer familiar with the Qt API (or any API in context) would be able to directly write down the right statement. Just an idea. Cheers, Rafael -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4861 bytes Desc: not available URL: From Marco.Bubke at theqtcompany.com Fri Dec 4 16:27:35 2015 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Fri, 4 Dec 2015 15:27:35 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <2218052.Skem11HUDW@tjmaciei-mobl4> <201512040849.14542.marc.mutz@kdab.com> <4931535.sUSLPcB9xs@tjmaciei-mobl4> Message-ID: On December 4, 2015 10:45:19 Blasche Alexander wrote: >> -----Original Message----- >> From: Development [mailto:development-bounces at qt-project.org] On Behalf >> Of Thiago Macieira >> Sent: Friday, 4 December 2015 9:14 >> To: development at qt-project.org >> Subject: Re: [Development] RFC: more liberal 'auto' rules? >> >> On Friday 04 December 2015 08:49:14 Marc Mutz wrote: >> > > Qt has enough market share by itself that we can choose our own direction >> > > and still be relevant. We are allowed to disagree with what others do. >> > >> > Yes, but only if we know *better*. >> > >> > I very much doubt that more than very few people in Qt development have the >> > knowledge to objectively overrule the accepted C++ authorities. >> >> That's why we use the mailing list and discuss the issue. Our collective minds >> together are quite powerful. > > First of all I'd like to point out that I agree with Thiago and Randall. In fact, I added the auto policy to the Qt coding conventions. > > This policy has been in place for much longer in Qt Creator (and therefore the Qt version just an adoption). I had my fair share of arguing over what is better or worse readability wise. At the end of the day it's subjective which makes argumentation about right or wrong harder. For me the point is that if I have to look up a function signature to figure out what type is behind the return values auto type then that's bad. An always auto policy is just asking for such situations. With the clang code model it is quite easy to provide that information. In my opinion it is better to give your functions and variables descriptive names so you don't need to look for the declaration. For Test Driven Development it is better to use auto if you must exchange types with mocks. So the interface(concepts) is important but not the type. >> You're calling for "opt-in by default" approach, while I am calling for an >> "opt-out by default" approach. > > +1 > -- > Alex > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Sent from cellphone From mitch.curtis at theqtcompany.com Fri Dec 4 16:39:01 2015 From: mitch.curtis at theqtcompany.com (Curtis Mitch) Date: Fri, 4 Dec 2015 15:39:01 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <4076201.l6MBBoA0kT@finn> References: <201512031949.46920.marc.mutz@kdab.com> <201512041407.10761.marc.mutz@kdab.com> <20151204131148.GB1818@troll08.it.local> <4076201.l6MBBoA0kT@finn> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On Behalf Of > Olivier Goffart > Sent: Friday, 4 December 2015 2:25 PM > To: development at qt-project.org > Subject: Re: [Development] RFC: more liberal 'auto' rules? > > On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote: > > On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote: > > > And as an aside, since it has been mentioned in this thread: in > > > Python _all_ variables are 'auto'. All. Without exception. Are > > > Python programmers more intelligent? Or do they just tolerate more > > > pain? :) > > > > i'd suggest the latter. > > no, really. people use external static checkers because the language > > lacks the feature. > > the lack of static typing is a common feature of scripting languages > > and makes them convenient to a degree, but it is an utter nightmare > > for any "real" software development. i really wouldn't want to go there. > > But auto is still staticaly typed. > > > When you have code like > > foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type())); > > You don't see any type. > > This code that use auto is not less readable. Even if you don't know > what's the type of bar without looking it up. > > auto *bar = foo->bar(); > bar->setFaz(m_factory->createFaz(bar->type())); > Isn't this kind of a bad example, because there was no type declared/visible in the first place? Anyway, if you're going to take the time to move the result of foo->bar() onto its own line, why not just declare a type? What benefit does auto give here? I really dislike hiding types behind a generic keyword. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Marco.Bubke at theqtcompany.com Fri Dec 4 16:46:58 2015 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Fri, 4 Dec 2015 15:46:58 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <60842AF0-5A0F-4639-9386-B33FF0A3861E@colorado.edu> References: <201512031949.46920.marc.mutz@kdab.com> <1729430.TSdWn3pEBt@tjmaciei-mobl4> <2218052.Skem11HUDW@tjmaciei-mobl4> <201512040849.14542.marc.mutz@kdab.com> <60842AF0-5A0F-4639-9386-B33FF0A3861E@colorado.edu> Message-ID: On December 4, 2015 08:35:19 Randall O'Reilly wrote: > This debate between the std:: lib and wider C++ community vs. the Qt traditions seems never-ending :) At the risk of perpetuating the inevitable flame war, my perspective is well captured in this article: http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/ > > C++ is WAY too complex of a language, and other alternatives are rapidly gaining users (particularly Python in the domain of scientific computing). The STL and its sea of recursive templates has in particular been incredibly daunting. C++11 helps, but the complexity remains.. > > Of course, there is no “right” answer in any of these language debates: only different people optimizing different ends of many different fundamental tradeoffs. > > C and C++ in general tend to attract people who favor optimization over simplicity / usability of the language. Marc is clearly in that camp, advocating many ways of optimizing performance.. With all the new language options, presumably those that stick with C++ are even more apt to be obsessed with performance.. > > But Qt is beloved by many (myself included) because it provides a *simple*, elegant, well-designed, well-named API, that does a lot of stuff.. Not because of its optimal performance or cutting-edge language features and adherence to the C++ standard.. Hmm, do you really believe we cannot improve? If you compare signal and slots with resumable functions it looks quite complicated for many use cases. Look how complicated our network API is. It could be much easier with resumable functions. I don't say signal slots should go away but should be used in places their they have still an advantage. Ranges are quite nice too. With Qt we made C++ of the nineties much nicer but now C++ is incorporating many advanced features for concurrency and other areas from C#, Python and other interesting languages. The world is changing and we should adapt to this changing context. > I got “stuck” in C++ for historical reasons: it was the only viable option for object-oriented programming in the 1990’s. Sure, I care about optimization for my critical inner loops. But for everything else, I really wish it was a lot simpler. And again, I value Qt for making it so in the GUI, which consumes a huge amount of my code, and has minimal performance demands, because it is a GUI and the human in the loop is almost always the rate limiting factor. Of course we don’t want exponential slowdowns with large numbers of Widgets etc, but I’ve never found that to be a problem in Qt. > > So anyway, this is just a vote to keep with the solid tradition of favoring simplicity, clarity, usability, readability, etc, instead of just following the std:: C++ crowd! Without Qt, I would have to suck it up and rewrite everything in Go or Python or something.. :) > > - Randy > >> On Dec 4, 2015, at 12:49 AM, Marc Mutz wrote: >> >> On Friday 04 December 2015 02:56:11 Thiago Macieira wrote: >>> On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote: >>>> That depends on how big the remainder is. I argue that we're relevant >>>> enough that our own direction is big enough to be of relevance. >>> >>> That didn't come out right. Rephrasing: >>> >>> Qt has enough market share by itself that we can choose our own direction >>> and still be relevant. We are allowed to disagree with what others do. >> >> Yes, but only if we know *better*. >> >> I very much doubt that more than very few people in Qt development have the >> knowledge to objectively overrule the accepted C++ authorities. I myself have >> seen over and over again that how I thought a feature should be used was blown >> to smithereens by members of the committee, usually rightfully so. >> >> So the default should be to follow what the greater C++ community is doing, >> while *divergence* from that needs to be argued for. >> >> Everything else is approaching hubris, imo. >> >>> we don't use exceptions >> >> ...and look at the sorry state of error handling in Qt - every class does it >> differently... It's ok not to use exceptions, but not having a consistent error >> handling strategy doesn't put us into a position to throw that stone. >> >>> we don't use underscores >> >> ... except we do (grep "qt_"). And there's *nothing* wrong with that! >> >> Thanks, >> Marc >> >> -- >> Marc Mutz | Senior Software Engineer >> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company >> Tel: +49-30-521325470 >> KDAB - The Qt Experts >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Sent from cellphone From Marco.Bubke at theqtcompany.com Fri Dec 4 17:20:44 2015 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Fri, 4 Dec 2015 16:20:44 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <20151204131159.GA6577@polaris> References: <201512031949.46920.marc.mutz@kdab.com> <201512041407.10761.marc.mutz@kdab.com> <20151204131148.GB1818@troll08.it.local> <4076201.l6MBBoA0kT@finn> <20151204131159.GA6577@polaris> Message-ID: On December 4, 2015 16:10:56 Rafael Roquetto wrote: > On Fri, Dec 04, 2015 at 02:25:14PM +0100, Olivier Goffart wrote: >> On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote: >> > On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote: >> > > And as an aside, since it has been mentioned in this thread: in Python >> > > _all_ variables are 'auto'. All. Without exception. Are Python >> > > programmers more intelligent? Or do they just tolerate more pain? :) >> > >> > i'd suggest the latter. >> > no, really. people use external static checkers because the language >> > lacks the feature. >> > the lack of static typing is a common feature of scripting languages and >> > makes them convenient to a degree, but it is an utter nightmare for any >> > "real" software development. i really wouldn't want to go there. >> >> But auto is still staticaly typed. >> >> >> When you have code like >> >> foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type())); >> >> You don't see any type. >> >> This code that use auto is not less readable. Even if you don't know what's >> the type of bar without looking it up. >> >> auto *bar = foo->bar(); >> bar->setFaz(m_factory->createFaz(bar->type())); > > Until you need to change your code and call any method of bar. Suppose I > need to change the following code, to print the first item of the collection: > > auto *bar = foo->collection(); > > /*TODO: print first item here */ > > model->setCollection(bar); // we know bar is a collection, but of what kind? > > > Choose the right alternative: > > a) qDebug() << bar->first(); > b) qDebug() << bar->values().first(); > c) qDebug() << bar[0] > d) none of the above > > > To answer this, you will need to find out the return type of > Foo::collection(); The compiler knows it, but the reader does not. And the > answer depends on whether it is a QList/QVector, QHash/QMap, etc... Had it > been explicit, any programmer familiar with the Qt API (or any API in context) > would be able to directly write down the right statement. > The clang code model completes auto so it should be not that hard. Actually I would call an ordered map or unordered map a dictionary. > > Just an idea. > > Cheers, > Rafael > > -- > Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - Qt Experts Sent from cellphone From Marco.Bubke at theqtcompany.com Fri Dec 4 17:29:18 2015 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Fri, 4 Dec 2015 16:29:18 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <201512041407.10761.marc.mutz@kdab.com> <20151204131148.GB1818@troll08.it.local> <4076201.l6MBBoA0kT@finn> Message-ID: On December 4, 2015 16:39:14 Curtis Mitch wrote: >> -----Original Message----- >> From: Development [mailto:development-bounces at qt-project.org] On Behalf Of >> Olivier Goffart >> Sent: Friday, 4 December 2015 2:25 PM >> To: development at qt-project.org >> Subject: Re: [Development] RFC: more liberal 'auto' rules? >> >> On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote: >> > On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote: >> > > And as an aside, since it has been mentioned in this thread: in >> > > Python _all_ variables are 'auto'. All. Without exception. Are >> > > Python programmers more intelligent? Or do they just tolerate more >> > > pain? :) >> > >> > i'd suggest the latter. >> > no, really. people use external static checkers because the language >> > lacks the feature. >> > the lack of static typing is a common feature of scripting languages >> > and makes them convenient to a degree, but it is an utter nightmare >> > for any "real" software development. i really wouldn't want to go there. >> >> But auto is still staticaly typed. >> >> >> When you have code like >> >> foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type())); >> >> You don't see any type. >> >> This code that use auto is not less readable. Even if you don't know >> what's the type of bar without looking it up. >> >> auto *bar = foo->bar(); >> bar->setFaz(m_factory->createFaz(bar->type())); >> > > Isn't this kind of a bad example, because there was no type declared/visible in the first place? > > Anyway, if you're going to take the time to move the result of foo->bar() onto its own line, why not just declare a type? What benefit does auto give here? We have a maximum length in the coding style. So if you give your variables and functions descriptive names you cannot chain them so you needs variables inbetween. The type information is not that important in that case. Anyway we can provide the actual type for auto in creator. Like we will provide highlighting for output parameters. A good tool can provide all the informations so we don't need to overload the source code with that information. So we can make the intent of the code much more clear. > I really dislike hiding types behind a generic keyword. > >> >> _______________________________________________ >> 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 Sent from cellphone From b.terrier at gmail.com Fri Dec 4 17:34:41 2015 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Fri, 4 Dec 2015 17:34:41 +0100 Subject: [Development] Proposal to change connectSlotsByName behavior Message-ID: 2015-12-04 10:30 GMT+01:00 Marc Mutz : > This is precisely the reason why connectSlotsByName is a bad idea in the first > place; changing the name of a widget breaks connections (at runtime, not at > compile time as with QObject::connect()). > > Just don't use it. Then we can let the function r.i.p. come Qt 6... :) As many seems to think connectSlotsByName should not be used, maybe it should be, as André Somers said, deprecated. However it is used by the designer plugin within Qt Creator as it uses the fact that uic will generate a call to connectsSlotByName to automatically generates slots when the user clicks on "Go to slots.." in the context menu. This means that every widget class that has a ui file will call connectSlotsByName. There is still an open bug report asking to make the call optional (https://bugreports.qt.io/browse/QTBUG-27866) BR, Benjamin From thiago.macieira at intel.com Fri Dec 4 17:36:51 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 04 Dec 2015 08:36:51 -0800 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> Message-ID: <10580672.IiZmPbRuF9@tjmaciei-mobl4> On Friday 04 December 2015 15:01:07 Knoll Lars wrote: > To implement Qt, we can and should use C++ in the most efficient way. If it > makes sense to use certain features (and we can actually use them on all > platforms), let's use them. But of course let's not force all of these upon > our users. Let me say again that our source code is product and it must be readable (to an extent) by our users. We should write efficient code, but not to a point that it's not understandable anymore by an advanced Qt application developer. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Dec 4 17:39:01 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 04 Dec 2015 08:39:01 -0800 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <60842AF0-5A0F-4639-9386-B33FF0A3861E@colorado.edu> Message-ID: <2317318.Cn7J2YIq7q@tjmaciei-mobl4> On Friday 04 December 2015 15:46:58 Bubke Marco wrote: > Hmm, do you really believe we cannot improve? If you compare signal and > slots with resumable functions it looks quite complicated for many use > cases. Look how complicated our network API is. It could be much easier > with resumable functions. I don't say signal slots should go away but > should be used in places their they have still an advantage. Our networking API is quite complex, but it could be worse. It could be like Boost.Asio and what's being proposed to the C++ standard networking API. Let me put it this way: *I* do not understand it. So yeah, we should use new things that make our lives and our users' lives easier, like we've done with variadic templates. We do not have to use things that make it worse. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mwoehlke.floss at gmail.com Fri Dec 4 17:46:32 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 04 Dec 2015 11:46:32 -0500 Subject: [Development] Proposal to change connectSlotsByName behavior In-Reply-To: References: <2767797.eYyfFsSCxr@tjmaciei-mobl4> Message-ID: On 2015-12-04 03:01, André Somers wrote: > On 2015-12-03 21:00, Thiago Macieira wrote: >> Note that for widgets, the order is not pure luck. The order of >> children of a QWidget implies the tabbing order. Therefore, it is >> usually well-defined. > > There are explicit methods for setting the tab order. Relying of the > order of creation (which may be the default tab order - I did not check) > is also pure luck, especially with designer-created UI's. I would have to disagree with that (and agree with Marc). I'm quite careful (or at least, I try to be) when using Designer to ensure that my widgets are defined in the .ui file in tab order. I, like Marc, consider it bad form to override the implicit tab order. (For one, it's a maintenance headache.) At any rate, any time I find that my tab order is wrong, I *always* fix it by changing the order of the widgets in the .ui file. (p.s. I believe that the order also controls the order in which widgets are painted. Although this shouldn't matter 99.9% of the time, it does if you have overlapping widgets.) IMHO, QWidget::setTabOrder should be used exclusively when you need the tab order to differ from the child order. > I'd like to add a new alternative (though it does not exclude a change > now either): > > - Deprecate the behaviour and remove in Qt 6. > > I have never thought this feature to lead to good design. It makes for > "magic" in the sense that it is tricky to trace what happened. It leads > to un-Qt-ish naming of methods, and it leads to naming methods based on > when they are triggered instead of what they do. +1. -- Matthew From thiago.macieira at intel.com Fri Dec 4 17:48:55 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 04 Dec 2015 08:48:55 -0800 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <20151204131159.GA6577@polaris> Message-ID: <17894174.ShkWaJyYla@tjmaciei-mobl4> On Friday 04 December 2015 16:20:44 Bubke Marco wrote: > The clang code model completes auto so it should be not that hard. Actually > I would call an ordered map or unordered map a dictionary. Does Creator have a way to reveal the deduced type of an auto? That would go a long way to alleviating the pain of using it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Dec 4 17:55:16 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 04 Dec 2015 08:55:16 -0800 Subject: [Development] New Qt5.6 Beta snapshot available In-Reply-To: References: Message-ID: <1697254.9ZveXjKooD@tjmaciei-mobl4> On Friday 04 December 2015 10:42:39 Heikkinen Jani wrote: > We have finally new qt5.6 beta snapshot available > > > Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/278/ > > Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/287/ > > Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/221/ > > Src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ Hi Jani Repeating the request from Linux packagers: they cannot create packages unless we provide the split sources. The split sources are our official release channel, not the big tarball. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nikolaseu at gmail.com Fri Dec 4 18:11:15 2015 From: nikolaseu at gmail.com (=?UTF-8?Q?Nicol=C3=A1s_Ulrich?=) Date: Fri, 04 Dec 2015 17:11:15 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <17894174.ShkWaJyYla@tjmaciei-mobl4> References: <201512031949.46920.marc.mutz@kdab.com> <20151204131159.GA6577@polaris> <17894174.ShkWaJyYla@tjmaciei-mobl4> Message-ID: Would be great something like Android Studio does with some things. For example it shows the "deduced" string in a different format (top) and when you click/modify it shows the "real" code (bottom) [image: Screenshot 2015-12-04 13.55.13.png] On Fri, Dec 4, 2015 at 1:49 PM Thiago Macieira wrote: On Friday 04 December 2015 16:20:44 Bubke Marco wrote: > The clang code model completes auto so it should be not that hard. Actually > I would call an ordered map or unordered map a dictionary. Does Creator have a way to reveal the deduced type of an auto? That would go a long way to alleviating the pain of using it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2015-12-04 13.55.13.png Type: image/png Size: 26010 bytes Desc: not available URL: From marc.mutz at kdab.com Fri Dec 4 19:30:10 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 4 Dec 2015 19:30:10 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <20151204133222.GA7457@troll08.it.local> References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> <20151204133222.GA7457@troll08.it.local> Message-ID: <201512041930.10576.marc.mutz@kdab.com> On Friday 04 December 2015 14:32:22 Oswald Buddenhagen wrote: > > But auto is still staticaly typed. > > > > > > that's why using a scripting language as a source of arguments wasn't a > very wise move tactically, even as an aside. ;) I, indeed, did not anticipate that anyone here would be able to seriously confuse static typing and var/auto, the omitting of the type name in variable declarations. I have the feeling I wasn't wrong, though. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Fri Dec 4 19:39:57 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 4 Dec 2015 19:39:57 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <20151204131159.GA6577@polaris> References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> <20151204131159.GA6577@polaris> Message-ID: <201512041939.57378.marc.mutz@kdab.com> On Friday 04 December 2015 14:12:00 Rafael Roquetto wrote: > Until you need to change your code and call any method of bar. QtC prints the signature of the function when you hover the mouse over it — since _ages_. It also completes function names of auto variables. Since _ages_. Even if it should be the case that it doesn't, yet, show the deduced type when you hover over the 'auto', the lhs can be inspected by hovering, and the rhs's type is clear[1]. But ok, for those of us using vi, I motion to ban function chaining like le->setText(foo.description()); or foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type())); Everyone in favour of restricting auto use due to readability concerns is automatically (no pun intended) counted as in-favour of the motion, with prejudice. Thanks, Marc [1] If it's not clear, we need to ban the use of template functions. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From oswald.buddenhagen at theqtcompany.com Fri Dec 4 19:06:51 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Fri, 4 Dec 2015 19:06:51 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512041930.10576.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> <20151204133222.GA7457@troll08.it.local> <201512041930.10576.marc.mutz@kdab.com> Message-ID: <20151204180651.GA21123@troll08.it.local> On Fri, Dec 04, 2015 at 07:30:10PM +0100, Marc Mutz wrote: > On Friday 04 December 2015 14:32:22 Oswald Buddenhagen wrote: > > > But auto is still staticaly typed. > > > > > > > that's why using a scripting language as a source of arguments wasn't a > > very wise move tactically, even as an aside. ;) > > I, indeed, did not anticipate that anyone here would be able to seriously > confuse static typing and var/auto, the omitting of the type name in variable > declarations. > it's not that anyone is confused, it's that your "aside" was inherently flawed: variables in python are dynamically typed, so the suggestion that they are "auto" in any way related to c++ makes no sense whatsoever. my response aimed merely at showing that even your little "joke" was off. > I have the feeling I wasn't wrong, though. > ??? From Marco.Bubke at theqtcompany.com Fri Dec 4 19:12:59 2015 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Fri, 4 Dec 2015 18:12:59 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <17894174.ShkWaJyYla@tjmaciei-mobl4> References: <201512031949.46920.marc.mutz@kdab.com> <20151204131159.GA6577@polaris> <17894174.ShkWaJyYla@tjmaciei-mobl4> Message-ID: On December 4, 2015 17:49:08 Thiago Macieira wrote: > On Friday 04 December 2015 16:20:44 Bubke Marco wrote: >> The clang code model completes auto so it should be not that hard. Actually >> I would call an ordered map or unordered map a dictionary. > > Does Creator have a way to reveal the deduced type of an auto? That would go a > long way to alleviating the pain of using it. In the clang code model we use the clang AST. So if the compiler knows it, we can show it. It's on the roadmap for 3.7. > -- > 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 Sent from cellphone From Marco.Bubke at theqtcompany.com Fri Dec 4 19:20:47 2015 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Fri, 4 Dec 2015 18:20:47 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <20151204131159.GA6577@polaris> <17894174.ShkWaJyYla@tjmaciei-mobl4> Message-ID: On December 4, 2015 18:11:39 Nicolás Ulrich wrote: > Would be great something like Android Studio does with some things. > For example it shows the "deduced" string in a different format (top) and when you click/modify it shows the "real" code (bottom) > > [Screenshot 2015-12-04 13.55.13.png] > Please do a suggestion in jira for it. It sounds nice. > On Fri, Dec 4, 2015 at 1:49 PM Thiago Macieira > wrote: > > On Friday 04 December 2015 16:20:44 Bubke Marco wrote: >> The clang code model completes auto so it should be not that hard. Actually >> I would call an ordered map or unordered map a dictionary. > > Does Creator have a way to reveal the deduced type of an auto? That would go a > long way to alleviating the pain of using it. Tooltips? > -- > 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 Sent from cellphone From thiago.macieira at intel.com Fri Dec 4 19:38:51 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 04 Dec 2015 10:38:51 -0800 Subject: [Development] Introducing qEnvironmentVariable Message-ID: <2313637.S8ZcSNDH89@tjmaciei-mobl4> I've just pushed a new function called qEnvironmentVariable. It's basically the equivalent of qgetenv returning a QString. Here's the rule of when to use it: A) qEnvironmentVariable: 1) file paths Always use this function when dealing with environment variables containing paths, in any OS. Exception: when writing Unix-only code and you're going to pass that path to a non-Qt function taking 8-bit file paths (very rare) 2) Windows code This function is more efficient than qgetenv on Windows because the environment on Windows is stored already as UTF-16. However, the gains may be quite small because the C runtime may be keeping both the UTF-16 and locale environments. 3) when you're about to convert to QString anyway This function does that for you, so you save some keystrokes and parentheses in your code. B) qgetenv: 1) when you're going to use as a QByteArray or it doesn't matter It's ok to continue using qgetenv if you need a QByteArray anyway. Please note file paths should never be stored in QByteArrays on Windows. 2) Unix code This function is more efficient than qEnvironmentVariable on Unix because the environment is stored in 8-bit. Note again the rules above for file paths. 3) converting from 8-bit *without* NFD/NFC conversion On the extremely rare case, on OS X and iOS, that your environment variable must not undergo NFC/NFD conversion, use QString::fromUtf8(qgetenv(x)) As a corollary, in cross-platform code that is not dealing with file paths, you can choose either qgetenv or qEnvironmentVariable to suit your code best. Note that if your variable contains numbers, you should use qEnvironmentVariableIntValue: C) qEnvironmentVariableIntValue Use if you just want the value. Use it directly if an unset variable is equivalent to it set to zero: x = qEnvironmentVariableIntValue("FOO"); Do not write: if (qEnvironmentVariableIsSet("FOO")) x = qEnvironmentVariableIntValue("FOO"); write instead: bool ok; x = qEnvironmentVariableIntValue("FOO", &ok); it's equivalent to: x = qgetenv("FOO").toInt(&ok); but won't allocate memory in a QByteArray temporary. D) qEnvironmentVariableIsSet, qEnvironmentVariableIsEmpty Prefer !qEnvironmentVariableIsEmpty over the IsSet alternative. This allows "unsetting" a variable in a Unix shell by setting it to empty. Example: $ QT_MESSAGE_PATTERN= ./appname E) qputenv, qunsetenv Don't use. They leak memory by construction. If you're dealing with the environment for a child process, set it with QProcessEnvironment instead. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From olivier at woboq.com Fri Dec 4 20:01:59 2015 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 04 Dec 2015 20:01:59 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> Message-ID: <4606126.Pqxnumcx4H@finn> On Friday 4. December 2015 15:39:01 Curtis Mitch wrote: > > -----Original Message----- > > From: Development [mailto:development-bounces at qt-project.org] On Behalf Of > > Olivier Goffart > > Sent: Friday, 4 December 2015 2:25 PM > > To: development at qt-project.org > > Subject: Re: [Development] RFC: more liberal 'auto' rules? > > > > On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote: > > > On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote: > > > > And as an aside, since it has been mentioned in this thread: in > > > > Python _all_ variables are 'auto'. All. Without exception. Are > > > > Python programmers more intelligent? Or do they just tolerate more > > > > pain? :) > > > > > > i'd suggest the latter. > > > no, really. people use external static checkers because the language > > > lacks the feature. > > > the lack of static typing is a common feature of scripting languages > > > and makes them convenient to a degree, but it is an utter nightmare > > > for any "real" software development. i really wouldn't want to go there. > > > > But auto is still staticaly typed. > > > > > > When you have code like > > > > foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type())); > > > > You don't see any type. > > > > This code that use auto is not less readable. Even if you don't know > > what's the type of bar without looking it up. > > > > auto *bar = foo->bar(); > > bar->setFaz(m_factory->createFaz(bar->type())); > > Isn't this kind of a bad example, because there was no type declared/visible > in the first place? Precisely my point! There is no type visible before and nobody complains. So why should one suddenly complains there are no types in the second snippet > Anyway, if you're going to take the time to move the result of foo->bar() > onto its own line, why not just declare a type? What benefit does auto give > here? > > I really dislike hiding types behind a generic keyword. Because the type is redundent and it's one reason less to make errors: Using 'int' instead of 'quint64' or 'size_t', or QString instead of QByteArray is way to frequent. (and the compiler won't complain) It is also refactoring-proof. Because you might want to change the name of the type from "FazManager" to "FazHolder", and then you need to touch less code in your refactoring. From olivier at woboq.com Fri Dec 4 20:14:16 2015 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 04 Dec 2015 20:14:16 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <20151204131159.GA6577@polaris> References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> <20151204131159.GA6577@polaris> Message-ID: <5412988.7Rua4yOfQm@finn> On Friday 4. December 2015 13:12:00 Rafael Roquetto wrote: > On Fri, Dec 04, 2015 at 02:25:14PM +0100, Olivier Goffart wrote: > > On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote: > > > On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote: > > > > And as an aside, since it has been mentioned in this thread: in Python > > > > _all_ variables are 'auto'. All. Without exception. Are Python > > > > programmers more intelligent? Or do they just tolerate more pain? :) > > > > > > i'd suggest the latter. > > > no, really. people use external static checkers because the language > > > lacks the feature. > > > the lack of static typing is a common feature of scripting languages and > > > makes them convenient to a degree, but it is an utter nightmare for any > > > "real" software development. i really wouldn't want to go there. > > > > But auto is still staticaly typed. > > > > > > When you have code like > > > > foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type())); > > > > You don't see any type. > > > > This code that use auto is not less readable. Even if you don't know > > what's > > the type of bar without looking it up. > > > > auto *bar = foo->bar(); > > bar->setFaz(m_factory->createFaz(bar->type())); > > Until you need to change your code and call any method of bar. Suppose I > need to change the following code, to print the first item of the > collection: > > auto *bar = foo->collection(); > > /*TODO: print first item here */ > > model->setCollection(bar); // we know bar is a collection, but of what > kind? > > > Choose the right alternative: > > a) qDebug() << bar->first(); > b) qDebug() << bar->values().first(); > c) qDebug() << bar[0] > d) none of the above > > > To answer this, you will need to find out the return type of > Foo::collection(); The compiler knows it, but the reader does not. And the > answer depends on whether it is a QList/QVector, QHash/QMap, etc... Had it > been explicit, any programmer familiar with the Qt API (or any API in > context) would be able to directly write down the right statement. Ok, so i'll write it like this: AddresseeList *bar = foo->collection(); Is it better? do you know how to print the first element? You anyway need to look up what the AdresseeList typedef is. (Yes, it was made a typedef so one can more easily change what is the underlying, it's not so untypical) You anyway have to know or lookup all the code you play around. Someone familiar with the codebase knows what Foo::collection() returns or can quickly look it up. But the day somebody fixes the API and returns a "const AddresseeList*" instead, you have to fix the locations you did not use auto. From marc.mutz at kdab.com Fri Dec 4 22:29:09 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 4 Dec 2015 22:29:09 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <20151204180651.GA21123@troll08.it.local> References: <201512031949.46920.marc.mutz@kdab.com> <201512041930.10576.marc.mutz@kdab.com> <20151204180651.GA21123@troll08.it.local> Message-ID: <201512042229.09453.marc.mutz@kdab.com> On Friday 04 December 2015 19:06:51 Oswald Buddenhagen wrote: > it's not that anyone is confused, it's that your "aside" was inherently > flawed: variables in python are dynamically typed, so the suggestion > that they are "auto" in any way related to c++ makes no sense > whatsoever. my response aimed merely at showing that even your little > "joke" was off. Again: I was referring to the omission of any form of type name when declaring variables. That Python is _also_ dynamically typed is correct, but irrelevant. If you have a problem distinguishing these two orthogonal issues, s/Python/C#/ Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From apoenitz at t-online.de Fri Dec 4 21:35:16 2015 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Fri, 4 Dec 2015 21:35:16 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <4606126.Pqxnumcx4H@finn> References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> <4606126.Pqxnumcx4H@finn> Message-ID: <20151204203516.GA2407@klara.mpi.htwm.de> On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote: > > > You don't see any type. > > > > > > This code that use auto is not less readable. Even if you don't know > > > what's the type of bar without looking it up. > > > > > > auto *bar = foo->bar(); > > > bar->setFaz(m_factory->createFaz(bar->type())); > > > > Isn't this kind of a bad example, because there was no type declared/visible > > in the first place? > > Precisely my point! > There is no type visible before and nobody complains. So why should one > suddenly complains there are no types in the second snippet Because they are different from a human reader's point of view. In the second snippet the scope of the 'bar' is larger than for an immediate use. This loses the context in which it is used, i.e. makes it harder to reason about whether the use is ok, and adds load on a human reader that needs to keep mental track of this 'untyped' item when reading the code until it goes out of scope in case there's another use of this item. Both alternatives help to reduce that load: - immediate consumption of the temporary makes it explicit that the item is used exactly once and provides the consumer as additional context, helping judging whether the use is ok, - using a separate line with a real type provides a stepping stone by giving additional information about the intermediate item *to the human reader*, helping him to split the task of verifying that 'the right thing is produced and consumed' into smaller subtasks. > > I really dislike hiding types behind a generic keyword. > > Because the type is redundent It might be redundant for the compiler, but it is not for human readers of the code. > and it's one reason less to make errors: > Using 'int' instead of 'quint64' or 'size_t', or QString instead of QByteArray > is way to frequent. (and the compiler won't complain) ["QString instead of QByteArray" does not happen with proper QT_NO__CAST_*_ASCII settings. Not to mention the cases where mindless replacement of explicit types by 'auto' doesn't produce identical results.] > It is also refactoring-proof. Because you might want to change the name of > the type from "FazManager" to "FazHolder", and then you need to touch less > code in your refactoring Code is typically read more often than changed. Targeting at making specific refactorings easier is optimizing the wrong utility function. Andre' From helio at kde.org Fri Dec 4 21:37:37 2015 From: helio at kde.org (Helio Chissini de Castro) Date: Fri, 04 Dec 2015 20:37:37 +0000 Subject: [Development] New Qt5.6 Beta snapshot available In-Reply-To: References: <1697254.9ZveXjKooD@tjmaciei-mobl4> Message-ID: Well, i'm not relying anymore on the released sources, i'm generating our test tarballs from git, in the specific case, the 5.6 branch. We complained already, and I decided that not worth wait to have our tasks done. If is too difficult to generate the official splitted tarballs, i can offer as a community member to generate it and provide for Linux distros in the not official basis. Regards, Helio On Fri, Dec 4, 2015, 17:55 Thiago Macieira wrote: On Friday 04 December 2015 10:42:39 Heikkinen Jani wrote: > We have finally new qt5.6 beta snapshot available > > > Windows: http:// download.qt.io / snapshots /qt/5.6/5.6.0-beta/278/ > > Linux: http:// download.qt.io / snapshots /qt/5.6/5.6.0-beta/287/ > > Mac: http:// download.qt.io / snapshots /qt/5.6/5.6.0-beta/221/ > > Src: http:// download.qt.io / snapshots /qt/5.6/5.6.0-beta/ latest _ src / Hi Jani Repeating the request from Linux packagers: they cannot create packages unless we provide the split sources. The split sources are our official release channel, not the big tarball. -- 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 mwoehlke.floss at gmail.com Fri Dec 4 22:33:26 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 04 Dec 2015 16:33:26 -0500 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <20151204203516.GA2407@klara.mpi.htwm.de> References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> <4606126.Pqxnumcx4H@finn> <20151204203516.GA2407@klara.mpi.htwm.de> Message-ID: On 2015-12-04 15:35, André Pönitz wrote: > On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote: >> and it's one reason less to make errors: >> Using 'int' instead of 'quint64' or 'size_t', or QString instead of QByteArray >> is way to frequent. (and the compiler won't complain) > > ["QString instead of QByteArray" does not happen with proper > QT_NO__CAST_*_ASCII settings. Not to mention the cases where mindless > replacement of explicit types by 'auto' doesn't produce identical results.] But wrongly mixing integer types *does* happen. I speak from personal experience based on a code base that has a relatively large mess of *exactly* such errors. > Code is typically read more often than changed. Targeting at making > specific refactorings easier is optimizing the wrong utility function. Which of these is easier to read? (More importantly, which is easier to *verify* that it is correct?) for (int i = 0; i < list.size(); ++i) foo(list[i]); for (auto i : qtIndexRange(list.size()) foo(list[i]); Which is *really* more meaningful? "The type of 'i' is 'int', and I really, really hope that 'list' is actually indexed by 'int'", or "the type of 'i' is the index type of 'list'¹"? Do you really *care* what is the type of 'i'? Or do you care that it is the *correct* type. I (and others) submit that the latter is more valuable. (¹ ...assuming that decltype(list.size()) is the index type, which it had darned well better be or whoever wrote the API of decltype(list) needs to have their coding privileges revoked.) -- Matthew From apoenitz at t-online.de Fri Dec 4 23:43:03 2015 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Fri, 4 Dec 2015 23:43:03 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> <4606126.Pqxnumcx4H@finn> <20151204203516.GA2407@klara.mpi.htwm.de> Message-ID: <20151204224303.GA2648@klara.mpi.htwm.de> On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote: > On 2015-12-04 15:35, André Pönitz wrote: > > On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote: > >> and it's one reason less to make errors: > >> Using 'int' instead of 'quint64' or 'size_t', or QString instead of QByteArray > >> is way to frequent. (and the compiler won't complain) > > > > ["QString instead of QByteArray" does not happen with proper > > QT_NO__CAST_*_ASCII settings. Not to mention the cases where mindless > > replacement of explicit types by 'auto' doesn't produce identical results.] > > But wrongly mixing integer types *does* happen. I speak from personal > experience based on a code base that has a relatively large mess of > *exactly* such errors. > > > Code is typically read more often than changed. Targeting at making > > specific refactorings easier is optimizing the wrong utility function. > > Which of these is easier to read? (More importantly, which is easier to > *verify* that it is correct?) > > for (int i = 0; i < list.size(); ++i) > foo(list[i]); Whether the access is correct depends on the type of list, which you don't disclose. In any case, this loop follows a well-known pattern. > for (auto i : qtIndexRange(list.size()) > foo(list[i]); Whether the access is correct depends on the type of list, which you don't disclose. In any case, this is an uncommon pattern, using some unknown qtIndexRange() function. Moreover it is more to type. The extra level of parantheses makes it harder to parse for humans, introducing an aditional source of errors, which you nicely demonstrated by making the example non-compilable. > Which is *really* more meaningful? The first one. > "The type of 'i' is 'int', and I > really, really hope that 'list' is actually indexed by 'int'", or "the > type of 'i' is the index type of 'list'¹"? > > Do you really *care* what is the type of 'i'? Yes, I do care about types, almost always. > Or do you care that it is > the *correct* type. I (and others) submit that the latter is more valuable. Your message has been heard. I do not agree with you. I feel more comfortable arguing about whether a type is the right one if the type is known than when it is unknown. There *are* some sensible uses of 'auto', those are pretty much the ones listed in Creator's coding-style.qdoc. Overuse of 'auto' reduces code readability and maintainability, I would not like to see the Qt code base move there. Andre' From mwoehlke.floss at gmail.com Sat Dec 5 00:10:45 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 04 Dec 2015 18:10:45 -0500 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <20151204224303.GA2648@klara.mpi.htwm.de> References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> <4606126.Pqxnumcx4H@finn> <20151204203516.GA2407@klara.mpi.htwm.de> <20151204224303.GA2648@klara.mpi.htwm.de> Message-ID: On 2015-12-04 17:43, André Pönitz wrote: > On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote: >> Which of these is easier to read? (More importantly, which is easier to >> *verify* that it is correct?) >> >> for (int i = 0; i < list.size(); ++i) >> foo(list[i]); > > Whether the access is correct depends on the type of list, which you don't > disclose. That's sort of *the point*. I can't tell if the above is correct or not. If it used 'auto', I'd know. (And it's sort of implied that it *is* wrong. Because, y'know, I see loops like the above quite often where, indeed, they do in fact use the wrong type. Actually, QList/QVector are about the *only* times the above is written correctly without using 'auto'. More often than not, a loop like that written against a non-Qt container uses the wrong index type.) > In any case, this loop follows a well-known pattern. It also follows a really *bad* pattern. The count is reevaluated every time (well, you hope the compiler will hoist it, but the code says that it is). Using type deduction... well, sucks: for (auto i = decltype(list.size()){0}; i < list.size(); ++i) >> for (auto i : qtIndexRange(list.size()) >> foo(list[i]); > > In any case, this is an uncommon pattern, using some unknown qtIndexRange() > function. Really? (Python) for i in range(len(list)) Just because it isn't standardized (or in Qt) yet doesn't mean it's "unheard of". It's just that C++ users have been suffering with the difficult to use form while programmers in other languages have had the much more sensible form for a long time. Really, it's not hard... nasty glorified while loop vs. 'I want to iterate over the indices [starting at zero] up to list.size()'. There's a reason I strongly prefer the latter form and use it whenever I can (usually subject to compiler compatibility limitations). > Moreover it is more to type. Really? for (auto i : qtInlist.si)) - vs. - for (int i = 0; i < list.si; ++i) Hey, look... mine's *fewer* keystrokes. And much more importantly, it's *correct*. Yours... may or may not be... as you pointed out, I don't know without knowing decltype(list). (Or I could use the much longer, *much* uglier old-style for loop with decltype that is correct, but then mine wins hands-down.) > The extra level of parantheses makes it harder to parse for > humans,introducing an aditional source of errors, which you nicely > demonstrated by making the example non-compilable. Bah. A decent IDE would have flagged that as soon as I stopped typing. (Actually, a decent *text editor* would have shown me () matches, so I would have noticed *as* I was typing. I challenge you to write bug-free code the first time in a text editor whose most advanced feature is cut and paste.) >> Which is *really* more meaningful? > > The first one. Sorry, but I must strongly disagree. >> "The type of 'i' is 'int', and I >> really, really hope that 'list' is actually indexed by 'int'", or "the >> type of 'i' is the index type of 'list'¹"? >> >> Do you really *care* what is the type of 'i'? > > Yes, I do care about types, almost always. Why? As long as it's the *correct* type, what difference did it make? Let's say that the correct type is my_list::index_t. Let's say I used that: for (my_list::index_t i = 0; i < list.size(); ++i) How is that better? Do you know now what is the actual type of 'i'? I submit that writing 'my_list::index_t' is not a significant improvement over 'auto'. It didn't tell you anything about the actual type of 'i'. (It does suggest that the type of 'list' might be 'my_list' and that a 'my_list' probably uses 'my_list::index_t' as its indexing type. But there's still that "probably". Whereas 'auto' says the type *is* the indexing type.) > Your message has been heard. I do not agree with you. Likewise. > I feel more comfortable arguing about whether a type is the right one > if the type is known than when it is unknown. Then you are missing the point. In fact, you are missing the whole point of 'auto'. By using 'auto' correctly, it's possible to know that the type *is correct*, even if you don't know what the type actually *is*. (Or if a change elsewhere should change what is the correct type.) -- Matthew From Marco.Bubke at theqtcompany.com Sat Dec 5 00:31:35 2015 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Fri, 4 Dec 2015 23:31:35 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <20151204203516.GA2407@klara.mpi.htwm.de> References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> <4606126.Pqxnumcx4H@finn> <20151204203516.GA2407@klara.mpi.htwm.de> Message-ID: On December 4, 2015 21:33:57 André Pönitz wrote: > On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote: >> > > You don't see any type. >> > > >> > > This code that use auto is not less readable. Even if you don't know >> > > what's the type of bar without looking it up. >> > > >> > > auto *bar = foo->bar(); >> > > bar->setFaz(m_factory->createFaz(bar->type())); >> > >> > Isn't this kind of a bad example, because there was no type declared/visible >> > in the first place? >> >> Precisely my point! >> There is no type visible before and nobody complains. So why should one >> suddenly complains there are no types in the second snippet > > Because they are different from a human reader's point of view. > > In the second snippet the scope of the 'bar' is larger than for an immediate > use. This loses the context in which it is used, i.e. makes it harder to > reason about whether the use is ok, and adds load on a human reader that > needs to keep mental track of this 'untyped' item when reading the code until > it goes out of scope in case there's another use of this item. > > Both alternatives help to reduce that load: > > - immediate consumption of the temporary makes it explicit that the item is > used exactly once and provides the consumer as additional context, helping > judging whether the use is ok, > > - using a separate line with a real type provides a stepping stone by > giving additional information about the intermediate item *to the > human reader*, helping him to split the task of verifying that > 'the right thing is produced and consumed' into smaller subtasks. For subtask you should write a new function with a descriptive name. Actually I don't buy they argument that explicit types improve readability so much as we allow long functions which do many subtasks. In python a never missed the types and python code in general is in my opinion much more readable. In my opinion is the culture and not so much the style guides. I think readable code is produced by programmers who care and not so much by style guides. It is easy to write unreadable code which complies to a style guide but much harder to write good readable code. And if I look at our code I must say I have seen much more readable code. So we have plenty space to improve. ;-) I think we discuss the matter of types so much because we have not a good culture to give variables and functions descriptive names. And how to decompose larger functions in smaller thanks to describe the intention. It's not only Qt but C++ in general. My argument for auto is quite simple that it is makes dependency breaking easier which is very important for Test Driven Development. And if you have good tests you can refactore your code much easier because you know the probability to introduce new bugs by code changes is much lower. This refactorings leads to much better readable code. So my argument is that should be used if it leads to more readable code. Our style guide can only gives hints about it. So developing rigid rules which stop the code to envolve in a more readable state is maybe not that smart. In the end you have always trust in the developers that they cares about the readability of what they produce. So I would like to add the advise to use auto if it makes unit testing easier. And with the clang code model we could add refactorings which change auto to the actual type too. But I prefer to visulize it in a other way. We could provide some kind of overlay. >> > I really dislike hiding types behind a generic keyword. >> >> Because the type is redundent > > It might be redundant for the compiler, but it is not for human > readers of the code. > >> and it's one reason less to make errors: >> Using 'int' instead of 'quint64' or 'size_t', or QString instead of QByteArray >> is way to frequent. (and the compiler won't complain) > > ["QString instead of QByteArray" does not happen with proper > QT_NO__CAST_*_ASCII settings. Not to mention the cases where mindless > replacement of explicit types by 'auto' doesn't produce identical results.] > >> It is also refactoring-proof. Because you might want to change the name of >> the type from "FazManager" to "FazHolder", and then you need to touch less >> code in your refactoring > > Code is typically read more often than changed. Targeting at making > specific refactorings easier is optimizing the wrong utility function. > > Andre' > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Sent from cellphone From olivier at woboq.com Sat Dec 5 00:40:33 2015 From: olivier at woboq.com (Olivier Goffart) Date: Sat, 05 Dec 2015 00:40:33 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <20151204203516.GA2407@klara.mpi.htwm.de> References: <201512031949.46920.marc.mutz@kdab.com> <4606126.Pqxnumcx4H@finn> <20151204203516.GA2407@klara.mpi.htwm.de> Message-ID: <1496336.kJmJR8SHW4@finn> On Friday 4. December 2015 21:35:16 André Pönitz wrote: > On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote: > > > > You don't see any type. > > > > > > > > This code that use auto is not less readable. Even if you don't know > > > > what's the type of bar without looking it up. > > > > > > > > auto *bar = foo->bar(); > > > > bar->setFaz(m_factory->createFaz(bar->type())); > > > > > > Isn't this kind of a bad example, because there was no type > > > declared/visible in the first place? > > > > Precisely my point! > > There is no type visible before and nobody complains. So why should one > > suddenly complains there are no types in the second snippet > > Because they are different from a human reader's point of view. > > In the second snippet the scope of the 'bar' is larger than for an immediate > use. That's a good argument for the need of sensible variable name, but not for mandating to write explicitly the type. > This loses the context in which it is used, i.e. makes it harder to > reason about whether the use is ok, and adds load on a human reader that > needs to keep mental track of this 'untyped' item when reading the code > until it goes out of scope in case there's another use of this item. If you were able to reason about foo->bar() in the first snippet without having the type explicitly written, why would the human reader need to see the type explicitly written in the second siuppet? > Both alternatives help to reduce that load: > > - immediate consumption of the temporary makes it explicit that the item is > used exactly once and provides the consumer as additional context, helping > judging whether the use is ok, > > - using a separate line with a real type provides a stepping stone by > giving additional information about the intermediate item *to the > human reader*, helping him to split the task of verifying that > 'the right thing is produced and consumed' into smaller subtasks. There might be cases where the type name is an important information and in that case we should put it of course. But in many case it is not. In the given example, 'bar' is only used locally. What might be more interesting is a decent variable name. Yet, it is frequent to see non-descriptive names for such localy used variable. That's because this information is obvious and redundant. > > > I really dislike hiding types behind a generic keyword. > > > > Because the type is redundent > > It might be redundant for the compiler, but it is not for human > readers of the code. Another example: fazCount++; // Increment the fazCount by one. name.remove(' '); // Remove all the spaces from the name. Following your argument, the comments makes the code more readable? The human reader might not know what remove() does? Then such comments should be mandatory? In practice, someone familiar with the code base will know what Foo::bar() returns. > > and it's one reason less to make errors: > > Using 'int' instead of 'quint64' or 'size_t', or QString instead of > > QByteArray is way to frequent. (and the compiler won't complain) > > ["QString instead of QByteArray" does not happen with proper > QT_NO__CAST_*_ASCII settings. Not to mention the cases where mindless > replacement of explicit types by 'auto' doesn't produce identical results.] The point is: it is just another oportunity to make mistakes. > > It is also refactoring-proof. Because you might want to change the name > > of the type from "FazManager" to "FazHolder", and then you need to touch > > less code in your refactoring > > Code is typically read more often than changed. Targeting at making > specific refactorings easier is optimizing the wrong utility function. I'm claiming that auto often does not harm readability. Given that, optimizing to make refactoring easier will allow the code base to evolve and to stay readable when things are changing Just to be clear. I'm not advocating to use auto everywhere. I'm just saying that the coding style is currently too strict by forbiding auto in most cases. From Marco.Bubke at theqtcompany.com Sat Dec 5 01:21:15 2015 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Sat, 5 Dec 2015 00:21:15 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> <4606126.Pqxnumcx4H@finn> <20151204203516.GA2407@klara.mpi.htwm.de> <20151204224303.GA2648@klara.mpi.htwm.de> Message-ID: I think the discussion is getting in an antagonistic direction and we should get back to our normal agonistic way or maybe being cooperative. ;-) I have seen big systems in dynamically languages like small talk or python and except that they were slower they look actually much more readable. So I think history have shown that type declaration is not the key to readable code. In my opinion it is the excuse to find good names. ;-) And what we should not forget is that tools getting better. So old rules can getting unproductive in a changing context. In my opinion we have to adapt to a changing context all the time and old wisdom can loose it's usefulness fast. So what about reviewing our style guides from time to time. With tools like clang format and clang tidy it should be not that hard to adapt code to a changed style guide. On December 5, 2015 00:11:14 Matthew Woehlke wrote: > On 2015-12-04 17:43, André Pönitz wrote: >> On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote: >>> Which of these is easier to read? (More importantly, which is easier to >>> *verify* that it is correct?) >>> >>> for (int i = 0; i < list.size(); ++i) >>> foo(list[i]); >> >> Whether the access is correct depends on the type of list, which you don't >> disclose. > > That's sort of *the point*. I can't tell if the above is correct or not. > If it used 'auto', I'd know. > > (And it's sort of implied that it *is* wrong. Because, y'know, I see > loops like the above quite often where, indeed, they do in fact use the > wrong type. Actually, QList/QVector are about the *only* times the above > is written correctly without using 'auto'. More often than not, a loop > like that written against a non-Qt container uses the wrong index type.) > >> In any case, this loop follows a well-known pattern. > > It also follows a really *bad* pattern. The count is reevaluated every > time (well, you hope the compiler will hoist it, but the code says that > it is). Using type deduction... well, sucks: > > for (auto i = decltype(list.size()){0}; i < list.size(); ++i) > >>> for (auto i : qtIndexRange(list.size()) >>> foo(list[i]); >> >> In any case, this is an uncommon pattern, using some unknown qtIndexRange() >> function. > > Really? > > (Python) > for i in range(len(list)) for index, value in enumerate(iteratable): print(index, value) would be much better because index accesses are quite slow. But it shows nicely why types can reduce readability. for (auto {index, value} : enumerate(iteratable)) Is so far I understand the new syntax in C++. Actually I want to use that because it makes code much more readable. Think about auto {value , isConvertable} = variant.toDouble(); In that case auto would enforce the test much more and the code is very readable too. > Just because it isn't standardized (or in Qt) yet doesn't mean it's > "unheard of". It's just that C++ users have been suffering with the > difficult to use form while programmers in other languages have had the > much more sensible form for a long time. > > Really, it's not hard... nasty glorified while loop vs. 'I want to > iterate over the indices [starting at zero] up to list.size()'. > > There's a reason I strongly prefer the latter form and use it whenever I > can (usually subject to compiler compatibility limitations). > >> Moreover it is more to type. > > Really? > > for (auto i : qtInlist.si)) > - vs. - > for (int i = 0; i < list.si; ++i) > > Hey, look... mine's *fewer* keystrokes. And much more importantly, it's > *correct*. Yours... may or may not be... as you pointed out, I don't > know without knowing decltype(list). (Or I could use the much longer, > *much* uglier old-style for loop with decltype that is correct, but then > mine wins hands-down.) > >> The extra level of parantheses makes it harder to parse for >> humans,introducing an aditional source of errors, which you nicely >> demonstrated by making the example non-compilable. > > Bah. A decent IDE would have flagged that as soon as I stopped typing. > (Actually, a decent *text editor* would have shown me () matches, so I > would have noticed *as* I was typing. I challenge you to write bug-free > code the first time in a text editor whose most advanced feature is cut > and paste.) > >>> Which is *really* more meaningful? >> >> The first one. > > Sorry, but I must strongly disagree. > >>> "The type of 'i' is 'int', and I >>> really, really hope that 'list' is actually indexed by 'int'", or "the >>> type of 'i' is the index type of 'list'¹"? >>> >>> Do you really *care* what is the type of 'i'? >> >> Yes, I do care about types, almost always. > > Why? As long as it's the *correct* type, what difference did it make? > > Let's say that the correct type is my_list::index_t. Let's say I used that: > > for (my_list::index_t i = 0; i < list.size(); ++i) > > How is that better? Do you know now what is the actual type of 'i'? > > I submit that writing 'my_list::index_t' is not a significant > improvement over 'auto'. It didn't tell you anything about the actual > type of 'i'. (It does suggest that the type of 'list' might be 'my_list' > and that a 'my_list' probably uses 'my_list::index_t' as its indexing > type. But there's still that "probably". Whereas 'auto' says the type > *is* the indexing type.) > >> Your message has been heard. I do not agree with you. > > Likewise. > >> I feel more comfortable arguing about whether a type is the right one >> if the type is known than when it is unknown. > > Then you are missing the point. In fact, you are missing the whole point > of 'auto'. By using 'auto' correctly, it's possible to know that the > type *is correct*, even if you don't know what the type actually *is*. > (Or if a change elsewhere should change what is the correct type.) > > -- > Matthew > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Sent from cellphone From apoenitz at t-online.de Sat Dec 5 01:44:45 2015 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Sat, 5 Dec 2015 01:44:45 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> <4606126.Pqxnumcx4H@finn> <20151204203516.GA2407@klara.mpi.htwm.de> <20151204224303.GA2648@klara.mpi.htwm.de> Message-ID: <20151205004445.GA2766@klara.mpi.htwm.de> On Fri, Dec 04, 2015 at 06:10:45PM -0500, Matthew Woehlke wrote: > On 2015-12-04 17:43, André Pönitz wrote: > > On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote: > >> Which of these is easier to read? (More importantly, which is easier to > >> *verify* that it is correct?) > >> > >> for (int i = 0; i < list.size(); ++i) > >> foo(list[i]); > > > > Whether the access is correct depends on the type of list, which you don't > > disclose. > > That's sort of *the point*. I can't tell if the above is correct or not. > If it used 'auto', I'd know. You don't know whether operator[] or .at() is the best way to access by index until you know the type of list. Once you know the type of list, you also know what the type of i should be. There's no point in being fuzzy about it unless there is a *significant* advantage to it (like using 'auto' for iterator types which are mostly line noise). > (And it's sort of implied that it *is* wrong. Because, y'know, I see > loops like the above quite often where, indeed, they do in fact use the > wrong type. Actually, QList/QVector are about the *only* times the above > is written correctly without using 'auto'. More often than not, a loop > like that written against a non-Qt container uses the wrong index type.) The context of this discussion is the development of Qt. Thank you for confirming that 'int' is the right thing to use. > > In any case, this loop follows a well-known pattern. > > It also follows a really *bad* pattern. The count is reevaluated every > time (well, you hope the compiler will hoist it, but the code says that > it is). Using type deduction... well, sucks: > > for (auto i = decltype(list.size()){0}; i < list.size(); ++i) [ If you care about size() re-evaluation: for (int i = 0, n = list.size(); i < n; ++i) ... ] > for (auto i : qtIndexRange(list.size()) > >> foo(list[i]); > > > > In any case, this is an uncommon pattern, using some unknown qtIndexRange() > > function. > > Really? > > (Python) Please stay on topic. The topic was whether to be more 'liberal' with the use of auto in Qt, written mostly in C++, not Python. > > > > The extra level of parantheses makes it harder to parse for > > humans,introducing an aditional source of errors, which you nicely > > demonstrated by making the example non-compilable. > > Bah. A decent IDE would have flagged that as soon as I stopped typing. You are basically assuming that there's no need for you to write sane code to start with because during your development work you have a decent IDE to help you out. This assumption is wrong, independent of the existence of such an IDE. Since the discussion here is about what to use in Qt, the whole Qt development workflow matters. A lot of Qt code reading happens on Gerrit without IDE features at hand. The context there usually just a few lines. The appropriateness of an expression 'list[x]' is impossible to judge on Gerrit after applying an 'Almost always auto' policy. This argument is not restricted to 'auto'. In general, code patterns that rely completely on IDE support are not beneficial for Qt development. > [...] > >> Which is *really* more meaningful? > > > > The first one. > > Sorry, but I must strongly disagree. So we agree to disagree. This was a call for comments. We've now established the fact that there's no consensus on this matter. > In fact, you are missing the whole point of 'auto'. I don't think so. > By using 'auto' correctly, it's possible to know that the > type *is correct*, even if you don't know what the type actually *is*. You are missing the fact that Qt development is not an IDE-only workflow and does in general not operate on complete translation unit. You also do not seem to believe that at least some humans need a bit more explicit context than compilers to efficiently read code. Andre' From Marco.Bubke at theqtcompany.com Sat Dec 5 01:57:23 2015 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Sat, 5 Dec 2015 00:57:23 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <20151205004445.GA2766@klara.mpi.htwm.de> References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> <4606126.Pqxnumcx4H@finn> <20151204203516.GA2407@klara.mpi.htwm.de> <20151204224303.GA2648@klara.mpi.htwm.de> <20151205004445.GA2766@klara.mpi.htwm.de> Message-ID: On December 5, 2015 01:43:40 André Pönitz wrote: > On Fri, Dec 04, 2015 at 06:10:45PM -0500, Matthew Woehlke wrote: >> On 2015-12-04 17:43, André Pönitz wrote: >> > On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote: >> >> Which of these is easier to read? (More importantly, which is easier to >> >> *verify* that it is correct?) >> >> >> >> for (int i = 0; i < list.size(); ++i) >> >> foo(list[i]); >> > >> > Whether the access is correct depends on the type of list, which you don't >> > disclose. >> >> That's sort of *the point*. I can't tell if the above is correct or not. >> If it used 'auto', I'd know. > > You don't know whether operator[] or .at() is the best way to access > by index until you know the type of list. Once you know the type of > list, you also know what the type of i should be. There's no point > in being fuzzy about it unless there is a *significant* advantage > to it (like using 'auto' for iterator types which are mostly line > noise). > >> (And it's sort of implied that it *is* wrong. Because, y'know, I see >> loops like the above quite often where, indeed, they do in fact use the >> wrong type. Actually, QList/QVector are about the *only* times the above >> is written correctly without using 'auto'. More often than not, a loop >> like that written against a non-Qt container uses the wrong index type.) > > The context of this discussion is the development of Qt. Thank you for > confirming that 'int' is the right thing to use. > >> > In any case, this loop follows a well-known pattern. >> >> It also follows a really *bad* pattern. The count is reevaluated every >> time (well, you hope the compiler will hoist it, but the code says that >> it is). Using type deduction... well, sucks: >> >> for (auto i = decltype(list.size()){0}; i < list.size(); ++i) > > [ > If you care about size() re-evaluation: > > for (int i = 0, n = list.size(); i < n; ++i) > ... > ] > >> for (auto i : qtIndexRange(list.size()) >> >> foo(list[i]); >> > >> > In any case, this is an uncommon pattern, using some unknown qtIndexRange() >> > function. >> >> Really? >> >> (Python) > > Please stay on topic. The topic was whether to be more 'liberal' with > the use of auto in Qt, written mostly in C++, not Python. > >> > >> > The extra level of parantheses makes it harder to parse for >> > humans,introducing an aditional source of errors, which you nicely >> > demonstrated by making the example non-compilable. >> >> Bah. A decent IDE would have flagged that as soon as I stopped typing. > > You are basically assuming that there's no need for you to write sane > code to start with because during your development work you have a > decent IDE to help you out. This assumption is wrong, independent > of the existence of such an IDE. > > Since the discussion here is about what to use in Qt, the whole Qt > development workflow matters. A lot of Qt code reading happens on Gerrit > without IDE features at hand. The context there usually just a few lines. > The appropriateness of an expression 'list[x]' is impossible to judge > on Gerrit after applying an 'Almost always auto' policy. Oswald and I spoke about using the clang code model to provide the information to gerrit too. It should be not that hard. But you have to import the code in the IDE anyway because of the missing context. For non trivial change review the calling context is far to important to be ignored. A html code browser could change that but we don't have one in gerrit. > This argument is not restricted to 'auto'. In general, code patterns > that rely completely on IDE support are not beneficial for Qt > development. > >> [...] >> >> Which is *really* more meaningful? >> > >> > The first one. >> >> Sorry, but I must strongly disagree. > > So we agree to disagree. This was a call for comments. We've now > established the fact that there's no consensus on this matter. > >> In fact, you are missing the whole point of 'auto'. > > I don't think so. > >> By using 'auto' correctly, it's possible to know that the >> type *is correct*, even if you don't know what the type actually *is*. > > You are missing the fact that Qt development is not an IDE-only workflow > and does in general not operate on complete translation unit. You also > do not seem to believe that at least some humans need a bit more explicit > context than compilers to efficiently read code. > > Andre' > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Sent from cellphone From thiago.macieira at intel.com Sat Dec 5 04:34:29 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 04 Dec 2015 19:34:29 -0800 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <20151205004445.GA2766@klara.mpi.htwm.de> Message-ID: <2741898.ueVUPJthEx@tjmaciei-mobl4> On Saturday 05 December 2015 00:57:23 Bubke Marco wrote: > Oswald and I spoke about using the clang code model to provide the > information to gerrit too. It should be not that hard. Please make sure those changes are making their way to Gerrit upstream. Forking Gerrit is not a good idea. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sean.harmer at kdab.com Sat Dec 5 10:30:33 2015 From: sean.harmer at kdab.com (Sean Harmer) Date: Sat, 5 Dec 2015 09:30:33 +0000 Subject: [Development] RFC: new moc feature Message-ID: <5662AEB9.5060705@kdab.com> Hi devs, I'd like to get some feedback on a new feature for moc before we take it any further than mild musing. The context is Qt3D has some frontend QObject subclass types, and corresponding backend, non-QObject subclass types for reasons of allowing us to process data on the backend without blocking the main thread or locking it. To get the property values from the frontend objects to the backend we wrap the data up in QScenePropertyChange and in the backend object we unpack the data and handle it with code something like this: if (e->type() == NodeUpdated) { const QScenePropertyChangePtr &propertyChange = qSharedPointerCast(e); if (propertyChange->propertyName() == QByteArrayLiteral("scale3D")) { m_scale = propertyChange->value().value(); updateMatrix(); } else if (propertyChange->propertyName() == QByteArrayLiteral("rotation")) { m_rotation = propertyChange->value().value(); updateMatrix(); } else if (propertyChange->propertyName() == QByteArrayLiteral("translation")) { m_translation = propertyChange->value().value(); updateMatrix(); } else if (propertyChange->propertyName() == QByteArrayLiteral("enabled")) { m_enabled = propertyChange->value().toBool(); } } Not too bad in this case but those cascaded if-else if blocks are not good when the number of properties is large. This is where the proposed new feature of moc would come in. If moc were able to generate an enum where each enum value corresponds to a static property we would be able to use a switch in the above code. Is such a feature feasible? Are there reasons why it couldn't work? Thanks in advance for any feedback. 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 olivier at woboq.com Sat Dec 5 11:22:23 2015 From: olivier at woboq.com (Olivier Goffart) Date: Sat, 05 Dec 2015 11:22:23 +0100 Subject: [Development] RFC: new moc feature In-Reply-To: <5662AEB9.5060705@kdab.com> References: <5662AEB9.5060705@kdab.com> Message-ID: <2280029.KrAAQK5H7f@finn> On Saturday 5. December 2015 09:30:33 Sean Harmer wrote: > Hi devs, > > I'd like to get some feedback on a new feature for moc before we take it > any further than mild musing. The context is Qt3D has some frontend > QObject subclass types, and corresponding backend, non-QObject subclass > types for reasons of allowing us to process data on the backend without > blocking the main thread or locking it. > > To get the property values from the frontend objects to the backend we > wrap the data up in QScenePropertyChange and in the backend object we > unpack the data and handle it with code something like this: > > if (e->type() == NodeUpdated) { > const QScenePropertyChangePtr &propertyChange = > qSharedPointerCast(e); > if (propertyChange->propertyName() == > QByteArrayLiteral("scale3D")) { > m_scale = propertyChange->value().value(); > updateMatrix(); > } else if (propertyChange->propertyName() == > QByteArrayLiteral("rotation")) { > m_rotation = propertyChange->value().value(); > updateMatrix(); > } else if (propertyChange->propertyName() == > QByteArrayLiteral("translation")) { > m_translation = propertyChange->value().value(); > updateMatrix(); > } else if (propertyChange->propertyName() == > QByteArrayLiteral("enabled")) { > m_enabled = propertyChange->value().toBool(); > } > } > > Not too bad in this case but those cascaded if-else if blocks are not > good when the number of properties is large. Why not? Readability or performence? > This is where the proposed new feature of moc would come in. If moc were > able to generate an enum where each enum value corresponds to a static > property we would be able to use a switch in the above code. > > Is such a feature feasible? Are there reasons why it couldn't work? I'm afraid this is not feasable. This enum would need to be in the header, and the moc generated code is not a header. Instead, I would suggest something similar to llvm::StringSwitch http://code.woboq.org/llvm/llvm/include/llvm/ADT/StringSwitch.h.html -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From Lars.Knoll at theqtcompany.com Sat Dec 5 11:50:23 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Sat, 5 Dec 2015 10:50:23 +0000 Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <4C163E56-0A16-4C53-A48E-2EA3D6ACBFF7@subsite.com> References: <3709A7D425EE8C45991DB29EC2FACA882720392B@GL-EXC-01.iesve.com> <3709A7D425EE8C45991DB29EC2FACA8827203A31@GL-EXC-01.iesve.com> <4C163E56-0A16-4C53-A48E-2EA3D6ACBFF7@subsite.com> Message-ID: On 03/12/15 15:09, "Development on behalf of Edward Sutton" on behalf of edward.sutton at subsite.com> wrote: Will Qt 5.6 have alternative methods to export HTML to PDF that support major platforms of Android, iOS, Linux, OS X, and Windows? On iOS a Qt developer must resort to native code to generate PDF files. Unfortunately Qt 5.5 PDF export is dependent on QPrinter which is not supported on iOS. While iOS can create and displays PDF’s just fine, iOS has no printer support. In the future, Is it possible the PDF creation dependency could be separated from QPrinter? So that Qt PDF generation would have better cross-platform support? QPrinter printer(QPrinter::ScreenResolution); // QPrinter not supported on iOS printer.setOutputFormat(QPrinter::PdfFormat); printer.setOutputFileName(pdfFileName); drawReport(printer); m_painter.end(); Without understanding internals of PDF file creation, it feels like PDF creation should not be dependent on QPrinter? We have an alternative to using QPrinter since Qt 5.0. Please have a look at QPdfWriter. It's in Qt Gui, fully platform independent and should just work on iOS. Cheers, Lars -Ed On Dec 3, 2015, at 7:37 AM, Mark De Wit > wrote: Thanks for all the feedback everyone. We are excited about the 5.6 release because we are looking closely at the new Qt3D module, as well as migrating to VS 2015. Sadly, PDF export of HTML content is a critical feature for our product (in general I’m happy to move to WebEngine, but we cannot remove output functionality from our software). Building from source would be an option, I guess. We have done it in the past, but the build process / flags (for distribution) is not sufficiently well documented, and starting with 5.5.1 we were excited to be able to use official binaries. Kind regards, Mark From: Turunen Tuukka [mailto:tuukka.turunen at theqtcompany.com] Sent: 03 December 2015 12:30 To: Mark De Wit >; development at qt-project.org Subject: RE: [Development] Please do not remove QtWebkit from 5.6 official binaries Hi Mark, If you need to use Qt Webkit, then it is probably better to stay with Qt 5.5. There is nothing that makes Qt 5.5 bad overnight, if it works for you now. Qt WebEngine is in many aspects already much better in features than Qt Webkit. Qt WebEngine is also better maintained, and does receive much more improvements and security fixes than Qt Webkit. Even though some features of Qt WebKit are not in same way available with Qt WebEngine, it is overall a better choice. Qt Webkit is removed from Qt 5.6 because it is no longer maintained well enough to be part of an official Qt release. We are also not developing and testing it to work with Qt 5.6. Yours, Tuukka From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Mark De Wit Sent: torstaina 3. joulukuuta 2015 13.18 To: development at qt-project.org Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries Hi all, QtWebEngine does not yet have feature parity with QtWebkit. For instance, print support (especially export to PDF) is a critical requirement for my use of Webkit. This missing feature prevents me from migrating to WebEngine. Removing webkit from the official distribution will prevent me (and surely others) from upgrading to 5.6. Thanks, Mark _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.blanc at nmc-company.com Sat Dec 5 12:08:38 2015 From: julien.blanc at nmc-company.com (Julien Blanc) Date: Sat, 05 Dec 2015 12:08:38 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> <4606126.Pqxnumcx4H@finn> <20151204203516.GA2407@klara.mpi.htwm.de> <20151204224303.GA2648@klara.mpi.htwm.de> Message-ID: <1449313718.2486.158.camel@nmc-company.com> Le vendredi 04 décembre 2015 à 18:10 -0500, Matthew Woehlke a écrit : > On 2015-12-04 17:43, André Pönitz wrote: > > On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote: > >> Which of these is easier to read? (More importantly, which is easier to > >> *verify* that it is correct?) > >> > >> for (int i = 0; i < list.size(); ++i) > >> foo(list[i]); [snip] > > >> for (auto i : qtIndexRange(list.size()) > >> foo(list[i]); > > > > In any case, this is an uncommon pattern, using some unknown qtIndexRange() > > function. > > Really? > > (Python) > for i in range(len(list)) Am I the only one to think that this example is inherently broken ? I mean, why wouldn’t any sane person write : for(auto const& element : list) foo(element) or std::for_each(list.begin(), list.end(), foo); Because : - it’s shorter - it’s more readable - it works for non random-access-container types - bonus : range checking is not needed, so it should be more performant - bonus : it doesn’t resort to a temporary value, same remark Now, getting back to what Marc proposed initially, because the debate has gone far away from his initial proposal : > - template code (esp., but not necessarily only, when the type name > would require the use of 'typename') This is the one i’m not at ease with. Template code tends to be difficult to read, partly *because* there’s no type information. For readability concerns, i would prefer a local typedef named by the concept. Yes, that makes it two lines instead of one, but i think that’s one case where hinting the reader with a well-chosen type name makes a lot of sense. > - all loop variables (both index and iterators) > the reason being that spelling out the name is usually wrong: > size_t i = stdVector.size() // wrong, should be > std::vector::size_type... > also helps when porting from Qt containers to STL ones That looks perfectly fine for me. Index based loops should be avoided whenever it is possible, and for iterator based loops auto makes no harm (seriously, who wants to write std::vector::const_iterator instead of auto ?). > - all references to elements in a collection (same problem - way too > easy to misspell std::pair for std::pair...) Same thing. Regards, Julien From sean.harmer at kdab.com Sat Dec 5 13:00:44 2015 From: sean.harmer at kdab.com (Sean Harmer) Date: Sat, 5 Dec 2015 12:00:44 +0000 Subject: [Development] RFC: new moc feature In-Reply-To: <2280029.KrAAQK5H7f@finn> References: <5662AEB9.5060705@kdab.com> <2280029.KrAAQK5H7f@finn> Message-ID: <5662D1EC.305@kdab.com> Hi Olivier, On 05/12/2015 10:22, Olivier Goffart wrote: > On Saturday 5. December 2015 09:30:33 Sean Harmer wrote: >> Hi devs, >> >> I'd like to get some feedback on a new feature for moc before we take it >> any further than mild musing. The context is Qt3D has some frontend >> QObject subclass types, and corresponding backend, non-QObject subclass >> types for reasons of allowing us to process data on the backend without >> blocking the main thread or locking it. >> >> To get the property values from the frontend objects to the backend we >> wrap the data up in QScenePropertyChange and in the backend object we >> unpack the data and handle it with code something like this: >> >> if (e->type() == NodeUpdated) { >> const QScenePropertyChangePtr &propertyChange = >> qSharedPointerCast(e); >> if (propertyChange->propertyName() == >> QByteArrayLiteral("scale3D")) { >> m_scale = propertyChange->value().value(); >> updateMatrix(); >> } else if (propertyChange->propertyName() == >> QByteArrayLiteral("rotation")) { >> m_rotation = propertyChange->value().value(); >> updateMatrix(); >> } else if (propertyChange->propertyName() == >> QByteArrayLiteral("translation")) { >> m_translation = propertyChange->value().value(); >> updateMatrix(); >> } else if (propertyChange->propertyName() == >> QByteArrayLiteral("enabled")) { >> m_enabled = propertyChange->value().toBool(); >> } >> } >> >> Not too bad in this case but those cascaded if-else if blocks are not >> good when the number of properties is large. > Why not? Readability or performence? Both but performance is the main driver as potentially we have a large number of string comparisons. > >> This is where the proposed new feature of moc would come in. If moc were >> able to generate an enum where each enum value corresponds to a static >> property we would be able to use a switch in the above code. >> >> Is such a feature feasible? Are there reasons why it couldn't work? > I'm afraid this is not feasable. This enum would need to be in the header, and > the moc generated code is not a header. Ah yes of course. Silly me. > Instead, I would suggest something similar to llvm::StringSwitch > http://code.woboq.org/llvm/llvm/include/llvm/ADT/StringSwitch.h.html Right, thanks. I've also been considering compile time hashing of the strings via constexpr implementation of some hashing algorithm but from reading around it seems MSVC2012 won't be up to the job for this approach. So at present that leaves a build time preprocess tool that goes over the sources and replaces marked up strings with their hashed values. Plus side is that the work is done at build time leaving just an integer comparison at run time. Down side is getting access to the original strings during debugging/runtime. This could be overcome by having the debugger/runtime load up the mapping of hashed values to original strings. So given the above example we'd be able to have something like this (name of macro pending): if (e->type() == NodeUpdated) { const QScenePropertyChangePtr &propertyChange = qSharedPointerCast(e); switch (propertyChange->propertyNameStringId()) { case qStrId("scale3D"): m_scale = propertyChange->value().value(); updateMatrix(); break; case qStrId("rotation"): m_rotation = propertyChange->value().value(); updateMatrix(); break; case qStrId("translation"): m_translation = propertyChange->value().value(); updateMatrix(); break; case qStrId("enabled"): m_enabled = propertyChange->value().toBool(); break; default: qWarning() << "Unknown property update"; } } Where the qStrId macro expands to nothing and the preprocess tool replaces its contents with the hashed value. No idea if all of our supported compilers allow hooking in custom preprocessors or not. Yes, I know in this particular case, the wrapping/unwrapping of the property values in QVariants is likely the bottleneck but we can solve that with specialised property change types. 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 Marco.Bubke at theqtcompany.com Sat Dec 5 13:08:44 2015 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Sat, 5 Dec 2015 12:08:44 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <1449313718.2486.158.camel@nmc-company.com> References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> <4606126.Pqxnumcx4H@finn> <20151204203516.GA2407@klara.mpi.htwm.de> <20151204224303.GA2648@klara.mpi.htwm.de> <1449313718.2486.158.camel@nmc-company.com> Message-ID: On December 5, 2015 12:08:51 Julien Blanc wrote: > Le vendredi 04 décembre 2015 à 18:10 -0500, Matthew Woehlke a écrit : >> On 2015-12-04 17:43, André Pönitz wrote: >> > On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote: >> >> Which of these is easier to read? (More importantly, which is easier to >> >> *verify* that it is correct?) >> >> >> >> for (int i = 0; i < list.size(); ++i) >> >> foo(list[i]); > [snip] >> >> >> for (auto i : qtIndexRange(list.size()) >> >> foo(list[i]); >> > >> > In any case, this is an uncommon pattern, using some unknown qtIndexRange() >> > function. >> >> Really? >> >> (Python) >> for i in range(len(list)) > > Am I the only one to think that this example is inherently broken ? I > mean, why wouldn’t any sane person write : > > for(auto const& element : list) > foo(element) > > or > std::for_each(list.begin(), list.end(), foo); > > Because : > - it’s shorter > - it’s more readable > - it works for non random-access-container types > - bonus : range checking is not needed, so it should be more performant > - bonus : it doesn’t resort to a temporary value, same remark What if you want to iterate over two lists. for token, cursors in zip(tokens, cursors): ... is quite handy. You can use std::transform for some cases but C++ is sometimes very far behind. To my understanding Ranges should provide a good solution for it but they hide the type for good reasons. > > Now, getting back to what Marc proposed initially, because the debate > has gone far away from his initial proposal : > >> - template code (esp., but not necessarily only, when the type name >> would require the use of 'typename') > > This is the one i’m not at ease with. Template code tends to be > difficult to read, partly *because* there’s no type information. For > readability concerns, i would prefer a local typedef named by the > concept. Yes, that makes it two lines instead of one, but i think that’s > one case where hinting the reader with a well-chosen type name makes a > lot of sense. Most typedefs I have seen was about hiding pointer or container types like CursorPointer or Cursors. But is CursorPointer a unique pointer, a shared pointer and which flavor is it. Cursors is the same because it could be std::vector or QList. Some would hide a dictionary behind this name. So the typedef can be misleading. In that case I prefer auto. std::shared cursorPointer = document.cursorAtPostion(46); CursorPointer cursorPointer = document.cursorAtPostion(46); auto cursorPointer = document.cursorAtPostion(46); I prefer the last but we need good tooling to show the type. It would be nice to have much more information like size, is it movable or copyable. It is not only the type and we can provide that information. >> - all loop variables (both index and iterators) >> the reason being that spelling out the name is usually wrong: >> size_t i = stdVector.size() // wrong, should be >> std::vector::size_type... >> also helps when porting from Qt containers to STL ones > > That looks perfectly fine for me. Index based loops should be avoided > whenever it is possible, and for iterator based loops auto makes no harm > (seriously, who wants to write > std::vector::const_iterator instead of auto ?). > >> - all references to elements in a collection (same problem - way too >> easy to misspell std::pair for std::pair...) > > Same thing. > > Regards, > > Julien > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Sent from cellphone From julien.blanc at nmc-company.com Sat Dec 5 13:46:53 2015 From: julien.blanc at nmc-company.com (Julien Blanc) Date: Sat, 05 Dec 2015 13:46:53 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> <4606126.Pqxnumcx4H@finn> <20151204203516.GA2407@klara.mpi.htwm.de> <20151204224303.GA2648@klara.mpi.htwm.de> <1449313718.2486.158.camel@nmc-company.com> Message-ID: <1449319613.2486.175.camel@nmc-company.com> Le samedi 05 décembre 2015 à 12:08 +0000, Bubke Marco a écrit : > > > >> - template code (esp., but not necessarily only, when the type name > >> would require the use of 'typename') > > > > This is the one i’m not at ease with. Template code tends to be > > difficult to read, partly *because* there’s no type information. For > > readability concerns, i would prefer a local typedef named by the > > concept. Yes, that makes it two lines instead of one, but i think that’s > > one case where hinting the reader with a well-chosen type name makes a > > lot of sense. > > Most typedefs I have seen was about hiding pointer or container types like CursorPointer or Cursors. But is CursorPointer a unique pointer, a shared pointer and which flavor is it. Cursors is the same because it could be std::vector or QList. Some would hide a dictionary behind this name. So the typedef can be misleading. In that case I prefer auto. > > std::shared cursorPointer = document.cursorAtPostion(46); > > CursorPointer cursorPointer = document.cursorAtPostion(46); > > auto cursorPointer = document.cursorAtPostion(46); > > I prefer the last but we need good tooling to show the type. It would be nice to have much more information like size, is it movable or copyable. It is not only the type and we can provide that information. My understanding of Marc’s proposal was that it was more for the following case : template void algorithm(List& input) { typename List::value_type& first = input.front(); ... } replaced by : template void algorithm(List& input) { auto& first = input.front(); ... } whereas i prefer template void algorithm(List& input) { typedef typename List::value_type Serializable; // there are some requirements on List : item_type must be // Serializable : now i can look the doc to see what a // Serializable is Serializable& first = input.front(); // i know what to expect from first, which methods i can call ... } I think the latter improves readability over the two others, because it just gives more information to the reader. And this information is currently *not* given by the type system, because concepts do not exists in the type system yet. No tooling will ever give you a type information here : it depends on the template instanciation. Regards, Julien Blanc From marc.mutz at kdab.com Sat Dec 5 20:01:00 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 5 Dec 2015 20:01:00 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <1449319613.2486.175.camel@nmc-company.com> References: <201512031949.46920.marc.mutz@kdab.com> <1449319613.2486.175.camel@nmc-company.com> Message-ID: <201512052001.00942.marc.mutz@kdab.com> On Saturday 05 December 2015 13:46:53 Julien Blanc wrote: > Le samedi 05 décembre 2015 à 12:08 +0000, Bubke Marco a écrit : [...] > whereas i prefer > template void algorithm(List& input) > { > typedef typename List::value_type Serializable; > // there are some requirements on List : item_type must be > // Serializable : now i can look the doc to see what a > // Serializable is > Serializable& first = input.front(); > // i know what to expect from first, which methods i can call > ... > } [...] Thank YOU! That's the PERFECT example of why you should use _auto_! In the best of Qt traditions: You're Doing It Wrong! If you don't see why, try to pass a C array to your function... There's a _reason_ we have std::begin(), and a _reason_ why we have iterator_traits. The _correct_ way to write this is without auto or decltype is: template void algorithm(List &list) { using namespace std; // no decltype, so way to refer to decltype(begin(list), // so need to defer to a helper: algorithm_impl(begin(list), end(list)); } template void algorithm_impl(ForwardIterator first, ForwardIterator last) { if (first == last) return; typedef typename std::iterator_traits::value_type Serializable; // useless comments Serializable &start = *first: } Well, or, with auto: template void algorithm(List &list) { using namespace std; auto first = begin(list), last = end(list); if (first == last) return; auto &start = *first; .... } Everyone who claims that the first one is more readable is crazy. And please don't _anyone_ out yourself as _actually_ believing that the first is more readable, because then I would have personally insulted you, and I don't want to do that. Let's hope common sense prevails and we all get out of this awkward situation with saved faces... Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Sat Dec 5 20:06:22 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 5 Dec 2015 20:06:22 +0100 Subject: [Development] RFC: new moc feature In-Reply-To: <5662D1EC.305@kdab.com> References: <5662AEB9.5060705@kdab.com> <2280029.KrAAQK5H7f@finn> <5662D1EC.305@kdab.com> Message-ID: <201512052006.22869.marc.mutz@kdab.com> On Saturday 05 December 2015 13:00:44 Sean Harmer wrote: > So given the above example we'd be able to have something like this > (name of macro pending): > > if (e->type() == NodeUpdated) { > const QScenePropertyChangePtr &propertyChange = > qSharedPointerCast(e); > switch (propertyChange->propertyNameStringId()) { > case qStrId("scale3D"): > m_scale = propertyChange->value().value(); > updateMatrix(); > break; > case qStrId("rotation"): > m_rotation = propertyChange->value().value(); > updateMatrix(); > break; > case qStrId("translation"): > m_translation = propertyChange->value().value(); > updateMatrix(); > break; > case qStrId("enabled"): > m_enabled = propertyChange->value().toBool(); > break; > default: > qWarning() << "Unknown property update"; > } > } > > Where the qStrId macro expands to nothing and the preprocess tool > replaces its contents with the hashed value. No idea if all of our > supported compilers allow hooking in custom preprocessors or not. How do you handle the invariable hash collisions? What's wrong the the old and trusted switch (propName.front()) { case 's': if (propName == "scale3D") ... case 'r': if (propName == "rotation") ... (and why the QByteArrayLiteral in the original code)? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Sat Dec 5 20:45:56 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 5 Dec 2015 20:45:56 +0100 Subject: [Development] RFC: new moc feature In-Reply-To: <201512052006.22869.marc.mutz@kdab.com> References: <5662AEB9.5060705@kdab.com> <5662D1EC.305@kdab.com> <201512052006.22869.marc.mutz@kdab.com> Message-ID: <201512052045.57549.marc.mutz@kdab.com> On Saturday 05 December 2015 20:06:22 Marc Mutz wrote: > invariable inevitable -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From sean.harmer at kdab.com Sat Dec 5 20:20:27 2015 From: sean.harmer at kdab.com (Sean Harmer) Date: Sat, 5 Dec 2015 19:20:27 +0000 Subject: [Development] RFC: new moc feature In-Reply-To: <201512052006.22869.marc.mutz@kdab.com> References: <5662AEB9.5060705@kdab.com> <2280029.KrAAQK5H7f@finn> <5662D1EC.305@kdab.com> <201512052006.22869.marc.mutz@kdab.com> Message-ID: <566338FB.5050601@kdab.com> Hi Marc, On 05/12/2015 19:06, Marc Mutz wrote: > On Saturday 05 December 2015 13:00:44 Sean Harmer wrote: >> So given the above example we'd be able to have something like this >> (name of macro pending): >> >> if (e->type() == NodeUpdated) { >> const QScenePropertyChangePtr &propertyChange = >> qSharedPointerCast(e); >> switch (propertyChange->propertyNameStringId()) { >> case qStrId("scale3D"): >> m_scale = propertyChange->value().value(); >> updateMatrix(); >> break; >> case qStrId("rotation"): >> m_rotation = propertyChange->value().value(); >> updateMatrix(); >> break; >> case qStrId("translation"): >> m_translation = propertyChange->value().value(); >> updateMatrix(); >> break; >> case qStrId("enabled"): >> m_enabled = propertyChange->value().toBool(); >> break; >> default: >> qWarning() << "Unknown property update"; >> } >> } >> >> Where the qStrId macro expands to nothing and the preprocess tool >> replaces its contents with the hashed value. No idea if all of our >> supported compilers allow hooking in custom preprocessors or not. > How do you handle the invariable hash collisions? Not sure yet. Still thinking this through. The chances of a collision within the scope of a comparison such as this is pretty small (of course dependent upon the quality of the hash function). If used within a hash the compiler would complain about duplicated case labels. If the preprocess tool maintains a catalogue of entries in the hash it could also warn about collisions to allow the user opportunity to alter the names being used. > What's wrong the the old and trusted > > switch (propName.front()) { > case 's': if (propName == "scale3D") ... > case 'r': if (propName == "rotation") ... Indeed, this is something we could adopt now with little effort. I was just wondering if we could get it down to the theoretical ideal of a single integer comparison mapped into the finite set of strings in use. Seems not, without some non-neglible effort. > (and why the QByteArrayLiteral in the original code)? Simple oversight. Will fix. 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 marc.mutz at kdab.com Sat Dec 5 21:37:32 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 5 Dec 2015 21:37:32 +0100 Subject: [Development] RFC: new moc feature In-Reply-To: <566338FB.5050601@kdab.com> References: <5662AEB9.5060705@kdab.com> <201512052006.22869.marc.mutz@kdab.com> <566338FB.5050601@kdab.com> Message-ID: <201512052137.32784.marc.mutz@kdab.com> On Saturday 05 December 2015 20:20:27 Sean Harmer wrote: > I was > just wondering if we could get it down to the theoretical ideal of a > single integer comparison mapped into the finite set of strings in use. > Seems not, without some non-neglible effort. man 1 gperf ? -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From annulen at yandex.ru Sat Dec 5 20:32:56 2015 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sat, 05 Dec 2015 22:32:56 +0300 Subject: [Development] RFC: new moc feature In-Reply-To: <201512052137.32784.marc.mutz@kdab.com> References: <5662AEB9.5060705@kdab.com> <201512052006.22869.marc.mutz@kdab.com> <566338FB.5050601@kdab.com> <201512052137.32784.marc.mutz@kdab.com> Message-ID: <2683341449343976@web24g.yandex.ru> 05.12.2015, 22:29, "Marc Mutz" : > On Saturday 05 December 2015 20:20:27 Sean Harmer wrote: >>  I was >>  just wondering if we could get it down to the theoretical ideal of a >>  single integer comparison mapped into the finite set of strings in use. >>  Seems not, without some non-neglible effort. > > man 1 gperf ? IMO, integration of gperf needs too much scaffolding. re2c is more convenient for implementing of string switch -- Regards, Konstantin From kevin.kofler at chello.at Sun Dec 6 04:01:45 2015 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 06 Dec 2015 04:01:45 +0100 Subject: [Development] RFC: new moc feature References: <5662AEB9.5060705@kdab.com> <2280029.KrAAQK5H7f@finn> Message-ID: Olivier Goffart wrote: > Instead, I would suggest something similar to llvm::StringSwitch > http://code.woboq.org/llvm/llvm/include/llvm/ADT/StringSwitch.h.html Ewww, this is horrible! It will evaluate ALL the result values passed to it, whether the cases match or not. That works if the values are just enum constants, as in their example, but if you have any function calls in it, the complexity and side effects (!) of EVERY function call get triggered. Plus, in that case, you'd be taking and storing the address of a temporary, which is a very very bad idea by itself. So this is a very dangerous class. At most, this can be used to convert the strings into an integer or enum to feed into a real switch that does the actual work. Kevin Kofler From Shawn.Rutledge at theqtcompany.com Mon Dec 7 07:53:12 2015 From: Shawn.Rutledge at theqtcompany.com (Rutledge Shawn) Date: Mon, 7 Dec 2015 06:53:12 +0000 Subject: [Development] Proposal to change connectSlotsByName behavior In-Reply-To: References: Message-ID: <1C052090-08E9-4198-B54B-578F94840870@digia.com> > On 4 Dec 2015, at 09:01, André Somers wrote: > I'd like to add a new alternative (though it does not exclude a change now either): > > - Deprecate the behaviour and remove in Qt 6. > > I have never thought this feature to lead to good design. It makes for "magic" in the sense that it is tricky to trace what happened. It leads to un-Qt-ish naming of methods, and it leads to naming methods based on when they are triggered instead of what they do. I find the latter usually leads to more readable code, more so if there is more than one way to trigger the behaviour encoded in the method. Last, I think private slots (for which this would be most used) are largely on the way out anyway. Trivial slots can be replaced by lambda's and non-trivial ones need a good function name anyway. The main reason I (and probably many others) end up using this feature is because Creator will automatically write the handler for any signal if you right-click on a widget in the designer view and select Go to Slot… So after we’ve decided what the pattern should really be, somebody needs to make Creator do it in the optimal way. Otherwise we are effectively promoting use of this feature. I’ve never used it when writing handlers by hand. From Julius.Bullinger at asctec.de Mon Dec 7 10:06:34 2015 From: Julius.Bullinger at asctec.de (Julius Bullinger) Date: Mon, 7 Dec 2015 09:06:34 +0000 Subject: [Development] New Qt5.6 Beta snapshot available In-Reply-To: References: Message-ID: Von: Development [mailto:development-bounces at qt-project.org] Im Auftrag von Heikkinen Jani Gesendet: Freitag, 4. Dezember 2015 11:43 Uhr An: development at qt-project.org Betreff: [Development] New Qt5.6 Beta snapshot available > Please test the packages & report all findings in Jira. We are trying to get beta out as soon as possible so please inform all new beta blockers to me immediately. With this snapshot, wheel scrolling in Creator is borked on my Win 8.1 64-bit machine. It used to respect system settings (scroll 3 lines), but now it only scrolls a single line. It's fixed in the lastest Qt Creator 3.6 snapshot, I just wanted to give you a heads up. Best regards, Julius -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at theqtcompany.com Mon Dec 7 10:53:06 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Mon, 7 Dec 2015 09:53:06 +0000 Subject: [Development] New Qt5.6 Beta snapshot available In-Reply-To: References: <1697254.9ZveXjKooD@tjmaciei-mobl4> Message-ID: Hi! We will create & release split src packages for beta. But for the snapshots we are offering only combined ones Br, Jani From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Helio Chissini de Castro Sent: 4. joulukuuta 2015 22:38 To: development at qt-project.org Subject: [Development] New Qt5.6 Beta snapshot available Well, i'm not relying anymore on the released sources, i'm generating our test tarballs from git, in the specific case, the 5.6 branch. We complained already, and I decided that not worth wait to have our tasks done. If is too difficult to generate the official splitted tarballs, i can offer as a community member to generate it and provide for Linux distros in the not official basis. Regards, Helio On Fri, Dec 4, 2015, 17:55 Thiago Macieira > wrote: On Friday 04 December 2015 10:42:39 Heikkinen Jani wrote: > We have finally new qt5.6 beta snapshot available > > > Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/278/ > > Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/287/ > > Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/221/ > > Src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ Hi Jani Repeating the request from Linux packagers: they cannot create packages unless we provide the split sources. The split sources are our official release channel, not the big tarball. -- 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 oswald.buddenhagen at theqtcompany.com Mon Dec 7 12:23:41 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Mon, 7 Dec 2015 12:23:41 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512042229.09453.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> <201512041930.10576.marc.mutz@kdab.com> <20151204180651.GA21123@troll08.it.local> <201512042229.09453.marc.mutz@kdab.com> Message-ID: <20151207112341.GC9806@ugly.fritz.box> On Fri, Dec 04, 2015 at 10:29:09PM +0100, Marc Mutz wrote: > On Friday 04 December 2015 19:06:51 Oswald Buddenhagen wrote: > > it's not that anyone is confused, it's that your "aside" was > > inherently flawed: variables in python are dynamically typed, so the > > suggestion that they are "auto" in any way related to c++ makes no > > sense whatsoever. my response aimed merely at showing that even your > > little "joke" was off. > > Again: I was referring to the omission of any form of type name when > declaring variables. That Python is _also_ dynamically typed is > correct, but irrelevant. > then maybe you want to explain how you want to implement auto *everywhere* without going dynamic. until you provide a credible answer to that, your "aside" is patently irrelevant. hint: c# type inference does *not* provide that answer. From marc.mutz at kdab.com Mon Dec 7 14:05:38 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 7 Dec 2015 14:05:38 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <20151207112341.GC9806@ugly.fritz.box> References: <201512031949.46920.marc.mutz@kdab.com> <201512042229.09453.marc.mutz@kdab.com> <20151207112341.GC9806@ugly.fritz.box> Message-ID: <201512071405.38780.marc.mutz@kdab.com> On Monday 07 December 2015 12:23:41 Oswald Buddenhagen wrote: > On Fri, Dec 04, 2015 at 10:29:09PM +0100, Marc Mutz wrote: > > On Friday 04 December 2015 19:06:51 Oswald Buddenhagen wrote: > > > it's not that anyone is confused, it's that your "aside" was > > > inherently flawed: variables in python are dynamically typed, so the > > > suggestion that they are "auto" in any way related to c++ makes no > > > sense whatsoever. my response aimed merely at showing that even your > > > little "joke" was off. > > > > Again: I was referring to the omission of any form of type name when > > declaring variables. That Python is _also_ dynamically typed is > > correct, but irrelevant. > > then maybe you want to explain how you want to implement auto > *everywhere* without going dynamic. until you provide a credible answer > to that, your "aside" is patently irrelevant. hint: c# type inference > does *not* provide that answer. I have explained it as good as I can. If you can or do not want to understand, then I'm sorry that I cannot explain it so you understand. Sorry, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Lars.Knoll at theqtcompany.com Mon Dec 7 13:11:58 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Mon, 7 Dec 2015 12:11:58 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512071405.38780.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> <201512042229.09453.marc.mutz@kdab.com> <20151207112341.GC9806@ugly.fritz.box> <201512071405.38780.marc.mutz@kdab.com> Message-ID: <28A0987F-5167-4362-A44C-D781BC1A9E89@theqtcompany.com> On 07/12/15 14:05, "Development on behalf of Marc Mutz" wrote: >On Monday 07 December 2015 12:23:41 Oswald Buddenhagen wrote: >> On Fri, Dec 04, 2015 at 10:29:09PM +0100, Marc Mutz wrote: >> > On Friday 04 December 2015 19:06:51 Oswald Buddenhagen wrote: >> > > it's not that anyone is confused, it's that your "aside" was >> > > inherently flawed: variables in python are dynamically typed, so the >> > > suggestion that they are "auto" in any way related to c++ makes no >> > > sense whatsoever. my response aimed merely at showing that even your >> > > little "joke" was off. >> > >> > Again: I was referring to the omission of any form of type name when >> > declaring variables. That Python is _also_ dynamically typed is >> > correct, but irrelevant. >> >> then maybe you want to explain how you want to implement auto >> *everywhere* without going dynamic. until you provide a credible answer >> to that, your "aside" is patently irrelevant. hint: c# type inference >> does *not* provide that answer. > >I have explained it as good as I can. If you can or do not want to understand, >then I'm sorry that I cannot explain it so you understand. Auto has nothing to do with anything being dynamically typed, as the type of an auto variable is defined by the way it’s being initialised. So let’s close that part of the discussion. We aren’t loosing static type information/checking just because we start using auto. I am personally not seeing why we need extremely strict and/or detailed rules governing our usage of auto. Basically we should optimise our code for readability. If that makes refactoring easier, it’s an added benefit, but it’s not the primary goal I believe we should aim for. So let's start using auto in all places where it helps readability. I personally think an ‘always use auto’ policy is overdoing it, but I do believe we can be relatively liberal in it’s use without sacrificing readability (and often improving it by doing so). Cheers, Lars From Lars.Knoll at theqtcompany.com Mon Dec 7 13:15:13 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Mon, 7 Dec 2015 12:15:13 +0000 Subject: [Development] RFC: new moc feature In-Reply-To: <201512052137.32784.marc.mutz@kdab.com> References: <5662AEB9.5060705@kdab.com> <201512052006.22869.marc.mutz@kdab.com> <566338FB.5050601@kdab.com> <201512052137.32784.marc.mutz@kdab.com> Message-ID: <0DFE5BBF-C58F-49BD-96A5-28A9F1C0C053@theqtcompany.com> On 05/12/15 21:37, "Development on behalf of Marc Mutz" wrote: >On Saturday 05 December 2015 20:20:27 Sean Harmer wrote: >> I was >> just wondering if we could get it down to the theoretical ideal of a >> single integer comparison mapped into the finite set of strings in use. >> Seems not, without some non-neglible effort. > >man 1 gperf ? Just as a side note: While perf ensures there’s no collisions between valid keys in the hash table, you still end up doing one string comparison in the end to ensure that your input string matches the key. Cheers, Lars From oswald.buddenhagen at theqtcompany.com Mon Dec 7 13:16:14 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Mon, 7 Dec 2015 13:16:14 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512071405.38780.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> <201512042229.09453.marc.mutz@kdab.com> <20151207112341.GC9806@ugly.fritz.box> <201512071405.38780.marc.mutz@kdab.com> Message-ID: <20151207121614.GD9806@ugly.fritz.box> On Mon, Dec 07, 2015 at 02:05:38PM +0100, Marc Mutz wrote: > On Monday 07 December 2015 12:23:41 Oswald Buddenhagen wrote: > > On Fri, Dec 04, 2015 at 10:29:09PM +0100, Marc Mutz wrote: > > > On Friday 04 December 2015 19:06:51 Oswald Buddenhagen wrote: > > > > it's not that anyone is confused, it's that your "aside" was > > > > inherently flawed: variables in python are dynamically typed, so the > > > > suggestion that they are "auto" in any way related to c++ makes no > > > > sense whatsoever. my response aimed merely at showing that even your > > > > little "joke" was off. > > > > > > Again: I was referring to the omission of any form of type name when > > > declaring variables. That Python is _also_ dynamically typed is > > > correct, but irrelevant. > > > > then maybe you want to explain how you want to implement auto > > *everywhere* without going dynamic. until you provide a credible answer > > to that, your "aside" is patently irrelevant. hint: c# type inference > > does *not* provide that answer. > > I have explained it as good as I can. If you can or do not want to understand, > then I'm sorry that I cannot explain it so you understand. > have you considered the possibility that *you* are the one who's not getting the point? you have not provided *any* sensible argument to refute my claim that your analogy is fucked. you just keep repeating the obvious. From Eike.Ziller at theqtcompany.com Mon Dec 7 13:48:58 2015 From: Eike.Ziller at theqtcompany.com (Ziller Eike) Date: Mon, 7 Dec 2015 12:48:58 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <4606126.Pqxnumcx4H@finn> References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> <4606126.Pqxnumcx4H@finn> Message-ID: <04544583-2102-4BE6-8232-D12634E879E7@theqtcompany.com> > On Dec 4, 2015, at 8:01 PM, Olivier Goffart wrote: > > On Friday 4. December 2015 15:39:01 Curtis Mitch wrote: >>> -----Original Message----- >>> From: Development [mailto:development-bounces at qt-project.org] On Behalf Of >>> Olivier Goffart >>> Sent: Friday, 4 December 2015 2:25 PM >>> To: development at qt-project.org >>> Subject: Re: [Development] RFC: more liberal 'auto' rules? >>> >>> On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote: >>>> On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote: >>>>> And as an aside, since it has been mentioned in this thread: in >>>>> Python _all_ variables are 'auto'. All. Without exception. Are >>>>> Python programmers more intelligent? Or do they just tolerate more >>>>> pain? :) >>>> >>>> i'd suggest the latter. >>>> no, really. people use external static checkers because the language >>>> lacks the feature. >>>> the lack of static typing is a common feature of scripting languages >>>> and makes them convenient to a degree, but it is an utter nightmare >>>> for any "real" software development. i really wouldn't want to go there. >>> >>> But auto is still staticaly typed. >>> >>> >>> When you have code like >>> >>> foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type())); >>> >>> You don't see any type. >>> >>> This code that use auto is not less readable. Even if you don't know >>> what's the type of bar without looking it up. >>> >>> auto *bar = foo->bar(); >>> bar->setFaz(m_factory->createFaz(bar->type())); >> >> Isn't this kind of a bad example, because there was no type declared/visible >> in the first place? > > Precisely my point! > There is no type visible before and nobody complains. So why should one > suddenly complains there are no types in the second snippet > >> Anyway, if you're going to take the time to move the result of foo->bar() >> onto its own line, why not just declare a type? What benefit does auto give >> here? >> >> I really dislike hiding types behind a generic keyword. > > Because the type is redundent and it's one reason less to make errors: > Using 'int' instead of 'quint64' or 'size_t', or QString instead of QByteArray > is way to frequent. (and the compiler won't complain) The compiler will then still not complain if you pass that ‘auto’ variable to a function taking ‘int’ (or QString, if you don’t have NO_CAST_...), will it? So in the end people will still just need to know what they are doing, or, since IDE support is mentioned several times in this thread, use an IDE with stricter warning policy. (The default setting for the Clang code model in Qt Creator is to warn when assigning or comparing 'unsigned int' and ‘int' etc ;) ) > It is also refactoring-proof. Because you might want to change the name of > the type from "FazManager" to "FazHolder", and then you need to touch less > code in your refactoring. On the other hand if you are changing the return value of a function, there will be cases where it would be better if you (and anyone using your function) had to explicitly look at the usages. I do not think that more usage of ‘auto’ will make any code (or refactorings of it) ‘safer’. IMO this is only about convenience and readability. Br, Eike From marc.mutz at kdab.com Mon Dec 7 15:28:17 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 7 Dec 2015 15:28:17 +0100 Subject: [Development] RFC: new moc feature In-Reply-To: <0DFE5BBF-C58F-49BD-96A5-28A9F1C0C053@theqtcompany.com> References: <5662AEB9.5060705@kdab.com> <201512052137.32784.marc.mutz@kdab.com> <0DFE5BBF-C58F-49BD-96A5-28A9F1C0C053@theqtcompany.com> Message-ID: <201512071528.18261.marc.mutz@kdab.com> On Monday 07 December 2015 13:15:13 Knoll Lars wrote: > On 05/12/15 21:37, "Development on behalf of Marc Mutz" wrote: > >On Saturday 05 December 2015 20:20:27 Sean Harmer wrote: > >> I was > >> just wondering if we could get it down to the theoretical ideal of a > >> single integer comparison mapped into the finite set of strings in use. > >> Seems not, without some non-neglible effort. > > > >man 1 gperf ? > > Just as a side note: While perf ensures there’s no collisions between valid > keys in the hash table, you still end up doing one string comparison in > the end to ensure that your input string matches the key. As you always must, because every hash function that maps an infinite-domain object such as a string into an object with finite domain (e.g. int) must exhibit collisions which need to be handled by comparing the actual objects. AFAIU, the original idea was to assign an enum value for each unique string (= property = property name) automatically, and use the enums instead of the strings inside the implementation. In that case, the validation would happen at the point of converting the string or whatever is left as a non-ID ID to the enum value, and further code could depend on enum value equality alone. But if you use strings in the implementation, and use the IDs only for quick comparision, you cannot rule out that two properties' IDs collide. The compiler won't help, since in general the collision may not be from objects at the same depth of hierarchy, so the compiler may not see the collision, as the equal values then appear in separate switch statements. But it could be that I misunderstand the situation completely :) Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Mon Dec 7 15:39:25 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 7 Dec 2015 15:39:25 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <20151207121614.GD9806@ugly.fritz.box> References: <201512031949.46920.marc.mutz@kdab.com> <201512071405.38780.marc.mutz@kdab.com> <20151207121614.GD9806@ugly.fritz.box> Message-ID: <201512071539.25531.marc.mutz@kdab.com> On Monday 07 December 2015 13:16:14 Oswald Buddenhagen wrote: > On Mon, Dec 07, 2015 at 02:05:38PM +0100, Marc Mutz wrote: > > On Monday 07 December 2015 12:23:41 Oswald Buddenhagen wrote: > > > On Fri, Dec 04, 2015 at 10:29:09PM +0100, Marc Mutz wrote: > > > > On Friday 04 December 2015 19:06:51 Oswald Buddenhagen wrote: > > > > > it's not that anyone is confused, it's that your "aside" was > > > > > inherently flawed: variables in python are dynamically typed, so > > > > > the suggestion that they are "auto" in any way related to c++ > > > > > makes no sense whatsoever. my response aimed merely at showing > > > > > that even your little "joke" was off. > > > > > > > > Again: I was referring to the omission of any form of type name when > > > > declaring variables. That Python is _also_ dynamically typed is > > > > correct, but irrelevant. > > > > > > then maybe you want to explain how you want to implement auto > > > *everywhere* without going dynamic. until you provide a credible answer > > > to that, your "aside" is patently irrelevant. hint: c# type inference > > > does *not* provide that answer. > > > > I have explained it as good as I can. If you can or do not want to > > understand, then I'm sorry that I cannot explain it so you understand. > > have you considered the possibility that *you* are the one who's not > getting the point? you have not provided *any* sensible argument to > refute my claim that your analogy is fucked. you just keep repeating > the obvious. OK, last try: - auto everywhere in C++ means that the type of the rhs defines the type of the variable - each variable is still statically typed. - In particular, you cannot assign, say, an int to the variable and later assign it a string. - in Python, variables are declared with 'var' (IIRC) - the simiarity with C++ auto is that no type name is visible - this is what I was referring to - the difference to C++ (auto or not) is that in Python, the variable is weakly typed / dynamically typed / duck-typed, however you may want to call it. - in particular, the variable can hold an integer first, then a string, and later an object of class type. Conversely, any type can be held in any variable. - this is orthogonal to the omission of the type name, which C++ auto and the whole thread is all about, thus *completely irrelevant* to the discussion. I, indeed, have no idea why you ride that particular horse so vehemently. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Mon Dec 7 15:44:42 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 7 Dec 2015 15:44:42 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <04544583-2102-4BE6-8232-D12634E879E7@theqtcompany.com> References: <201512031949.46920.marc.mutz@kdab.com> <4606126.Pqxnumcx4H@finn> <04544583-2102-4BE6-8232-D12634E879E7@theqtcompany.com> Message-ID: <201512071544.42707.marc.mutz@kdab.com> On Monday 07 December 2015 13:48:58 Ziller Eike wrote: > I do not think that more usage of ‘auto’ will make any code (or > refactorings of it) ‘safer’. IMO this is only about convenience and > readability. std::map stdMap = ...; for (const std::pair &e : stdMap) doSomething(e.first, e.second); for (const auto &e : stdMap) doSomething(e.first, e.second); The second loop is at least two orders of magnitude faster (doSomething() is an out-of-line no-op). Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From mathias at taschenorakel.de Mon Dec 7 14:39:37 2015 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Mon, 7 Dec 2015 14:39:37 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512071539.25531.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> <201512071405.38780.marc.mutz@kdab.com> <20151207121614.GD9806@ugly.fritz.box> <201512071539.25531.marc.mutz@kdab.com> Message-ID: <56658C19.4040405@taschenorakel.de> Am 07.12.2015 um 15:39 schrieb Marc Mutz: > - auto everywhere in C++ means that the type of the rhs defines the type of the > variable To the extreme of having: auto x = Type { init }; Instead of: Type x(init); ...if you follow Herb Sutter to the extreme[1]. It feels quite extreme in the first moment, but undeniable has some inner logic if you read that article to the end. I am undecided by myself still since that proposal is that extreme. Well, but this could just mean I am getting old and inflexible. [1]: http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/ From Lars.Knoll at theqtcompany.com Mon Dec 7 14:41:00 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Mon, 7 Dec 2015 13:41:00 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512071544.42707.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> <4606126.Pqxnumcx4H@finn> <04544583-2102-4BE6-8232-D12634E879E7@theqtcompany.com> <201512071544.42707.marc.mutz@kdab.com> Message-ID: <1BD99747-4E60-4C76-8612-DE744E1CCA14@theqtcompany.com> On 07/12/15 15:44, "Development on behalf of Marc Mutz" wrote: >On Monday 07 December 2015 13:48:58 Ziller Eike wrote: >> I do not think that more usage of ‘auto’ will make any code (or >> refactorings of it) ‘safer’. IMO this is only about convenience and >> readability. > > std::map stdMap = ...; > > for (const std::pair &e : stdMap) > doSomething(e.first, e.second); > > for (const auto &e : stdMap) > doSomething(e.first, e.second); > >The second loop is at least two orders of magnitude faster (doSomething() is >an out-of-line no-op). I think the summary here is that auto gives you one guarantee: It won’t do an implicit conversion for the initial assignment. Cheers, Lars From mwoehlke.floss at gmail.com Mon Dec 7 16:08:34 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 07 Dec 2015 10:08:34 -0500 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <20151205004445.GA2766@klara.mpi.htwm.de> References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> <4606126.Pqxnumcx4H@finn> <20151204203516.GA2407@klara.mpi.htwm.de> <20151204224303.GA2648@klara.mpi.htwm.de> <20151205004445.GA2766@klara.mpi.htwm.de> Message-ID: On 2015-12-04 19:44, André Pönitz wrote: > You don't know whether operator[] or .at() is the best way to access > by index until you know the type of list. Once you know the type of > list, you also know what the type of i should be. There's no point > in being fuzzy about it unless there is a *significant* advantage > to it (like using 'auto' for iterator types which are mostly line > noise). Then there is also no significant advantage to writing an explicit type rather than inferring it. You can't have it both ways. > The context of this discussion is the development of Qt. Thank you for > confirming that 'int' is the right thing to use. The correct *actual* type is 'int'. Whether Qt should encourage bad programming practices by writing explicitly typed index loops, that are more often wrong than otherwise outside of Qt containers, is a different question. > [ > If you care about size() re-evaluation: > > for (int i = 0, n = list.size(); i < n; ++i) > ... > ] ...and now 'n' is mutable, opening the door to bugs due to accidental modification thereof. (As is 'i', for that matter; a range-based for over an index enumerator¹ allows you to make that const also.) (¹ English-language sense, not C++ "enum".) > On Fri, Dec 04, 2015 at 06:10:45PM -0500, Matthew Woehlke wrote: >> On 2015-12-04 17:43, André Pönitz wrote: >>> In any case, this is an uncommon pattern, using some unknown qtIndexRange() >>> function. >> >> Really? >> >> (Python) > > Please stay on topic. The topic was whether to be more 'liberal' with > the use of auto in Qt, written mostly in C++, not Python. The point is that index enumerators are *not* an unknown programming construct, as you assert. >>> The extra level of parantheses makes it harder to parse for >>> humans,introducing an aditional source of errors, which you nicely >>> demonstrated by making the example non-compilable. >> >> Bah. A decent IDE would have flagged that as soon as I stopped typing. > > You are basically assuming that there's no need for you to write sane > code to start with because during your development work you have a > decent IDE to help you out. This assumption is wrong, independent > of the existence of such an IDE. Uh... no? The point is your bashing a particular construct because it can be mistyped *in the pitiful excuse for a text editor with which I'm writing this message*, but will be easily and immediately noticed in a decent editor, is silly. Or, maybe we should stop using C++ because of all those pesky ';'s one has to remember at the end of every statement. > Since the discussion here is about what to use in Qt, the whole Qt > development workflow matters. A lot of Qt code reading happens on Gerrit > without IDE features at hand. The context there usually just a few lines. > The appropriateness of an expression 'list[x]' is impossible to judge > on Gerrit after applying an 'Almost always auto' policy. Well, then, I guess you can't judge if 'int' is the correct type for 'x', either. Sounds like an excellent reason *to* use 'auto'!!! Anyway, if you're going to bash a feature, you need to find a better reason than obvious compile errors that are flagged in the user's editor. Because the chances of those ever being committed locally, much less merged (or indeed, even lasting more than a few seconds) are virtually nil. -- Matthew From mwoehlke.floss at gmail.com Mon Dec 7 16:15:49 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 07 Dec 2015 10:15:49 -0500 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <1449313718.2486.158.camel@nmc-company.com> References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> <4606126.Pqxnumcx4H@finn> <20151204203516.GA2407@klara.mpi.htwm.de> <20151204224303.GA2648@klara.mpi.htwm.de> <1449313718.2486.158.camel@nmc-company.com> Message-ID: On 2015-12-05 06:08, Julien Blanc wrote: > Am I the only one to think that this example is inherently broken ? I > mean, why wouldn’t any sane person write : > > for(auto const& element : list) > foo(element) If you don't actually *need* the index, then yes. "Broken" might be strong, but yes, the example is somewhat lacking. A better example would be: foo(i, list[i]); (And yes, if you don't need the index, *please do* iterate over the elements directly!) > On 2015-12-03 13:49, Marc Mutz wrote: >> - all loop variables (both index and iterators) >> the reason being that spelling out the name is usually wrong: >> size_t i = stdVector.size() // wrong, should be >> std::vector::size_type... >> also helps when porting from Qt containers to STL ones > > That looks perfectly fine for me. Index based loops should be avoided > whenever it is possible, and for iterator based loops auto makes no harm > (seriously, who wants to write > std::vector::const_iterator instead of auto ?). Agreed. But the above started with objections to using 'auto' for indexed iteration :-). -- Matthew From mwoehlke.floss at gmail.com Mon Dec 7 16:22:01 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 07 Dec 2015 10:22:01 -0500 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <04544583-2102-4BE6-8232-D12634E879E7@theqtcompany.com> References: <201512031949.46920.marc.mutz@kdab.com> <4076201.l6MBBoA0kT@finn> <4606126.Pqxnumcx4H@finn> <04544583-2102-4BE6-8232-D12634E879E7@theqtcompany.com> Message-ID: On 2015-12-07 07:48, Ziller Eike wrote: > On Dec 4, 2015, at 8:01 PM, Olivier Goffart wrote: >> Because the type is redundent and it's one reason less to make errors: >> Using 'int' instead of 'quint64' or 'size_t', or QString instead of QByteArray >> is way to frequent. (and the compiler won't complain) > > The compiler will then still not complain if you pass that ‘auto’ > variable to a function taking ‘int’ (or QString, if you don’t have > NO_CAST_...), will it? ...it won't complain any *less* than if you'd done the cast in an assignment. But it *might* complain, e.g. if you use the auto in an initializer list that results in narrowing. Or it might call an appropriate function overload for the larger type. At worst, is equally dangerous. But in some cases it will be less dangerous. Another argument is that the correct way to use 'int' is: auto i = int{list.size()}; ...which will fail to compile if a narrowing conversion occurs. (Or if you're *truly* paranoid, use 'auto' and then static_assert the actual resulting type.) -- Matthew From marc.mutz at kdab.com Mon Dec 7 17:42:50 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 7 Dec 2015 17:42:50 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <1BD99747-4E60-4C76-8612-DE744E1CCA14@theqtcompany.com> References: <201512031949.46920.marc.mutz@kdab.com> <201512071544.42707.marc.mutz@kdab.com> <1BD99747-4E60-4C76-8612-DE744E1CCA14@theqtcompany.com> Message-ID: <201512071742.50563.marc.mutz@kdab.com> On Monday 07 December 2015 14:41:00 Knoll Lars wrote: > On 07/12/15 15:44, "Development on behalf of Marc Mutz" wrote: > >On Monday 07 December 2015 13:48:58 Ziller Eike wrote: > >> I do not think that more usage of ‘auto’ will make any code (or > >> refactorings of it) ‘safer’. IMO this is only about convenience and > >> readability. > >> > > std::map stdMap = ...; > > > > for (const std::pair &e : stdMap) > > > > doSomething(e.first, e.second); > > > > for (const auto &e : stdMap) > > > > doSomething(e.first, e.second); > > > >The second loop is at least two orders of magnitude faster (doSomething() > >is an out-of-line no-op). > > I think the summary here is that auto gives you one guarantee: It won’t do > an implicit conversion for the initial assignment. Correct. The first line is missing the const in the pair's first type, thus forces an implicit conversion to the declared type (the const-& conveniently extending the lifetime of the temporary so everything appears to work, execept you're deep-copying two std::strings now). -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From mwoehlke.floss at gmail.com Mon Dec 7 16:34:06 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 07 Dec 2015 10:34:06 -0500 Subject: [Development] RFC: new moc feature In-Reply-To: <5662D1EC.305@kdab.com> References: <5662AEB9.5060705@kdab.com> <2280029.KrAAQK5H7f@finn> <5662D1EC.305@kdab.com> Message-ID: On 2015-12-05 07:00, Sean Harmer wrote: > No idea if all of our > supported compilers allow hooking in custom preprocessors or not. Okay, that sentence just scares the pants off me... forget whether or not the *compilers* support it; what about the build systems? Not everyone uses qmake. At minimum you'll want/need to support CMake as well. -- Matthew From marc.mutz at kdab.com Mon Dec 7 17:50:41 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 7 Dec 2015 17:50:41 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512031949.46920.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> Message-ID: <201512071750.41760.marc.mutz@kdab.com> On Thursday 03 December 2015 19:49:46 Marc Mutz wrote: > The remainder of the C++ world is moving towards an "always auto" scheme. > We don't need to go there, but I'd at least like to propose, for new code > and as a drive-by, the required use of auto for: > > - template code (esp., but not necessarily only, when the type name would > require the use of 'typename') > - all loop variables (both index and iterators) > the reason being that spelling out the name is usually wrong: > size_t i = stdVector.size() // wrong, should be std::vector::size_type... > also helps when porting from Qt containers to STL ones > - all references to elements in a collection (same problem - way too easy > to misspell std::pair for std::pair...) Let me extend that: - whenever possible when declaring a QList It seems like we all agree that QList as-is will not be in Qt 6[1]. To me, it sounds prudent to anticipate that and to hold QList (whereever possible) in auto variables only, so they port themselves automatically (no pun intended) to, say, QVector, std::vector, or QArrayList. [1] Before you flame again: Independant of the exit strategy, it should be consensus that the *name* QList will only exist as a porting vehicle (deprecated class or deprecated template alias or something entirely different). Whether the actual implementation lives on as QArrayList (say) is orthogonal to that. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Mon Dec 7 17:28:53 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 07 Dec 2015 08:28:53 -0800 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512071742.50563.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> <1BD99747-4E60-4C76-8612-DE744E1CCA14@theqtcompany.com> <201512071742.50563.marc.mutz@kdab.com> Message-ID: <2577123.yGTkY66psy@tjmaciei-mobl4> On Monday 07 December 2015 17:42:50 Marc Mutz wrote: > > > std::map stdMap = ...; > > > > > > for (const std::pair &e : stdMap) > > > > > > doSomething(e.first, e.second); > > > > > > for (const auto &e : stdMap) > > > > > > doSomething(e.first, e.second); > > > > > >The second loop is at least two orders of magnitude faster (doSomething() > > >is an out-of-line no-op). > > > > I think the summary here is that auto gives you one guarantee: It won’t do > > an implicit conversion for the initial assignment. > > Correct. The first line is missing the const in the pair's first type, thus > forces an implicit conversion to the declared type (the const-& conveniently > extending the lifetime of the temporary so everything appears to work, > execept you're deep-copying two std::strings now). What const is missing? Are you saying it should have been for (const std::pair &e: stdMap) If so, I consider that an API defect in std::map or an implementation defect in std::string in the first place. It wouldn't cause a magnitude of performance difference if they were implicitly shared, like QString. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Dec 7 17:30:52 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 07 Dec 2015 08:30:52 -0800 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512071750.41760.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> <201512071750.41760.marc.mutz@kdab.com> Message-ID: <1648647.X0R15G2neB@tjmaciei-mobl4> On Monday 07 December 2015 17:50:41 Marc Mutz wrote: > [1] Before you flame again: Independant of the exit strategy, it should be > consensus that the *name* QList will only exist as a porting vehicle > (deprecated class or deprecated template alias or something entirely > different). Whether the actual implementation lives on as QArrayList (say) > is orthogonal to that. Yes, we are in agreement. There will be a "QList" in Qt 6, but not with its current memory layout. How we'll implement it, that's a discussion for another day. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Mon Dec 7 19:00:23 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 7 Dec 2015 19:00:23 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <2577123.yGTkY66psy@tjmaciei-mobl4> References: <201512031949.46920.marc.mutz@kdab.com> <201512071742.50563.marc.mutz@kdab.com> <2577123.yGTkY66psy@tjmaciei-mobl4> Message-ID: <201512071900.24091.marc.mutz@kdab.com> On Monday 07 December 2015 17:28:53 Thiago Macieira wrote: > On Monday 07 December 2015 17:42:50 Marc Mutz wrote: > > > > std::map stdMap = ...; > > > > > > > > for (const std::pair &e : stdMap) > > > > > > > > doSomething(e.first, e.second); > > > > > > > > for (const auto &e : stdMap) > > > > > > > > doSomething(e.first, e.second); > > > > > > > >The second loop is at least two orders of magnitude faster > > > >(doSomething() is an out-of-line no-op). > > > > > > I think the summary here is that auto gives you one guarantee: It won’t > > > do an implicit conversion for the initial assignment. > > > > Correct. The first line is missing the const in the pair's first type, > > thus forces an implicit conversion to the declared type (the const-& > > conveniently extending the lifetime of the temporary so everything > > appears to work, execept you're deep-copying two std::strings now). > > What const is missing? Are you saying it should have been > > for (const std::pair &e: stdMap) Yes. > If so, I consider that an API defect in std::map or an implementation > defect in std::string in the first place. It is not an API defect, it is necessary to preserve class invariants (maintain sort order). > It wouldn't cause a magnitude of > performance difference if they were implicitly shared, like QString. No comment... Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From olivier at woboq.com Mon Dec 7 17:53:41 2015 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 07 Dec 2015 17:53:41 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <2577123.yGTkY66psy@tjmaciei-mobl4> References: <201512031949.46920.marc.mutz@kdab.com> <201512071742.50563.marc.mutz@kdab.com> <2577123.yGTkY66psy@tjmaciei-mobl4> Message-ID: <1631034.XHHqZUFP1f@finn> On Monday 7. December 2015 08:28:53 Thiago Macieira wrote: > What const is missing? Are you saying it should have been > > for (const std::pair &e: stdMap) Yes. The value_type of a std::map is std::pair. It allows to do this: // add "foobar" to all the entries for (auto &e: stdMap) e.second += "foobar"; But it does not allow to change the key because that cannot be changed via an iterator. > If so, I consider that an API defect in std::map Quite the contrary. > or an implementation defect in std::string in the first place. It wouldn't > cause a magnitude of performance difference if they were implicitly shared, > like QString. That's another issue. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From thiago.macieira at intel.com Mon Dec 7 18:04:00 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 07 Dec 2015 09:04 -0800 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <1631034.XHHqZUFP1f@finn> References: <201512031949.46920.marc.mutz@kdab.com> <2577123.yGTkY66psy@tjmaciei-mobl4> <1631034.XHHqZUFP1f@finn> Message-ID: <15106118.0aT8ZIeB8J@tjmaciei-mobl4> On Monday 07 December 2015 17:53:41 Olivier Goffart wrote: > On Monday 7. December 2015 08:28:53 Thiago Macieira wrote: > > What const is missing? Are you saying it should have been > > > > for (const std::pair &e: stdMap) > > Yes. > > The value_type of a std::map is std::pair. > > It allows to do this: > > // add "foobar" to all the entries > for (auto &e: stdMap) > e.second += "foobar"; > > But it does not allow to change the key because that cannot be changed via > an iterator. Ah, right, this is a *mutating* iterator. Sorry, I missed that fact. I was thinking of the usual read-only iteration that we get from foreach. Mutating with a range for is something I've never done. > > If so, I consider that an API defect in std::map > > Quite the contrary. I stand corrected. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sean.harmer at kdab.com Mon Dec 7 19:46:05 2015 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 7 Dec 2015 18:46:05 +0000 Subject: [Development] RFC: new moc feature In-Reply-To: References: <5662AEB9.5060705@kdab.com> <2280029.KrAAQK5H7f@finn> <5662D1EC.305@kdab.com> Message-ID: <5665D3ED.5030609@kdab.com> On 07/12/2015 15:34, Matthew Woehlke wrote: > On 2015-12-05 07:00, Sean Harmer wrote: >> No idea if all of our >> supported compilers allow hooking in custom preprocessors or not. > Okay, that sentence just scares the pants off me... forget whether or > not the *compilers* support it; what about the build systems? Not > everyone uses qmake. At minimum you'll want/need to support CMake as well. > Right after investigating a little more, doing it via the build system is better. I have too much on right now to actually implement this but may get back to it at some point if benchmarks still highlight this type of code as being a problem. 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 Eike.Ziller at theqtcompany.com Tue Dec 8 10:46:21 2015 From: Eike.Ziller at theqtcompany.com (Ziller Eike) Date: Tue, 8 Dec 2015 09:46:21 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <1BD99747-4E60-4C76-8612-DE744E1CCA14@theqtcompany.com> References: <201512031949.46920.marc.mutz@kdab.com> <4606126.Pqxnumcx4H@finn> <04544583-2102-4BE6-8232-D12634E879E7@theqtcompany.com> <201512071544.42707.marc.mutz@kdab.com> <1BD99747-4E60-4C76-8612-DE744E1CCA14@theqtcompany.com> Message-ID: <592A0CC7-1F6F-4F31-8B91-BF1C17D78796@theqtcompany.com> > On Dec 7, 2015, at 2:41 PM, Knoll Lars wrote: > > On 07/12/15 15:44, "Development on behalf of Marc Mutz" wrote: > > > >> On Monday 07 December 2015 13:48:58 Ziller Eike wrote: >>> I do not think that more usage of ‘auto’ will make any code (or >>> refactorings of it) ‘safer’. IMO this is only about convenience and >>> readability. >> >> std::map stdMap = ...; >> >> for (const std::pair &e : stdMap) >> doSomething(e.first, e.second); >> >> for (const auto &e : stdMap) >> doSomething(e.first, e.second); >> >> The second loop is at least two orders of magnitude faster (doSomething() is >> an out-of-line no-op). > > I think the summary here is that auto gives you one guarantee: It won’t do an implicit conversion for the initial assignment. Granted. I really wonder though, why it is possible to assign the wrong type to a _reference_ here, even if it is const ? I cannot do that with e.g. a std::vector (std::vector v; const std::vector &v2 = v;), so is that some funny thing with std::pair? The spirit of the “you can use auto when assigning iterator type” was to mean “you can use auto when assigning long ugly template types” at least in case of ‘known patterns' (of which we do not have too many in Qt API, therefore iterator types). So I think this use of auto is covered by the “spirit” of the rule. Br, Eike From giuseppe.dangelo at kdab.com Tue Dec 8 10:54:00 2015 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Tue, 8 Dec 2015 10:54:00 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <592A0CC7-1F6F-4F31-8B91-BF1C17D78796@theqtcompany.com> References: <201512031949.46920.marc.mutz@kdab.com> <4606126.Pqxnumcx4H@finn> <04544583-2102-4BE6-8232-D12634E879E7@theqtcompany.com> <201512071544.42707.marc.mutz@kdab.com> <1BD99747-4E60-4C76-8612-DE744E1CCA14@theqtcompany.com> <592A0CC7-1F6F-4F31-8B91-BF1C17D78796@theqtcompany.com> Message-ID: <5666A8B8.3030906@kdab.com> Il 08/12/2015 10:46, Ziller Eike ha scritto: > I really wonder though, why it is possible to assign the wrong type to a_reference_ here, even if it is const ? > I cannot do that with e.g. a std::vector (std::vector v; const std::vector &v2 = v;), so is that some funny thing with std::pair? Just that std::pair has a constructor performing implicit conversions from another pair's types, see the constructors 4/5 > http://en.cppreference.com/w/cpp/utility/pair/pair Those conversions silently succeed and kaboom, you're deep copying std::strings... Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4068 bytes Desc: Firma crittografica S/MIME URL: From oswald.buddenhagen at theqtcompany.com Tue Dec 8 15:52:06 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Tue, 8 Dec 2015 15:52:06 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512071539.25531.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> <201512071405.38780.marc.mutz@kdab.com> <20151207121614.GD9806@ugly.fritz.box> <201512071539.25531.marc.mutz@kdab.com> Message-ID: <20151208145206.GA3387@ugly.fritz.box> On Mon, Dec 07, 2015 at 03:39:25PM +0100, Marc Mutz wrote: > OK, last try: > > - auto everywhere in C++ means that the type of the rhs defines the > type of the variable > it starts with the fact that you didn't specify that you mean just local variables - it's your unstated assumption. your triple emphasis that it's not necessary *anywhere* in python implied that you do indeed mean more than just locals. > - each variable is still statically typed. > - In particular, you cannot assign, say, an int to the variable and later > assign it a string. > - in Python, variables are declared with 'var' (IIRC) > well, wrong. in python, you don't explicitly declare variables *at all*. you only ever assign them. just so. "var" is c#'s auto. or js' variant (aka c#'s "dynamic"). these are actually the two opposite concepts, so maybe you're the one who's confused? ;) > - the simiarity with C++ auto is that no type name is visible > - this is what I was referring to > - the difference to C++ (auto or not) is that in Python, the variable is weakly > typed / dynamically typed / duck-typed, however you may want to call it. > - in particular, the variable can hold an integer first, then a string, and > later an object of class type. Conversely, any type can be held in any > variable. > - this is orthogonal to the omission of the type name, which C++ auto and > the whole thread is all about, thus *completely irrelevant* to the > discussion. > no, it's actually not orthogonal, and that's the whole point. in the generic case, it's impossible to implement "auto *everywhere*" without going dynamic. this is such a fundamental property of the language, that it is patently absurd to infer anything from it for statically typed languages, especially if you look at just one particular case. > I, indeed, have no idea why you ride that particular horse so > vehemently. > so let's state the purpose even more clearly: i'm giving you a lesson. you tried to prove your point with a bogus analogy, and screwed up even more by underestimating the downsides of the paradigm you were comparing to. just admit it, and we're done - i'm actually convinced by your non-bogus arguments. From mwoehlke.floss at gmail.com Tue Dec 8 16:53:41 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 08 Dec 2015 10:53:41 -0500 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <20151208145206.GA3387@ugly.fritz.box> References: <201512031949.46920.marc.mutz@kdab.com> <201512071405.38780.marc.mutz@kdab.com> <20151207121614.GD9806@ugly.fritz.box> <201512071539.25531.marc.mutz@kdab.com> <20151208145206.GA3387@ugly.fritz.box> Message-ID: On 2015-12-08 09:52, Oswald Buddenhagen wrote: > On Mon, Dec 07, 2015 at 03:39:25PM +0100, Marc Mutz wrote: >> - auto everywhere in C++ means that the type of the rhs defines the >> type of the variable > > it starts with the fact that you didn't specify that you mean just local > variables - it's your unstated assumption. your triple emphasis that > it's not necessary *anywhere* in python implied that you do indeed mean > more than just locals. Any variable definitions, actually... not just local, but also member (static or otherwise) and global. Although IME, AAA is not pushed so much for other than local variables. (Also, 'auto' for NSDM's requires compiler support for default initializers, which is less widely available than 'auto' itself.) >> - the simiarity with C++ auto is that no type name is visible >> - this is what I was referring to >> - the difference to C++ (auto or not) is that in Python, the variable is weakly >> typed / dynamically typed / duck-typed, however you may want to call it. >> - in particular, the variable can hold an integer first, then a string, and >> later an object of class type. Conversely, any type can be held in any >> variable. >> >> - this is orthogonal to the omission of the type name, which C++ auto and >> the whole thread is all about, thus *completely irrelevant* to the >> discussion. > > no, it's actually not orthogonal, and that's the whole point. in the > generic case, it's impossible to implement "auto *everywhere*" without > going dynamic. To be clear, the "everywhere" here is limited to variable declarations. (Which must be definitions. Which is one of the objectives of AAA; it prevents uninitialized variables.) Function/method parameters are specifically excluded. (Although using 'auto' there - which C++ is actually moving to allow, although I'm not necessarily thrilled by such - is still not dynamic typing; rather, it is implicit templatization. There are some possible benefits to this, along the lines of AAA, but overall there are many more drawbacks.) -- Matthew From marc.mutz at kdab.com Tue Dec 8 20:43:53 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 8 Dec 2015 20:43:53 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <20151208145206.GA3387@ugly.fritz.box> References: <201512031949.46920.marc.mutz@kdab.com> <201512071539.25531.marc.mutz@kdab.com> <20151208145206.GA3387@ugly.fritz.box> Message-ID: <201512082043.54043.marc.mutz@kdab.com> On Tuesday 08 December 2015 15:52:06 Oswald Buddenhagen wrote: > On Mon, Dec 07, 2015 at 03:39:25PM +0100, Marc Mutz wrote: > > OK, last try: > > > > - auto everywhere in C++ means that the type of the rhs defines the > > type of the variable > > it starts with the fact that you didn't specify that you mean just local > variables - it's your unstated assumption. Wrong. This whole thread was never about anything but auto variables: On Thursday 03 December 2015 19:49:46 Marc Mutz wrote: > The wiki[1] currently contains some rules for how to use automatic type > deduction for variables (Q_C_AUTO_TYPE) that are very restrictive. > your triple emphasis that > it's not necessary *anywhere* in python implied that you do indeed mean > more than just locals. Only for someone who chimes in on a side-line without having read the thread's first mail... > > - each variable is still statically typed. > > - In particular, you cannot assign, say, an int to the variable and later > > > > assign it a string. > > > > - in Python, variables are declared with 'var' (IIRC) > > well, wrong. in python, you don't explicitly declare variables *at all*. > you only ever assign them. just so. > > "var" is c#'s auto. or js' variant (aka c#'s "dynamic"). these are > actually the two opposite concepts, so maybe you're the one who's > confused? ;) I don't *care* whether it's "var" or no keyword or JS variant or _whatever_. I said it's about the omission of the _type name_. You deliberately misunderstand and drag this subthread on and then zoom in on the first slip of mine. That's trolling at it's worst. > > - the simiarity with C++ auto is that no type name is visible > > > > - this is what I was referring to > > > > - the difference to C++ (auto or not) is that in Python, the variable is > > weakly > > > > typed / dynamically typed / duck-typed, however you may want to call > > it. > > > > - in particular, the variable can hold an integer first, then a string, > > and > > > > later an object of class type. Conversely, any type can be held in any > > variable. > > > > - this is orthogonal to the omission of the type name, which C++ auto > > and > > > > the whole thread is all about, thus *completely irrelevant* to the > > discussion. > > no, it's actually not orthogonal, and that's the whole point. in the > generic case, it's impossible to implement "auto *everywhere*" without > going dynamic. this is such a fundamental property of the language, that > it is patently absurd to infer anything from it for statically typed > languages, especially if you look at just one particular case. > > > I, indeed, have no idea why you ride that particular horse so > > vehemently. > > so let's state the purpose even more clearly: i'm giving you a lesson. > you tried to prove your point with a bogus analogy, and screwed up even > more by underestimating the downsides of the paradigm you were comparing > to. just admit it, and we're done - i'm actually convinced by your > non-bogus arguments. I should have known.... tr(Besserwisser). Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From rjvbertin at gmail.com Tue Dec 8 21:38:10 2015 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Tue, 08 Dec 2015 21:38:10 +0100 Subject: [Development] [OS X]: native classes (widgets) used for QTabBar and QTabWidget? References: <2063068.e6xtoLpgx3@portia.local> <1514935.9Q06xFpApu@finn> Message-ID: <30229862.UKJP5bEaWm@patux.local> Olivier Goffart wrote: Hi, > QWidgets (and QML) don't use native UI views. They draw everything themself. > The drawing is done in the style (qmacstyle_mac.mm in this case) > > So to repeat: > QTabBar::paintEvent asks the style to paint the tabs > QMacStyle::drawControl (see the case CE_TabBarTabShape) draws it. > Apparently it's using HIThemeTabDrawInfo and HIThemeDrawTab. If I may, do you also know how it is determined whether or not push buttons should show icons or not? There's no equivalent to Qt::AA_DontShowIconsInMenus and I'm also trying to understand why certain KF5 applications (using kdelibs4support) always show icons in buttons when the KdePlatformTheme is used (on Mac and Linux), but not when the native Mac style is used. It's not directly caused by KdePlatformTheme, because otherwise all applications using it would always show icons in buttons, which is not the case (and the theme actually sets a theme hint which should lead to disabling the icon display). Thanks, R. From olivier at woboq.com Tue Dec 8 22:03:06 2015 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 08 Dec 2015 22:03:06 +0100 Subject: [Development] [OS X]: native classes (widgets) used for QTabBar and QTabWidget? In-Reply-To: <30229862.UKJP5bEaWm@patux.local> References: <2063068.e6xtoLpgx3@portia.local> <1514935.9Q06xFpApu@finn> <30229862.UKJP5bEaWm@patux.local> Message-ID: <2721025.pAapW6Em4q@finn> On Tuesday 8. December 2015 21:38:10 René J. V. Bertin wrote: > If I may, do you also know how it is determined whether or not push buttons > should show icons or not? There's no equivalent to > Qt::AA_DontShowIconsInMenus and I'm also trying to understand why certain > KF5 applications (using kdelibs4support) always show icons in buttons when > the KdePlatformTheme is used (on Mac and Linux), but not when the native > Mac style is used. It's not directly caused by KdePlatformTheme, because > otherwise all applications using it would always show icons in buttons, > which is not the case (and the theme actually sets a theme hint which > should lead to disabling the icon display). I believe you are looking for QStyle::SH_DialogButtonBox_ButtonsHaveIcons, which is false for mac. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From marc.mutz at kdab.com Wed Dec 9 11:54:54 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 9 Dec 2015 11:54:54 +0100 Subject: [Development] toLower() vs. toCaseFolded() Message-ID: <201512091154.55089.marc.mutz@kdab.com> Hi, http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what case folding actually _is_ and how it's different from toLower(). Can someone please tell me the difference and why toCaseFolded() exists in the first place? Is it faster? Is it guaranteed to not make the string longer/shorter? Preferably answer by updating the docs to be a bit more descriptive. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From me at the-compiler.org Wed Dec 9 10:57:21 2015 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 9 Dec 2015 10:57:21 +0100 Subject: [Development] toLower() vs. toCaseFolded() In-Reply-To: <201512091154.55089.marc.mutz@kdab.com> References: <201512091154.55089.marc.mutz@kdab.com> Message-ID: <20151209095721.GQ5582@tonks> * Marc Mutz [2015-12-09 11:54:54 +0100]: > Hi, > > http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what case > folding actually _is_ and how it's different from toLower(). > > Can someone please tell me the difference and why toCaseFolded() exists in the > first place? Is it faster? Is it guaranteed to not make the string > longer/shorter? Maybe http://www.w3.org/International/wiki/Case_folding helps? Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From oswald.buddenhagen at theqtcompany.com Wed Dec 9 11:00:48 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Wed, 9 Dec 2015 11:00:48 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512082043.54043.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> <201512071539.25531.marc.mutz@kdab.com> <20151208145206.GA3387@ugly.fritz.box> <201512082043.54043.marc.mutz@kdab.com> Message-ID: <20151209100048.GA29009@troll08.it.local> On Tue, Dec 08, 2015 at 08:43:53PM +0100, Marc Mutz wrote: > On Tuesday 08 December 2015 15:52:06 Oswald Buddenhagen wrote: > > your triple emphasis that it's not necessary *anywhere* in python > > implied that you do indeed mean more than just locals. > > Only for someone who chimes in on a side-line without having read the > thread's first mail... > actually, it's quite reasonable to take someone by their word when they make such an effort to emphasize it without further qualification. > I don't *care* whether it's "var" or no keyword or JS variant or > _whatever_. I said it's about the omission of the _type name_. > you're still not getting it. python's property of omitting the type name is *inherently* linked to it being dynamic. it's *meaningless* to compare the two. you're essentially arguing that auto is *just* like QVariant because it shares some of the visible properties. how is that an argument for *anything*? > You deliberately misunderstand and drag this subthread on and then > zoom in on the first slip of mine. That's trolling at it's worst. > i didn't misunderstand anything (deliberately or not), and didn't present it as such, either. all i did was pointing out that the analogy wasn't that apt, and that your "joke" actually backfired. *you* dragged it out by deciding to treat me like an idiot instead of trying to understand and acknowledge the point (however trivial you may find it). > > so let's state the purpose even more clearly: i'm giving you a lesson. > > I should have known.... tr(Besserwisser). > i'm sure the irony of *you* saying that is momentarily lost on you. From marc.mutz at kdab.com Wed Dec 9 12:20:36 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 9 Dec 2015 12:20:36 +0100 Subject: [Development] toLower() vs. toCaseFolded() In-Reply-To: <20151209095721.GQ5582@tonks> References: <201512091154.55089.marc.mutz@kdab.com> <20151209095721.GQ5582@tonks> Message-ID: <201512091220.37163.marc.mutz@kdab.com> On Wednesday 09 December 2015 10:57:21 Florian Bruhin wrote: > * Marc Mutz [2015-12-09 11:54:54 +0100]: > > Hi, > > > > http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what > > case folding actually _is_ and how it's different from toLower(). > > > > Can someone please tell me the difference and why toCaseFolded() exists > > in the first place? Is it faster? Is it guaranteed to not make the > > string longer/shorter? > > Maybe http://www.w3.org/International/wiki/Case_folding helps? Not really. Neither does it patch our docs... :) -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Lars.Knoll at theqtcompany.com Wed Dec 9 11:16:56 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Wed, 9 Dec 2015 10:16:56 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <20151209100048.GA29009@troll08.it.local> References: <201512031949.46920.marc.mutz@kdab.com> <201512071539.25531.marc.mutz@kdab.com> <20151208145206.GA3387@ugly.fritz.box> <201512082043.54043.marc.mutz@kdab.com> <20151209100048.GA29009@troll08.it.local> Message-ID: On 09/12/15 11:00, "Development on behalf of Oswald Buddenhagen" wrote: >On Tue, Dec 08, 2015 at 08:43:53PM +0100, Marc Mutz wrote: >> On Tuesday 08 December 2015 15:52:06 Oswald Buddenhagen wrote: >> > your triple emphasis that it's not necessary *anywhere* in python >> > implied that you do indeed mean more than just locals. >> >> Only for someone who chimes in on a side-line without having read the >> thread's first mail... >> >actually, it's quite reasonable to take someone by their word when they >make such an effort to emphasize it without further qualification. > >> I don't *care* whether it's "var" or no keyword or JS variant or >> _whatever_. I said it's about the omission of the _type name_. >> >you're still not getting it. python's property of omitting the type name >is *inherently* linked to it being dynamic. it's *meaningless* to >compare the two. you're essentially arguing that auto is *just* like >QVariant because it shares some of the visible properties. how is that >an argument for *anything*? > >> You deliberately misunderstand and drag this subthread on and then >> zoom in on the first slip of mine. That's trolling at it's worst. >> >i didn't misunderstand anything (deliberately or not), and didn't >present it as such, either. all i did was pointing out that the analogy >wasn't that apt, and that your "joke" actually backfired. *you* dragged >it out by deciding to treat me like an idiot instead of trying to >understand and acknowledge the point (however trivial you may find it). > >> > so let's state the purpose even more clearly: i'm giving you a lesson. >> >> I should have known.... tr(Besserwisser). >> >i'm sure the irony of *you* saying that is momentarily lost on you. And I’d say it’s about time to stop that particular sub-thread. It’s neither productive nor leading anywhere. Thanks, Lars From gmaxera at gmail.com Wed Dec 9 11:17:15 2015 From: gmaxera at gmail.com (Gian Maxera) Date: Wed, 9 Dec 2015 10:17:15 +0000 Subject: [Development] toLower() vs. toCaseFolded() In-Reply-To: <201512091220.37163.marc.mutz@kdab.com> References: <201512091154.55089.marc.mutz@kdab.com> <20151209095721.GQ5582@tonks> <201512091220.37163.marc.mutz@kdab.com> Message-ID: Hello Marc, I think the answer is into this Wikipedia page: http://www.w3.org/International/wiki/Case_folding As you can notice, case folding in languages different from English can be more difficult than just lowering the characters. So, I suppose (it’s only my guess), that the toLower just lower all characters without taking into account the correct language rules while toCaseFolded take into account language. Ciao, Gianluca. > On 9 Dec 2015, at 11:20, Marc Mutz wrote: > > On Wednesday 09 December 2015 10:57:21 Florian Bruhin wrote: >> * Marc Mutz [2015-12-09 11:54:54 +0100]: >>> Hi, >>> >>> http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what >>> case folding actually _is_ and how it's different from toLower(). >>> >>> Can someone please tell me the difference and why toCaseFolded() exists >>> in the first place? Is it faster? Is it guaranteed to not make the >>> string longer/shorter? >> >> Maybe http://www.w3.org/International/wiki/Case_folding helps? > > Not really. Neither does it patch our docs... :) > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Wed Dec 9 11:18:56 2015 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 9 Dec 2015 11:18:56 +0100 Subject: [Development] toLower() vs. toCaseFolded() In-Reply-To: <201512091220.37163.marc.mutz@kdab.com> References: <201512091154.55089.marc.mutz@kdab.com> <20151209095721.GQ5582@tonks> <201512091220.37163.marc.mutz@kdab.com> Message-ID: <20151209101856.GS5582@tonks> * Marc Mutz [2015-12-09 12:20:36 +0100]: > On Wednesday 09 December 2015 10:57:21 Florian Bruhin wrote: > > * Marc Mutz [2015-12-09 11:54:54 +0100]: > > > Hi, > > > > > > http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what > > > case folding actually _is_ and how it's different from toLower(). > > > > > > Can someone please tell me the difference and why toCaseFolded() exists > > > in the first place? Is it faster? Is it guaranteed to not make the > > > string longer/shorter? > > > > Maybe http://www.w3.org/International/wiki/Case_folding helps? > > Not really. Neither does it patch our docs... :) I'm going to say it - the overhead a small doc contribution really discourages me from doing so. I'm tired of waiting[1] for reviews, having to ping people again, and then fighting with the CI (though that part is getting better). Florian [1] https://codereview.qt-project.org/#/q/owner:%22Florian+Bruhin+%253Cqt-project.org%2540the-compiler.org%253E%22+status:open,n,z -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From dangelog at gmail.com Wed Dec 9 11:19:09 2015 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Wed, 9 Dec 2015 11:19:09 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <201512071539.25531.marc.mutz@kdab.com> <20151208145206.GA3387@ugly.fritz.box> <201512082043.54043.marc.mutz@kdab.com> <20151209100048.GA29009@troll08.it.local> Message-ID: On Wed, Dec 9, 2015 at 11:16 AM, Knoll Lars wrote: > And I’d say it’s about time to stop that particular sub-thread. It’s neither productive nor leading anywhere. Is there a consensus otherwise about a more liberal use of auto in our source code? Cheers, -- Giuseppe D'Angelo From jani.heikkinen at theqtcompany.com Wed Dec 9 11:22:10 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Wed, 9 Dec 2015 10:22:10 +0000 Subject: [Development] Qt 5.7 feature freeze postponed, new date to be agreed Message-ID: Hi all, According to original plans we should have Qt 5.7 FF next Friday (18th Dec). But we are still fighting to get Qt 5.6 (beta) out so there is no point to start freezing Qt 5.7 yet. We discussed about that yesterday's release team meeting & agreed to start discussion in ML about the issue. Ideally we should wait Qt 5.6.0 RC before start freezing Qt 5.7. But waiting Qt 5.6.0 RC might cause unnecessary delay for Qt 5.7 as well and I don't want to postpone 5.7 so much. That's why I propose 15th Jan 2016 for new feature freeze date for Qt 5.7. It should be quite near Qt 5.6.0 RC (if we managed to get Qt 5.6.0 out during next week as planned). br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at theqtcompany.com Wed Dec 9 11:44:33 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Wed, 9 Dec 2015 11:44:33 +0100 Subject: [Development] buildsystem now needs to keep behaviour compatibility In-Reply-To: <22298513.hvfALFAysn@finn> References: <2394178.nH4WTEmeSG@tjmaciei-mobl4> <565EB745.8080507@theqtcompany.com> <22298513.hvfALFAysn@finn> Message-ID: <20151209104433.GB29009@troll08.it.local> On Wed, Dec 02, 2015 at 01:04:40PM +0100, Olivier Goffart wrote: > On Wednesday 2. December 2015 10:17:57 Joerg Bornemann wrote: > > We should then keep build tests for these modules in the CI. > > Otherwise we won't notice breakages. > > I agree. > this is true. but that basically defeats the whole point, which was not needing to care about these modules any more. now reality caught up already and it turns out that i broke webkit. well, what i actually did, i broke bug-to-bug compatibility, which exposed a pre-existing problem in webkit, as it usually goes. it would be possible to revert the respective qmake change (and uglify the surrounding code), but i don't think it's reasonable to enforce this type of stagnation - we generally accept that code which relies on undefined or outright broken behavior is broken by fixes. so how do we go from there? i see several options: - continue to drag along webkit and the other deprecated modules. the additional cost of actually doing that in addition to compatibility testing is rather low with the new CI. - release further 5.5.x versions of these modules when necessary. i expect this to be a lot more effort than the first option, so it doesn't seem reasonable. - simply accept that it's broken, and tell people to apply patches. From Lars.Knoll at theqtcompany.com Wed Dec 9 13:18:06 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Wed, 9 Dec 2015 12:18:06 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <201512071539.25531.marc.mutz@kdab.com> <20151208145206.GA3387@ugly.fritz.box> <201512082043.54043.marc.mutz@kdab.com> <20151209100048.GA29009@troll08.it.local> Message-ID: On 09/12/15 11:19, "Giuseppe D'Angelo" wrote: >On Wed, Dec 9, 2015 at 11:16 AM, Knoll Lars wrote: >> And I’d say it’s about time to stop that particular sub-thread. It’s neither productive nor leading anywhere. Just for the record here, I was only asking to stop the off topic part of the discussion (about python and who’s right there). Let’s focus on auto in c++ and how we want to use it. > >Is there a consensus otherwise about a more liberal use of auto in our >source code? I don’t think there is a full consensus. Let me try to summarise where we are, what I think we agree upon and then add my thoughts :) As a primary goal, auto should be used wherever it increases readability of the code. I think we all agree here. The problem is that there’s dissent in what ‘more readable code’ is in practice. I think everybody also agrees one the use cases listed in https://wiki.qt.io/Coding_Conventions#auto_Keyword , so the question now is what additional use cases do most of us agree to? And how to put that into rules, as a listing with 50 entries won’t help anybody. While I don’t think we should go and implement aaa right now, I would probably be ok with a somewhat broader usage than the current coding conventions imply. Marc presented some use cases. Going through those, I don’t think I heard any disagreement about using auto in template, so I think we can probably add that one to our guidelines. For loop variables, I don’t think we should require ‘auto’. Using it can be the right thing to do in some cases, esp when using patterns like ‘for(auto item: items)’ , but when looping using integer indices, I still prefer ‘for (int i=...; cond; ++i)’. Are these cases something we can agree upon? Cheers, Lars From Marco.Bubke at theqtcompany.com Wed Dec 9 14:15:47 2015 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Wed, 9 Dec 2015 13:15:47 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <201512071539.25531.marc.mutz@kdab.com> <20151208145206.GA3387@ugly.fritz.box> <201512082043.54043.marc.mutz@kdab.com> <20151209100048.GA29009@troll08.it.local> , Message-ID: I would like to bring up the a case from creator: const TextEditor::FontSettings &fontSettings = TextEditor::TextEditorSettings::instance()->fontS ettings(); I really prefer in that case const auto &fontSettings = TextEditor::TextEditorSettings::instance()->fontSettings(); Should we recommend forward(universal) references in for loops (which are "const &value" for "const values"): for (auto &&value : values) or for (const auto &value : values) to show the difference to for (auto &value : values) ________________________________________ From: Development on behalf of Knoll Lars Sent: Wednesday, December 09, 2015 1:18 PM To: Giuseppe D'Angelo Cc: development at qt-project.org Subject: Re: [Development] RFC: more liberal 'auto' rules? On 09/12/15 11:19, "Giuseppe D'Angelo" wrote: >On Wed, Dec 9, 2015 at 11:16 AM, Knoll Lars wrote: >> And I’d say it’s about time to stop that particular sub-thread. It’s neither productive nor leading anywhere. Just for the record here, I was only asking to stop the off topic part of the discussion (about python and who’s right there). Let’s focus on auto in c++ and how we want to use it. > >Is there a consensus otherwise about a more liberal use of auto in our >source code? I don’t think there is a full consensus. Let me try to summarise where we are, what I think we agree upon and then add my thoughts :) As a primary goal, auto should be used wherever it increases readability of the code. I think we all agree here. The problem is that there’s dissent in what ‘more readable code’ is in practice. I think everybody also agrees one the use cases listed in https://wiki.qt.io/Coding_Conventions#auto_Keyword , so the question now is what additional use cases do most of us agree to? And how to put that into rules, as a listing with 50 entries won’t help anybody. While I don’t think we should go and implement aaa right now, I would probably be ok with a somewhat broader usage than the current coding conventions imply. Marc presented some use cases. Going through those, I don’t think I heard any disagreement about using auto in template, so I think we can probably add that one to our guidelines. For loop variables, I don’t think we should require ‘auto’. Using it can be the right thing to do in some cases, esp when using patterns like ‘for(auto item: items)’ , but when looping using integer indices, I still prefer ‘for (int i=...; cond; ++i)’. Are these cases something we can agree upon? Cheers, Lars _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Wed Dec 9 15:54:06 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 9 Dec 2015 15:54:06 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> Message-ID: <201512091554.07075.marc.mutz@kdab.com> On Wednesday 09 December 2015 13:18:06 Knoll Lars wrote: > as a listing with 50 entries won’t help anybody. Indeed. Therefore the suggestion to opt into C++ features, but optiing out of specific use cases. We have no indication that any compiler has problems with auto variables, so I don't see a reason for the Coding Style to restrict their use. We don't restrict the use of other C++ feature, such as do-while loops, either, even though they're inherently unreadable. Why do we need detailed, point-by-point rules micromanging the use of auto? The problem with codifying what isn't codifiable (due to lack of consensus in the wider C++ community) is that it will set in stone something that should grow as understanding grows. Some people are scared of auto, other (_not_ me, in case that wasn't clear) want to go to the other extreme: AAA-style. Codifying any two of the positions is wrong. Picking something in-between is something for people with a crystal ball. We should _require_ a small set of use-cases, for code consistency, and leave the rest for comments in reviews. That only works, of course, if people don't start running around -2'ing code just because they think there are too many or too few autos in there. It should be the prerogative of the patch author to decide, as she's the one doing the work. It's as subjective as variable naming, and we also only have very broad guidelines for that. > Are these cases something we can agree upon? Too little, imho. If we continue at this speed (one week for 1.5 more use- cases of an already-allowed feature), then we're going to be done with C++11 when C++22 is out. It's ok to discuss things, but discussions on this mailing-list tend to be fruitless (there's no conclusion to Thiago's thread "Upgrading the source..." from January 2015), tend to be hijacked by people over and over again who are "against" every change, the OP getting side-tracked into offside discussions (his fault! :), and discouragement for all sides involved. Please just _decide_. I, for one, pledge to live with the outcome. You heard all the arguments. Let's get it over with, and start over with nullptr :) For 5.8, we can re-open the discussion for auto variables. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Andre.Poenitz at theqtcompany.com Wed Dec 9 14:47:52 2015 From: Andre.Poenitz at theqtcompany.com (Poenitz Andre) Date: Wed, 9 Dec 2015 13:47:52 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <201512071539.25531.marc.mutz@kdab.com> <20151208145206.GA3387@ugly.fritz.box> <201512082043.54043.marc.mutz@kdab.com> <20151209100048.GA29009@troll08.it.local> , Message-ID: Lars wrote: > I don’t think there is a full consensus. Indeed, there isn't. > Let me try to summarise where > we are, what I think we agree upon and then add my thoughts :) > > As a primary goal, auto should be used wherever it increases readability > of the code. I think we all agree here. The problem is that there’s dissent > in what ‘more readable code’ is in practice. > > I think everybody also agrees one the use cases listed in > https://wiki.qt.io/Coding_Conventions#auto_Keyword , so the question now > is what additional use cases do most of us agree to? > > And how to put that into rules, as a listing with 50 entries won’t help anybody. I agree with that so far. > While I don’t think we should go and implement aaa right now, I would probably > be ok with a somewhat broader usage than the current coding conventions imply. > Marc presented some use cases. Going through those, I don’t think I heard > any disagreement about using auto in template, so I think we can probably > add that one to our guidelines. Marc's proposal included to *require* use of "auto" in some cases. I do not agree with that *required* use at all. That's not just because "auto is required in templates" would give the AAA supporters suddenly a big incentive to start writing or converting normal functions to templates just because they can use auto freely there, but since I don't believe visible types are bad per-se and far less of a "problem" than the AAA faction tries to make me believe. I would accept (and probably use myself) "optional use of auto" for - *some* template code (e.g. the mentioned 'typename' case) - references to elements in a collection *with "non-trivial" type*, i.e. something that is a template instance, or in deeply nested namespaces. (i.e. ok for std::pair, not ok for 'int' or 'QString') Marc's *optional* proposal "Optional use of auto: whereever it makes sense. Use your own judgement, but remember: fear is a bad advisor." pretty much opens the door for AAA, as for an AAA supporter "auto" will *always* make sense. So effectively the proposal consists of two attempts to implement an AAA policy. That's going way too far in one step. Andre' From marc.mutz at kdab.com Wed Dec 9 16:14:00 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 9 Dec 2015 16:14:00 +0100 Subject: [Development] RFF: nullptr rules Message-ID: <201512091614.00734.marc.mutz@kdab.com> Hi, in 5.7, nullptr (Q_C_NULLPTR) is required to be supported by the compiler, but there are no guidelines as to its use in the coding conventions (to the extent they need to be in there). I propose the following, based on Thiago's proposal from January this year, considering the new situation that we now require nullptr support in the compiler: - 0 as a nullptr constant is banned except in tests testing APIs so we don't accidentally require nullptr (ie. all tests should use 0, not nullptr, as far as it makes sense) - clang-modernize is used to convert all uses of the null pointer constant to nullptr, incl. examples, excl. tests and 3rdparty - compilers that have it, will have -Wzero-as-nullptr-constant added during headersclean[0] - APIs that require the use of nullptr for disambiguation are discouraged, but may be acceptable to be decided on a case-by-case basis. - Accidental (ie. non-apidox'ed) reliance on nullptr for disambiguation is always an error. To this end, tests should continue to use 0, not nullptr. - if (!foo) vs. if (foo == nullptr), if (foo) vs. if (foo != nullptr): author's prerogative[1] [0] I'd prefer "when building Qt", but realise that we'll have problems with upstream libs [1] I prefer the short form, but I don't think we'll gain a consensus here, so let's not even try Arguments in favour: - it's the C++ way of writing the null pointer constant these days - we need to use it in headers, anyway, to allow people to use -Wzero-as..., and it makes no sense to have two sets of rules for headers and impl - it can disambiguate code and prevent accidents - in some situations, it makes code easier to understand (: m_foo(nullptr)). Arguments against: - it's uglier than "0", and more to type Let's have comments and additions float in for a week, and then let's have Lars decide. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Wed Dec 9 16:32:34 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 9 Dec 2015 16:32:34 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> Message-ID: <201512091632.35479.marc.mutz@kdab.com> On Wednesday 09 December 2015 14:15:47 Bubke Marco wrote: > for (auto &&value : values) This is ok in generic code. In non-generic code, I think it's too clever. In general, I would always try to preserve which kind of type we're dealing with: const auto *e = auto e* = const auto &e = auto &e = auto e = const auto e = But that's just the level of auto that _I_ feel comfortable with. YMMV. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From louai.al-khanji at theqtcompany.com Wed Dec 9 15:42:18 2015 From: louai.al-khanji at theqtcompany.com (Al-Khanji Louai) Date: Wed, 9 Dec 2015 14:42:18 +0000 Subject: [Development] Nominating Samuli Pippo for Approver status In-Reply-To: References: , Message-ID: +1! _____________________________ From: Meadows Louis > Sent: Wednesday, December 2, 2015 2:01 PM Subject: Re: [Development] Nominating Samuli Pippo for Approver status To: >, Agocs Laszlo > +1 from me as well From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Agocs Laszlo Sent: Wednesday, December 02, 2015 6:13 AM To: development at qt-project.org Subject: [Development] Nominating Samuli Pippo for Approver status Hello, I would like to nominate Samuli Piippo for Approver status in the Qt Project. Samuli has been working on Qt's Embedded Linux support and Qt for Device Creation during the past few years. He is our resident Yocto expert and is contributing to meta-qt5 as well. Public Gerrit dashboard: https://codereview.qt-project.org/#/q/owner:samuli.piippo,n,z meta-qt5 contributions: https://github.com/meta-qt5/meta-qt5/commits/master?author=sapiippo Best regards, Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From rolland at ghs.com Wed Dec 9 15:52:04 2015 From: rolland at ghs.com (Rolland Dudemaine) Date: Wed, 9 Dec 2015 15:52:04 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512091554.07075.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> <201512091554.07075.marc.mutz@kdab.com> Message-ID: <56684014.4020109@ghs.com> >> Are these cases something we can agree upon? > Too little, imho. If we continue at this speed (one week for 1.5 more use- > cases of an already-allowed feature), then we're going to be done with C++11 > when C++22 is out. If I may ask, what is wrong with not using features of a language? I've always been a fan of Qt, not because of its conciseness, portability, versatility (although these help), but really because a C++ beginner, a seasoned C engineer unfamiliar with C++, and several other non-expert types can read and understand the Qt API, and also write basic applications. Preaching pragmatism, I'd happily vote for "what's convenient" inside the Qt implementation, but also vote against the C++11-ification of the API. Rolland ---------------------------------------------------------- Rolland Dudemaine tel direct:+33 143 143 702 Green Hills Software tel:+33 143 143 700 4 rue de la Pierre Levee mailto:rolland at ghs.com 75011 Paris fax: +33 143 143 707 France web: http://www.ghs.com ---------------------------------------------------------- From mwoehlke.floss at gmail.com Wed Dec 9 16:02:01 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 09 Dec 2015 10:02:01 -0500 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <201512071539.25531.marc.mutz@kdab.com> <20151208145206.GA3387@ugly.fritz.box> <201512082043.54043.marc.mutz@kdab.com> <20151209100048.GA29009@troll08.it.local> Message-ID: On 2015-12-09 07:18, Knoll Lars wrote: > For loop variables, I don’t think we should require ‘auto’. Using it > can be the right thing to do in some cases, esp when using patterns > like ‘for(auto item: items)’ , but when looping using integer > indices, I still prefer ‘for (int i=...; cond; ++i)’. For the record, while I still think 'for (auto const i : qIndexRange(list.count()))' is better, my objection here isn't so much to failing to mandate 'auto' in such cases as forbidding it entirely in such cases. Especially if there ever does end up being code in Qt operating on STL objects where the correct type is something esoteric like 'std::vector::size_type'. -- Matthew From mwoehlke.floss at gmail.com Wed Dec 9 16:02:58 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 09 Dec 2015 10:02:58 -0500 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <201512071539.25531.marc.mutz@kdab.com> <20151208145206.GA3387@ugly.fritz.box> <201512082043.54043.marc.mutz@kdab.com> <20151209100048.GA29009@troll08.it.local> , Message-ID: On 2015-12-09 08:15, Bubke Marco wrote: > Should we recommend forward(universal) references in for loops (which are "const &value" for "const values"): > > for (auto &&value : values) Someone remind me; what's the benefit of this vs. 'auto const&' (assuming that I won't be modifying 'value')? > or > > for (const auto &value : values) > > to show the difference to > > for (auto &value : values) I personally prefer making everything I can 'const'. That means 'const&' returns from functions ("forces" a copy elision), 'const' local variables, etc.. In the case of loops like the above, if I'm not going to modify the value, I prefer to say so. If I *am* going to modify it, I prefer 'auto&' to a) also say so, and b) statically ensure that I *can*. That's just my 2¢ however; I'd be interested in hearing arguments for 'auto&&'. -- Matthew From sergio.martins at kdab.com Wed Dec 9 16:06:43 2015 From: sergio.martins at kdab.com (Sergio Martins) Date: Wed, 09 Dec 2015 15:06:43 +0000 Subject: [Development] RFF: nullptr rules In-Reply-To: <201512091614.00734.marc.mutz@kdab.com> References: <201512091614.00734.marc.mutz@kdab.com> Message-ID: <4681137.XKpEsm96cF@desktop> On Wednesday, 9 December 2015 16:14:00 WET Marc Mutz wrote: > Arguments in favour: > - it's the C++ way of writing the null pointer constant these days > - we need to use it in headers, anyway, to allow people to use -Wzero-as..., > and it makes no sense to have two sets of rules for headers and impl - it > can disambiguate code and prevent accidents > - in some situations, it makes code easier to understand (: m_foo(nullptr)). Agreed. The last point being the strongest argument IMHO, since we don't use hungarian notation m_foo(0) hurts readability. > Arguments against: > - it's uglier than "0", and more to type Not agreed. This is highly subjective, for me Q_NULLPTR was uglier than 0 but nullptr feels just natural. Regards, -- Sérgio Martins | sergio.martins at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From mwoehlke.floss at gmail.com Wed Dec 9 16:19:38 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 09 Dec 2015 10:19:38 -0500 Subject: [Development] RFF: nullptr rules In-Reply-To: <201512091614.00734.marc.mutz@kdab.com> References: <201512091614.00734.marc.mutz@kdab.com> Message-ID: On 2015-12-09 10:14, Marc Mutz wrote: > in 5.7, nullptr (Q_C_NULLPTR) is required to be supported by the compiler, but > there are no guidelines as to its use in the coding conventions (to the extent > they need to be in there). > > I propose the following, based on Thiago's proposal from January this year, > considering the new situation that we now require nullptr support in the > compiler: > [...] > - compilers that have it, will have -Wzero-as-nullptr-constant added during > headersclean[0] Yay! :-) Yes, please, for exactly the reason you gave. > - APIs that require the use of nullptr for disambiguation are discouraged, > but may be acceptable to be decided on a case-by-case basis. On that note, there *is* one case in which '0' as nullptr makes sense... default values for QFlags. A literal '0' "looks like" an empty bitset much more than 'nullptr', even though IIRC it actually ends up implemented via a void* ctor. This probably means that those should be changed to use '{}' as the default initializer instead (i.e. not 'nullptr'). I'm not sure what this means for compiler support (i.e. if any compilers that Qt still supports don't support it), though I do know offhand it does exclude GCC < 4.7. (Alternatively, there could be a qNullFlag or some such, but that might have compatibility problems.) > Arguments against: > - it's uglier than "0", and more to type FWIW, I'm with Sergio here; not sure I agree about it being "uglier"... it's certainly more obvious that 'nullptr' is... a null pointer, and not an integer literal... (And, likewise, I'm more sympathetic to '0' vs. 'Q_NULLPTR'. But since that's not what we're talking about...) -- Matthew From joerg.bornemann at theqtcompany.com Wed Dec 9 16:38:02 2015 From: joerg.bornemann at theqtcompany.com (Joerg Bornemann) Date: Wed, 9 Dec 2015 16:38:02 +0100 Subject: [Development] RFF: nullptr rules In-Reply-To: <201512091614.00734.marc.mutz@kdab.com> References: <201512091614.00734.marc.mutz@kdab.com> Message-ID: <56684ADA.70106@theqtcompany.com> On 09-Dec-15 16:14, Marc Mutz wrote: > in 5.7, nullptr (Q_C_NULLPTR) is required to be supported by the compiler, but > there are no guidelines as to its use in the coding conventions (to the extent > they need to be in there). There are also no guidelines for every other language feature, and I doubt that we need those. Everything that's not controlled by rules is controlled by common sense, which I trust this community has. > I propose the following, based on Thiago's proposal from January this year, > considering the new situation that we now require nullptr support in the > compiler: > > - 0 as a nullptr constant is banned except in tests testing APIs so > we don't accidentally require nullptr (ie. all tests should use 0, not > nullptr, as far as it makes sense) What is the advantage apart from fixing the edge case of having void foo(int) and void foo(Blubb *) ? > - clang-modernize is used to convert all uses of the null pointer constant to > nullptr, incl. examples, excl. tests and 3rdparty This just adds pointless noise to the history. I see no value in it. > - compilers that have it, will have -Wzero-as-nullptr-constant added during > headersclean[0] I can see value in enforcing nullptr in public headers. > - APIs that require the use of nullptr for disambiguation are discouraged, > but may be acceptable to be decided on a case-by-case basis. I agree. > - Accidental (ie. non-apidox'ed) reliance on nullptr for disambiguation is > always an error. To this end, tests should continue to use 0, not nullptr. > - if (!foo) vs. if (foo == nullptr), if (foo) vs. if (foo != nullptr): > author's prerogative[1] > > [0] I'd prefer "when building Qt", but realise that we'll have problems with > upstream libs > [1] I prefer the short form, but I don't think we'll gain a consensus here, so > let's not even try So why do you try yet? > Arguments in favour: > - it's the C++ way of writing the null pointer constant these days > - we need to use it in headers, anyway, to allow people to use -Wzero-as..., > and it makes no sense to have two sets of rules for headers and impl > - it can disambiguate code and prevent accidents Yes, it can. In edge cases. Let's use nullptr for those. > - in some situations, it makes code easier to understand (: m_foo(nullptr)). So nullptr is easier to understand, because assigning 0 to a pointer variable didn't make clear that it now contains a null pointer? If there's need to signify using m_foo(nullptr) that m_foo is a pointer, then m_foo is maybe a bad name and should be fixed. There are very few cases where nullptr actually prevents errors. Let's use it there. And if you think it's pretty and fits your style, use it. But do not enforce it just because of its mere existence. BR, Joerg From tuukka.turunen at theqtcompany.com Wed Dec 9 16:58:27 2015 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Wed, 9 Dec 2015 15:58:27 +0000 Subject: [Development] Qt 5.7 feature freeze postponed, new date to be agreed In-Reply-To: References: Message-ID: Hi, 15th Jan sounds good to me as the new FF time for Qt 5.7. The idea is to have the currently TP modules (at least many of them) supported with Qt 5.7 and also to drop the non-C++11 compilers as already discussed, agreed and implemented for dev. Therefore the content of Qt 5.7 is to a large extent already shaping up and in case someone has new features just starting, these are probably better to aim towards Qt 5.8. I really would like us the finally get to the desired April & October release cycle during 2016 with the new Coin CI. Even though moving Qt 5.7 FF to 15th Jan means the final being in May instead of April, I think it is something we can accept. Yours, Tuukka From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Heikkinen Jani Sent: keskiviikkona 9. joulukuuta 2015 12.22 To: development at qt-project.org Subject: [Development] Qt 5.7 feature freeze postponed, new date to be agreed Importance: High Hi all, According to original plans we should have Qt 5.7 FF next Friday (18th Dec). But we are still fighting to get Qt 5.6 (beta) out so there is no point to start freezing Qt 5.7 yet. We discussed about that yesterday's release team meeting & agreed to start discussion in ML about the issue. Ideally we should wait Qt 5.6.0 RC before start freezing Qt 5.7. But waiting Qt 5.6.0 RC might cause unnecessary delay for Qt 5.7 as well and I don't want to postpone 5.7 so much. That's why I propose 15th Jan 2016 for new feature freeze date for Qt 5.7. It should be quite near Qt 5.6.0 RC (if we managed to get Qt 5.6.0 out during next week as planned). br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathias at taschenorakel.de Wed Dec 9 17:34:56 2015 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Wed, 9 Dec 2015 17:34:56 +0100 Subject: [Development] toLower() vs. toCaseFolded() In-Reply-To: <201512091220.37163.marc.mutz@kdab.com> References: <201512091154.55089.marc.mutz@kdab.com> <20151209095721.GQ5582@tonks> <201512091220.37163.marc.mutz@kdab.com> Message-ID: <56685830.5030902@taschenorakel.de> Am 09.12.2015 um 12:20 schrieb Marc Mutz: > On Wednesday 09 December 2015 10:57:21 Florian Bruhin wrote: >> * Marc Mutz [2015-12-09 11:54:54 +0100]: >>> Hi, >>> >>> http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what >>> case folding actually _is_ and how it's different from toLower(). >>> >>> Can someone please tell me the difference and why toCaseFolded() exists >>> in the first place? Is it faster? Is it guaranteed to not make the >>> string longer/shorter? >> >> Maybe http://www.w3.org/International/wiki/Case_folding helps? > > Not really. Neither does it patch our docs... :) > Like that W3C document says the difference really is about handling of characters like ß, or the different variants of I in Turkic languages. While doing word prediction one really wants to treat words like "Straße", "STRASSE" to be equal and delegate the final string matching to the user. Details are in http://www.unicode.org/Public/8.0.0/ucd/CaseFolding.txt, the rows with status field other than "C" are the interesting ones. No, this also doesn't update the docs yet. From mathias at taschenorakel.de Wed Dec 9 17:45:25 2015 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Wed, 9 Dec 2015 17:45:25 +0100 Subject: [Development] RFF: nullptr rules In-Reply-To: <201512091614.00734.marc.mutz@kdab.com> References: <201512091614.00734.marc.mutz@kdab.com> Message-ID: <56685AA5.9020004@taschenorakel.de> Am 09.12.2015 um 16:14 schrieb Marc Mutz: > Arguments in favour: > - it's the C++ way of writing the null pointer constant these days > - we need to use it in headers, anyway, to allow people to use -Wzero-as..., > and it makes no sense to have two sets of rules for headers and impl > - it can disambiguate code and prevent accidents > - in some situations, it makes code easier to understand (: m_foo(nullptr)). > > Arguments against: > - it's uglier than "0", and more to type Have we discussed "{}" instead of "nullptr", or "0" already? Ciao, Mathias From rich at kde.org Wed Dec 9 18:23:20 2015 From: rich at kde.org (Richard Moore) Date: Wed, 9 Dec 2015 17:23:20 +0000 Subject: [Development] Fwd: RFF: nullptr rules In-Reply-To: References: <201512091614.00734.marc.mutz@kdab.com> Message-ID: Resending from the right address. ---------- Forwarded message ---------- From: Richard Moore Date: 9 December 2015 at 17:22 Subject: Re: [Development] RFF: nullptr rules To: "development at qt-project.org" On 9 December 2015 at 15:14, Marc Mutz wrote: > - 0 as a nullptr constant is banned except in tests testing APIs so > we don't accidentally require nullptr (ie. all tests should use 0, not > nullptr, as far as it makes sense) > ​This seems pretty arbitrary to me, and would lead to inconsistency with APIs that ​predated this rule. I can't say I'm in favour. > - clang-modernize is used to convert all uses of the null pointer constant > to > nullptr, incl. examples, excl. tests and 3rdparty > ​Won't this just add noise and make forward porting bug fixes harder? I don't see it gains much.​ > - APIs that require the use of nullptr for disambiguation are discouraged, > but may be acceptable to be decided on a case-by-case basis. > ​Makes sense​ > > Arguments in favour: > - it's the C++ way of writing the null pointer constant these days > - we need to use it in headers, anyway, to allow people to use > -Wzero-as..., > and it makes no sense to have two sets of rules for headers and impl > ​There's nothing that says we need to allow people to use that warning, and nothing stopping us disabling it for our headers, so this is a non-argument.​ > - it can disambiguate code and prevent accidents > ​I'm not convinced about this for sane APIs.​ > - in some situations, it makes code easier to understand (: > m_foo(nullptr)). > > I don't see any difference from 0 here to be honest, but perhaps that's just me.​ > Arguments against: > - it's uglier than "0", and more to type > ​Definitely, also:​ - ​It will also make forward-porting​ ​bug fixes and merges harder.​ - If the automated change you suggest was done then the history would be (a little) less useful. ​Cheers Rich.​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Wed Dec 9 19:32:50 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 9 Dec 2015 19:32:50 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <56684014.4020109@ghs.com> References: <201512031949.46920.marc.mutz@kdab.com> <201512091554.07075.marc.mutz@kdab.com> <56684014.4020109@ghs.com> Message-ID: <201512091932.51517.marc.mutz@kdab.com> On Wednesday 09 December 2015 15:52:04 Rolland Dudemaine wrote: > If I may ask, what is wrong with not using features of a language? Nothing. Except that new generations of programmers will look at the code written in 90s style, label it "legacy", treat it with utmost disgust, slow down to a crwawl when making changes to it and demand 150% of the rates when going in. This whole story of "code is written once, and read many times" is wrong (the "once" part). Code should be continuously evolved to stay current. Just try compiling Qt 3.x with a current GCC and you will know why. > I've always been a fan of Qt, not because of its conciseness, > portability, versatility (although these help), but really because a C++ > beginner, a seasoned C engineer unfamiliar with C++, and several other > non-expert types can read and understand the Qt API, and also write > basic applications. > > Preaching pragmatism, I'd happily vote for "what's convenient" inside > the Qt implementation, but also vote against the C++11-ification of the > API. This discussion is not about the Qt API. It is about its implementation. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Wed Dec 9 19:37:29 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 9 Dec 2015 19:37:29 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> Message-ID: <201512091937.30031.marc.mutz@kdab.com> On Wednesday 09 December 2015 16:02:01 Matthew Woehlke wrote: > Especially if there ever does end up being code in Qt > operating on STL objects where the correct type is something esoteric > like 'std::vector::size_type'. Already there: qmetaobjectbuilder.cpp -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Wed Dec 9 19:39:28 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 9 Dec 2015 19:39:28 +0100 Subject: [Development] RFF: nullptr rules In-Reply-To: References: <201512091614.00734.marc.mutz@kdab.com> Message-ID: <201512091939.29303.marc.mutz@kdab.com> On Wednesday 09 December 2015 16:19:38 Matthew Woehlke wrote: > > - APIs that require the use of nullptr for disambiguation are > > discouraged, > > > > but may be acceptable to be decided on a case-by-case basis. > > On that note, there is one case in which '0' as nullptr makes sense... > default values for QFlags. A literal '0' "looks like" an empty bitset > much more than 'nullptr', even though IIRC it actually ends up > implemented via a void* ctor. This probably means that those should be > changed to use '{}' as the default initializer instead (i.e. not > 'nullptr'). I'm not sure what this means for compiler support (i.e. if > any compilers that Qt still supports don't support it), though I do know > offhand it does exclude GCC < 4.7. > > (Alternatively, there could be a qNullFlag or some such, but that might > have compatibility problems.) FTR: this is already fixed in QtBase 5.6, but not other modules, by using the default ctor (uniform init isn't required in Qt 5.7). -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Wed Dec 9 19:41:28 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 9 Dec 2015 19:41:28 +0100 Subject: [Development] RFF: nullptr rules In-Reply-To: <56684ADA.70106@theqtcompany.com> References: <201512091614.00734.marc.mutz@kdab.com> <56684ADA.70106@theqtcompany.com> Message-ID: <201512091941.29325.marc.mutz@kdab.com> On Wednesday 09 December 2015 16:38:02 Joerg Bornemann wrote: > > - if (!foo) vs. if (foo == nullptr), if (foo) vs. if (foo != nullptr): > > author's prerogative[1] [...] > > [1] I prefer the short form, but I don't think we'll gain a consensus > > here, so let's not even try > > So why do you try yet? What part of "author's prerogative" was unclear? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Wed Dec 9 19:46:52 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 9 Dec 2015 19:46:52 +0100 Subject: [Development] Fwd: RFF: nullptr rules In-Reply-To: References: <201512091614.00734.marc.mutz@kdab.com> Message-ID: <201512091946.52627.marc.mutz@kdab.com> On Wednesday 09 December 2015 18:23:20 Richard Moore wrote: > > Arguments in favour: [...] > > -Wzero-as..., > > > > and it makes no sense to have two sets of rules for headers and impl > > ​There's nothing that says we need to allow people to use that warning, and > nothing stopping us disabling it for our headers, so this is a > non-argument.​ https://bugreports.qt.io/browse/QTBUG-45291 -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From md at rpzdesign.com Wed Dec 9 18:45:08 2015 From: md at rpzdesign.com (md at rpzdesign.com) Date: Wed, 9 Dec 2015 11:45:08 -0600 Subject: [Development] Qt 5.7 feature freeze postponed, new date to be agreed In-Reply-To: References: Message-ID: <566868A4.3000008@rpzdesign.com> Tuuka: I was looking around for "Coin CI" information on google. Can you provide links and additional insight into this CI? We have a thread on the interest list related to CI. md On 12/9/2015 9:58 AM, Turunen Tuukka wrote: > > Hi, > > 15th Jan sounds good to me as the new FF time for Qt 5.7. The idea is > to have the currently TP modules (at least many of them) supported > with Qt 5.7 and also to drop the non-C++11 compilers as already > discussed, agreed and implemented for dev. Therefore the content of Qt > 5.7 is to a large extent already shaping up and in case someone has > new features just starting, these are probably better to aim towards > Qt 5.8. I really would like us the finally get to the desired April & > October release cycle during 2016 with the new Coin CI. Even though > moving Qt 5.7 FF to 15^th Jan means the final being in May instead of > April, I think it is something we can accept. > > Yours, > > Tuukka > > *From:*Development [mailto:development-bounces at qt-project.org] *On > Behalf Of *Heikkinen Jani > *Sent:* keskiviikkona 9. joulukuuta 2015 12.22 > *To:* development at qt-project.org > *Subject:* [Development] Qt 5.7 feature freeze postponed, new date to > be agreed > *Importance:* High > > Hi all, > > According to original plans we should have Qt 5.7 FF next Friday (18th > Dec). But we are still fighting to get Qt 5.6 (beta) out so there is > no point to start freezing Qt 5.7 yet. We discussed about that > yesterday's release team meeting & agreed to start discussion in ML > about the issue. Ideally we should wait Qt 5.6.0 RC before start > freezing Qt 5.7. But waiting Qt 5.6.0 RC might cause unnecessary delay > for Qt 5.7 as well and I don't want to postpone 5.7 so much. That's > why I propose 15th Jan 2016 for new feature freeze date for Qt 5.7. It > should be quite near Qt 5.6.0 RC (if we managed to get Qt 5.6.0 out > during next week as planned). > > br, > > Jani > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwoehlke.floss at gmail.com Wed Dec 9 18:51:06 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 09 Dec 2015 12:51:06 -0500 Subject: [Development] Fwd: RFF: nullptr rules In-Reply-To: References: <201512091614.00734.marc.mutz@kdab.com> Message-ID: On 2015-12-09 12:23, Richard Moore wrote: > On 9 December 2015 at 15:14, Marc Mutz wrote: >> Arguments in favour: >> -Wzero-as..., >> and it makes no sense to have two sets of rules for headers and impl > > ​There's nothing that says we need to allow people to use that warning, ...except that it isn't just a question of whether Qt uses it internally, it affects whether or not *consumers* (of Qt) can use it. (And yes, there is some extent to which this is a compiler problem, but fixing it in the compiler is apparently really, really difficult. See e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486.) > and nothing stopping us disabling it for our headers, ...except when that doesn't work, e.g. the bug report Marc referenced. -- Matthew From thiago.macieira at intel.com Wed Dec 9 19:09:14 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 09 Dec 2015 10:09:14 -0800 Subject: [Development] toLower() vs. toCaseFolded() In-Reply-To: <201512091154.55089.marc.mutz@kdab.com> References: <201512091154.55089.marc.mutz@kdab.com> Message-ID: <3800206.sUigBAWOPR@tjmaciei-mobl4> On Wednesday 09 December 2015 11:54:54 Marc Mutz wrote: > Hi, > > http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what case > folding actually _is_ and how it's different from toLower(). > > Can someone please tell me the difference and why toCaseFolded() exists in > the first place? Is it faster? Is it guaranteed to not make the string > longer/shorter? It's a different form of case transformation in Unicode. If you care about it, you've probably read some document that said that you should do case folding. An example is the "stringprep" / "nameprep" step of Internationalised Domain Names: it requires case folding. It's given in the Unicode file CaseFolding.txt. For example, İ lowercases to i, but casefolds to i + combining dot above. Also, don't confuse case folding with title-casing. That's the difference between LJ, Lj, and lj and is found in the third column of cases (last column) in UnicodeData.txt. 01C7;LATIN CAPITAL LETTER LJ;Lu;0;L; 004C 004A;;;;N;LATIN CAPITAL LETTER L J;;;01C9;01C8 01C8;LATIN CAPITAL LETTER L WITH SMALL LETTER J;Lt;0;L; 004C 006A;;;;N;LATIN LETTER CAPITAL L SMALL J;;01C7;01C9;01C8 01C9;LATIN SMALL LETTER LJ;Ll;0;L; 006C 006A;;;;N;LATIN SMALL LETTER L J;;01C7;;01C8 > Preferably answer by updating the docs to be a bit more descriptive. I'd like Konstantin to do that, as he might have a better idea than "Unicode says so"... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Dec 9 19:11:29 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 09 Dec 2015 10:11:29 -0800 Subject: [Development] RFF: nullptr rules In-Reply-To: <201512091614.00734.marc.mutz@kdab.com> References: <201512091614.00734.marc.mutz@kdab.com> Message-ID: <2798447.IKuPeqeCOI@tjmaciei-mobl4> On Wednesday 09 December 2015 16:14:00 Marc Mutz wrote: > - 0 as a nullptr constant is banned except in tests testing APIs so > we don't accidentally require nullptr (ie. all tests should use 0, not > nullptr, as far as it makes sense) This is not what we had agreed to. We had said that where it's unambiguous, we can still use 0, outside of public headers. const char *ptr = 0; -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Wed Dec 9 22:47:51 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 9 Dec 2015 22:47:51 +0100 Subject: [Development] RFF: nullptr rules In-Reply-To: <2798447.IKuPeqeCOI@tjmaciei-mobl4> References: <201512091614.00734.marc.mutz@kdab.com> <2798447.IKuPeqeCOI@tjmaciei-mobl4> Message-ID: <201512092247.52291.marc.mutz@kdab.com> On Wednesday 09 December 2015 19:11:29 Thiago Macieira wrote: > On Wednesday 09 December 2015 16:14:00 Marc Mutz wrote: > > - 0 as a nullptr constant is banned except in tests testing APIs so > > > > we don't accidentally require nullptr (ie. all tests should use 0, not > > nullptr, as far as it makes sense) > > This is not what we had agreed to. > > We had said that where it's unambiguous, we can still use 0, outside of > public headers. > > const char *ptr = 0; What we agreed on was for Q_NULLPTR. Some developers back then were complaining that the *macro* is ugly, and that by 5.7, we would be able to use the real thing and didn't want the double conversion 0 -> Q_NULLPTR -> nullptr. The agreement back then also was not to rely on the disambiguating features of nullptr, because Q_NULLPTR might be 0. Now we can use the real thing. With real nullptr semantics. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Wed Dec 9 22:54:22 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 9 Dec 2015 22:54:22 +0100 Subject: [Development] RFF: nullptr rules In-Reply-To: <201512091614.00734.marc.mutz@kdab.com> References: <201512091614.00734.marc.mutz@kdab.com> Message-ID: <201512092254.22883.marc.mutz@kdab.com> On Wednesday 09 December 2015 16:14:00 Marc Mutz wrote: > Hi, > > in 5.7, nullptr (Q_C_NULLPTR) is required to be supported by the compiler, > but there are no guidelines as to its use in the coding conventions (to > the extent they need to be in there). > > I propose the following, based on Thiago's proposal from January this year, > considering the new situation that we now require nullptr support in the > compiler: > > - 0 as a nullptr constant is banned except in tests testing APIs so > we don't accidentally require nullptr (ie. all tests should use 0, not > nullptr, as far as it makes sense) > - clang-modernize is used to convert all uses of the null pointer constant > to nullptr, incl. examples, excl. tests and 3rdparty > - compilers that have it, will have -Wzero-as-nullptr-constant added during > headersclean[0] > - APIs that require the use of nullptr for disambiguation are discouraged, > but may be acceptable to be decided on a case-by-case basis. > - Accidental (ie. non-apidox'ed) reliance on nullptr for disambiguation is > always an error. To this end, tests should continue to use 0, not > nullptr. - if (!foo) vs. if (foo == nullptr), if (foo) vs. if (foo != > nullptr): author's prerogative[1] > > [0] I'd prefer "when building Qt", but realise that we'll have problems > with upstream libs > [1] I prefer the short form, but I don't think we'll gain a consensus here, > so let's not even try > > Arguments in favour: > - it's the C++ way of writing the null pointer constant these days > - we need to use it in headers, anyway, to allow people to use > -Wzero-as..., and it makes no sense to have two sets of rules for headers > and impl - it can disambiguate code and prevent accidents > - in some situations, it makes code easier to understand (: > m_foo(nullptr)). > > Arguments against: > - it's uglier than "0", and more to type Because it's coming up again to have nullptr only in some places and leave 0 in others: The predictable "let's use it only in X" reply is a rearguard battle trying to keep the _inevitable_ change from 0 to nullptr contained to a certain subset of cases, thereby complicating the ruleset, subsequently the reviews based on that ruleset and thwards automatic migration. Converting _all_ null pointer constants to nullptr is a simple run of clang- modernize. It is reasonable to trust the tool and not review every single instance by multiple people on Gerrit, but wave it though into CI quickly. But if we have a complicated ruleset for when to use nullptr and when to use 0, the person submitting the results of clang-modernize will have to wade through the changes one-by-one, separating the wanted from the unwanted changes. Then a few Gerrit reviewers will have to review all the changes _again_, matching against the ruleset, discussing unclear situations.... All this just because some people have an aesthetic problem with "nullptr". Guess what, you can always s/nullptr/0/ for display, but the converse is _not_ possible. Whatever happened to KISS? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Wed Dec 9 22:56:48 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 9 Dec 2015 22:56:48 +0100 Subject: [Development] toLower() vs. toCaseFolded() In-Reply-To: <201512091154.55089.marc.mutz@kdab.com> References: <201512091154.55089.marc.mutz@kdab.com> Message-ID: <201512092256.49246.marc.mutz@kdab.com> On Wednesday 09 December 2015 11:54:54 Marc Mutz wrote: > Can someone please tell me the difference and why toCaseFolded() exists in > the first place? Is it faster? Is it guaranteed to not make the string > longer/shorter? To be more precise: I'd like the docs to say when I should use toCaseFolded() or toLower(). Since the Unicode docs linked say toCaseFolded() is locale- dependent, as an API user I'd also wonder which locale the QString function uses. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Wed Dec 9 22:27:09 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 09 Dec 2015 13:27:09 -0800 Subject: [Development] toLower() vs. toCaseFolded() In-Reply-To: <201512092256.49246.marc.mutz@kdab.com> References: <201512091154.55089.marc.mutz@kdab.com> <201512092256.49246.marc.mutz@kdab.com> Message-ID: <5943591.JzShLcks9d@tjmaciei-mobl4> On Wednesday 09 December 2015 22:56:48 Marc Mutz wrote: > On Wednesday 09 December 2015 11:54:54 Marc Mutz wrote: > > Can someone please tell me the difference and why toCaseFolded() exists in > > the first place? Is it faster? Is it guaranteed to not make the string > > longer/shorter? > > To be more precise: I'd like the docs to say when I should use > toCaseFolded() or toLower(). Since the Unicode docs linked say > toCaseFolded() is locale- dependent, as an API user I'd also wonder which > locale the QString function uses. QString is *not* locale dependent and must not be. toCaseFolding does not imply that. We have no code for doing Turkic (Turkish and Azerbaijani) case mapping of i/İ/ı/I along with i̇/İ. We could add overloads to the case mapping functions that take an extra enum indicating whether to do the "T" mapping and we should add QLocale overloads too that enable it automatically depending on locale. Another alternative is to add a new class that does locale-specific case mapping, along with natural sorting. For example, when title-casing in French, you drop accents ("école" becomes "Ecole"). Assuming such data exists and is implemented in ICU. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Dec 9 23:29:19 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 09 Dec 2015 14:29:19 -0800 Subject: [Development] RFF: nullptr rules In-Reply-To: <201512092247.52291.marc.mutz@kdab.com> References: <201512091614.00734.marc.mutz@kdab.com> <2798447.IKuPeqeCOI@tjmaciei-mobl4> <201512092247.52291.marc.mutz@kdab.com> Message-ID: <1897245.5mlEbTrKZ8@tjmaciei-mobl4> On Wednesday 09 December 2015 22:47:51 Marc Mutz wrote: > > const char *ptr = 0; > > What we agreed on was for Q_NULLPTR. > > Some developers back then were complaining that the *macro* is ugly, and > that by 5.7, we would be able to use the real thing and didn't want the > double conversion 0 -> Q_NULLPTR -> nullptr. > > The agreement back then also was not to rely on the disambiguating features > of nullptr, because Q_NULLPTR might be 0. > > Now we can use the real thing. With real nullptr semantics. True. I'd like to propose this: a) no massive replacement or clang-modernize, for the reasons Richard pointed out b) which means existing zeroes continue in sources and private headers c) which means no -Werror=zero-as-nullptr outside of headersclean New code should use nullptr where it improves readability. Changes to existing code can update to use nullptr. But I don't think we should mandate use of nullptr everywhere. Where it's unambiguous, it doesn't add value. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Dec 9 23:30:31 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 09 Dec 2015 14:30:31 -0800 Subject: [Development] RFF: nullptr rules In-Reply-To: <201512092254.22883.marc.mutz@kdab.com> References: <201512091614.00734.marc.mutz@kdab.com> <201512092254.22883.marc.mutz@kdab.com> Message-ID: <5871444.AOchpK5Pub@tjmaciei-mobl4> On Wednesday 09 December 2015 22:54:22 Marc Mutz wrote: > Whatever happened to KISS? That's a good reason not to run clang-modernize and force people to review. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mwoehlke.floss at gmail.com Wed Dec 9 23:41:26 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 09 Dec 2015 17:41:26 -0500 Subject: [Development] RFF: nullptr rules In-Reply-To: <1897245.5mlEbTrKZ8@tjmaciei-mobl4> References: <201512091614.00734.marc.mutz@kdab.com> <2798447.IKuPeqeCOI@tjmaciei-mobl4> <201512092247.52291.marc.mutz@kdab.com> <1897245.5mlEbTrKZ8@tjmaciei-mobl4> Message-ID: On 2015-12-09 17:29, Thiago Macieira wrote: > On Wednesday 09 December 2015 22:47:51 Marc Mutz wrote: > I'd like to propose this: > [...] > c) which means no -Werror=zero-as-nullptr outside of headersclean I just want to say that I think this is fair. The key phrase there is "outside of". -Wzero-as-nullptr is controversial and I can totally understand and accept the Qt project not wanting to go there. It's the *public* headers that (potentially) spill over into preventing other projects that use Qt from choosing to use -W[error=]zero-as-nullptr themselves. So only enforcing it there is more than sufficient to satisfy external consumers of Qt. (Also; thanks for thinking of said consumers!) -- Matthew From thiago.macieira at intel.com Wed Dec 9 23:50:54 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 09 Dec 2015 14:50:54 -0800 Subject: [Development] RFF: nullptr rules In-Reply-To: References: <201512091614.00734.marc.mutz@kdab.com> <1897245.5mlEbTrKZ8@tjmaciei-mobl4> Message-ID: <3495469.H59Wt5mJRa@tjmaciei-mobl4> On Wednesday 09 December 2015 17:41:26 Matthew Woehlke wrote: > On 2015-12-09 17:29, Thiago Macieira wrote: > > On Wednesday 09 December 2015 22:47:51 Marc Mutz wrote: > > > > I'd like to propose this: > > [...] > > c) which means no -Werror=zero-as-nullptr outside of headersclean > > I just want to say that I think this is fair. The key phrase there is > "outside of". -Wzero-as-nullptr is controversial and I can totally > understand and accept the Qt project not wanting to go there. It's the > *public* headers that (potentially) spill over into preventing other > projects that use Qt from choosing to use -W[error=]zero-as-nullptr > themselves. So only enforcing it there is more than sufficient to > satisfy external consumers of Qt. For headersclean, we can already enable for 5.6. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Gabriel.deDietrich at theqtcompany.com Thu Dec 10 01:03:25 2015 From: Gabriel.deDietrich at theqtcompany.com (deDietrich Gabriel) Date: Thu, 10 Dec 2015 00:03:25 +0000 Subject: [Development] toLower() vs. toCaseFolded() In-Reply-To: <5943591.JzShLcks9d@tjmaciei-mobl4> References: <201512091154.55089.marc.mutz@kdab.com> <201512092256.49246.marc.mutz@kdab.com> <5943591.JzShLcks9d@tjmaciei-mobl4> Message-ID: <09F74151-6155-454F-B7BE-EBE62510EC93@digia.com> On Dec 9, 2015, at 1:27 PM, Thiago Macieira > wrote: For example, when title-casing in French, you drop accents ("école" becomes "Ecole"). This is off-topic but no, you don’t. Please, stop propagating this. This is a common mistake introduced mostly during the typewriter era and perpetuated by the (obvious, in my opinion) inadequacy of the AZERTY keyboard layout and input methods for writing French. The Académie française is unambiguously clear about accents on capital letters as are all serious French typography guides. Mandatory Wikipedia link: https://fr.wikipedia.org/wiki/Usage_des_majuscules_en_français#Accentuation_des_majuscules_et_des_capitales (actually, the English article is a bit more explicit about the current state of confusion https://en.wikipedia.org/wiki/Capitalization#Accents). Best regards, Dr. Gabriel de Dietrich Senior Software Developer The Qt Company — www.qt.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at theqtcompany.com Thu Dec 10 05:42:12 2015 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Thu, 10 Dec 2015 04:42:12 +0000 Subject: [Development] Qt 5.7 feature freeze postponed, new date to be agreed In-Reply-To: <566868A4.3000008@rpzdesign.com> References: , <566868A4.3000008@rpzdesign.com> Message-ID: <4519F337-45CA-4C88-BD84-8FAA1B768F44@theqtcompany.com> Hi, A blog post is in the works, but not yet published. Now we have been focusing to get the Qt 5.6 beta out. We have not changed how Qt is built, codereview or the HW of CI, it is only the CI SW side that is renewed. Yours, -- Tuukka "md at rpzdesign.com" > kirjoitti 9.12.2015 kello 19.46: Tuuka: I was looking around for "Coin CI" information on google. Can you provide links and additional insight into this CI? We have a thread on the interest list related to CI. md On 12/9/2015 9:58 AM, Turunen Tuukka wrote: Hi, 15th Jan sounds good to me as the new FF time for Qt 5.7. The idea is to have the currently TP modules (at least many of them) supported with Qt 5.7 and also to drop the non-C++11 compilers as already discussed, agreed and implemented for dev. Therefore the content of Qt 5.7 is to a large extent already shaping up and in case someone has new features just starting, these are probably better to aim towards Qt 5.8. I really would like us the finally get to the desired April & October release cycle during 2016 with the new Coin CI. Even though moving Qt 5.7 FF to 15th Jan means the final being in May instead of April, I think it is something we can accept. Yours, Tuukka From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Heikkinen Jani Sent: keskiviikkona 9. joulukuuta 2015 12.22 To: development at qt-project.org Subject: [Development] Qt 5.7 feature freeze postponed, new date to be agreed Importance: High Hi all, According to original plans we should have Qt 5.7 FF next Friday (18th Dec). But we are still fighting to get Qt 5.6 (beta) out so there is no point to start freezing Qt 5.7 yet. We discussed about that yesterday's release team meeting & agreed to start discussion in ML about the issue. Ideally we should wait Qt 5.6.0 RC before start freezing Qt 5.7. But waiting Qt 5.6.0 RC might cause unnecessary delay for Qt 5.7 as well and I don't want to postpone 5.7 so much. That's why I propose 15th Jan 2016 for new feature freeze date for Qt 5.7. It should be quite near Qt 5.6.0 RC (if we managed to get Qt 5.6.0 out during next week as planned). br, Jani _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From joerg.bornemann at theqtcompany.com Thu Dec 10 10:25:14 2015 From: joerg.bornemann at theqtcompany.com (Joerg Bornemann) Date: Thu, 10 Dec 2015 10:25:14 +0100 Subject: [Development] RFF: nullptr rules In-Reply-To: <201512091941.29325.marc.mutz@kdab.com> References: <201512091614.00734.marc.mutz@kdab.com> <56684ADA.70106@theqtcompany.com> <201512091941.29325.marc.mutz@kdab.com> Message-ID: <566944FA.9070300@theqtcompany.com> On 09-Dec-15 19:41, Marc Mutz wrote: > What part of "author's prerogative" was unclear? Unclear is, why you take the time to answer but horribly fail to explain why you deem it necessary to enforce this particular insignificant language glitch fix. Thanks, Joerg From mathias at taschenorakel.de Thu Dec 10 10:52:15 2015 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Thu, 10 Dec 2015 10:52:15 +0100 Subject: [Development] RFF: nullptr rules In-Reply-To: <56685AA5.9020004@taschenorakel.de> References: <201512091614.00734.marc.mutz@kdab.com> <56685AA5.9020004@taschenorakel.de> Message-ID: <56694B4F.5040709@taschenorakel.de> Am 09.12.2015 um 17:45 schrieb Mathias Hasselmann: > > > Am 09.12.2015 um 16:14 schrieb Marc Mutz: > >> Arguments in favour: >> - it's the C++ way of writing the null pointer constant these days >> - we need to use it in headers, anyway, to allow people to use >> -Wzero-as..., >> and it makes no sense to have two sets of rules for headers and impl >> - it can disambiguate code and prevent accidents >> - in some situations, it makes code easier to understand (: >> m_foo(nullptr)). >> >> Arguments against: >> - it's uglier than "0", and more to type > > Have we discussed "{}" instead of "nullptr", or "0" already? This actually was a serious question: What are the opinions on using "{}" instead of "0" or "nullptr" to initialize a pointer? Ciao, Mathias From olivier at woboq.com Thu Dec 10 11:12:42 2015 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 10 Dec 2015 11:12:42 +0100 Subject: [Development] RFF: nullptr rules In-Reply-To: <56694B4F.5040709@taschenorakel.de> References: <201512091614.00734.marc.mutz@kdab.com> <56685AA5.9020004@taschenorakel.de> <56694B4F.5040709@taschenorakel.de> Message-ID: <1563489.Mupr78NZz6@finn> On Thursday 10. December 2015 10:52:15 Mathias Hasselmann wrote: > Am 09.12.2015 um 17:45 schrieb Mathias Hasselmann: > > Am 09.12.2015 um 16:14 schrieb Marc Mutz: > >> Arguments in favour: > >> - it's the C++ way of writing the null pointer constant these days > >> - we need to use it in headers, anyway, to allow people to use > >> -Wzero-as..., > >> > >> and it makes no sense to have two sets of rules for headers and impl > >> > >> - it can disambiguate code and prevent accidents > >> - in some situations, it makes code easier to understand (: > >> m_foo(nullptr)). > >> > >> Arguments against: > >> - it's uglier than "0", and more to type > > > > Have we discussed "{}" instead of "nullptr", or "0" already? > > This actually was a serious question: What are the opinions on using > "{}" instead of "0" or "nullptr" to initialize a pointer? We still support compilers that does not support uniform initialization. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From jani.heikkinen at theqtcompany.com Thu Dec 10 12:43:49 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Thu, 10 Dec 2015 11:43:49 +0000 Subject: [Development] Qt 5.6.0 Beta candidate packages available Message-ID: Hi, We have finally Qt 5.6.0 beta candidate packages available: Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/224/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/290/ Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/283/ src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ All known blockers are fixed in these packages so if nothing serious found during testing we will release these package as Qt 5.6.0 beta on Monday so please inform me immediately if you find something badly broken. br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From helio at kde.org Thu Dec 10 12:57:12 2015 From: helio at kde.org (Helio Chissini de Castro) Date: Thu, 10 Dec 2015 12:57:12 +0100 Subject: [Development] Qt 5.6.0 Beta candidate packages available In-Reply-To: References: Message-ID: Ok, again We're told that the splitted packages will be available with the beta release ( not the snapshots ). This still considered a snapshot or we packagers will be ignored until someone say "released" ? And how we suppose to test and inform you, if we don't have the proper set ? Helio On Thu, Dec 10, 2015 at 12:43 PM, Heikkinen Jani < jani.heikkinen at theqtcompany.com> wrote: > Hi, > > > We have finally Qt 5.6.0 beta candidate packages available: > > > Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/224/ > > Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/290/ > > Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/283/ > > src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ > > > All known blockers are fixed in these packages so if nothing serious found > during testing we will release these package as Qt 5.6.0 beta on Monday so > please inform me immediately if you find something badly broken. > > > br, > > Jani > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Thu Dec 10 14:36:49 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 10 Dec 2015 14:36:49 +0100 Subject: [Development] RFF: nullptr rules In-Reply-To: <566944FA.9070300@theqtcompany.com> References: <201512091614.00734.marc.mutz@kdab.com> <201512091941.29325.marc.mutz@kdab.com> <566944FA.9070300@theqtcompany.com> Message-ID: <201512101436.49880.marc.mutz@kdab.com> On Thursday 10 December 2015 10:25:14 Joerg Bornemann wrote: > On 09-Dec-15 19:41, Marc Mutz wrote: > > What part of "author's prerogative" was unclear? > > Unclear is, why you take the time to answer but horribly fail to explain > why you deem it necessary to enforce this particular insignificant > language glitch fix. You were quoting a footnote that said: > [1] I prefer the short form, but I don't think we'll gain a consensus here, > so let's not even try This footnote is in the context of if (!foo) vs if (foo == nullptr). Quoting this footnote, you asked: > So why do you try yet? Which I interpreted as referring to the footnote. In the context, the question makes no sense, because I wasn't "trying yet". From your reply now, it seems that you had all of the proposal in mind. In that case, the placement of your question was very misleading. As for why we need to have rules for nullptr: It's a funny you should ask, because you're contributing to a project that mandates the placement of {}s in minute detail. It's unclear why there should be no guideline for 0 vs. nullptr if there is for for() vs. for (). The rationale, in both cases, of course, is: consistency. HTH, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From jani.heikkinen at theqtcompany.com Thu Dec 10 14:10:52 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Thu, 10 Dec 2015 13:10:52 +0000 Subject: [Development] Qt 5.6.0 Beta candidate packages available In-Reply-To: References: Message-ID: Hi! Mirroring in ongoing. Splitted src packages will be in download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/submodules Br, Jani From: heliocastro at gmail.com [mailto:heliocastro at gmail.com] On Behalf Of Helio Chissini de Castro Sent: 10. joulukuuta 2015 13:57 To: Heikkinen Jani Cc: development at qt-project.org Subject: Re: [Development] Qt 5.6.0 Beta candidate packages available Ok, again We're told that the splitted packages will be available with the beta release ( not the snapshots ). This still considered a snapshot or we packagers will be ignored until someone say "released" ? And how we suppose to test and inform you, if we don't have the proper set ? Helio On Thu, Dec 10, 2015 at 12:43 PM, Heikkinen Jani > wrote: Hi, We have finally Qt 5.6.0 beta candidate packages available: Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/224/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/290/ Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/283/ src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ All known blockers are fixed in these packages so if nothing serious found during testing we will release these package as Qt 5.6.0 beta on Monday so please inform me immediately if you find something badly broken. br, Jani _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From helio at kde.org Thu Dec 10 14:11:59 2015 From: helio at kde.org (Helio Chissini de Castro) Date: Thu, 10 Dec 2015 14:11:59 +0100 Subject: [Development] Qt 5.6.0 Beta candidate packages available In-Reply-To: References: Message-ID: Hello Thanks for that. Best, Helio On Thu, Dec 10, 2015 at 2:10 PM, Heikkinen Jani < jani.heikkinen at theqtcompany.com> wrote: > Hi! > > > > Mirroring in ongoing. Splitted src packages will be in > download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/submodules > > > > Br, > > Jani > > > > *From:* heliocastro at gmail.com [mailto:heliocastro at gmail.com] *On Behalf > Of *Helio Chissini de Castro > *Sent:* 10. joulukuuta 2015 13:57 > *To:* Heikkinen Jani > *Cc:* development at qt-project.org > *Subject:* Re: [Development] Qt 5.6.0 Beta candidate packages available > > > > Ok, again > > We're told that the splitted packages will be available with the beta > release ( not the snapshots ). > > This still considered a snapshot or we packagers will be ignored until > someone say "released" ? > > And how we suppose to test and inform you, if we don't have the proper set > ? > > > > Helio > > > > On Thu, Dec 10, 2015 at 12:43 PM, Heikkinen Jani < > jani.heikkinen at theqtcompany.com> wrote: > > Hi, > > > > We have finally Qt 5.6.0 beta candidate packages available: > > > > Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/224/ > > Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/290/ > > Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/283/ > > src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ > > > > All known blockers are fixed in these packages so if nothing serious found > during testing we will release these package as Qt 5.6.0 beta on Monday so > please inform me immediately if you find something badly broken. > > > > br, > > Jani > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From milian.wolff at kdab.com Thu Dec 10 14:39:17 2015 From: milian.wolff at kdab.com (Milian Wolff) Date: Thu, 10 Dec 2015 14:39:17 +0100 Subject: [Development] RFF: nullptr rules In-Reply-To: <201512101436.49880.marc.mutz@kdab.com> References: <201512091614.00734.marc.mutz@kdab.com> <566944FA.9070300@theqtcompany.com> <201512101436.49880.marc.mutz@kdab.com> Message-ID: <2437493.9i5hK11cGl@agathebauer> On Donnerstag, 10. Dezember 2015 14:36:49 CET Marc Mutz wrote: > As for why we need to have rules for nullptr: It's a funny you should ask, > because you're contributing to a project that mandates the placement of {}s > in minute detail. It's unclear why there should be no guideline for 0 vs. > nullptr if there is for for() vs. for (). > > The rationale, in both cases, of course, is: consistency. This, for me, is btw. a very strong argument in favor of requesting nullptr everywhere. Personally, I'd be in favor of running clang-modernize on Qt and asking people to use nullptr in new code. Reviewing the patch of clang-modernize is easy btw. It either compiles and is good, or it doesn't and needs work. None of this needs manual review. -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From joerg.bornemann at theqtcompany.com Thu Dec 10 15:02:09 2015 From: joerg.bornemann at theqtcompany.com (Joerg Bornemann) Date: Thu, 10 Dec 2015 15:02:09 +0100 Subject: [Development] RFF: nullptr rules In-Reply-To: <201512101436.49880.marc.mutz@kdab.com> References: <201512091614.00734.marc.mutz@kdab.com> <201512091941.29325.marc.mutz@kdab.com> <566944FA.9070300@theqtcompany.com> <201512101436.49880.marc.mutz@kdab.com> Message-ID: <566985E1.1070707@theqtcompany.com> On 10-Dec-15 14:36, Marc Mutz wrote: > As for why we need to have rules for nullptr: It's a funny you should ask, > because you're contributing to a project that mandates the placement of {}s in > minute detail. It's unclear why there should be no guideline for 0 vs. nullptr > if there is for for() vs. for (). > > The rationale, in both cases, of course, is: consistency. The consequence of this argument is that we need a rule for every language feature for consistency. Please, no. I was arguing that the unconditional enforcement of nullptr is solving a non-issue. BR, Joerg From Marco.Bubke at theqtcompany.com Thu Dec 10 15:25:06 2015 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Thu, 10 Dec 2015 14:25:06 +0000 Subject: [Development] RFF: nullptr rules In-Reply-To: <566985E1.1070707@theqtcompany.com> References: <201512091614.00734.marc.mutz@kdab.com> <201512091941.29325.marc.mutz@kdab.com> <566944FA.9070300@theqtcompany.com> <201512101436.49880.marc.mutz@kdab.com>, <566985E1.1070707@theqtcompany.com> Message-ID: I think it less a technical issue. To me it looked very perlish to use zero to mark a defined invalid pointer but C++ is full of this expert language hacks. I think it is more a social issue because Qt can look to old fashion. New people who discover Qt maybe get the same feeling as I got in nineties as I looked at Motif. So I think the question should be how much harm is produced by this policy? I don't see any except people have to change their habits. ________________________________________ From: Development on behalf of Joerg Bornemann Sent: Thursday, December 10, 2015 3:02 PM To: development at qt-project.org Subject: Re: [Development] RFF: nullptr rules On 10-Dec-15 14:36, Marc Mutz wrote: > As for why we need to have rules for nullptr: It's a funny you should ask, > because you're contributing to a project that mandates the placement of {}s in > minute detail. It's unclear why there should be no guideline for 0 vs. nullptr > if there is for for() vs. for (). > > The rationale, in both cases, of course, is: consistency. The consequence of this argument is that we need a rule for every language feature for consistency. Please, no. I was arguing that the unconditional enforcement of nullptr is solving a non-issue. BR, Joerg _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Kai.Koehne at theqtcompany.com Thu Dec 10 15:37:57 2015 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Thu, 10 Dec 2015 14:37:57 +0000 Subject: [Development] buildsystem now needs to keep behaviour compatibility In-Reply-To: <20151209104433.GB29009@troll08.it.local> References: <2394178.nH4WTEmeSG@tjmaciei-mobl4> <565EB745.8080507@theqtcompany.com> <22298513.hvfALFAysn@finn> <20151209104433.GB29009@troll08.it.local> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On > Behalf Of Oswald Buddenhagen > Sent: Wednesday, December 09, 2015 11:45 AM > To: development at qt-project.org > Cc: releasing at qt-project.org > Subject: Re: [Development] buildsystem now needs to keep behaviour > compatibility > > On Wed, Dec 02, 2015 at 01:04:40PM +0100, Olivier Goffart wrote: > > On Wednesday 2. December 2015 10:17:57 Joerg Bornemann wrote: > > > We should then keep build tests for these modules in the CI. > > > Otherwise we won't notice breakages. > > > > I agree. > > > this is true. > but that basically defeats the whole point, which was not needing to care > about these modules any more. > > now reality caught up already and it turns out that i broke webkit. > well, what i actually did, i broke bug-to-bug compatibility, which exposed a > pre-existing problem in webkit, as it usually goes. > > it would be possible to revert the respective qmake change (and uglify the > surrounding code), but i don't think it's reasonable to enforce this type of > stagnation - we generally accept that code which relies on undefined or > outright broken behavior is broken by fixes. > > so how do we go from there? i see several options: > - continue to drag along webkit and the other deprecated modules. the > additional cost of actually doing that in addition to compatibility > testing is rather low with the new CI. I think this is a good compromise. Let's do at least some minimal compile testing before a release, and fix the stuff that's absolutely necessary. We can talk again in case we run into issues that would require some real work... https://bugreports.qt.io/browse/QTBUG-49883 Regards Kai > - release further 5.5.x versions of these modules when necessary. i > expect this to be a lot more effort than the first option, so it > doesn't seem reasonable. > - simply accept that it's broken, and tell people to apply patches. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From joerg.bornemann at theqtcompany.com Thu Dec 10 15:38:15 2015 From: joerg.bornemann at theqtcompany.com (Joerg Bornemann) Date: Thu, 10 Dec 2015 15:38:15 +0100 Subject: [Development] RFF: nullptr rules In-Reply-To: References: <201512091614.00734.marc.mutz@kdab.com> <201512091941.29325.marc.mutz@kdab.com> <566944FA.9070300@theqtcompany.com> <201512101436.49880.marc.mutz@kdab.com> <566985E1.1070707@theqtcompany.com> Message-ID: <56698E57.1080209@theqtcompany.com> On 10-Dec-15 15:25, Bubke Marco wrote: > I think it less a technical issue. To me it looked very perlish > to use zero to mark a defined invalid pointer but C++ is full of this expert > language hacks. You still will need this thourough expert knowledge if you encounter a crash and the backtrace/debugger tells you that memory near address 0x00000000 has been accessed. There is no fancy popup that yells "invalid pointer" at you. Also, for some reason it was decided to call the keyword nullptr. If that's not a hint for the inexperienced developer / leakage of implementation details... > I think it is more a social issue because Qt can look to old fashion. > New people who discover Qt maybe get the same feeling as I got in > nineties as I looked at Motif. errm...no > So I think the question should be how much harm is produced > by this policy? I don't see any except people have to change their > habits. How much harm is produced by forbidding do while loops? How much harm is done by changing every Foo > to Foo>? BR, Joerg From sergio.martins at kdab.com Thu Dec 10 17:23:50 2015 From: sergio.martins at kdab.com (Sergio Martins) Date: Thu, 10 Dec 2015 16:23:50 +0000 Subject: [Development] RFF: nullptr rules In-Reply-To: <56684ADA.70106@theqtcompany.com> References: <201512091614.00734.marc.mutz@kdab.com> <56684ADA.70106@theqtcompany.com> Message-ID: <2174373.BeS3oEKe0q@desktop> On Wednesday, 9 December 2015 16:38:02 WET Joerg Bornemann wrote: > > - in some situations, it makes code easier to understand (: > > m_foo(nullptr)). > So nullptr is easier to understand, because assigning 0 to a pointer > variable didn't make clear that it now contains a null pointer? > If there's need to signify using m_foo(nullptr) that m_foo is a pointer, > then m_foo is maybe a bad name and should be fixed. : m_foo(0) What if m_foo was a bool, would you rename the variable or use false instead of 0 ? Regards, -- Sérgio Martins | sergio.martins at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From sergio.martins at kdab.com Thu Dec 10 17:24:02 2015 From: sergio.martins at kdab.com (Sergio Martins) Date: Thu, 10 Dec 2015 16:24:02 +0000 Subject: [Development] RFF: nullptr rules In-Reply-To: <1897245.5mlEbTrKZ8@tjmaciei-mobl4> References: <201512091614.00734.marc.mutz@kdab.com> <201512092247.52291.marc.mutz@kdab.com> <1897245.5mlEbTrKZ8@tjmaciei-mobl4> Message-ID: <2066004.iCHARKlK11@desktop> On Wednesday, 9 December 2015 14:29:19 WET Thiago Macieira wrote: > On Wednesday 09 December 2015 22:47:51 Marc Mutz wrote: > > > const char *ptr = 0; > > > > What we agreed on was for Q_NULLPTR. > > > > Some developers back then were complaining that the *macro* is ugly, and > > that by 5.7, we would be able to use the real thing and didn't want the > > double conversion 0 -> Q_NULLPTR -> nullptr. > > > > The agreement back then also was not to rely on the disambiguating > > features > > of nullptr, because Q_NULLPTR might be 0. > > > > Now we can use the real thing. With real nullptr semantics. > > True. > > I'd like to propose this: > a) no massive replacement or clang-modernize, for the reasons Richard > pointed out > b) which means existing zeroes continue in sources and private headers > c) which means no -Werror=zero-as-nullptr outside of headersclean > > New code should use nullptr where it improves readability. > > Changes to existing code can update to use nullptr. > > But I don't think we should mandate use of nullptr everywhere. Where it's > unambiguous, it doesn't add value. bool foo = 0; This is unambiguous, just like your "const char *ptr = 0" example, so "= false" wouldn't add value ? Regards, -- Sérgio Martins | sergio.martins at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From joerg.bornemann at theqtcompany.com Thu Dec 10 17:42:30 2015 From: joerg.bornemann at theqtcompany.com (Joerg Bornemann) Date: Thu, 10 Dec 2015 17:42:30 +0100 Subject: [Development] RFF: nullptr rules In-Reply-To: <2174373.BeS3oEKe0q@desktop> References: <201512091614.00734.marc.mutz@kdab.com> <56684ADA.70106@theqtcompany.com> <2174373.BeS3oEKe0q@desktop> Message-ID: <5669AB76.9060600@theqtcompany.com> On 10-Dec-15 17:23, Sergio Martins wrote: >>> - in some situations, it makes code easier to understand (: >>> m_foo(nullptr)). >> So nullptr is easier to understand, because assigning 0 to a pointer >> variable didn't make clear that it now contains a null pointer? >> If there's need to signify using m_foo(nullptr) that m_foo is a pointer, >> then m_foo is maybe a bad name and should be fixed. > > : m_foo(0) > > What if m_foo was a bool, would you rename the variable or use false instead > of 0 ? Nowadays, that bool is a native type, I would of course use the keyword false, because the type bool takes the values true or false. Anything else would be an implicit conversion, unlike in pointer assignments. BR, Joerg From jturcotte at woboq.com Thu Dec 10 18:42:05 2015 From: jturcotte at woboq.com (Jocelyn Turcotte) Date: Thu, 10 Dec 2015 18:42:05 +0100 Subject: [Development] RFF: nullptr rules In-Reply-To: <1897245.5mlEbTrKZ8@tjmaciei-mobl4> References: <201512091614.00734.marc.mutz@kdab.com> <2798447.IKuPeqeCOI@tjmaciei-mobl4> <201512092247.52291.marc.mutz@kdab.com> <1897245.5mlEbTrKZ8@tjmaciei-mobl4> Message-ID: <62235DEC-8A8F-482D-B1C9-41969153C22D@woboq.com> > On 09 Dec 2015, at 23:29, Thiago Macieira wrote: > > I'd like to propose this: > a) no massive replacement or clang-modernize, for the reasons Richard pointed > out > b) which means existing zeroes continue in sources and private headers > c) which means no -Werror=zero-as-nullptr outside of headersclean > > New code should use nullptr where it improves readability. > > Changes to existing code can update to use nullptr. > > But I don't think we should mandate use of nullptr everywhere. Where it's > unambiguous, it doesn't add value. (I’m not sure what is the official protocol to know when we’ve reached a consensus unless we vote somehow, so:) +1 I personally don't think that the consistency gain is worth the cost that’d we’d pay in history conciseness if we would change 0 —> nullptr everywhere. IMO yes, we should be encouraged to use nullptr through the coding convention, but it’s also difficult to convince a whole community to accept being required to use a new toy before everybody had some time to play a bit with it, and like it. So doing this progressively and relying on author+reviewer common sense also seems to me like a good compromise. Cheers, Jocelyn From thiago.macieira at intel.com Thu Dec 10 19:35:42 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 10 Dec 2015 10:35:42 -0800 Subject: [Development] RFF: nullptr rules In-Reply-To: <2066004.iCHARKlK11@desktop> References: <201512091614.00734.marc.mutz@kdab.com> <1897245.5mlEbTrKZ8@tjmaciei-mobl4> <2066004.iCHARKlK11@desktop> Message-ID: <1699671.DrdGk8q2Ef@tjmaciei-mobl4> On Thursday 10 December 2015 16:24:02 Sergio Martins wrote: > > But I don't think we should mandate use of nullptr everywhere. Where it's > > unambiguous, it doesn't add value. > > bool foo = 0; > > This is unambiguous, just like your "const char *ptr = 0" example, so "= > false" wouldn't add value ? Strictly and technically speaking, that is true. Current coding practice is that we don't do it. I am willing to accept that using nullptr improves readability and people should use it if they want to. But I don't want -1s going on because someone's muscle memory used a 0 instead of nullptr. More importantly, I don't want a massive code change, because it will not catch everything and it will cause unnecessary churn and merge conflicts. Clang-modernize requires inspecting all platforms and that will not happen. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Lars.Knoll at theqtcompany.com Fri Dec 11 08:44:29 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Fri, 11 Dec 2015 07:44:29 +0000 Subject: [Development] buildsystem now needs to keep behaviour compatibility In-Reply-To: References: <2394178.nH4WTEmeSG@tjmaciei-mobl4> <565EB745.8080507@theqtcompany.com> <22298513.hvfALFAysn@finn> <20151209104433.GB29009@troll08.it.local> Message-ID: <354D5F9D-0E08-46F4-AAED-5BB2E4927AB5@theqtcompany.com> On 10/12/15 15:37, "Development on behalf of Koehne Kai" wrote: > > >> -----Original Message----- >> From: Development [mailto:development-bounces at qt-project.org] On >> Behalf Of Oswald Buddenhagen >> Sent: Wednesday, December 09, 2015 11:45 AM >> To: development at qt-project.org >> Cc: releasing at qt-project.org >> Subject: Re: [Development] buildsystem now needs to keep behaviour >> compatibility >> >> On Wed, Dec 02, 2015 at 01:04:40PM +0100, Olivier Goffart wrote: >> > On Wednesday 2. December 2015 10:17:57 Joerg Bornemann wrote: >> > > We should then keep build tests for these modules in the CI. >> > > Otherwise we won't notice breakages. >> > >> > I agree. >> > >> this is true. >> but that basically defeats the whole point, which was not needing to care >> about these modules any more. >> >> now reality caught up already and it turns out that i broke webkit. >> well, what i actually did, i broke bug-to-bug compatibility, which exposed a >> pre-existing problem in webkit, as it usually goes. >> >> it would be possible to revert the respective qmake change (and uglify the >> surrounding code), but i don't think it's reasonable to enforce this type of >> stagnation - we generally accept that code which relies on undefined or >> outright broken behavior is broken by fixes. >> >> so how do we go from there? i see several options: >> - continue to drag along webkit and the other deprecated modules. the >> additional cost of actually doing that in addition to compatibility >> testing is rather low with the new CI. > >I think this is a good compromise. Let's do at least some minimal compile testing before a release, and fix the stuff that's absolutely necessary. We can talk again in case we run into issues that would require some real work... +1. This is probably the best compromise we can come up with. Cheers, Lars > >https://bugreports.qt.io/browse/QTBUG-49883 > >Regards > >Kai > > >> - release further 5.5.x versions of these modules when necessary. i >> expect this to be a lot more effort than the first option, so it >> doesn't seem reasonable. >> - simply accept that it's broken, and tell people to apply patches. >> _______________________________________________ >> 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 christianbauer at siemens.com Fri Dec 11 11:05:00 2015 From: christianbauer at siemens.com (Bauer, Christian) Date: Fri, 11 Dec 2015 10:05:00 +0000 Subject: [Development] QFutureInterface In-Reply-To: <201512041401.25747.marc.mutz@kdab.com> References: <54B0CAFD8875674EAD2C2C03BA3652F001849F66@DENBGAT9EI5MSX.ww902.siemens.net> <201512041018.08201.marc.mutz@kdab.com> <54B0CAFD8875674EAD2C2C03BA3652F001855F85@DENBGAT9EI5MSX.ww902.siemens.net> <201512041401.25747.marc.mutz@kdab.com> Message-ID: <54B0CAFD8875674EAD2C2C03BA3652F001858C16@DENBGAT9EI5MSX.ww902.siemens.net> Hi, Sorry for the delay. > Yes, please provide a short example with std::promise, which, afaiu, works for your use-case. Below is a simplified example where a client calls an API function that blocks until the result is actually available. The request is sent to a queue, where a "server" thread sends a network packet to another host. As soon as the reply arrives from the network, another "server" thread uses the promise for delivering the result to the client. Thread 1 (called by client) -------- std::promise prom; // put promise into map for later retrieval by server thread promiseMap.insert(id, prom); // trigger work queue.enqueueWork(id, workItem); // get future and block until result becomes available std::future fut = prom.get_future(); return fut.get(); Thread 2 ("server" request thread) -------- workItem = queue.dequeueWork(); // do some work, then send the request sendRequest(workItem.id, workItem.content); Thread 3 ("server" reply thread) -------- reply = receiveReply(); // retrieve promise for the original request std::promise prom = promiseMap.get(reply.id); // deliver result to original requestor prom.set_value(reply.value); HTH Christian From rjvbertin at gmail.com Fri Dec 11 11:53:40 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 11 Dec 2015 11:53:40 +0100 Subject: [Development] [OS X]: native classes (widgets) used for QTabBar and QTabWidget? In-Reply-To: <2721025.pAapW6Em4q@finn> References: <2063068.e6xtoLpgx3@portia.local> <30229862.UKJP5bEaWm@patux.local> <2721025.pAapW6Em4q@finn> Message-ID: <5040648.nhchpUrkmA@patux> Olivier Goffart wrote: > On Tuesday 8. December 2015 21:38:10 René J. V. Bertin wrote: >> If I may, do you also know how it is determined whether or not push buttons >> should show icons or not? There's no equivalent to >> Qt::AA_DontShowIconsInMenus and I'm also trying to understand why certain >> KF5 applications (using kdelibs4support) always show icons in buttons [snip] > I believe you are looking for QStyle::SH_DialogButtonBox_ButtonsHaveIcons, > which is false for mac. Is it even possible for QPushButtons to show an icon on OS X, or does the Mac drawing style simply ignore any icons on buttons? If so, on all buttons or only on those in a QDialogButtonBox (i.e. those that can have an icon added automatically as a function of their role)? The code does seem to be a bit ambiguous about that style hint SH_DialogButtonBox_ButtonsHaveIcons. Is there a reason NOT to use this hint to turn off drawing of all button icons in a context (like KDE's) where there is a setting (ShowIconsOnPushButtons) that is intended to apply to all buttons? More generally, is there a reason NOT to give this hint this kind of a general application to all buttons in Qt itself (and thus ultimately rename it, or provide a corresponding Qt:AA_xxx attribute)? I can only think of 1: buttons created with only an icon, but it is trivial to to include to override a false ButtonsHaveIcons hint if button->text.isEmpty(). For instance: --- a/qtbase/src/widgets/widgets/qpushbutton.cpp +++ b/qtbase/src/widgets/widgets/qpushbutton.cpp @@ -332,8 +332,13 @@ void QPushButton::initStyleOption(QStyleOptionButton *option) const if (!d->flat && !d->down) option->state |= QStyle::State_Raised; option->text = d->text; - option->icon = d->icon; - option->iconSize = iconSize(); + if (option->text.isEmpty() || style()->styleHint(QStyle::SH_DialogButtonBox_ButtonsHaveIcons)) { + option->icon = d->icon; + option->iconSize = iconSize(); + } else { + option->icon = QIcon(); + option->iconSize = QSize(0,0); + } } void QPushButton::setAutoDefault(bool enable) @@ -398,20 +403,20 @@ QSize QPushButton::sizeHint() const initStyleOption(&opt); // calculate contents size... + QString s(text()); + bool empty = s.isEmpty(); #ifndef QT_NO_ICON bool showButtonBoxIcons = qobject_cast(parentWidget()) && style()->styleHint(QStyle::SH_DialogButtonBox_ButtonsHaveIcons); - if (!icon().isNull() || showButtonBoxIcons) { + if (!icon().isNull() && (showButtonBoxIcons || empty)) { int ih = opt.iconSize.height(); int iw = opt.iconSize.width() + 4; w += iw; h = qMax(h, ih); } #endif - QString s(text()); - bool empty = s.isEmpty(); if (empty) s = QString::fromLatin1("XXXX"); QFontMetrics fm = fontMetrics(); -------------- next part -------------- An HTML attachment was scrubbed... URL: From antonxx at gmx.de Sat Dec 12 10:22:03 2015 From: antonxx at gmx.de (anton) Date: Sat, 12 Dec 2015 10:22:03 +0100 Subject: [Development] New Qt5.6 Beta snapshot available References: Message-ID: Hi, just tested the visualstudio 2015 version on windows. One thing I noticed: In the Designer of a Qt Widgets Application, the QWebView Widget is missing. Are you aware of this? Thanks Anton Heikkinen Jani wrote: > Hi all, > > > We have finally new qt5.6 beta snapshot available > > > Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/278/ > > Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/287/ > > Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/221/ > > Src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ > > > > Unfortunately it seems these aren't yet final beta packages, in mac > package creator seems to be unusable because of > QTBUG-49676 [Reg 5.5->5.6]: > Painting of widgets broken when embedding QQuickWidget > > > Please test the packages & report all findings in Jira. We are trying to > get beta out as soon as possible so please inform all new beta blockers to > me immediately. > > > br, > > Jani From nsukeg at gmail.com Sat Dec 12 12:59:18 2015 From: nsukeg at gmail.com (Nobuaki Sukegawa) Date: Sat, 12 Dec 2015 11:59:18 +0000 Subject: [Development] Review request for ArrayBuffer+WebSocket/XHR (a.k.a Introducing protobuf-qml) Message-ID: Hello Qt team and community, Could anyone help me with reviews on ArrayBuffer support for QtWebSockets and QtQuick XMLHttpRequest ? WebSockets: https://codereview.qt-project.org/#/c/125712/ XHR: https://codereview.qt-project.org/#/c/143732/ While I believe these features are generally useful, let me share my motivation: I've written Protocol Buffers / gRPC bindings for QtQuick2. https://github.com/nsuke/protobuf-qml Main feature of this is to serialize schematized message objects to ArrayBuffer. While it works fine for my need (plugging to proprietary RPC stack), I'd like to share this with others and see what they would do with this. Unfortunately, currently ArrayBuffer is not that useful out of the box as is, so it's not going to be much of interest without these features. You can find working examples of these patches here: WebSockets https://github.com/nsuke/protobuf-qml/blob/master/examples/WebSockets/client/client.qml#L105 XHR https://github.com/nsuke/protobuf-qml/blob/master/examples/XMLHttpRequest/client/XhrClient.qml#L112 Best regards, Nobuaki Sukegawa -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Sun Dec 13 10:35:50 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Sun, 13 Dec 2015 10:35:50 +0100 Subject: [Development] monkey curiosity: Qt::AA_MacDontSwapCtrlAndMeta and the XCB plugin Message-ID: <53710191.q8tAV7vJHY@patux> Hi, Mostly out of personal interest: When running Qt applications with the XCB plugin on OS X everything mostly works, except notably for menu shortcuts. I've long suspected that this has to do with the Ctrl/Meta swap; where would be the appropriate place to set Qt::AA_MacDontSwapCtrlAndMeta to true in the XCB plugin code to test that hypothesis? Thanks, René From marc.mutz at kdab.com Sun Dec 13 13:46:14 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Sun, 13 Dec 2015 13:46:14 +0100 Subject: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings In-Reply-To: <201510132246.37689.marc.mutz@kdab.com> References: <201510132246.37689.marc.mutz@kdab.com> Message-ID: <201512131346.14838.marc.mutz@kdab.com> On Tuesday 13 October 2015 22:46:36 Marc Mutz wrote: > I would propose to package the two into a class, called > - you guessed it - QStringView. I now started work on QStringView (and later QByteArrayView), here: https://codereview.qt-project.org/#/q/topic:qstringview,n,z Input welcome. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Eike.Ziller at theqtcompany.com Mon Dec 14 08:53:58 2015 From: Eike.Ziller at theqtcompany.com (Ziller Eike) Date: Mon, 14 Dec 2015 07:53:58 +0000 Subject: [Development] New Qt5.6 Beta snapshot available In-Reply-To: References: Message-ID: > On Dec 12, 2015, at 10:22 AM, anton wrote: > > Hi, > > just tested the visualstudio 2015 version on windows. > One thing I noticed: > > In the Designer of a Qt Widgets Application, > the QWebView Widget is missing. > > Are you aware of this? Since QtWebKit is deprecated and no binaries are provided, that is expected, yes. Br, Eike > Thanks > > Anton > > > Heikkinen Jani wrote: > >> Hi all, >> >> >> We have finally new qt5.6 beta snapshot available >> >> >> Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/278/ >> >> Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/287/ >> >> Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/221/ >> >> Src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ >> >> >> >> Unfortunately it seems these aren't yet final beta packages, in mac >> package creator seems to be unusable because of >> QTBUG-49676 [Reg 5.5->5.6]: >> Painting of widgets broken when embedding QQuickWidget >> >> >> Please test the packages & report all findings in Jira. We are trying to >> get beta out as soon as possible so please inform all new beta blockers to >> me immediately. >> >> >> br, >> >> Jani > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From olivier at woboq.com Mon Dec 14 11:52:15 2015 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 14 Dec 2015 11:52:15 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <20151205004445.GA2766@klara.mpi.htwm.de> Message-ID: <1924523.uU8nHp7Emt@finn> On Saturday 5. December 2015 00:57:23 Bubke Marco wrote: > > You are basically assuming that there's no need for you to write sane > > code to start with because during your development work you have a > > decent IDE to help you out. This assumption is wrong, independent > > of the existence of such an IDE. > > > > Since the discussion here is about what to use in Qt, the whole Qt > > development workflow matters. A lot of Qt code reading happens on Gerrit > > without IDE features at hand. The context there usually just a few lines. > > The appropriateness of an expression 'list[x]' is impossible to judge > > on Gerrit after applying an 'Almost always auto' policy. > > Oswald and I spoke about using the clang code model to provide the > information to gerrit too. It should be not that hard. > > But you have to import the code in the IDE anyway because of the missing > context. For non trivial change review the calling context is far to > important to be ignored. A html code browser could change that but we don't > have one in gerrit. I have made a user script to integrate http://code.woboq.org/qt5/ with gerrit. With that script, you can just click on a function in the code on gerrit and it will lookup in the code.woboq.org database and show the signature in a tooltip and links to code.woboq.org. (It shows a disambiguation popup if there are several possibilities.) It also makes the filename in the header of the diff clickable to the corresponding file on code.woboq.org Look at this screenshot: http://i.imgur.com/Q3a2ixz.png When you see the signature you can see the return type. And had 'auto' been used there, we would have known it's a QUrl. This does not work for all functions, but should already be of a great help when reviewing. The user script is there: https://code.woboq.org/qt-gerrit.user.js You can use it with the Greasmonkey extension on Firefox or the Tampermonkey extension on Chrome, or whatever equivalent extension for your browser. If qt-project's admins think it's a good idea they could enable it by default. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From Simon.Hausmann at theqtcompany.com Mon Dec 14 15:34:07 2015 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Mon, 14 Dec 2015 14:34:07 +0000 Subject: [Development] qtdeclarative 5.6 CI status Message-ID: Hi, I can see how people keep trying to integrate changes into qtdeclarative's 5.6 branch. Until https://codereview.qt-project.org/#/c/143824/ lands, all those attempts of integrating changes are going to fail, unfortunately :) Simon From alexander.blasche at theqtcompany.com Mon Dec 14 15:54:13 2015 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Mon, 14 Dec 2015 14:54:13 +0000 Subject: [Development] =?iso-8859-1?q?Nominating_Pasi_Ker=E4nen_for_Approv?= =?iso-8859-1?q?er_status?= In-Reply-To: <1971491.miAyTmngjk@frederik-thinkcentre-m93p> References: <1971491.miAyTmngjk@frederik-thinkcentre-m93p> Message-ID: >I'd like to nominate Pasi Keränen as Approver in the Qt Project. He is Congratulation. The Gerrit and Jira rights have been updated. -- Alex From sean.harmer at kdab.com Mon Dec 14 16:39:28 2015 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 14 Dec 2015 15:39:28 +0000 Subject: [Development] qtdeclarative 5.6 CI status In-Reply-To: References: Message-ID: <26865608.tHX7dILf4g@cartman> On Monday 14 Dec 2015 14:34:07 Hausmann Simon wrote: > Hi, > > I can see how people keep trying to integrate changes into qtdeclarative's > 5.6 branch. Until https://codereview.qt-project.org/#/c/143824/ lands, all > those attempts of integrating changes are going to fail, unfortunately :) Thanks, didn't realise. Thought it was a random failure. 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 Ravikiran_Polepalli at mentor.com Mon Dec 14 17:11:18 2015 From: Ravikiran_Polepalli at mentor.com (Polepalli, Ravikiran) Date: Mon, 14 Dec 2015 16:11:18 +0000 Subject: [Development] QML Memory leak. Message-ID: <2BC7AFDD92E258489867D1AB8D4CFF47DA31E6FB@EU-MBX-04.mgc.mentorg.com> Hi All, I'm working on a project and I'm affected by Memory leak in QML. https://bugreports.qt.io/browse/QTBUG-42055 https://bugreports.qt.io/browse/QTBUG-28712 I tried to run the test application(qml available in ticket) on a target board. In the application QML Object is created and destroyed for every 100ms. Application ran for 2 days. Here are observations: - Overall memory increased 1MB for every ~90mins. - Captured memory usage for every 10 mins(through pmap -x $pid). - Memory map is not changing except number of "[anon]" allocated memory blocks was growing constantly for every ~90mins. - At end of test run approximately 82 blocks were seen. - Could anyone help me understand where memory leak could possibly be? I would like to know if the memory leak is fixed. Any patch/solution available to fix this issue? Any help would be great. Thanks and regards, Ravikiran. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: main.qml Type: application/octet-stream Size: 656 bytes Desc: main.qml URL: From antonxx at gmx.de Mon Dec 14 19:11:15 2015 From: antonxx at gmx.de (anton) Date: Mon, 14 Dec 2015 19:11:15 +0100 Subject: [Development] New Qt5.6 Beta snapshot available References: Message-ID: So if I understand right, in a Qt Widgets Application I can no more embed a Html/Browser component anymore. I have to use QML instaed since WebView seems to be QML only (if I understood the docs). Anton PS: By the way: where can I see the roadmap of Qt? Ziller Eike wrote: > >> On Dec 12, 2015, at 10:22 AM, anton wrote: >> >> Hi, >> >> just tested the visualstudio 2015 version on windows. >> One thing I noticed: >> >> In the Designer of a Qt Widgets Application, >> the QWebView Widget is missing. >> >> Are you aware of this? > > Since QtWebKit is deprecated and no binaries are provided, that is > expected, yes. Br, Eike > >> Thanks >> >> Anton >> >> >> Heikkinen Jani wrote: >> >>> Hi all, >>> >>> >>> We have finally new qt5.6 beta snapshot available >>> >>> >>> Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/278/ >>> >>> Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/287/ >>> >>> Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/221/ >>> >>> Src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ >>> >>> >>> >>> Unfortunately it seems these aren't yet final beta packages, in mac >>> package creator seems to be unusable because of >>> QTBUG-49676 [Reg 5.5->5.6]: >>> Painting of widgets broken when embedding QQuickWidget >>> >>> >>> Please test the packages & report all findings in Jira. We are trying to >>> get beta out as soon as possible so please inform all new beta blockers >>> to me immediately. >>> >>> >>> br, >>> >>> Jani >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development From me at the-compiler.org Mon Dec 14 19:51:27 2015 From: me at the-compiler.org (Florian Bruhin) Date: Mon, 14 Dec 2015 19:51:27 +0100 Subject: [Development] New Qt5.6 Beta snapshot available In-Reply-To: References: Message-ID: <20151214185127.GC13519@tonks> * anton [2015-12-14 19:11:15 +0100]: > So if I understand right, > in a Qt Widgets Application I can no more embed > a Html/Browser component anymore. You can use QtWebEngine instead which is the successor of QtWebKit, and based on Chromium: http://wiki.qt.io/QtWebEngine Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From louai.al-khanji at theqtcompany.com Tue Dec 15 00:12:18 2015 From: louai.al-khanji at theqtcompany.com (Al-Khanji Louai) Date: Mon, 14 Dec 2015 23:12:18 +0000 Subject: [Development] New Qt5.6 Beta snapshot available In-Reply-To: <20151214185127.GC13519@tonks> References: ,<20151214185127.GC13519@tonks> Message-ID: The problem is that there is no designer plugin for QtWebEngine. Sorry for top posting. Louai On Mon, Dec 14, 2015 at 10:51 AM -0800, "Florian Bruhin" > wrote: * anton [2015-12-14 19:11:15 +0100]: > So if I understand right, > in a Qt Widgets Application I can no more embed > a Html/Browser component anymore. You can use QtWebEngine instead which is the successor of QtWebKit, and based on Chromium: http://wiki.qt.io/QtWebEngine Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at theqtcompany.com Tue Dec 15 08:29:22 2015 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Tue, 15 Dec 2015 07:29:22 +0000 Subject: [Development] qtdeclarative 5.6 CI status In-Reply-To: References: Message-ID: <20151215072922.5922896.31485.53232@theqtcompany.com> The crisis is over and resolved - happy staging :) Simon Original Message From: Hausmann Simon Sent: Monday, December 14, 2015 15:34 To: development at qt-project.org Subject: [Development] qtdeclarative 5.6 CI status Hi, I can see how people keep trying to integrate changes into qtdeclarative's 5.6 branch. Until https://codereview.qt-project.org/#/c/143824/ lands, all those attempts of integrating changes are going to fail, unfortunately :) Simon _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Kai.Koehne at theqtcompany.com Tue Dec 15 08:31:33 2015 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Tue, 15 Dec 2015 07:31:33 +0000 Subject: [Development] New Qt5.6 Beta snapshot available In-Reply-To: References: ,<20151214185127.GC13519@tonks> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On > Behalf Of Al-Khanji Louai > Sent: Tuesday, December 15, 2015 12:12 AM > To: development at qt-project.org; Florian Bruhin > Cc: antonxx at gmx.de > Subject: Re: [Development] New Qt5.6 Beta snapshot available > > The problem is that there is no designer plugin for QtWebEngine. True. You can use Qt Designer's 'Widget Promotion' though: http://doc.qt.io/qt-5/designer-using-custom-widgets.html#promoting-widgets Regards Kai From johannes.oikarinen at theqtcompany.com Tue Dec 15 09:06:37 2015 From: johannes.oikarinen at theqtcompany.com (Oikarinen Johannes) Date: Tue, 15 Dec 2015 08:06:37 +0000 Subject: [Development] New Qt5.6 Beta snapshot available In-Reply-To: References: ,<20151214185127.GC13519@tonks> Message-ID: Hi Anton, You should be able to embed browser component to QtWidget application by using WebEngine Widgets: http://doc.qt.io/qt-5/qtwebenginewidgets-index.html -Johannes From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Al-Khanji Louai Sent: 15. joulukuuta 2015 1:12 To: development at qt-project.org; Florian Bruhin Cc: antonxx at gmx.de Subject: Re: [Development] New Qt5.6 Beta snapshot available The problem is that there is no designer plugin for QtWebEngine. Sorry for top posting. Louai On Mon, Dec 14, 2015 at 10:51 AM -0800, "Florian Bruhin" > wrote: * anton > [2015-12-14 19:11:15 +0100]: > So if I understand right, > in a Qt Widgets Application I can no more embed > a Html/Browser component anymore. You can use QtWebEngine instead which is the successor of QtWebKit, and based on Chromium: http://wiki.qt.io/QtWebEngine Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at theqtcompany.com Tue Dec 15 09:21:37 2015 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Tue, 15 Dec 2015 08:21:37 +0000 Subject: [Development] =?iso-8859-1?q?Nominating_Pasi_Pet=E4j=E4j=E4rvi_fo?= =?iso-8859-1?q?r_Approver_status?= In-Reply-To: References: Message-ID: Congratulations to Pasi. Jira and Gerrit rights have been set. -- Alex ________________________________ From: Development on behalf of Agocs Laszlo Sent: Tuesday, November 24, 2015 10:04 To: development at qt-project.org Subject: [Development] Nominating Pasi Petäjäjärvi for Approver status Hello, I would like to nominate Pasi Petäjäjärvi for Approver status in the Qt Project. Pasi is the maintainer of the VxWorks port and has also been contributing a lot for other embedded platforms over the years. Public Gerrit dashboard: https://codereview.qt-project.org/#/q/owner:pasi.petajajarvi,n,z [https://codereview.qt-project.org/static/logo_open_gov.png] Gerrit Code Review codereview.qt-project.org Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; Planet Qt; Qt Repository Browser Best regards, Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From Morten.Sorvig at theqtcompany.com Tue Dec 15 12:03:05 2015 From: Morten.Sorvig at theqtcompany.com (Sorvig Morten) Date: Tue, 15 Dec 2015 11:03:05 +0000 Subject: [Development] High-DPI 5.6 beta update Message-ID: <86C36AA2-E168-43ED-B464-3125E74406F9@digia.com> Hi, I’d like to provide short update on the changes in this space, an also lay out some plans and possibilities for the future. Thanks to everyone who has helped out! New changes: * @3x support landed, both for Qt Widgets and Qt Quick. Implemented as @Nx support, with @9x as a maximum value. * The internal documentation for scaling in Qt has been updated: github.com/qtproject/qtbase/blob/dev/src/gui/kernel/qhighdpiscaling.cpp. * Added C++ API for enabling/disabling high-dpi scaling: Qt::AA_EnableHighDpiScaling Qt::AA_DisableHighDpiScaling Together with the environment variable (QT_AUTO_SCREEN_SCALE_FACTOR=1 or 0) these provide comprehensive support for controlling whether scaling in Qt should be enabled or not. Several use cases are supported: * User wants to enable scaling (perhaps for “legacy” Qt apps): QT_AUTO_SCREEN_SCALE_FACTOR=1 * User wants disable scaling (there may be a hardware config issue): QT_AUTO_SCREEN_SCALE_FACTOR=0 * Developer wants to enable scaling: Qt::AA_EnableHighDpiScaling * Developer wants application to work in device pixels and disable scaling: Qt::AA_DisableHighDpiScaling In case of conflicts between the environment and C++ side the logic is ‘veto’. The actual scale factor applied is controlled by the platform plugin, which provides it by overriding QPlatformScreen::pixelDensity() The default implementation returns 1. pixelDensity() is currently implemented by the android, eglfs, windows, and xcb platform plugins. What’s next? 5.6 series: * Public overview documentation update. * Misc fixing in Widgets and Quick. In particular I would like to land a series of GraphicsView fixes: https://codereview.qt-project.org/#/c/142920 dev: * Improve support for fractional scale factors for QtWidgets (render at 2x and then downscale). Will require OpenGL for the scaling. Prototype at https://codereview.qt-project.org/143819 (OS X only). * Refactor qhighdpiscaling_h API and implementation: https://codereview.qt-project.org/#/c/140176 * Improve pixmap versioning support, replacing/extending @Nx and QIcon: QTBUG-49820 * Figure out auto-testing: We can run entire tests at a given scale factor, or individual test functions can test at a range of scale factors. Or we can do both. We’ve so far relied on manual tests on actual high-dpi hardware. The cross-platform scaling layer in Qt Gui now gives us the ability to auto test on any hardware (including CI virtual hardware). If anyone is interested or has input on the above, drop me a note or comment on the mentioned task/changes. Thanks, Morten From announce at qt-project.org Tue Dec 15 12:11:35 2015 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Tue, 15 Dec 2015 11:11:35 +0000 Subject: [Development] [Announce] Qt Creator 3.6.0 released Message-ID: We are happy to announce the release of Qt Creator 3.6.0: http://blog.qt.io/blog/2015/12/15/qt-creator-3-6-0-released/ -- Eike Ziller, Senior Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From louai.al-khanji at theqtcompany.com Tue Dec 15 14:20:16 2015 From: louai.al-khanji at theqtcompany.com (Al-Khanji Louai) Date: Tue, 15 Dec 2015 13:20:16 +0000 Subject: [Development] =?iso-8859-1?q?Nominating_Pasi_Pet=E4j=E4j=E4rvi_fo?= =?iso-8859-1?q?r_Approver_status?= In-Reply-To: References: , Message-ID: Congrats! _____________________________ From: Blasche Alexander > Sent: Tuesday, December 15, 2015 3:21 AM Subject: Re: [Development] Nominating Pasi Petäjäjärvi for Approver status To: > Congratulations to Pasi. Jira and Gerrit rights have been set. -- Alex ________________________________ From: Development > on behalf of Agocs Laszlo > Sent: Tuesday, November 24, 2015 10:04 To: development at qt-project.org Subject: [Development] Nominating Pasi Petäjäjärvi for Approver status Hello, I would like to nominate Pasi Petäjäjärvi for Approver status in the Qt Project. Pasi is the maintainer of the VxWorks port and has also been contributing a lot for other embedded platforms over the years. Public Gerrit dashboard: https://codereview.qt-project.org/#/q/owner:pasi.petajajarvi,n,z [https://codereview.qt-project.org/static/logo_open_gov.png] Gerrit Code Review codereview.qt-project.org Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; Planet Qt; Qt Repository Browser Best regards, Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch.curtis at theqtcompany.com Tue Dec 15 17:03:02 2015 From: mitch.curtis at theqtcompany.com (Curtis Mitch) Date: Tue, 15 Dec 2015 16:03:02 +0000 Subject: [Development] Aliasing with QSGRectangleNode Message-ID: Hi. I'm implementing a busy indicator for the new controls using QSGRectangleNode. Even after calling rectNode->setAntialiasing(true), I'm noticing some strange aliasing going on. Take a look at the various attached screenshots to see what I'm talking about (the 2x/6x variants are with QT_SCALE_FACTOR set). For filled "rectangles", there seems to be a lack of antialiasing on the outer left side, and for unfilled rectangles with borders, it's missing on the left inner side. The attached zip file contains a simplified example to try out. Anyone know why this is happening? Cheers. -------------- next part -------------- A non-text attachment was scrubbed... Name: busyindicator-simplified-example.zip Type: application/zip Size: 3647 bytes Desc: busyindicator-simplified-example.zip URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: aliasing.png Type: image/png Size: 9121 bytes Desc: aliasing.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: aliasing-2x.png Type: image/png Size: 3793 bytes Desc: aliasing-2x.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: aliasing-6x.png Type: image/png Size: 10375 bytes Desc: aliasing-6x.png URL: From rpzrpzrpz at gmail.com Tue Dec 15 20:25:01 2015 From: rpzrpzrpz at gmail.com (rpzrpzrpz at gmail.com) Date: Tue, 15 Dec 2015 13:25:01 -0600 Subject: [Development] High-DPI 5.6 beta update In-Reply-To: <86C36AA2-E168-43ED-B464-3125E74406F9@digia.com> References: <86C36AA2-E168-43ED-B464-3125E74406F9@digia.com> Message-ID: <5670690D.6040305@gmail.com> On 12/15/2015 5:03 AM, Sorvig Morten wrote: > Hi, > > I’d like to provide short update on the changes in this space, an also lay out > some plans and possibilities for the future. Thanks to everyone who has helped > out! New changes: > > * @3x support landed, both for Qt Widgets and Qt Quick. Implemented as @Nx > support, with @9x as a maximum value. > > * The internal documentation for scaling in Qt has been updated: > github.com/qtproject/qtbase/blob/dev/src/gui/kernel/qhighdpiscaling.cpp. > > * Added C++ API for enabling/disabling high-dpi scaling: > Qt::AA_EnableHighDpiScaling > Qt::AA_DisableHighDpiScaling > > Together with the environment variable (QT_AUTO_SCREEN_SCALE_FACTOR=1 or 0) > these provide comprehensive support for controlling whether scaling in Qt > should be enabled or not. Several use cases are supported: > > * User wants to enable scaling (perhaps for “legacy” Qt apps): > QT_AUTO_SCREEN_SCALE_FACTOR=1 > * User wants disable scaling (there may be a hardware config issue): > QT_AUTO_SCREEN_SCALE_FACTOR=0 > * Developer wants to enable scaling: > Qt::AA_EnableHighDpiScaling > * Developer wants application to work in device pixels and disable scaling: > Qt::AA_DisableHighDpiScaling > > In case of conflicts between the environment and C++ side the logic is ‘veto’. > > The actual scale factor applied is controlled by the platform plugin, which > provides it by overriding QPlatformScreen::pixelDensity() The default > implementation returns 1. pixelDensity() is currently implemented by the > android, eglfs, windows, and xcb platform plugins. > > What’s next? > > 5.6 series: > > * Public overview documentation update. > > * Misc fixing in Widgets and Quick. In particular I would like to land a series of > GraphicsView fixes: https://codereview.qt-project.org/#/c/142920 > > dev: > > * Improve support for fractional scale factors for QtWidgets (render at 2x and then > downscale). Will require OpenGL for the scaling. Prototype at > https://codereview.qt-project.org/143819 (OS X only). > > * Refactor qhighdpiscaling_h API and implementation: > https://codereview.qt-project.org/#/c/140176 > > * Improve pixmap versioning support, replacing/extending @Nx and QIcon: QTBUG-49820 > > * Figure out auto-testing: We can run entire tests at a given scale factor, or > individual test functions can test at a range of scale factors. Or we can do both. > We’ve so far relied on manual tests on actual high-dpi hardware. The cross-platform > scaling layer in Qt Gui now gives us the ability to auto test on any hardware > (including CI virtual hardware). > > If anyone is interested or has input on the above, drop me a note or comment on the > mentioned task/changes. > > Thanks, > Morten > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Morten: My comment only deals with vector graphics SVG formats QT. Instead of worrying about @2x and @3x and trying to generate artwork in all of the sizes, would it not be advantageous to only use SVG vector format and allow the svg plugin to generate and scale at run-time a single svg file in the QRC file instead of having to pre-generate files. Image { id: gicon source: qrc:/img/test.svg anchors.fill: parent } Pro File: QT += svg Outside of the app, in the Android Manifext.xml and IOS, you need to provide pre-generated launcher PNG icons, but inside the app as well? Your thoughts on projects that use ONLY SVG image resources and not PNG/JPEG? md From dangelog at gmail.com Tue Dec 15 20:43:15 2015 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Tue, 15 Dec 2015 20:43:15 +0100 Subject: [Development] High-DPI 5.6 beta update In-Reply-To: <5670690D.6040305@gmail.com> References: <86C36AA2-E168-43ED-B464-3125E74406F9@digia.com> <5670690D.6040305@gmail.com> Message-ID: On Tue, Dec 15, 2015 at 8:25 PM, rpzrpzrpz at gmail.com wrote: > Image > { > id: gicon > source: qrc:/img/test.svg > anchors.fill: parent > } > > Pro File: > > QT += svg > > Outside of the app, in the Android Manifext.xml and IOS, you need to provide > pre-generated launcher PNG icons, but inside the app as well? > > Your thoughts on projects that use ONLY SVG image resources and not > PNG/JPEG? But the above: 1) already works 2) is limited to SVG Tiny (that is, whatever QtSvg support) 3) has terrible performances due to the rasterization (which has a huge cost, happens entirely at runtime, and whose results are not cached) 4) gives worse visual results than icons which were produced by rasterizing SVG files, then having artists giving final touches the output Are you really sure you want to go down this path? My 2 c, -- Giuseppe D'Angelo From tim at klingt.org Tue Dec 15 20:53:22 2015 From: tim at klingt.org (Tim Blechmann) Date: Tue, 15 Dec 2015 20:53:22 +0100 Subject: [Development] High-DPI 5.6 beta update In-Reply-To: References: <86C36AA2-E168-43ED-B464-3125E74406F9@digia.com> <5670690D.6040305@gmail.com> Message-ID: <56706FB2.8000706@klingt.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> Image { id: gicon source: qrc:/img/test.svg anchors.fill: parent >> } >> >> Pro File: >> >> QT += svg >> >> Outside of the app, in the Android Manifext.xml and IOS, you need >> to provide pre-generated launcher PNG icons, but inside the app >> as well? >> >> Your thoughts on projects that use ONLY SVG image resources and >> not PNG/JPEG? > > > But the above: > > 1) already works kind of ... the above will rasterize the svg for the resolution of the Image which is then upscaled, to match the resolution of the screen, resulting in a blurry rendering :/ > 2) is limited to SVG Tiny (that is, whatever QtSvg support) 3) has > terrible performances due to the rasterization (which has a huge > cost, happens entirely at runtime, and whose results are not > cached) 4) gives worse visual results than icons which were > produced by rasterizing SVG files, then having artists giving final > touches the output > > Are you really sure you want to go down this path? > > My 2 c, > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWcG+yAAoJEAIkvWiom07DJqQP/i5+O1XWbjnKTTDhKlyYp5L8 vQ43UZ3DNcISg3R3awHgH6gZ6j+YX7HpsdjhQNFoWvjr4WSpLuMfFKmX+nLnI61C QYNNV+b8N5IQ/3gYeOAp42G9H+w4hg0wzjGWWvSsUKT/HbUY1Pko1LUg3A7+EZQP JQ8bLiCzFdm9avkC/tYA3Wbc6xZb2toXFO9zApzcligODvvkkyyuax9WKLjorC1U 0jC/FqmKYG2P28K4A5uMzSV4gpbqP+cQEQv6jod12fjAlwvNBQFpWVD+e/kKOkG2 FybtoPSQH6MyB7/arMJ+1YtXQVoT+cEC1xFt+uDPVPeYUZlGWtWMEFKJLc7zfLai vU3cYn/z3ST+z+36AYkORIVSg/W5zn9RnU5ze2prZgyqe35mzvJO0/9Cf0i55mis iYbwjXhjTwCid6uEphQ0phj32UG9I6n9Kt6vvzJRb3NC7mcI+KZfwAPpt9EVs192 RjxzsResG98Sh3pKxJ6YEPnUe0rHotRN4VLE5PUqsCbFsMFxCjjHA0sowIN0TNB5 SynnlBCvyEaGz/qEgp/GobfB/pX6J2Ahnl9IW4Zpv6p5r3ZLh2sBKcPDRUQ4i9Mc sjvPTW43zIqNdvvL30O+GhrwESUdQbdMtk43uPatp3FgN+9grLSdawiaMwdwUqwV ++9z850fPbDeD59K5jnK =HUtE -----END PGP SIGNATURE----- From olivier at woboq.com Tue Dec 15 21:56:18 2015 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 15 Dec 2015 21:56:18 +0100 Subject: [Development] High-DPI 5.6 beta update In-Reply-To: <56706FB2.8000706@klingt.org> References: <86C36AA2-E168-43ED-B464-3125E74406F9@digia.com> <56706FB2.8000706@klingt.org> Message-ID: <13306033.BbFkpjytuM@finn> On Tuesday 15. December 2015 20:53:22 Tim Blechmann wrote: > >> Image { id: gicon source: qrc:/img/test.svg anchors.fill: parent > >> } > >> > >> Pro File: > >> > >> QT += svg > >> > >> Outside of the app, in the Android Manifext.xml and IOS, you need > >> to provide pre-generated launcher PNG icons, but inside the app > >> as well? > >> > >> Your thoughts on projects that use ONLY SVG image resources and > >> not PNG/JPEG? > > > > But the above: > > > > 1) already works > > kind of ... the above will rasterize the svg for the resolution of the > Image which is then upscaled, to match the resolution of the screen, > resulting in a blurry rendering :/ What you describe is QTBUG-38991 which we fixed in Qt 5.5 already > > 2) is limited to SVG Tiny (that is, whatever QtSvg support) > > 3) has terrible performances due to the rasterization (which has a huge > > cost, happens entirely at runtime, and whose results are not > > cached) We used svg for a mobile application. All the icons are in svg. We thought it would be slow and was only done temporarily. But it turns out it is fast enough and not a bottleneck at all. So in practice this work perfectly fine and we did not had to generate the png in several sizes. So "terrible performances" is a bit of an overstatement. > > 4) gives worse visual results than icons which were > > produced by rasterizing SVG files, then having artists giving final > > touches the output > > > > Are you really sure you want to go down this path? -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From tim at klingt.org Tue Dec 15 22:16:25 2015 From: tim at klingt.org (Tim Blechmann) Date: Tue, 15 Dec 2015 22:16:25 +0100 Subject: [Development] High-DPI 5.6 beta update In-Reply-To: <13306033.BbFkpjytuM@finn> References: <86C36AA2-E168-43ED-B464-3125E74406F9@digia.com> <56706FB2.8000706@klingt.org> <13306033.BbFkpjytuM@finn> Message-ID: <56708329.9080402@klingt.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>> Your thoughts on projects that use ONLY SVG image resources >>>> and not PNG/JPEG? >>> >>> But the above: >>> >>> 1) already works >> >> kind of ... the above will rasterize the svg for the resolution >> of the Image which is then upscaled, to match the resolution of >> the screen, resulting in a blurry rendering :/ > > What you describe is QTBUG-38991 which we fixed in Qt 5.5 already just setting the image source to an svg will still result in a blurry rendering in 5.5 and 5.6. i have to work around this by setting the source size explicitly, as it doesn't take the devicePixelRatio into account ... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWcIMpAAoJEAIkvWiom07D2ukQAJizU/Lv9U/6QM3ZZHX9U9g/ 7rm3bhFEu3gpExxdmhUuhdr6iuA/INU/P1H1/Wlg4f8Ys+hS3mZIiveClXvMx0f8 1WELFmlPckb5yNjiFxYUYe1SCykvJCHRmfgeI4zYa4TZr3dYQV8HzN4slR29219V zkb9Sp6GO9M0En2cAEj6yZ/b1n0Z2otIH0PE7l/trFZk+JSuCF38zHl/ljlZNAuW 9G1JKpsHp7XNXDbEyXtHYuO5m/+5f3ISjJECm9wOyGRYZwU6vVE/kigZtGPopiFk hhofa14rF3wb6ypuOwL7V8xxQDWwlKUoFvB28VSXT75z1ho6OBJzWfLm3jpePfnB 72TehyYf53hYyJjcy598AWB6C13m81BgQbbJ1puY8CJhiQN3NzElUt0kUEKPb7WE 31CpcwQIUH0ZZMkVny4B/Wk8xblAKt+AbJuF4v0W3STZFMvp9DHMrBFmAfuRCY4C y1H6voXMPuweAbSJFhcpedQb537yfy1Me0gxm8n8FFpeIoTOiJPn9b7O5SF03C+J bayr2UEz8gk9kEe7QNr4NQBOHeHeBiqjSvIugvvhLFX2e7R41a/uxCQdVZvLympW hBDBmIF6Q6tGaw4/7G4zXkwIsA7V7CHlURRbut36+zQ037xbZISFzCowSwIh91/t 035sBC7J1c5uM2CG8UR9 =8bSY -----END PGP SIGNATURE----- From jim at strackaline.com Tue Dec 15 22:44:17 2015 From: jim at strackaline.com (Jim Stracka) Date: Tue, 15 Dec 2015 13:44:17 -0800 Subject: [Development] QT development needed Message-ID: I have an iOS App that I need written in QT for porting to other platforms. the iOS App is "StrackaLine" -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Wed Dec 16 06:11:34 2015 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 16 Dec 2015 06:11:34 +0100 Subject: [Development] QT development needed In-Reply-To: References: Message-ID: <20151216051133.GO13519@tonks> * Jim Stracka [2015-12-15 13:44:17 -0800]: > I have an iOS App that I need written in QT for porting to other platforms. > > the iOS App is "StrackaLine" This list is for development *of* Qt itself. As for your question, I suggest you take a look at Qt's partners: http://www.qt.io/partners/ Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From gunnar at sletta.org Wed Dec 16 09:05:09 2015 From: gunnar at sletta.org (Gunnar Sletta) Date: Wed, 16 Dec 2015 09:05:09 +0100 Subject: [Development] Aliasing with QSGRectangleNode In-Reply-To: References: Message-ID: <96A93274-A0BB-4F1D-9CA0-18829A489FAD@sletta.org> It is curious that the aliasing in the 1x image is not reproducible with the Rectangle {} element and only for some of the elements.. Some subtlety with the private api. One difference might be that you are giving your rectangle nodes an explicit x/y while the Rectangle element uses a transform node. It would require a bit of digging.. The segmentation you see in the 2x and 6x images is a different problem. That comes from the fact that the rectangle node doesn't know its render size, so when the thing gets scaled up by 2x or 6x it doesn't know to take that scale factor into account. This is another place that needs to look up QQuickWindow::effectiveDevicePixelRatio() and apply that to the segmentation factor. cheers, Gunnar > On 15 Dec 2015, at 17:03, Curtis Mitch wrote: > > > Hi. > > I'm implementing a busy indicator for the new controls using QSGRectangleNode. Even after calling rectNode->setAntialiasing(true), I'm noticing some strange aliasing going on. Take a look at the various attached screenshots to see what I'm talking about (the 2x/6x variants are with QT_SCALE_FACTOR set). For filled "rectangles", there seems to be a lack of antialiasing on the outer left side, and for unfilled rectangles with borders, it's missing on the left inner side. > > The attached zip file contains a simplified example to try out. > > Anyone know why this is happening? > > Cheers._______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From passeli at gmail.com Wed Dec 16 09:35:29 2015 From: passeli at gmail.com (=?UTF-8?B?UGFzaSBQZXTDpGrDpGrDpHJ2aQ==?=) Date: Wed, 16 Dec 2015 08:35:29 +0000 Subject: [Development] =?utf-8?b?Tm9taW5hdGluZyBQYXNpIFBldMOkasOkasOkcnZp?= =?utf-8?q?_for_Approver_status?= In-Reply-To: References: Message-ID: Thank you all! :) Br, Pasi On Tue, 15 Dec 2015 at 15:20 Al-Khanji Louai < louai.al-khanji at theqtcompany.com> wrote: > Congrats! > > _____________________________ > From: Blasche Alexander > Sent: Tuesday, December 15, 2015 3:21 AM > Subject: Re: [Development] Nominating Pasi Petäjäjärvi for Approver status > To: > > > > Congratulations to Pasi. Jira and Gerrit rights have been set. > > > -- > > Alex > > > ------------------------------ > *From:* Development on behalf of > Agocs Laszlo > *Sent:* Tuesday, November 24, 2015 10:04 > *To:* development at qt-project.org > *Subject:* [Development] Nominating Pasi Petäjäjärvi for Approver status > > > Hello, > > > > I would like to nominate Pasi Petäjäjärvi for Approver status in the Qt > Project. > > > > Pasi is the maintainer of the VxWorks port and has also been contributing > a lot for other embedded platforms over the years. > > > > Public Gerrit dashboard: > https://codereview.qt-project.org/#/q/owner:pasi.petajajarvi,n,z > > Gerrit Code Review > > codereview.qt-project.org > Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; > Planet Qt; Qt Repository Browser > > > > Best regards, > > Laszlo > > > > > _______________________________________________ > 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 theqtcompany.com Wed Dec 16 11:25:00 2015 From: Morten.Sorvig at theqtcompany.com (Sorvig Morten) Date: Wed, 16 Dec 2015 10:25:00 +0000 Subject: [Development] High-DPI 5.6 beta update In-Reply-To: <56708329.9080402@klingt.org> References: <86C36AA2-E168-43ED-B464-3125E74406F9@digia.com> <56706FB2.8000706@klingt.org> <13306033.BbFkpjytuM@finn> <56708329.9080402@klingt.org> Message-ID: > On 15 Dec 2015, at 22:16, Tim Blechmann wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > >>>>> Your thoughts on projects that use ONLY SVG image resources >>>>> and not PNG/JPEG? >>>> >>>> But the above: >>>> >>>> 1) already works >>> >>> kind of ... the above will rasterize the svg for the resolution >>> of the Image which is then upscaled, to match the resolution of >>> the screen, resulting in a blurry rendering :/ >> >> What you describe is QTBUG-38991 which we fixed in Qt 5.5 already > > just setting the image source to an svg will still result in a blurry > rendering in 5.5 and 5.6. i have to work around this by setting the > source size explicitly, as it doesn't take the devicePixelRatio into > account … Yes, as I understand it the way SVG loading works in Qt Quick is that the SVG image provider will determine the rasterized size if sourceSize is not set. (In the general, normal-dpi case). The SVG image provider has of course no idea what the target display is can can’t account for high-dpi displays. If you set sourceSize then QQuickImageBase will scale it by the target devicePixelRatio and you get a high-resolution image. There are ways to fix this, for example we could ferry the target scale factor through the image loading and caching layers, down to QImageIOHandler. This is part of what QTBUG-49820 is about. Before we start fixing I think we need to make a decision about multi-version images in Qt Quick: do we want to add an Icon type and keep Image simple, or go for a single Image type handling all such use cases. Morten From Morten.Sorvig at theqtcompany.com Wed Dec 16 11:29:21 2015 From: Morten.Sorvig at theqtcompany.com (Sorvig Morten) Date: Wed, 16 Dec 2015 10:29:21 +0000 Subject: [Development] High-DPI 5.6 beta update In-Reply-To: <5670690D.6040305@gmail.com> References: <86C36AA2-E168-43ED-B464-3125E74406F9@digia.com> <5670690D.6040305@gmail.com> Message-ID: <03F1FCAD-FDE3-459A-8ED3-E9B04263F6CB@digia.com> > On 15 Dec 2015, at 20:25, rpzrpzrpz at gmail.com wrote: > > Instead of worrying about @2x and @3x and trying to generate artwork in all of the sizes, would it not be advantageous > to only use SVG vector format and allow the svg plugin to generate and scale at run-time a single svg file in the QRC file instead of having to pre-generate files. > > Your thoughts on projects that use ONLY SVG image resources and not PNG/JPEG? I think using SVG only is fine if that works for your project, and we want to support it. But Qt _enforcing_ SVG only? We can’t really make that decision for our users. Morten From marc.mutz at kdab.com Wed Dec 16 15:01:23 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 16 Dec 2015 15:01:23 +0100 Subject: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda In-Reply-To: <1844631.0KWYPjGfsc@tjmaciei-mobl4> References: <2824381.7J9KQt27bL@marvin> <54E66EEC.60705@taschenorakel.de> <1844631.0KWYPjGfsc@tjmaciei-mobl4> Message-ID: <201512161501.24196.marc.mutz@kdab.com> On Friday 20 February 2015 02:26:25 Thiago Macieira wrote: > Do NOT do this. This will crash: > > for (auto const &item : std::cref(somefunction()) { ... } Sorry for warming up an old thread, but since there was talk about the QtC coding style recommending this... It's safe for lvalues. What't not safe are rvalues, but the std:.cref() overload from rvalues (const) is supposed to be deleted, according o en- cppreference.com, so it shouldn't even compile. Doesn't help much if the compiler doesn't know = delete, though. This might work, based on the cref() overload pattern: template class QContainerWrapper { T container; friend decltype(auto) begin(const QContainerWrapper &w) Q_DECL_NOEXCEPT_EXPR(noexcept(w.container.begin())) { return w.container.begin(); } friend decltype(auto) end(const QContainerWrapper &w) Q_DECL_NOEXCEPT_EXPR(noexcept(w.container.end())) { return w.container.end(); } }; // assume the following are friends of QContainerWrapper, resp.: template QContainerWrapper qAsConst(const T &t) // lvalue Q_DECL_NOTHROW { return {t}; } // stores reference template QContainerWrapper qAsConst(const T &&t) Q_DECL_NOEXCEPT_EXPR(std::is_nothrow_move_constructible_v) { return {std::move(t)}; } // stores a copy Untested! Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Wed Dec 16 15:08:25 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 16 Dec 2015 15:08:25 +0100 Subject: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda In-Reply-To: <201512161501.24196.marc.mutz@kdab.com> References: <2824381.7J9KQt27bL@marvin> <1844631.0KWYPjGfsc@tjmaciei-mobl4> <201512161501.24196.marc.mutz@kdab.com> Message-ID: <201512161508.26130.marc.mutz@kdab.com> On Wednesday 16 December 2015 15:01:23 Marc Mutz wrote: > // assume the following are friends of QContainerWrapper, > resp.: template > QContainerWrapper qAsConst(const T &t) // lvalue > Q_DECL_NOTHROW > { return {t}; } // stores reference > template > QContainerWrapper qAsConst(const T &&t) > Q_DECL_NOEXCEPT_EXPR(std::is_nothrow_move_constructible_v) > { return {std::move(t)}; } // stores a copy Actually, this would be even simpler: template Q_DECL_CONSTEXPR const T &qAsConst(const T &t) Q_DECL_NOTHROW { return t; } template Q_DECL_CONSTEXPR const T qAsConst(T &&t) Q_DECL_NOEXCEPT_EXPR(std::is_nothrow_move_constructible_v) { return std::move(t); } -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From jani.heikkinen at theqtcompany.com Wed Dec 16 14:26:42 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Wed, 16 Dec 2015 13:26:42 +0000 Subject: [Development] New Qt 5.6.0 Beta candidate packages available In-Reply-To: References: Message-ID: Hi all, Unfortunately we found new blocker (QTBUG-49886) from previous packages. Fixes for it is now in new packages: Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/292/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/295/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/229/ Src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ Please test these packages to see if these are now proper beta quality. We will release these packages as Qt 5.6.0 beta at the end of this week/beginning of next one if nothing serious found during testing. Qt5 changes since previous packages: https://codereview.qt-project.org/#/c/143673/ Patch Set 3: qt/qtconnectivity 2402bb9421ab8ba4479b7a4e9566b682146f70ff..cd81e43c26ea998aa009ea452e5723059ded8595: > Bluetooth: Documentation fix. > qlowenergycontroller_osx - move delegate to the qt_LE_queue qt/qtwebengine 1c09b16ebb88737682a5cd6ddc58f6d360b635af..d239b60313f798cf75a4e34a768d9f4a1fc8f92a: > Stabilize test_urlProperty > Fix namespaced build of demobrowser > Make QQuickWebEngineProfile public > Build qmltests only if QML testsupport API is available > Fix some syncqt warnings > Fix path issues tst_QQuickWebEngineView > Update tests/auto/quick/publicapi > Remove explicit version \inqmlmodule > Add changes file > Update Chromium > Make use of QObject's d-pointer in QWebEngineCookieStore > Stabilize tst_QWebEnginePage::getUserMediaRequest > Stabilize tst_download.qml > Merge remote-tracking branch 'origin/5.5' into 5.6 qt/qtxmlpatterns ee56885f52b63132bffafad1ccc8830a65d129fa..8ba610490e2d93526c165584e2f52c7ae8e9edc0: > Change uses of toAscii to toLatin1 qt/qt3d 94f3df1aacab5853d09e79596eb3bdae3aecae0a..dc6e9d02ac1a9030308f2cdf11f96d4d3612fd6d: > Remove initialize/shutdown from API > Make the p-impl really private > Move initNodeTree to the p-impl > Turn all services private for now > QTransform: Add convenience properties for Euler angle rotations > Rename Q3D*Event to Q*Event and handle namespace > Move all raycasting code as private in Qt3DRender > Bring the GLSL 1.00 fallback shader up-to-date > Reduce specular reflectivity defaults > Do lighting calculation in world space > Register QAxisSetting as QML type > Use lists of ints for axes on axis settings qt/qtwayland 4d3c3a08eba8d30805f18397c98e19ab9fd40722..f51de354b14d5a25d7e32debe0d56b9fbed67a4f: > Revert "Don't invalidate textures when the scene graph is stopped." qt/qtbase 3414be909df60fa8a726c692b2a93f6b36a9c474..adb914f4b9b723099824fd51a09a9b30bed4ec6c: > QtNetwork: Standardize error message about IPv6 addresses for nameservers. > xcb: Don't try to detect cases where the WM restricts geometry changes > winrt: Avoid blocking for the first processEvents run > remove visual studio specific argument > Fix compilation for WinRT > Don't detach the color table vector > QFileSystemModel: report special files which are not symlinks > QWindowsBackingStore::flush(): Add warning for UpdateLayeredWindowIndirect() failures. > QFileSystemModel autotest: fix a broken sort() test > Remove iOS workaround for pixman drawhelpers > QLineEdit: a validator fixup() should keep it modified; add failing test > iOS: Enable non-pixman NEON drawhelpers for both 32 and 64-bit > xcb: Use a placeholder QScreen when there are no outputs connected > xcb: Don't cache the screen for a window > Don't ignore first character after a string. > winrt: Readd parameters to the pid-file's CreateFile2 call > QWidgetBackingStore::markDirty(): Clamp dirty region to window size. > winrt: Use Windows 10 features when available > automatically put TESTDATA into RESOURCES on android/ios/winrt > QJsonObject::(const_)iterator: add pointer typedef > Fix broken QIOSContext setup due to missing 0-initialization of EAGLContext > QFileDialog test: make the right subwidget visible > xcb: compare to previous state when sending geometry and expose events > XCB: prevent a fp division by zero > QFileSystemModel: do not unwatch directories if removal fails > QPlatformTheme: added TabButtonFont and GroupBoxTitleFont > configureapp: Print FontConfig in "Third Party Libraries" section > configureapp: Add missing empty line between paragraphs > Fix swapped descriptions for [-no]-optimized-tools > Register QPA Menu, Dialog & SysTray enums & flags > Doc: Online style: CSS fixes for image alignment > Clarify what time-zone "transitions" are. > winrt: Store exit code in pid file > QProcessPrivate::startProcess - fix invalid encodedProgramName (OS X) > Add generic g++ spec for arm devices. > Use CROSS_COMPILE when setting PKG_CONFIG. > Check for any existing file in XCOMPOSEFILE. > Doc: Online template: dynamically load footer content > Standarddialogs example: Adapt layout for fullscreen platforms. > fortuneserver/fortuneclient: Fix layout for WinRT. > Fix debug operator for QRegion. > Fix URL to "The Microsoft Windows User Experience". qt/qtqa b8a34de3134ef24a8ad4937bc48365b0635e4431..0ff6cfc355378efdab53ea54fb493de22f1e950b: > Read license check exclude rules from files qt/qttools 83a197e1d73d855360fd45d2172ba09bfc127f62..58d1304edb82a0a17ee39d259e56b930ca35ffcc: > winrtrunner: Fix warning about unused variable. > lupdate: mention location type guessing in help output > tst_lupdate: Add a call to QProcess::waitForStarted(). > qdoc: Add support for listing all examples from all modules > Haiku: Fix compilation of Qt Designer qt/qtquickcontrols2 f2f9786e6194725bf48ee3833b1fdf9603b74e69..d4df163af0609340f8b4c006ee18daaff563053d: > Universal: fix Pane background > Fix ScrollBar & ScrollIndicator for the new Gallery > Make QQuickStyleSelector case-insensitive > Remove QQuickStyleSelector::instance() > Popup: rename show()/hide() to open()/close() > Material style: read theme, accent & primary from qtlabscontrols.conf > Universal style: read theme & accent from qtlabscontrols.conf > Read preferred style from qtlabscontrols.conf > Add QQuickStyle::settings() > Docs: move "Differences between Qt Quick Controls" on its own page > tst_activeFocusOnTab: remove unnecessary layouts dependency > Universal ComboBox: visualize key & mouse focus differently > Universal: focus rectangle > Add QQuickControl::focusReason > AppWindow docs: fix \L -> \l > Cleanup duplicate ApplicationWindow::activeFocusControl docs > Add missing TextArea::pressAndHold() docs > testbench: fix TextArea placeholder text > Fix QQuickComboBox::focusOutEvent() > Pane: don't let presses leak through > Add ApplicationWindow::activeFocusControl > Register also "unstyled" controls to the Qt.labs.controls namespace > Use TabButtonFont and GroupBoxTitleFont from QPlatformTheme > Move ApplicationHelper to visualtestutil.h and rename it > Docs: ApplicationWindow > Introduce Pane > Rename Panel to Popup > StackView: fix property initialization > Remove Control::layoutDirection > Docs: Material style > GroupBox: add an example of a checkable groupbox qt/qtwebview ba4302894ecc511228b010ec49b9f865ea6ebe5a..7b6d9a4cba8a4470ee346de40f6f4855fc2b2854: > Android: Explicitly tear-down the Native WebView. qt/qtlocation fda281b81730d0d41af09170e732b3d70c4cfff1..d75c0469c05809a4c6ff85a4c78784b397cbfcc0: > Added methods for modifying QDeclarativePolylineMapItem. > Fix static build qt/qtserialport 5641fd99e3c61291cf5562b5083e93678c5d6ab4..bd3fb6cc346b3bdbb7a05131b912d450490fa5c8: > Do not use settingFromBaudRate() on Windows > Use C-style tokens array for query of device name from registry > Use the C-style array of GUID tokens > Use pre-defined class/interface devices GUIDs qt/qtdeclarative 177050862e644f9a279086b703cb04e06ea409b8..5f96bc07389382d534934120301c2d1a89d24657: > qmlplugindump: add manual tests. qt/qtmultimedia 5916caae7a043da4c5547725cccbbeb10d18e1f5..82e135167a5d24f600f006480b78a59511ae5cb3: > Change the way a playlist is bound to a media object. > Blacklist qmediaplayerbackend tests in OSX 10.11 > Blacklist qaudiodecoderbackend tests in OSX 10.11 > GStreamer: Add color balance and sharpening adjustments using V4L2 > DirectShow: Get current image processing parameter from the cache > DirectShow: Add WhiteBalancePreset and ColorTemperature for the camera > GStreamer: Adjust the camera's manual color temperature through V4L2 qt/qtdoc 5f996b5e8abad7379a43a1e6158c228081a2e86d..91ca24d0484ba1166fbd31e7f444346f65e5637b: > Doc: Add a page listing all Qt examples https://codereview.qt-project.org/#/c/143416/ Patch Set 2: qt/qtwebengine 991e32f2fae311f32791df90d8e531e1cbd23c2f..1c09b16ebb88737682a5cd6ddc58f6d360b635af: > Update Chromium SHA1 > enable tests/auto/widgets > stabilize tst_qwebenginepage some more > Make the MIME-type of downloads available > Quick: Close WebUI popups properly > Fix unclosable tabs in demobrowser > Add margin to downloadmanageritem ui qt/qtlocation e70502b14a6b78067c18a4645570c077453c34ea..fda281b81730d0d41af09170e732b3d70c4cfff1: > WinRT: Refactor backend qt/qtquickcontrols a3ba1a532f92a933141d4671ce644053a0cb6fea..80cde7c7ca22511494ae6d32b2023fb1e92ede4d: > Moved menuBar function from QQuickMenuPopupWindow to QQuickmenu > Fixed missing close of the ComboBox when clicking on it qt/qtimageformats 531c30ea66d2b8fe517c89bed149a938e16332ec..6730d70f001c9492d32a6a8e95c304a52d7ddc35: > Bundled libtiff updated to version 4.0.6 > libwebp: update patches to 0.4.4 for Qt usage > libwebp: update to 0.4.4 qt/qtgraphicaleffects 59699c9322b3861e3d0251dfd40a65d0f03c76d4..3f240169388d2f3090cd5730e03df8d8ab670510: > Fix SourceProxy's method for determining when to activate. qt/qtbase dae77465d1a96d7a6c4fd21e9cd92dc11d5ff68b..3414be909df60fa8a726c692b2a93f6b36a9c474: > Fix QAction::menuRole() documentation > Fix QAction MenuRole documentation > Reduce flushes with repaint() when GL-based compositing is active > Doc: Circumvented qdoc parsing by removing '!' > Doc: do not claim that SUBDIRS.depends is only available for Makefiles > doc: fix the shortcut for QListWidget::itemActivated > Align signature with generic native socket engine > iOS: filter edit menu actions depending on selection state > iOS: support edit action 'select' > QFileDialog: Call reject() on Key_Escape even when itemview has focus > Favor OpenGLES 3 on iOS if available > QWinRTFontDatabase: Add "Arial" as alias for "Helvetica". > QString: where possible, re-use existing capacity in op(QChar/QL1S) > Win: Use native separators in QLibrary errors > Teach qmake's #include parser to recognize C++11 Raw strings. > Remove Wow6432Node versions of Visual Studio registry keys > syncqt.pl: say "ERROR" when it's an error > QNetworkInterface: fix support for address labels on Linux interfaces > Fix constructing a QSharedPointer of a QEnableSharedFromThis type > QVariant: retain duplicate keys when converting > QPlatformWindow::initialGeometry(): Pass screen when scaling. > Doc: Add the missing styles to get multi-column classes list > WinRT: Prepend '.' to default file suffix. > WinRT: Add RETURN_[]_IF_FAILED_WITH_ARGS macros. > Add QStyleHints::showIsMaximized(). > Don't treat "/etc/localtime" in TZ env var as a valid timezone id > Optimize qt_findAtNxFile by reducing the amount of allocations > Android: Implement QInputMethod::keyboardRectangle > Android: Fix QInputMethod's visible property > WinRT: Set TemporaryError in QNativeSocketEngine::accept() when no connections are pending. > Q_UNIMPLEMENTED: remove explicit file, line and funcinfo information > Initialize function tables without QGuiApplication > Remove additional copyright notice > Fix typo in QObject::disconnect() documentation qt/qtquickcontrols2 c930f4adf8dd0829c4d3a00d48b70ca988721033..f2f9786e6194725bf48ee3833b1fdf9603b74e69: > Round expected event coordinates in Button's events test > Print out actual and expected events in Button's events test > Fix some issues with GifRecorder > Add Control::locale qt/qt3d f6ff4023e42bec8cfe088f27c17f7d309f0a9003..94f3df1aacab5853d09e79596eb3bdae3aecae0a: > Add support for spotlights > Fix Rendering to Scene3D on Raspberry Pi (maybe other ES2 devices) > Added parameters to signals and made setters Q_SLOTS > Make QFrameAllocator private > Update simple-qml to use correct time delta > Pass frame time delta through to the logic component frame update > Add sensitivity property to QMouseController > simple-qml: CameraController implementation using the new Input API > Quick3D: QMatrix4x4 add translate overload > MouseController: various fixes > KeyboardController: fix PageUp position > Input: fix, event filters can't be registered with the same priority > Expose QDispatchCompute to QML > QRenderAspect: register ComputeDispatch backend node > BackendNode for QComputeDispatch > Add QDispatchCompute framegraph node > QMouseController: converted to QAbstractPhysicalDevice qt/qtconnectivity 0a9d4e32de60f31dac43973037ae7c546fb8cd6a..2402bb9421ab8ba4479b7a4e9566b682146f70ff: > Fix assignment of wrong errors values in read operations qt/qtqa 499756938979a9aaca5e378abd06cb6d10ceeb65..b8a34de3134ef24a8ad4937bc48365b0635e4431: > Revert "Revert "Open up license restrictions"" qt/qtdoc 23d7854f66ce5a37d0ce05a76a2c6350b0f6b81b..5f996b5e8abad7379a43a1e6158c228081a2e86d: > Doc: QML Performance: Remove mention of non-existent env. variable qt/qtmultimedia 2b7c617e090f495bbf62c1257c822f5849c21742..5916caae7a043da4c5547725cccbbeb10d18e1f5: > Doc: Move all doc artifacts under one project qt/qtdeclarative bb921064b966efdaabc2245cad21c3d852848a22..177050862e644f9a279086b703cb04e06ea409b8: > Clean up correctly in rendercontrol to avoid crashes > Particle Turbulence image now reads correctly from QRC or local files > Turbulence was accidentally deactivated on geometry changed > Make QQuickWidget update inside a proxy widget > Correct heightmap values for Turbulence > QQuickImageBase: Add support for @3x images > ListView: Sanitize visibleItems list after model insertions > Flickable: avoid perturbing the timeline further while in overshoot > Auto-tests for fast model updates while flicking > QQuickAnimatorJob: store the target with a QPointer > Add .qmltypes files for built-in QML API qt/qtactiveqt ac734d1bf343d64d6df93589ce1d8c9a2f7dbe9c..dd0feaa95a4c3e186c18bab16db5552bb8efc2db: > Fix infinite loop in MIME classinfo parser in ActiveQt ________________________________ Lähettäjä: Heikkinen Jani Lähetetty: 10. joulukuuta 2015 13:43 Vastaanottaja: development at qt-project.org Aihe: Qt 5.6.0 Beta candidate packages available Hi, We have finally Qt 5.6.0 beta candidate packages available: Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/224/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/290/ Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/283/ src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ All known blockers are fixed in these packages so if nothing serious found during testing we will release these package as Qt 5.6.0 beta on Monday so please inform me immediately if you find something badly broken. br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From massimocallegari at yahoo.it Wed Dec 16 14:40:57 2015 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Wed, 16 Dec 2015 13:40:57 +0000 (UTC) Subject: [Development] New Qt 5.6.0 Beta candidate packages available In-Reply-To: References: Message-ID: <680004908.3365164.1450273257443.JavaMail.yahoo@mail.yahoo.com> Hi and thanks everyone for your hard work on this massive Qt release. I'd just like to add my 2 cents. I know Qt3D on Qt 5.6.0 will still be a tech preview, but recently 2 examples (deferred-rendering-cpp and deferred-rendering-qml) got broken due to some changes in the lighting area. Here's the JIRA reference: https://bugreports.qt.io/browse/QTBUG-49788 Not a big deal, but if no one fix them, they will slip (broken) into the final release. Maybe it's worth considering if this is blocker for the RC or not. Or even better, fix the code :) Thanks ! (and sorry to the Qt3D team for sounding like a broken record...) Massimo ________________________________ Da: Heikkinen Jani A: "development at qt-project.org" Inviato: Mercoledì 16 Dicembre 2015 14:26 Oggetto: [Development] New Qt 5.6.0 Beta candidate packages available Hi all, Unfortunately we found new blocker (QTBUG-49886) from previous packages. Fixes for it is now in new packages: Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/292/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/295/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/229/ Src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ Please test these packages to see if these are now proper beta quality. We will release these packages as Qt 5.6.0 beta at the end of this week/beginning of next one if nothing serious found during testing. From mitch.curtis at theqtcompany.com Wed Dec 16 18:12:10 2015 From: mitch.curtis at theqtcompany.com (Curtis Mitch) Date: Wed, 16 Dec 2015 17:12:10 +0000 Subject: [Development] Aliasing with QSGRectangleNode In-Reply-To: <96A93274-A0BB-4F1D-9CA0-18829A489FAD@sletta.org> References: <96A93274-A0BB-4F1D-9CA0-18829A489FAD@sletta.org> Message-ID: > -----Original Message----- > From: Gunnar Sletta [mailto:gunnar at sletta.org] > Sent: Wednesday, 16 December 2015 9:05 AM > To: Curtis Mitch > Cc: development at qt-project.org > Subject: Re: [Development] Aliasing with QSGRectangleNode > > It is curious that the aliasing in the 1x image is not reproducible with > the Rectangle {} element and only for some of the elements.. Some subtlety > with the private api. One difference might be that you are giving your > rectangle nodes an explicit x/y while the Rectangle element uses a > transform node. It would require a bit of digging.. Thanks! That fixed it. :) For those interested, I changed it to the following: QPointF pos = QPointF(boundingRect().width() / 2 - circleRadius, boundingRect().height() / 2 - circleRadius); pos = moveBy(pos, 360 / circles * i, boundingRect().height() / 2 - circleRadius); rectNode->setRect(QRectF(QPointF(0, 0), QSizeF(circleRadius * 2, circleRadius * 2))); rectNode->setColor(i % 2 == 0 ? QColor("#353637") : QColor("transparent")); rectNode->setPenColor(QColor("#353637")); rectNode->setPenWidth(i % 2 == 0 ? 0 : 1); rectNode->update(); QMatrix4x4 matrix = transformNode->matrix(); matrix.translate(pos.x(), pos.y(), 0); transformNode->setMatrix(matrix); > The segmentation you see in the 2x and 6x images is a different problem. > That comes from the fact that the rectangle node doesn't know its render > size, so when the thing gets scaled up by 2x or 6x it doesn't know to take > that scale factor into account. This is another place that needs to look > up QQuickWindow::effectiveDevicePixelRatio() and apply that to the > segmentation factor. > > cheers, > Gunnar > > > On 15 Dec 2015, at 17:03, Curtis Mitch > wrote: > > > > > > Hi. > > > > I'm implementing a busy indicator for the new controls using > QSGRectangleNode. Even after calling rectNode->setAntialiasing(true), I'm > noticing some strange aliasing going on. Take a look at the various > attached screenshots to see what I'm talking about (the 2x/6x variants are > with QT_SCALE_FACTOR set). For filled "rectangles", there seems to be a > lack of antialiasing on the outer left side, and for unfilled rectangles > with borders, it's missing on the left inner side. > > > > The attached zip file contains a simplified example to try out. > > > > Anyone know why this is happening? > > > > Cheers. 2x.png>_______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development From filippocucchetto at gmail.com Thu Dec 17 19:49:21 2015 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Thu, 17 Dec 2015 19:49:21 +0100 Subject: [Development] Linear QQuick layouts change proposal Message-ID: Hi everyone, in these days i'm working on a project and dealing with how RowLayout and ColumnLayout behave. The thing that i don't like is that the elements are evenly spaced if the the layout is wider than the sum of the elements implicit size. To me the correct behaviour should mimic the one in the Row (Column) positioner where elements are layed out one after the other. The result is that most of the time you find yourself adding a dummy Item { Layout.fillWidth: true } for moving the elements at the beginning (or end) of the layout. This in turn create issues when you want to stretch an element dynamically because you have to make this dummy Item invisible. Finally adding a dummy item just for working around the default behaviour make the code messy. My proposal is to make the RowLayout (ColumnLayout) to lay thing one after each other and for miming the old behaviour to add an enum for the spacing property. For example Layout { spacing: Layout.UniformSpacing } or something like that. In this way we can get the best of both worlds: old behaviour, new behaviour and no dummy items. What do you think? -- Filippo Cucchetto -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.jabot at gmail.com Fri Dec 18 01:05:08 2015 From: corentin.jabot at gmail.com (Corentin Jabot) Date: Fri, 18 Dec 2015 01:05:08 +0100 Subject: [Development] High-DPI 5.6 beta update In-Reply-To: <03F1FCAD-FDE3-459A-8ED3-E9B04263F6CB@digia.com> References: <86C36AA2-E168-43ED-B464-3125E74406F9@digia.com> <5670690D.6040305@gmail.com> <03F1FCAD-FDE3-459A-8ED3-E9B04263F6CB@digia.com> Message-ID: Having stumbled upon this issue very recently, here are my 2 cents. - Svg images should be devicePixelRatio aware without having to set a source size - Likewise, QQuickImageProvider should know about devicePixelRation, without having to set a source size. - I would absolutely love an icon format, but I'm not a fan of QTBUG-49820 proposal. As mentioned, it basically requires a full scan of the directory. The performance implications are quite scary. I see a few solutions: - Use a list of files ( sources : [f1, f2, f3] ) or a list of sizes - Use some sort of pattern string : source : "foo-{32x32,64x64}.png" (with @x detected automatically ) - Accept .ico/icns files. The limitation is that these formats do not distinguish size and density (I quite like the idea of these too things being independent, but I don't think it will be used that often) - Use some sort of icon-descriptor file. But this solution feels a bit cumbersome - In any case, I feel that the extension should always be specified. ( source = "path/to/foo" really does feel TOO magical ) If we are only speaking about size/density (and not other features of QIcon like modes and states), I think extending the Image item would be more beneficial than adding a new type. 2015-12-16 11:29 GMT+01:00 Sorvig Morten : > > > On 15 Dec 2015, at 20:25, rpzrpzrpz at gmail.com wrote: > > > > Instead of worrying about @2x and @3x and trying to generate artwork in > all of the sizes, would it not be advantageous > > to only use SVG vector format and allow the svg plugin to generate and > scale at run-time a single svg file in the QRC file instead of having to > pre-generate files. > > > > Your thoughts on projects that use ONLY SVG image resources and not > PNG/JPEG? > > I think using SVG only is fine if that works for your project, and we want > to support it. > > But Qt _enforcing_ SVG only? We can’t really make that decision for our > users. > > Morten > > > > _______________________________________________ > 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 announce at qt-project.org Fri Dec 18 10:18:41 2015 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Fri, 18 Dec 2015 09:18:41 +0000 Subject: [Development] [Announce] Qt 5.6 Beta released Message-ID: Hi all, Qt 5.6.0 beta is finally out, see http://blog.qt.io/blog/2015/12/18/qt-5-6-beta-released/ . It was quite hard at this time ;) Big thanks to everyone involved! Best regards, Jani Heikkinen Release Manager | The Qt Company The Qt Company / Digia Finland Ltd, Elektroniikkatie 10, 90590 Oulu, Finland Email: jani.heikkinen at theqtcompany.com www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject Facebook: www.facebook.com/qt -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From Morten.Sorvig at theqtcompany.com Fri Dec 18 12:20:52 2015 From: Morten.Sorvig at theqtcompany.com (Sorvig Morten) Date: Fri, 18 Dec 2015 11:20:52 +0000 Subject: [Development] High-DPI 5.6 beta update In-Reply-To: References: <86C36AA2-E168-43ED-B464-3125E74406F9@digia.com> <5670690D.6040305@gmail.com> <03F1FCAD-FDE3-459A-8ED3-E9B04263F6CB@digia.com> Message-ID: <36200CA7-5E13-4B36-BB85-8A6CC029BDAE@digia.com> > On 18 Dec 2015, at 01:05, Corentin Jabot wrote: > > Having stumbled upon this issue very recently, here are my 2 cents. > • Svg images should be devicePixelRatio aware without having to set a source size > • Likewise, QQuickImageProvider should know about devicePixelRation, without having to set a source size. > • I would absolutely love an icon format, but I'm not a fan of QTBUG-49820 proposal. As mentioned, it basically requires a full scan of the directory. The performance implications are quite scary. I see a few solutions: Updated the task to mention an icon-descriptor file (this was already in the comments). I wonder what the actual performance implications will be. You are already going to disk to load the image file, what is the cost of adding a directory scan on top of that? > • Accept .ico/icns files. The limitation is that these formats do not distinguish size and density (I quite like the idea of these too things being independent, but I don't think it will be used that often) For what it’s worth, Qt Creator already has an instance of an icon that uses both (the spinning busy indicator). You can get far with not making the distinction though. > • In any case, I feel that the extension should always be specified. ( source = "path/to/foo" really does feel TOO magical ) I’m also not 100% happy with how the source is specified there. I added the “.png” extension in task now. We still have a path to a file that does not exist on the file system, so I’m not sure if it helped. Morten From rjvbertin at gmail.com Fri Dec 18 14:04:03 2015 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Fri, 18 Dec 2015 14:04:03 +0100 Subject: [Development] RFF: nullptr rules References: <201512091614.00734.marc.mutz@kdab.com> <566944FA.9070300@theqtcompany.com> <201512101436.49880.marc.mutz@kdab.com> <2437493.9i5hK11cGl@agathebauer> Message-ID: <3245793.BFbVNWY8ZT@patux.local> The invention of the 0 concept was a revolution; are we facing something similar here? :) Milian Wolff wrote: > This, for me, is btw. a very strong argument in favor of requesting nullptr > everywhere. Or of using 0 everywhere, but not having read the entire thread I must presume good reasons have been presented to use nullptr over 0. I saw mention of a Q_xxx macro in this thread (and lots of code using it). If it has been argued here already, let me add my voice to the opinion that this implies a Qt-specific type that should only be used in calls to Qt functions, something that seems counterproductive. R. From Simon.Hausmann at theqtcompany.com Fri Dec 18 14:56:26 2015 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Fri, 18 Dec 2015 13:56:26 +0000 Subject: [Development] Review request for ArrayBuffer+WebSocket/XHR (a.k.a Introducing protobuf-qml) In-Reply-To: References: Message-ID: Hi, I've started reviewing your series of patches. Excellent work! Thank you for contributing your changes back. I also think that protobuf bindings would make a lot of sense to have in Qt itself. Is there any chance that you could make it to the next Qt contributor summit and we have a chat about it there? :) Simon ________________________________ From: Development on behalf of Nobuaki Sukegawa Sent: Saturday, December 12, 2015 12:59 To: development at qt-project.org Subject: [Development] Review request for ArrayBuffer+WebSocket/XHR (a.k.a Introducing protobuf-qml) Hello Qt team and community, Could anyone help me with reviews on ArrayBuffer support for QtWebSockets and QtQuick XMLHttpRequest ? WebSockets: https://codereview.qt-project.org/#/c/125712/ [https://codereview.qt-project.org/static/logo_open_gov.png] Gerrit Code Review codereview.qt-project.org Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; Planet Qt; Qt Repository Browser XHR: https://codereview.qt-project.org/#/c/143732/ While I believe these features are generally useful, let me share my motivation: I've written Protocol Buffers / gRPC bindings for QtQuick2. https://github.com/nsuke/protobuf-qml Main feature of this is to serialize schematized message objects to ArrayBuffer. While it works fine for my need (plugging to proprietary RPC stack), I'd like to share this with others and see what they would do with this. Unfortunately, currently ArrayBuffer is not that useful out of the box as is, so it's not going to be much of interest without these features. You can find working examples of these patches here: WebSockets https://github.com/nsuke/protobuf-qml/blob/master/examples/WebSockets/client/client.qml#L105 XHR https://github.com/nsuke/protobuf-qml/blob/master/examples/XMLHttpRequest/client/XhrClient.qml#L112 Best regards, Nobuaki Sukegawa -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Fri Dec 18 15:59:20 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 18 Dec 2015 15:59:20 +0100 Subject: [Development] [OS X] window frame autosave/restore and [NSWindow representedFileName] Message-ID: <6285519.t3qztLP2QO@patux> Hi, I was looking into the mechanism OS X uses to save and restore window geometry automatically, notably using [window setFrameAutosaveName:[window representedFilename]] . The representedFileName property is controlled through [QWindow::setFilePath], but I cannot find any trace suggesting that the FrameAutosave functionality is available through Qt. If I haven't missed anything, is there a reason not to provide it e.g. through QtMacExtras - the only constraint it imposes is that the shouldCascadeWindows property must be turned off. Of course you'd need a way to remove stale/obsolete AutosaveNames from the defaults system, but that'd be a responsibility for the client code. -- René From heliocastro at gmail.com Fri Dec 18 16:32:00 2015 From: heliocastro at gmail.com (Helio Chissini de Castro) Date: Fri, 18 Dec 2015 16:32:00 +0100 Subject: [Development] [Announce] Qt 5.6 Beta released In-Reply-To: References: Message-ID: Thanks for the work Jani Would be so much to ask to have a .xz version of submodules ? We use to have on both https://download.qt.io/development_releases/qt/5.6/5.6.0-alpha/submodules/ and https://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/ and they cause sometimes a huge size difference. Regards, Helio On Fri, Dec 18, 2015 at 10:18 AM, List for announcements regarding Qt releases and development wrote: > Hi all, > > > Qt 5.6.0 beta is finally out, see > http://blog.qt.io/blog/2015/12/18/qt-5-6-beta-released/ . > > > It was quite hard at this time ;) Big thanks to everyone involved! > > > Best regards, > > Jani Heikkinen > > Release Manager | The Qt Company > > > > The Qt Company / Digia Finland Ltd, Elektroniikkatie 10, 90590 Oulu, > Finland > > Email: jani.heikkinen at theqtcompany.com > > www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, > @Qtproject Facebook: www.facebook.com/qt > > > _______________________________________________ > Announce mailing list > Announce at qt-project.org > http://lists.qt-project.org/mailman/listinfo/announce > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From helio at kde.org Fri Dec 18 16:32:50 2015 From: helio at kde.org (Helio Chissini de Castro) Date: Fri, 18 Dec 2015 16:32:50 +0100 Subject: [Development] [Announce] Qt 5.6 Beta released In-Reply-To: References: Message-ID: Thanks for the work Jani Would be so much to ask to have a .xz version of submodules ? We use to have on both https://download.qt.io/development_releases/qt/5.6/5.6.0-alpha/submodules/ and https://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/ and they cause sometimes a huge size difference. Regards, Helio On Fri, Dec 18, 2015 at 10:18 AM, List for announcements regarding Qt releases and development wrote: > Hi all, > > > Qt 5.6.0 beta is finally out, see > http://blog.qt.io/blog/2015/12/18/qt-5-6-beta-released/ . > > > It was quite hard at this time ;) Big thanks to everyone involved! > > > Best regards, > > Jani Heikkinen > > Release Manager | The Qt Company > > > > The Qt Company / Digia Finland Ltd, Elektroniikkatie 10, 90590 Oulu, > Finland > > Email: jani.heikkinen at theqtcompany.com > > www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, > @Qtproject Facebook: www.facebook.com/qt > > > _______________________________________________ > Announce mailing list > Announce at qt-project.org > http://lists.qt-project.org/mailman/listinfo/announce > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Dec 18 18:41:55 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 18 Dec 2015 09:41:55 -0800 Subject: [Development] RFF: nullptr rules In-Reply-To: <3245793.BFbVNWY8ZT@patux.local> References: <201512091614.00734.marc.mutz@kdab.com> <2437493.9i5hK11cGl@agathebauer> <3245793.BFbVNWY8ZT@patux.local> Message-ID: <2688699.tphTNUgzNN@tjmaciei-mobl4> On Friday 18 December 2015 14:04:03 René J. V. Bertin wrote: > I saw mention of a Q_xxx macro in this thread (and lots of code using it). > If it has been argued here already, let me add my voice to the opinion that > this implies a Qt-specific type that should only be used in calls to Qt > functions, something that seems counterproductive. The macro is deprecated in Qt 5.7 and should not be used in any new code. It will deserve a -1. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From frederic.marchal at wowtechnology.com Sun Dec 20 08:56:18 2015 From: frederic.marchal at wowtechnology.com (Frederic Marchal) Date: Sun, 20 Dec 2015 08:56:18 +0100 Subject: [Development] How to link a commit to a bug report Message-ID: <60444868.QhRvH1hYQJ@fmarchal.edpnet.be> Hello, I created QTBUG-50068: https://bugreports.qt.io/browse/QTBUG-50068 and now I may have a patch to commit. How do I tell the world that this commit is for that bug report? I see some commits have a Task-number. Do I add it manually to the commit message? In the meantime, while I'm taming gerrit, how do I inform any reader of QTBUG-50068 that I'm working on a patch? Thanks, Frederic -------------- next part -------------- An HTML attachment was scrubbed... URL: From giuseppe.dangelo at kdab.com Sun Dec 20 11:15:19 2015 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Sun, 20 Dec 2015 11:15:19 +0100 Subject: [Development] How to link a commit to a bug report In-Reply-To: <60444868.QhRvH1hYQJ@fmarchal.edpnet.be> References: <60444868.QhRvH1hYQJ@fmarchal.edpnet.be> Message-ID: <56767FB7.8090605@kdab.com> Hi, thanks for contributing to Qt! :) Il 20/12/2015 08:56, Frederic Marchal ha scritto: > I created QTBUG-50068: https://bugreports.qt.io/browse/QTBUG-50068 and > now I may have a patch to commit. > > How do I tell the world that this commit is for that bug report? > > I see some commits have a Task-number. Do I add it manually to the > commit message? That's correct. There should be a hint in the commit message template (when you install the hooks from Qt), but otherwise, it's manual. > In the meantime, while I'm taming gerrit, how do I inform any reader of > QTBUG-50068 that I'm working on a patch? After you push your patch to gerrit you can simply leave a comment on QTBUG-50068 , linking to your review on gerrit. You may further ask for the bug to be assigned to you and to mark it in review (I'm not sure which privileges one needs to do so, eventually just ask on this list or on #qt-labs on Freenode, any approver will be glad to help); so far the rules on bug tracking have been quite sloppy and not really enforced (we care more about fixing the bug than having a strict bug tracking procedure, I guess). Last, when your patch gets merged, you can ask to mark the bug as fixed, with the SHA1 of the commit that got merged and the version of Qt that will include the bug. Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4068 bytes Desc: Firma crittografica S/MIME URL: From nsukeg at gmail.com Sun Dec 20 12:55:50 2015 From: nsukeg at gmail.com (Nobuaki Sukegawa) Date: Sun, 20 Dec 2015 11:55:50 +0000 Subject: [Development] Review request for ArrayBuffer+WebSocket/XHR (a.k.a Introducing protobuf-qml) In-Reply-To: References: Message-ID: Thank you for the review and feedback ! I wasn't aware of the event and it looks interesting. I hope Oslo wasn't that distant from here (12+ hours flight from Japan) but in case I attend it I'd be more than happy to have a chat over this for sure. Nobuaki Sukegawa On Fri, Dec 18, 2015 at 10:56 PM Hausmann Simon < Simon.Hausmann at theqtcompany.com> wrote: > Hi, > > > I've started reviewing your series of patches. Excellent work! Thank you > for contributing your changes back. > > > I also think that protobuf bindings would make a lot of sense to have in > Qt itself. Is there any chance that you could > > make it to the next Qt contributor summit and we have a chat about it > there? :) > > > > Simon > > > ------------------------------ > *From:* Development on behalf of > Nobuaki Sukegawa > *Sent:* Saturday, December 12, 2015 12:59 > *To:* development at qt-project.org > *Subject:* [Development] Review request for ArrayBuffer+WebSocket/XHR > (a.k.a Introducing protobuf-qml) > > Hello Qt team and community, > > Could anyone help me with reviews on ArrayBuffer support for QtWebSockets > and QtQuick XMLHttpRequest ? > > WebSockets: > https://codereview.qt-project.org/#/c/125712/ > > Gerrit Code Review > codereview.qt-project.org > Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; > Planet Qt; Qt Repository Browser > > > XHR: > https://codereview.qt-project.org/#/c/143732/ > > > While I believe these features are generally useful, let me share my > motivation: > > I've written Protocol Buffers / gRPC bindings for QtQuick2. > https://github.com/nsuke/protobuf-qml > > Main feature of this is to serialize schematized message objects to > ArrayBuffer. > > While it works fine for my need (plugging to proprietary RPC stack), I'd > like to share this with others and see what they would do with this. > > Unfortunately, currently ArrayBuffer is not that useful out of the box as > is, so it's not going to be much of interest without these features. > > You can find working examples of these patches here: > > WebSockets > > https://github.com/nsuke/protobuf-qml/blob/master/examples/WebSockets/client/client.qml#L105 > > XHR > > https://github.com/nsuke/protobuf-qml/blob/master/examples/XMLHttpRequest/client/XhrClient.qml#L112 > > Best regards, > > Nobuaki Sukegawa > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Sun Dec 20 17:44:36 2015 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sun, 20 Dec 2015 17:44:36 +0100 Subject: [Development] Qt::WindowFullScreen on OS X Message-ID: <2961880.PVBJvt9YAg@portia.local> Hi OS X introduced a "Displays have separate Spaces" feature in I think 10.9, which controls whether virtual desktops span over all connected displays or are specific to each display. There is an interplay with fullscreen behaviour. Fullscreen still means occupying the window's screen (display), not the full desktop, which is probably good. It also means that setting a window to fullscreen mode blacks out the view on all other displays, which is much more debatable IMHO. There are still (Qt4-based) applications that manage to achieve the legacy fullscreen mode in which only the window's "own" display is affected and the view on other displays remains visible normally. Is there a way foreseen to achieve this in Qt5? I had hoped that QWindow::Fullscreen might have this effect because it is documented as "The window occupies one entire screen, is not resizable, and there is no titlebar." but no such luck. Regards, René From rjvbertin at gmail.com Sun Dec 20 19:02:58 2015 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sun, 20 Dec 2015 19:02:58 +0100 Subject: [Development] Qt::WindowFullScreen on OS X References: <2961880.PVBJvt9YAg@portia.local> Message-ID: <1957200.682zoGqAmP@portia.local> René J. V. Bertin wrote: Apologies, this was intended for the interest ML. R. > Hi > > OS X introduced a "Displays have separate Spaces" feature in I think 10.9, > which controls whether virtual desktops span over all connected displays or > are specific to each display. There is an interplay with fullscreen behaviour. > Fullscreen still means occupying the window's screen (display), not the full > desktop, which is probably good. It also means that setting a window to > fullscreen mode blacks out the view on all other displays, which is much more > debatable IMHO. > > There are still (Qt4-based) applications that manage to achieve the legacy > fullscreen mode in which only the window's "own" display is affected and the > view on other displays remains visible normally. > > Is there a way foreseen to achieve this in Qt5? I had hoped that > QWindow::Fullscreen might have this effect because it is documented as > "The window occupies one entire screen, is not resizable, and there is no > titlebar." > > but no such luck. > > Regards, > René From jani.heikkinen at theqtcompany.com Mon Dec 21 08:56:15 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Mon, 21 Dec 2015 07:56:15 +0000 Subject: [Development] HEADS UP - Qt 5.6.0 String freeze coming Message-ID: Hi, Beta is finally out & work for finalizing Qt 5.6 continues. One milestone for that is string freeze which will be 30.12.2015. So it is time to start keeping the translatable strings as it is and fix remaining important issues. br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jukka.Jokiniva at theqtcompany.com Mon Dec 21 09:48:37 2015 From: Jukka.Jokiniva at theqtcompany.com (Jokiniva Jukka) Date: Mon, 21 Dec 2015 08:48:37 +0000 Subject: [Development] Heads up for Qt Bug Report & Code Review users Message-ID: Hi, Some months ago we asked all Qt users to provide us input on ideas to further improve the Qt developer experience. You spoke. We listened. It was overwhelmingly clear that single sign-on for all Qt Services was at the top of desired features and functionality. Since then, we have been working toward providing this to you. As part of this effort, you will now have common credentials for all of the following Qt services: · Qt Account web portal for license management, downloads and commercial support · Qt Forum · Qt Wiki · Qt Bug Tracker (NEW) · Qt Code Review (NEW) Note: There will be a maintenance break on Tuesday 12 January 2016 from 07:00-11:00 a.m. (CET) when we unify the login for Qt Bug Tracker (https://bugreports.qt.io) and Qt Code Review (https://codereview.qt-project.org). IMPORTANT The email address that you currently use to log into Bug Tracker and Code Review will be associated with Qt account credentials. · If you don't already have Qt credentials, all you need to do is register at https://login.qt.io/register* using the same email address you currently use for Bug Tracker and Code Review. If you want to change to a different email address for your unified login credentials, you should first update the email address in Bug Tracker** to ensure the logins will be merged. · If you already have Qt account credentials, but use different email addresses for each account, you should ensure that your Bug Tracker email address is the same as in your Qt account profile so that all your account credentials will be merged. * Please be sure to complete the email verification process, which will be explained to you in the email sent upon registering. ** To edit your Bug Reports email address, go to https://bugreports.qt.io/secure/ViewProfile.jspa profile settings and select the pen icon. We hope you will enjoy this improvement. We will also continue to work toward adding more of features and functionality that you all asked for. Best regards, The Qt Company www.qt.io |Qt Blog: http://blog.qt.io/ | Twitter: @Qtproject | Facebook: www.facebook.com/qt -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.harmer at kdab.com Mon Dec 21 10:22:06 2015 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 21 Dec 2015 09:22:06 +0000 Subject: [Development] Heads up for Qt Bug Report & Code Review users In-Reply-To: References: Message-ID: <2059054.qG5NSfjtj3@titan> On Monday 21 December 2015 08:48:37 Jokiniva Jukka wrote: > Hi, > > Some months ago we asked all Qt users to provide us input on ideas to > further improve the Qt developer experience. You spoke. We listened. It was > overwhelmingly clear that single sign-on for all Qt Services was at the top > of desired features and functionality. Since then, we have been working > toward providing this to you. As part of this effort, you will now have > common credentials for all of the following Qt services: > > > · Qt Account web portal for license > management, downloads and commercial support > > · Qt Forum > > · Qt Wiki > > · Qt Bug Tracker (NEW) > > · Qt Code Review (NEW) > > Note: There will be a maintenance break on Tuesday 12 January 2016 from > 07:00-11:00 a.m. (CET) when we unify the login for Qt Bug Tracker > (https://bugreports.qt.io) and Qt Code Review > (https://codereview.qt-project.org). Thank you for all the hard work but can we please please not break the CI two days before feature freeze? Cheers, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions From jani.heikkinen at theqtcompany.com Mon Dec 21 11:01:51 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Mon, 21 Dec 2015 10:01:51 +0000 Subject: [Development] Heads up for Qt Bug Report & Code Review users In-Reply-To: <2059054.qG5NSfjtj3@titan> References: <2059054.qG5NSfjtj3@titan> Message-ID: >>-----Original Message----- >>From: Development [mailto:development-bounces at qt-project.org] On Behalf >>Of Sean Harmer >>Sent: 21. joulukuuta 2015 11:22 >>To: development at qt-project.org >>Subject: Re: [Development] Heads up for Qt Bug Report & Code Review users >> >>On Monday 21 December 2015 08:48:37 Jokiniva Jukka wrote: >>> Hi, >>> >>> Some months ago we asked all Qt users to provide us input on ideas to >>> further improve the Qt developer experience. You spoke. We listened. It was >>> overwhelmingly clear that single sign-on for all Qt Services was at the top >>> of desired features and functionality. Since then, we have been working >>> toward providing this to you. As part of this effort, you will now have >>> common credentials for all of the following Qt services: >>> >>> >>> · Qt Account web portal for license >>> management, downloads and commercial support >>> >>> · Qt Forum >>> >>> · Qt Wiki >>> >>> · Qt Bug Tracker (NEW) >>> >>> · Qt Code Review (NEW) >>> >>> Note: There will be a maintenance break on Tuesday 12 January 2016 from >>> 07:00-11:00 a.m. (CET) when we unify the login for Qt Bug Tracker >>> (https://bugreports.qt.io) and Qt Code Review >>> (https://codereview.qt-project.org). >> >>Thank you for all the hard work but can we please please not break the CI two >>days before feature freeze? >> >>Cheers, >> >>Sean >>-- You are right, we should postpone this maintenance break after FF. 21st January might be good target for that, all feature freeze related stuff should be ready at this point Br, Jani >>Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK >>Klarälvdalens Datakonsult AB, a KDAB Group company >>Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) >>KDAB - Qt Experts - Platform-independent software solutions >>_______________________________________________ >>Development mailing list >>Development at qt-project.org >>http://lists.qt-project.org/mailman/listinfo/development From oswald.buddenhagen at theqtcompany.com Mon Dec 21 11:51:31 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Mon, 21 Dec 2015 11:51:31 +0100 Subject: [Development] How to link a commit to a bug report In-Reply-To: <56767FB7.8090605@kdab.com> References: <60444868.QhRvH1hYQJ@fmarchal.edpnet.be> <56767FB7.8090605@kdab.com> Message-ID: <20151221105131.GB8920@troll08.it.local> On Sun, Dec 20, 2015 at 11:15:19AM +0100, Giuseppe D'Angelo wrote: > Il 20/12/2015 08:56, Frederic Marchal ha scritto: > >In the meantime, while I'm taming gerrit, how do I inform any reader of > >QTBUG-50068 that I'm working on a patch? > > After you push your patch to gerrit you can simply leave a comment on > QTBUG-50068 , linking to your review on gerrit. > little noticed fact: there is actually a "gerrit reviews" tab in jira which links right back to the review, including its current status. unfortunately, this is lacking a proper notification workflow, so it isn't very useful ... From dangelog at gmail.com Mon Dec 21 11:52:53 2015 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Mon, 21 Dec 2015 11:52:53 +0100 Subject: [Development] Heads up for Qt Bug Report & Code Review users In-Reply-To: References: Message-ID: Hi, On Mon, Dec 21, 2015 at 9:48 AM, Jokiniva Jukka wrote: > · If you don’t already have Qt credentials, all you need to do is > register at https://login.qt.io/register* using the same email address you > currently use for Bug Tracker and Code Review. If you want to change to a > different email address for your unified login credentials, you should first > update the email address in Bug Tracker** to ensure the logins will be > merged. What happens if one does not have a Qt Account on login.qt.io, but only a Jira/Gerrit account? Will a Qt Account be created automatically? Thanks, -- Giuseppe D'Angelo From jani.heikkinen at theqtcompany.com Mon Dec 21 12:40:15 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Mon, 21 Dec 2015 11:40:15 +0000 Subject: [Development] Qt 5.7 new feature list needs to be created/updated Message-ID: Hi all, According to current plans we will have Qt 5.7 feature freeze 15th Jan 2016. That is already quite close so we should have pretty good understanding of new features for Qt 5.7. So please start listing all new features for Qt 5.7 in new features list ( https://wiki.qt.io/New_Features_in_Qt_5.7 ) br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From timo.jyrinki at gmail.com Mon Dec 21 15:22:08 2015 From: timo.jyrinki at gmail.com (Timo Jyrinki) Date: Mon, 21 Dec 2015 16:22:08 +0200 Subject: [Development] [Announce] Qt 5.6 Beta released In-Reply-To: References: Message-ID: Thanks and congrats for Qt 5.6 beta from my side too! I had the same question has Helio did, about missing .tar.xz. Nothing urgent, as long as they'll be available at least for the RC and final releases. -Timo 2015-12-18 17:32 GMT+02:00 Helio Chissini de Castro : > Thanks for the work Jani > > Would be so much to ask to have a .xz version of submodules ? > We use to have on both > https://download.qt.io/development_releases/qt/5.6/5.6.0-alpha/submodules/ > and > https://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/ and they > cause sometimes a huge size difference. > > Regards, Helio > > > On Fri, Dec 18, 2015 at 10:18 AM, List for announcements regarding Qt > releases and development wrote: >> >> Hi all, >> >> >> Qt 5.6.0 beta is finally out, see >> http://blog.qt.io/blog/2015/12/18/qt-5-6-beta-released/ . >> >> >> It was quite hard at this time ;) Big thanks to everyone involved! >> >> >> Best regards, >> >> Jani Heikkinen >> >> Release Manager | The Qt Company >> >> >> >> The Qt Company / Digia Finland Ltd, Elektroniikkatie 10, 90590 Oulu, >> Finland >> >> Email: jani.heikkinen at theqtcompany.com >> >> www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, >> @Qtproject Facebook: www.facebook.com/qt >> >> >> >> _______________________________________________ >> Announce mailing list >> Announce at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/announce >> > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From gunnar.roth at gmx.de Mon Dec 21 17:44:19 2015 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Mon, 21 Dec 2015 17:44:19 +0100 Subject: [Development] wec2013 build fails with qt 5.6 beta in dbus. Message-ID: An HTML attachment was scrubbed... URL: From jtranter at ics.com Mon Dec 21 18:38:01 2015 From: jtranter at ics.com (Jeff Tranter) Date: Mon, 21 Dec 2015 12:38:01 -0500 Subject: [Development] Qt SerialBus still planned to be in Qt 5.6.0? Message-ID: <567838F9.3030508@ics.com> I was curious if Qt SerialBus is still planned to be in the Qt 5.6.0 release, given that it was not included in the beta? From thiago.macieira at intel.com Mon Dec 21 19:46:19 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 21 Dec 2015 16:46:19 -0200 Subject: [Development] wec2013 build fails with qt 5.6 beta in dbus. In-Reply-To: References: Message-ID: <3321106.6JoSvrVuDN@tjmaciei-mobl4> On Monday 21 December 2015 17:44:19 Gunnar Roth wrote: > Hi, > the problem is that dbus is set to runtime instead of no for windows from > configure when no dbus support is found. So it is being tried to build it, > which fails, mostly due to using 'interface' as identifier, which seems to > be a define somewhere in the wec2013 headers. I wil add -no-dbus to my > configure line. > I assume there is no ci in place for wec2013? There is and it probably has -no-dbus. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From gunnar.roth at gmx.de Mon Dec 21 21:58:46 2015 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Mon, 21 Dec 2015 21:58:46 +0100 Subject: [Development] wec2013 build fails with qt 5.6 beta in dbus. In-Reply-To: <3321106.6JoSvrVuDN@tjmaciei-mobl4> References: <3321106.6JoSvrVuDN@tjmaciei-mobl4> Message-ID: <8AAEE870-786F-4D88-A6BD-DF3C583C08DA@gmx.de> Hi Thiago, > Am 21.12.2015 um 19:46 schrieb Thiago Macieira : > > On Monday 21 December 2015 17:44:19 Gunnar Roth wrote: >> Hi, >> the problem is that dbus is set to runtime instead of no for windows from >> configure when no dbus support is found. So it is being tried to build it, >> which fails, mostly due to using 'interface' as identifier, which seems to >> be a define somewhere in the wec2013 headers. I wil add -no-dbus to my >> configure line. >> I assume there is no ci in place for wec2013? > > There is and it probably has -no-dbus. How am I supposed know? It worked without that since 5.2.1. How should anybody know that now -no-dbus is needed. Why has configure app.cpp so many special cases for ce, which disable ssl even if you give -openssl to configure ( fixed in dev) or disable sse(2) for ce, even if you give -sse2 to configure, which is a use case when having an x86 wec2013? But there is no bus disabling, which would actually make sense and the other before mentioned cases do not. Regards, Gunnar From Simon.Hausmann at theqtcompany.com Mon Dec 21 22:22:19 2015 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Mon, 21 Dec 2015 21:22:19 +0000 Subject: [Development] wec2013 build fails with qt 5.6 beta in dbus. In-Reply-To: References: Message-ID: <20151221212218.5922896.22933.53946@theqtcompany.com> We ran into similar issues in a few places and the established workaround is a carefully placed #undef interface. Would you be able to tell us where the conflict happened or maybe even make a patch? (see qtnetwork for a similar #undef) Simon From: Gunnar Roth Sent: Monday, December 21, 2015 17:44 To: development at qt-project.org Subject: [Development] wec2013 build fails with qt 5.6 beta in dbus. Hi, the problem is that dbus is set to runtime instead of no for windows from configure when no dbus support is found. So it is being tried to build it, which fails, mostly due to using 'interface' as identifier, which seems to be a define somewhere in the wec2013 headers. I wil add -no-dbus to my configure line. I assume there is no ci in place for wec2013? Regards, Gunnar -------------- next part -------------- An HTML attachment was scrubbed... URL: From gunnar.roth at gmx.de Mon Dec 21 23:43:15 2015 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Mon, 21 Dec 2015 23:43:15 +0100 Subject: [Development] wec2013 build fails with qt 5.6 beta in dbus. In-Reply-To: <20151221212218.5922896.22933.53946@theqtcompany.com> References: <20151221212218.5922896.22933.53946@theqtcompany.com> Message-ID: <9074C2E2-8009-41FA-94B8-FB34D37463E6@gmx.de> Hi Simon. The conflict happens in a dozen files in qtbase/src/dbus/ and qttools/src/qdbus. I just wrote my mail so other can save the time i spend on figuring out what is wrong with the new qt version. As I wrote in another mail, for wince bus should be set to no by default, as it was before ( because it was no for windows but is runtime now, when no bus headers are found) I know of no working dbus for wec2013 and i don’t need it either. Regards, Gunnar > Am 21.12.2015 um 22:22 schrieb Hausmann Simon : > > We ran into similar issues in a few places and the established workaround is a carefully placed #undef interface. Would you be able to tell us where the conflict happened or maybe even make a patch? (see qtnetwork for a similar #undef) > > > Simon > > From: Gunnar Roth > Sent: Monday, December 21, 2015 17:44 > To: development at qt-project.org > Subject: [Development] wec2013 build fails with qt 5.6 beta in dbus. > > Hi, > the problem is that dbus is set to runtime instead of no for windows from configure when no dbus support is found. So it is being tried to build it, which fails, > mostly due to using 'interface' as identifier, which seems to be a define somewhere in the wec2013 headers. I wil add -no-dbus to my configure line. > > I assume there is no ci in place for wec2013? > > Regards, > Gunnar > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at theqtcompany.com Tue Dec 22 06:10:11 2015 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Tue, 22 Dec 2015 05:10:11 +0000 Subject: [Development] Qt SerialBus still planned to be in Qt 5.6.0? In-Reply-To: <567838F9.3030508@ics.com> References: <567838F9.3030508@ics.com> Message-ID: <4AAA4461-1AB1-40B0-80EC-440D1F6A063D@theqtcompany.com> Yes, as a technology preview. -- Tuukka > Jeff Tranter kirjoitti 21.12.2015 kello 19.38: > > I was curious if Qt SerialBus is still planned to be in the Qt 5.6.0 release, given that it was not included in the beta? > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From gunnar.roth at gmx.de Tue Dec 22 10:43:53 2015 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Tue, 22 Dec 2015 10:43:53 +0100 Subject: [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with uic.exe showing dialog qt5core.dll cannot be found. Message-ID: An HTML attachment was scrubbed... URL: From gunnar.roth at gmx.de Tue Dec 22 11:13:29 2015 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Tue, 22 Dec 2015 11:13:29 +0100 Subject: [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with uic.exe showing dialog qt5core.dll cannot be found. In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From tim at klingt.org Tue Dec 22 11:17:03 2015 From: tim at klingt.org (Tim Blechmann) Date: Tue, 22 Dec 2015 11:17:03 +0100 Subject: [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with uic.exe showing dialog qt5core.dll cannot be found. In-Reply-To: References: Message-ID: <5679231F.9030802@klingt.org> > I found out that the % is due to using jom in 5.5.1 and nmake in 5.6.1. > I looked into the Makefiles and bot had the same term. When i use jom > for 5.6 i see (set > QT_PLUGIN_PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\plugins) > & (set > PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin;%%PATH:)=^)%%) > & D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin\uic.exe > D:\TFS\_Global\Shared\src\Qt\5.6.0\qt-src\qtbase\src\widgets\dialogs\qfiledialog.ui > -o .uic\ui_qfiledialog.h > which has also %%PATH:)=^)%% , so that is not the problem. wec2013 works > because there uic.exe and qlarl.exe are build statically. seems that i'm not hallucinating then: https://codereview.qt-project.org/#/c/144550/ > Regards, > Gunnar > > *Gesendet:* Dienstag, 22. Dezember 2015 um 10:43 Uhr > *Von:* "Gunnar Roth" > *An:* "development at qt-project.org" > *Betreff:* [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with > uic.exe showing dialog qt5core.dll cannot be found. > Hello, > > when i used jom i get this dialog with qt5core not found. > When using nmake i get this error: > (set > QT_PLUGIN_PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\plugins) > & (set PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin;%PATH:)=^)% > ) & D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin\uic.exe > D:\TFS\_Global\Shared\src\Qt\5.6.0\qt-src\qtbase\src\widgets\dialogs\qfiledialog.ui > -o .uic\ui_q > filedialog.h > NMAKE : fatal error U1077: '(set' : return code '0xc0000135' > Stop. > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual > Studio 11.0\VC\BIN\nmake.exe"' : return code '0x2' > Stop. > NMAKE : fatal error U1077: 'cd' : return code '0x2' > Stop. > NMAKE : fatal error U1077: 'cd' : return code '0x2' > Stop. > NMAKE : fatal error U1077: 'cd' : return code '0x2' > > > Looking into a successful 5.5.1 build log i see > > (set > QT_PLUGIN_PATH=D:\TFS\bld__GLOBAL\Qt5.5.1\WIN32-VS11-32\qtbase\plugins) > & (set > PATH=D:\TFS\bld__GLOBAL\Qt5.5.1\WIN32-VS11-32\qtbase\lib;%%PATH:)=^)%%) > & D:\TFS\bld__GLOBAL\Qt5.5.1\WIN32-VS11-32\qtbase\bin\uic.exe > D:\TFS\_Global\Shared\src\Qt\5.5.1\qt-src\qtbase\src\widgets\dialogs\qfiledialog.ui > -o .uic\ui_qfiledialog.h > and in my 5.6.0 build > (set > QT_PLUGIN_PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\plugins) > & (set > PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin;%PATH:)=^)%) & > D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin\uic.exe > D:\TFS\_Global\Shared\src\Qt\5.6.0\qt-src\qtbase\src\widgets\dialogs\qfiledialog.ui > -o .uic\ui_qfiledialog.h > > so %%PATH:)=^)%% is now %PATH:)=^)%. > > How did CI not catch that? Strange is my wec2013 build has worked after > adding -no-dbus. > > Regards, > Gunnar > > _______________________________________________ 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 Eike.Ziller at theqtcompany.com Tue Dec 22 11:26:40 2015 From: Eike.Ziller at theqtcompany.com (Ziller Eike) Date: Tue, 22 Dec 2015 10:26:40 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <592A0CC7-1F6F-4F31-8B91-BF1C17D78796@theqtcompany.com> References: <201512031949.46920.marc.mutz@kdab.com> <4606126.Pqxnumcx4H@finn> <04544583-2102-4BE6-8232-D12634E879E7@theqtcompany.com> <201512071544.42707.marc.mutz@kdab.com> <1BD99747-4E60-4C76-8612-DE744E1CCA14@theqtcompany.com> <592A0CC7-1F6F-4F31-8B91-BF1C17D78796@theqtcompany.com> Message-ID: <2751DBCD-0CE9-42B9-97C1-5AA9B2D4E4C3@theqtcompany.com> > On Dec 8, 2015, at 10:46 AM, Ziller Eike wrote: > > >> On Dec 7, 2015, at 2:41 PM, Knoll Lars wrote: >> >> On 07/12/15 15:44, "Development on behalf of Marc Mutz" wrote: >> >> >> >>> On Monday 07 December 2015 13:48:58 Ziller Eike wrote: >>>> I do not think that more usage of ‘auto’ will make any code (or >>>> refactorings of it) ‘safer’. IMO this is only about convenience and >>>> readability. >>> >>> std::map stdMap = ...; >>> >>> for (const std::pair &e : stdMap) >>> doSomething(e.first, e.second); >>> >>> for (const auto &e : stdMap) >>> doSomething(e.first, e.second); >>> >>> The second loop is at least two orders of magnitude faster (doSomething() is >>> an out-of-line no-op). >> >> I think the summary here is that auto gives you one guarantee: It won’t do an implicit conversion for the initial assignment. So, directly after the above example in Item 5, Item 6 in Effective Modern C++ continues with the examples of how you can shoot yourself in the foot _because_ you used auto. std::vector features(const MyType &w); MyType w; auto someFeatureActive = features(w)[5]; doSomething(someFeatureActive); // <---- undefined behavior because someFeatureActive is _not_ a bool We have something similar in Qt: QString a = "ABC"; QString b = "abc"; auto result = a + b; a.replace("A", "C"); qDebug() << result; prints “CBCabc” instead of “ABCabc” when QT_USE_FAST_OPERATOR_PLUS is defined, because result is not a QString in that case. So funny/unwanted behavior can occur both because one used the wrong explicit type, and because one used auto instead of an explicit type. > Granted. > I really wonder though, why it is possible to assign the wrong type to a _reference_ here, even if it is const ? > I cannot do that with e.g. a std::vector (std::vector v; const std::vector &v2 = v;), so is that some funny thing with std::pair? > The spirit of the “you can use auto when assigning iterator type” was to mean “you can use auto when assigning long ugly template types” at least in case of ‘known patterns' (of which we do not have too many in Qt API, therefore iterator types). So I think this use of auto is covered by the “spirit” of the rule. > > Br, Eike -- Eike Ziller, Senior Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Jukka.Jokiniva at theqtcompany.com Tue Dec 22 11:33:32 2015 From: Jukka.Jokiniva at theqtcompany.com (Jokiniva Jukka) Date: Tue, 22 Dec 2015 10:33:32 +0000 Subject: [Development] Heads up for Qt Bug Report & Code Review users In-Reply-To: References: <2059054.qG5NSfjtj3@titan> Message-ID: OK, Let¹s reschedule this to 21-Jan-2016. ‹Jukka On 21/12/15 12:01, "Development on behalf of Heikkinen Jani" wrote: >>>-----Original Message----- >>>From: Development [mailto:development-bounces at qt-project.org] On Behalf >>>Of Sean Harmer >>>Sent: 21. joulukuuta 2015 11:22 >>>To: development at qt-project.org >>>Subject: Re: [Development] Heads up for Qt Bug Report & Code Review >>>users >>> >>>On Monday 21 December 2015 08:48:37 Jokiniva Jukka wrote: >>>> Hi, >>>> >>>> Some months ago we asked all Qt users to provide us input on ideas to >>>> further improve the Qt developer experience. You spoke. We listened. >>>>It was >>>> overwhelmingly clear that single sign-on for all Qt Services was at >>>>the top >>>> of desired features and functionality. Since then, we have been >>>>working >>>> toward providing this to you. As part of this effort, you will now >>>>have >>>> common credentials for all of the following Qt services: >>>> >>>> >>>> · Qt Account web portal for license >>>> management, downloads and commercial support >>>> >>>> · Qt Forum >>>> >>>> · Qt Wiki >>>> >>>> · Qt Bug Tracker (NEW) >>>> >>>> · Qt Code Review (NEW) >>>> >>>> Note: There will be a maintenance break on Tuesday 12 January 2016 >>>>from >>>> 07:00-11:00 a.m. (CET) when we unify the login for Qt Bug Tracker >>>> (https://bugreports.qt.io) and Qt Code >>>>Review >>>> >>>>(https://codereview.qt-project.org) >>>>. >>> >>>Thank you for all the hard work but can we please please not break the >>>CI two >>>days before feature freeze? >>> >>>Cheers, >>> >>>Sean >>>-- > >You are right, we should postpone this maintenance break after FF. 21st >January might be good target for that, all feature freeze related stuff >should be ready at this point > >Br, >Jani > >>>Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK >>>Klarälvdalens Datakonsult AB, a KDAB Group company >>>Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) >>>KDAB - Qt Experts - Platform-independent software solutions >>>_______________________________________________ >>>Development mailing list >>>Development 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 Jukka.Jokiniva at theqtcompany.com Tue Dec 22 11:37:55 2015 From: Jukka.Jokiniva at theqtcompany.com (Jokiniva Jukka) Date: Tue, 22 Dec 2015 10:37:55 +0000 Subject: [Development] Heads up for Qt Bug Report & Code Review users In-Reply-To: References: Message-ID: On 21/12/15 12:52, "Giuseppe D'Angelo" wrote: >Hi, > >On Mon, Dec 21, 2015 at 9:48 AM, Jokiniva Jukka > wrote: >> · If you don¹t already have Qt credentials, all you need to do >>is >> register at https://login.qt.io/register* using the same email address >>you >> currently use for Bug Tracker and Code Review. If you want to change to >>a >> different email address for your unified login credentials, you should >>first >> update the email address in Bug Tracker** to ensure the logins will be >> merged. > >What happens if one does not have a Qt Account on login.qt.io, but >only a Jira/Gerrit account? Will a Qt Account be created >automatically? Qt Account won¹t be created automatically. If you don¹t have one, you need to register at https://login.qt.io/register ‹Jukka From giuseppe.dangelo at kdab.com Tue Dec 22 11:59:03 2015 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Tue, 22 Dec 2015 11:59:03 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <2751DBCD-0CE9-42B9-97C1-5AA9B2D4E4C3@theqtcompany.com> References: <201512031949.46920.marc.mutz@kdab.com> <4606126.Pqxnumcx4H@finn> <04544583-2102-4BE6-8232-D12634E879E7@theqtcompany.com> <201512071544.42707.marc.mutz@kdab.com> <1BD99747-4E60-4C76-8612-DE744E1CCA14@theqtcompany.com> <592A0CC7-1F6F-4F31-8B91-BF1C17D78796@theqtcompany.com> <2751DBCD-0CE9-42B9-97C1-5AA9B2D4E4C3@theqtcompany.com> Message-ID: <56792CF7.8040606@kdab.com> Il 22/12/2015 11:26, Ziller Eike ha scritto: > So funny/unwanted behavior can occur both because one used the wrong explicit type, and because one used auto instead of an explicit type. These shortcomings of auto are recognized in the community, but yes, they're real and dangerous. Clazy [1] already has a warning for the danger of auto with QStringBuilder, I guess it can be extended to other cases. N4035 [2] proposes general purpose workarounds ("operator auto", specializations to std::decay, etc.) to address these issues. > [1] https://github.com/KDE/clazy/blob/master/README > [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4035.pdf My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4068 bytes Desc: Firma crittografica S/MIME URL: From marc.mutz at kdab.com Tue Dec 22 13:28:44 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 22 Dec 2015 13:28:44 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <2751DBCD-0CE9-42B9-97C1-5AA9B2D4E4C3@theqtcompany.com> References: <201512031949.46920.marc.mutz@kdab.com> <592A0CC7-1F6F-4F31-8B91-BF1C17D78796@theqtcompany.com> <2751DBCD-0CE9-42B9-97C1-5AA9B2D4E4C3@theqtcompany.com> Message-ID: <201512221328.45657.marc.mutz@kdab.com> On Tuesday 22 December 2015 11:26:40 Ziller Eike wrote: > We have something similar in Qt: > > QString a = "ABC"; > QString b = "abc"; > auto result = a + b; > a.replace("A", "C"); > qDebug() << result; > > prints “CBCabc” instead of “ABCabc” when QT_USE_FAST_OPERATOR_PLUS is > defined, because result is not a QString in that case. > > So funny/unwanted behavior can occur both because one used the wrong > explicit type, and because one used auto instead of an explicit type. This is not specific to auto, though: QStringView v = QLatin1Char('a'); const char *data = str.toLatin1(); // implicit conversion by default QLatin1String l1 = str.toLatin1(); QVector v = {0, 1, 2}; QVector::iterator it = v.begin(); const QVector v2 = v; *it = 1; assert(v2.front() == 0); // boom It's a general peril when working with C++. Reminds me of the 1970s when we got a law requiring the use of the seat-belt in cars in Germany. My uncle used to tell the story how one of his friends survived a crash because he was ejected from the car since he was _not_ buckled up, just to follow up with the story how another friend was not harmed in a crash because he _was_ strapped in... Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From albert.astals at canonical.com Tue Dec 22 12:44:39 2015 From: albert.astals at canonical.com (Albert Astals Cid) Date: Tue, 22 Dec 2015 12:44:39 +0100 Subject: [Development] Heads up for Qt Bug Report & Code Review users In-Reply-To: References: Message-ID: On Tue, Dec 22, 2015 at 11:37 AM, Jokiniva Jukka wrote: > > > On 21/12/15 12:52, "Giuseppe D'Angelo" wrote: > >>Hi, >> >>On Mon, Dec 21, 2015 at 9:48 AM, Jokiniva Jukka >> wrote: >>> · If you don¹t already have Qt credentials, all you need to do >>>is >>> register at https://login.qt.io/register* using the same email address >>>you >>> currently use for Bug Tracker and Code Review. If you want to change to >>>a >>> different email address for your unified login credentials, you should >>>first >>> update the email address in Bug Tracker** to ensure the logins will be >>> merged. >> >>What happens if one does not have a Qt Account on login.qt.io, but >>only a Jira/Gerrit account? Will a Qt Account be created >>automatically? > > Qt Account won¹t be created automatically. If you don¹t have one, you need > to register at https://login.qt.io/register Any reason the password i have for gerrit and the bug tracker is not good enough anymore? Cheers, Albert > > ‹Jukka > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From gunnar.roth at gmx.de Tue Dec 22 12:46:28 2015 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Tue, 22 Dec 2015 12:46:28 +0100 Subject: [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with uic.exe showing dialog qt5core.dll cannot be found. In-Reply-To: <5679231F.9030802@klingt.org> References: , <5679231F.9030802@klingt.org> Message-ID: An HTML attachment was scrubbed... URL: From Marco.Bubke at theqtcompany.com Tue Dec 22 12:49:50 2015 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Tue, 22 Dec 2015 11:49:50 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <56792CF7.8040606@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> <4606126.Pqxnumcx4H@finn> <04544583-2102-4BE6-8232-D12634E879E7@theqtcompany.com> <201512071544.42707.marc.mutz@kdab.com> <1BD99747-4E60-4C76-8612-DE744E1CCA14@theqtcompany.com> <592A0CC7-1F6F-4F31-8B91-BF1C17D78796@theqtcompany.com> <2751DBCD-0CE9-42B9-97C1-5AA9B2D4E4C3@theqtcompany.com>, <56792CF7.8040606@kdab.com> Message-ID: Clazy is nice but it's under GPL so it's not possible to integrate it in the creator clang code model. But I think we need something like clazy for the clang code model too. ________________________________________ From: Development on behalf of Giuseppe D'Angelo Sent: Tuesday, December 22, 2015 11:59 AM To: development at qt-project.org Subject: Re: [Development] RFC: more liberal 'auto' rules? Il 22/12/2015 11:26, Ziller Eike ha scritto: > So funny/unwanted behavior can occur both because one used the wrong explicit type, and because one used auto instead of an explicit type. These shortcomings of auto are recognized in the community, but yes, they're real and dangerous. Clazy [1] already has a warning for the danger of auto with QStringBuilder, I guess it can be extended to other cases. N4035 [2] proposes general purpose workarounds ("operator auto", specializations to std::decay, etc.) to address these issues. > [1] https://github.com/KDE/clazy/blob/master/README > [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4035.pdf My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts From tim at klingt.org Tue Dec 22 12:53:12 2015 From: tim at klingt.org (Tim Blechmann) Date: Tue, 22 Dec 2015 12:53:12 +0100 Subject: [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with uic.exe showing dialog qt5core.dll cannot be found. In-Reply-To: References: <5679231F.9030802@klingt.org> Message-ID: <567939A8.7090201@klingt.org> > The thing is that in Qt 5.5.1, uic.exe and qlalr.exe were also build > using qtcore dll, but there this was not a problem. > In wec build they are always build statically, i think that should be > made uniform. > > Now that I look closer i see the cause of the problem: > set PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin > vs. > set PATH=D:\TFS\bld__GLOBAL\Qt5.5.1\WIN32-VS11-32\qtbase\lib > > So actually anyone who successfully build qt 5.6 beta on windows seems > to have some directory containing a Qt5Core.dll in the PATH env variable. ... hmm ... i ran into this issue before with rcc (iirc), but not with uic or qlalr ... btw, qt's translation tools also fail to run for me: https://codereview.qt-project.org/#/c/144558/ hope with these two patches, msvc/dll builds work again ... cheers, tim From annulen at yandex.ru Tue Dec 22 13:06:34 2015 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 22 Dec 2015 15:06:34 +0300 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <4606126.Pqxnumcx4H@finn> <04544583-2102-4BE6-8232-D12634E879E7@theqtcompany.com> <201512071544.42707.marc.mutz@kdab.com> <1BD99747-4E60-4C76-8612-DE744E1CCA14@theqtcompany.com> <592A0CC7-1F6F-4F31-8B91-BF1C17D78796@theqtcompany.com> <2751DBCD-0CE9-42B9-97C1-5AA9B2D4E4C3@theqtcompany.com>, <56792CF7.8040606@kdab.com> Message-ID: <2618821450785994@web29o.yandex.ru> 22.12.2015, 14:50, "Bubke Marco" : > Clazy is nice but it's under GPL so it's not possible to integrate it in the creator clang code model. But I think we need something like clazy for the clang code model too. I see at least 2 options how to integrate clazy: 1. Include it as a separate GPL-only plugin, users of commercial edition will be able to install it separately. If that's too cumbersome to separate this checks from code model, guard them with ifdefs so Clang plugin could be compiled as GPL or as LGPL 2. Just use it as external tool and parse its output. > > ________________________________________ > From: Development on behalf of Giuseppe D'Angelo > Sent: Tuesday, December 22, 2015 11:59 AM > To: development at qt-project.org > Subject: Re: [Development] RFC: more liberal 'auto' rules? > > Il 22/12/2015 11:26, Ziller Eike ha scritto: >>  So funny/unwanted behavior can occur both because one used the wrong explicit type, and because one used auto instead of an explicit type. > > These shortcomings of auto are recognized in the community, but yes, > they're real and dangerous. Clazy [1] already has a warning for the > danger of auto with QStringBuilder, I guess it can be extended to other > cases. > > N4035 [2] proposes general purpose workarounds ("operator auto", > specializations to std::decay, etc.) to address these issues. > >>  [1] https://github.com/KDE/clazy/blob/master/README >>  [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4035.pdf > > My 2 c, > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer > KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 > KDAB - The Qt Experts > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From gunnar.roth at gmx.de Tue Dec 22 13:35:54 2015 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Tue, 22 Dec 2015 13:35:54 +0100 Subject: [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with uic.exe showing dialog qt5core.dll cannot be found. In-Reply-To: <567939A8.7090201@klingt.org> References: <5679231F.9030802@klingt.org> , <567939A8.7090201@klingt.org> Message-ID: An HTML attachment was scrubbed... URL: From Eike.Ziller at theqtcompany.com Tue Dec 22 13:42:06 2015 From: Eike.Ziller at theqtcompany.com (Ziller Eike) Date: Tue, 22 Dec 2015 12:42:06 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512221328.45657.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> <592A0CC7-1F6F-4F31-8B91-BF1C17D78796@theqtcompany.com> <2751DBCD-0CE9-42B9-97C1-5AA9B2D4E4C3@theqtcompany.com> <201512221328.45657.marc.mutz@kdab.com> Message-ID: > On Dec 22, 2015, at 1:28 PM, Marc Mutz wrote: > > On Tuesday 22 December 2015 11:26:40 Ziller Eike wrote: >> We have something similar in Qt: >> >> QString a = "ABC"; >> QString b = "abc"; >> auto result = a + b; >> a.replace("A", "C"); >> qDebug() << result; >> >> prints “CBCabc” instead of “ABCabc” when QT_USE_FAST_OPERATOR_PLUS is >> defined, because result is not a QString in that case. >> >> So funny/unwanted behavior can occur both because one used the wrong >> explicit type, and because one used auto instead of an explicit type. > > This is not specific to auto, though: > > QStringView v = QLatin1Char('a'); > const char *data = str.toLatin1(); // implicit conversion by default > QLatin1String l1 = str.toLatin1(); > QVector v = {0, 1, 2}; > QVector::iterator it = v.begin(); > const QVector v2 = v; > *it = 1; > assert(v2.front() == 0); // boom > > It's a general peril when working with C++. I’m actually not arguing against the use of auto in principle. But I’m arguing against introducing auto because it (supposedly?) makes the code safe(r). (That context has unfortunately been cut off from the mail at some point.) C++ is complicated, and type deduction and its results are no exception. If you know what you are doing, auto can make code more readable and easier to write, especially with templated code. When it makes code more readable or not tends to be pretty subjective it seems, so IMO someone just has to decide :) > Reminds me of the 1970s when we got a law requiring the use of the seat-belt > in cars in Germany. My uncle used to tell the story how one of his friends > survived a crash because he was ejected from the car since he was _not_ > buckled up, just to follow up with the story how another friend was not harmed > in a crash because he _was_ strapped in... Not sure what you want to say with this analogy. Anyhow, discussions about pros and cons are still necessary. I’m sure that there are laws in Germany that supposedly increase security but effectively don’t. I would require that the decision to introduce a law requiring the use of seat-belts was based on extensive studies on how seat belts increase or decrease the security of a car’s occupants, and how they need to be designed to achieve that best. And not on stories at the bar, of how one or the other person was either saved or doomed by a seat belt, which you seem to be reminded of by the discussion here? ;) -- Eike Ziller, Senior Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Marco.Bubke at theqtcompany.com Tue Dec 22 13:48:11 2015 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Tue, 22 Dec 2015 12:48:11 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <2618821450785994@web29o.yandex.ru> References: <201512031949.46920.marc.mutz@kdab.com> <4606126.Pqxnumcx4H@finn> <04544583-2102-4BE6-8232-D12634E879E7@theqtcompany.com> <201512071544.42707.marc.mutz@kdab.com> <1BD99747-4E60-4C76-8612-DE744E1CCA14@theqtcompany.com> <592A0CC7-1F6F-4F31-8B91-BF1C17D78796@theqtcompany.com> <2751DBCD-0CE9-42B9-97C1-5AA9B2D4E4C3@theqtcompany.com>, <56792CF7.8040606@kdab.com> <2618821450785994@web29o.yandex.ru> Message-ID: I think in the end we will look if it is easier to implement something similar. It's a tradeoff. On December 22, 2015 13:06:42 Konstantin Tokarev wrote: > 22.12.2015, 14:50, "Bubke Marco" : >> Clazy is nice but it's under GPL so it's not possible to integrate it in the creator clang code model. But I think we need something like clazy for the clang code model too. > > I see at least 2 options how to integrate clazy: > > 1. Include it as a separate GPL-only plugin, users of commercial edition will be able to install it separately. If that's too cumbersome to separate this checks from code model, guard them with ifdefs so Clang plugin could be compiled as GPL or as LGPL I don't think it is feasible but you must ask lawyers about that. > > 2. Just use it as external tool and parse its output. Sorry, this is not how the code models works. It would be much easier to reimplement the functionality of clazy. > >> >> ________________________________________ >> From: Development on behalf of Giuseppe D'Angelo >> Sent: Tuesday, December 22, 2015 11:59 AM >> To: development at qt-project.org >> Subject: Re: [Development] RFC: more liberal 'auto' rules? >> >> Il 22/12/2015 11:26, Ziller Eike ha scritto: >>>  So funny/unwanted behavior can occur both because one used the wrong explicit type, and because one used auto instead of an explicit type. >> >> These shortcomings of auto are recognized in the community, but yes, >> they're real and dangerous. Clazy [1] already has a warning for the >> danger of auto with QStringBuilder, I guess it can be extended to other >> cases. >> >> N4035 [2] proposes general purpose workarounds ("operator auto", >> specializations to std::decay, etc.) to address these issues. >> >>>  [1] https://github.com/KDE/clazy/blob/master/README >>>  [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4035.pdf >> >> My 2 c, >> -- >> Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer >> KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 >> KDAB - The Qt Experts >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin Sent from cellphone From annulen at yandex.ru Tue Dec 22 14:25:11 2015 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 22 Dec 2015 16:25:11 +0300 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <4606126.Pqxnumcx4H@finn> <04544583-2102-4BE6-8232-D12634E879E7@theqtcompany.com> <201512071544.42707.marc.mutz@kdab.com> <1BD99747-4E60-4C76-8612-DE744E1CCA14@theqtcompany.com> <592A0CC7-1F6F-4F31-8B91-BF1C17D78796@theqtcompany.com> <2751DBCD-0CE9-42B9-97C1-5AA9B2D4E4C3@theqtcompany.com>, <56792CF7.8040606@kdab.com> <2618821450785994@web29o.yandex.ru> Message-ID: <50021450790711@web24g.yandex.ru> 22.12.2015, 15:48, "Bubke Marco" : > I think in the end we will look if it is easier to implement something similar. It's a tradeoff. > > On December 22, 2015 13:06:42 Konstantin Tokarev wrote: > >>  22.12.2015, 14:50, "Bubke Marco" : >>>  Clazy is nice but it's under GPL so it's not possible to integrate it in the creator clang code model. But I think we need something like clazy for the clang code model too. >> >>  I see at least 2 options how to integrate clazy: >> >>  1. Include it as a separate GPL-only plugin, users of commercial edition will be able to install it separately. If that's too cumbersome to separate this checks from code model, guard them with ifdefs so Clang plugin could be compiled as GPL or as LGPL > > I don't think it is feasible but you must ask lawyers about that. >>  2. Just use it as external tool and parse its output. > > Sorry, this is not how the code models works. I've meant to use it as static analyzer, not part of code model in this case. It would be much easier to reimplement the functionality of clazy. >>>  ________________________________________ >>>  From: Development on behalf of Giuseppe D'Angelo >>>  Sent: Tuesday, December 22, 2015 11:59 AM >>>  To: development at qt-project.org >>>  Subject: Re: [Development] RFC: more liberal 'auto' rules? >>> >>>  Il 22/12/2015 11:26, Ziller Eike ha scritto: >>>>   So funny/unwanted behavior can occur both because one used the wrong explicit type, and because one used auto instead of an explicit type. >>> >>>  These shortcomings of auto are recognized in the community, but yes, >>>  they're real and dangerous. Clazy [1] already has a warning for the >>>  danger of auto with QStringBuilder, I guess it can be extended to other >>>  cases. >>> >>>  N4035 [2] proposes general purpose workarounds ("operator auto", >>>  specializations to std::decay, etc.) to address these issues. >>> >>>>   [1] https://github.com/KDE/clazy/blob/master/README >>>>   [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4035.pdf >>> >>>  My 2 c, >>>  -- >>>  Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer >>>  KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 >>>  KDAB - The Qt Experts >>> >>>  _______________________________________________ >>>  Development mailing list >>>  Development at qt-project.org >>>  http://lists.qt-project.org/mailman/listinfo/development >> >>  -- >>  Regards, >>  Konstantin > > Sent from cellphone -- Regards, Konstantin From marc.mutz at kdab.com Tue Dec 22 15:50:30 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 22 Dec 2015 15:50:30 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <201512221328.45657.marc.mutz@kdab.com> Message-ID: <201512221550.31408.marc.mutz@kdab.com> On Tuesday 22 December 2015 13:42:06 Ziller Eike wrote: > > On Dec 22, 2015, at 1:28 PM, Marc Mutz wrote: > > > > On Tuesday 22 December 2015 11:26:40 Ziller Eike wrote: > >> We have something similar in Qt: > >> QString a = "ABC"; > >> QString b = "abc"; > >> auto result = a + b; > >> a.replace("A", "C"); > >> qDebug() << result; > >> > >> prints “CBCabc” instead of “ABCabc” when QT_USE_FAST_OPERATOR_PLUS is > >> defined, because result is not a QString in that case. > >> > >> So funny/unwanted behavior can occur both because one used the wrong > >> explicit type, and because one used auto instead of an explicit type. > > > > This is not specific to auto, though: > > QStringView v = QLatin1Char('a'); > > const char *data = str.toLatin1(); // implicit conversion by default > > QLatin1String l1 = str.toLatin1(); > > QVector v = {0, 1, 2}; > > QVector::iterator it = v.begin(); > > const QVector v2 = v; > > *it = 1; > > assert(v2.front() == 0); // boom > > > > It's a general peril when working with C++. > > I’m actually not arguing against the use of auto in principle. But I’m > arguing against introducing auto because it (supposedly?) makes the code > safe(r). (That context has unfortunately been cut off from the mail at > some point.) C++ is complicated, and type deduction and its results are no > exception. If you know what you are doing, auto can make code more > readable and easier to write, especially with templated code. When it > makes code more readable or not tends to be pretty subjective it seems, so > IMO someone just has to decide :) > > > Reminds me of the 1970s when we got a law requiring the use of the > > seat-belt in cars in Germany. My uncle used to tell the story how one of > > his friends survived a crash because he was ejected from the car since > > he was _not_ buckled up, just to follow up with the story how another > > friend was not harmed in a crash because he _was_ strapped in... > > Not sure what you want to say with this analogy. > Anyhow, discussions about pros and cons are still necessary. I’m sure that > there are laws in Germany that supposedly increase security but > effectively don’t. I would require that the decision to introduce a law > requiring the use of seat-belts was based on extensive studies on how seat > belts increase or decrease the security of a car’s occupants, and how they > need to be designed to achieve that best. And not on stories at the bar, > of how one or the other person was either saved or doomed by a seat belt, > which you seem to be reminded of by the discussion here? ;) It was just a story I was reminded of, but if you want an interpretation: It's a reminder about how progress always needs to overcome the status quo. And about how humans rate personal experience (first hand, or perceived through third parties) higher than statistics. You can see it over and over again here: QList is a mistake, but people will try to find ways to argue that it's useful because they have this one contrieved use-case where it outperforms vector: struct payload { char data[1024]; }; QList l(10000); l.pop_front(); , say. nullptr is obviously a better alternative than 0 or NULL, but people argue that there's this one corner of the huge C++ design space where nullptr doesn't add value over 0. Why should I learn a complicated rule if there's a simple one: always use nullptr? Adding const to local variables is very important in a world of implicitly- shared types, you can see the asm getting simpler, sometimes radically so, by just adding const when it avoids detaches, but people deny adding const as a drive-by and disallow commits that just add const without some kind of performance analysis). I don't know whether auto creates more harm than it fixes. What I _do_ know is that it makes it much easier to write efficient code, because you _do_ think twice whether to submit something like for (QHash::const_iterator it = m_veryExpressiveName.constBegin(), end = m_veryExpressiveName.constEnd(); it != end; ++it) as a replacement of foreach(const QLongTypeName &key, m_veryExpressiveName.keys()) { const QEvenLongerTypeName &value = m_veryExpressiveName.value(key); but not if you can say for (auto it = m_veryExpressiveName.cbegin(), end = m_veryExpressiveName.cend(); it != end; ++it) (yes, this use is uncontended, but this one isn't: foreach(const QString &s : someLongExpression()->fooBar().names()) const auto strings = someLongExpression()->fooBar().names(); for (const QString &s : strings) , but is essentially the same). Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Tue Dec 22 15:01:41 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 22 Dec 2015 12:01:41 -0200 Subject: [Development] wec2013 build fails with qt 5.6 beta in dbus. In-Reply-To: <9074C2E2-8009-41FA-94B8-FB34D37463E6@gmx.de> References: <20151221212218.5922896.22933.53946@theqtcompany.com> <9074C2E2-8009-41FA-94B8-FB34D37463E6@gmx.de> Message-ID: <3373366.Wl3LCLtKrD@tjmaciei-mobl4> On Monday 21 December 2015 23:43:15 Gunnar Roth wrote: > Hi Simon. > The conflict happens in a dozen files in qtbase/src/dbus/ and > qttools/src/qdbus. I can add the #undef to qdbusmessage.h. It has a function called interface(). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Dec 22 15:01:08 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 22 Dec 2015 12:01:08 -0200 Subject: [Development] wec2013 build fails with qt 5.6 beta in dbus. In-Reply-To: <8AAEE870-786F-4D88-A6BD-DF3C583C08DA@gmx.de> References: <3321106.6JoSvrVuDN@tjmaciei-mobl4> <8AAEE870-786F-4D88-A6BD-DF3C583C08DA@gmx.de> Message-ID: <2178999.9sA4qhKYRB@tjmaciei-mobl4> On Monday 21 December 2015 21:58:46 Gunnar Roth wrote: > How am I supposed know? It worked without that since 5.2.1. How should > anybody know that now -no-dbus is needed. It's an unfortunate side effect of the configure.exe changes that enable QtDBus on all platforms. The code does work on Windows CE, but you have to figure out why windows.h got included when it shouldn't have or tell it to stop #define'ing interface. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From aclight at gmail.com Tue Dec 22 15:05:03 2015 From: aclight at gmail.com (Adam Light) Date: Tue, 22 Dec 2015 06:05:03 -0800 Subject: [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with uic.exe showing dialog qt5core.dll cannot be found. In-Reply-To: References: Message-ID: On Tue, Dec 22, 2015 at 1:43 AM, Gunnar Roth wrote: > Hello, > > when i used jom i get this dialog with qt5core not found. > When using nmake i get this error: > > For what it's worth, I created a bug report about this about a week ago at https://bugreports.qt.io/browse/QTBUG-49985. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.martins at kdab.com Tue Dec 22 15:06:36 2015 From: sergio.martins at kdab.com (Sergio Martins) Date: Tue, 22 Dec 2015 14:06:36 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <2618821450785994@web29o.yandex.ru> References: <201512031949.46920.marc.mutz@kdab.com> <2618821450785994@web29o.yandex.ru> Message-ID: <1940335.rZVzGoCRt6@desktop> On Tuesday, 22 December 2015 15:06:34 WET Konstantin Tokarev wrote: > 22.12.2015, 14:50, "Bubke Marco" : > > Clazy is nice but it's under GPL so it's not possible to integrate it in > > the creator clang code model. But I think we need something like clazy > > for the clang code model too. > I see at least 2 options how to integrate clazy: > > 1. Include it as a separate GPL-only plugin, users of commercial edition > will be able to install it separately. If that's too cumbersome to separate > this checks from code model, guard them with ifdefs so Clang plugin could > be compiled as GPL or as LGPL > > 2. Just use it as external tool and parse its output. 3. Change clazy's license to LGPL Regards, -- Sérgio Martins | sergio.martins at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From gunnar.roth at gmx.de Tue Dec 22 15:07:51 2015 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Tue, 22 Dec 2015 15:07:51 +0100 Subject: [Development] wec2013 build fails with qt 5.6 beta in dbus. In-Reply-To: <2178999.9sA4qhKYRB@tjmaciei-mobl4> References: <3321106.6JoSvrVuDN@tjmaciei-mobl4> <8AAEE870-786F-4D88-A6BD-DF3C583C08DA@gmx.de>, <2178999.9sA4qhKYRB@tjmaciei-mobl4> Message-ID: An HTML attachment was scrubbed... URL: From gunnar.roth at gmx.de Tue Dec 22 15:18:50 2015 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Tue, 22 Dec 2015 15:18:50 +0100 Subject: [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with uic.exe showing dialog qt5core.dll cannot be found. In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_functions.prf Type: application/pics-rules Size: 7163 bytes Desc: not available URL: From dangelog at gmail.com Tue Dec 22 15:22:36 2015 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Tue, 22 Dec 2015 15:22:36 +0100 Subject: [Development] Heads up for Qt Bug Report & Code Review users In-Reply-To: References: Message-ID: On Tue, Dec 22, 2015 at 11:37 AM, Jokiniva Jukka wrote: > Qt Account won¹t be created automatically. If you don¹t have one, you need > to register at https://login.qt.io/register Ok, but what happens if I don't do that before the deadline? Will my account go into a black hole? Can't a matching Qt Account automatically be created? :) Cheers, -- Giuseppe D'Angelo From mwoehlke.floss at gmail.com Tue Dec 22 15:33:12 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 22 Dec 2015 09:33:12 -0500 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <2751DBCD-0CE9-42B9-97C1-5AA9B2D4E4C3@theqtcompany.com> References: <201512031949.46920.marc.mutz@kdab.com> <4606126.Pqxnumcx4H@finn> <04544583-2102-4BE6-8232-D12634E879E7@theqtcompany.com> <201512071544.42707.marc.mutz@kdab.com> <1BD99747-4E60-4C76-8612-DE744E1CCA14@theqtcompany.com> <592A0CC7-1F6F-4F31-8B91-BF1C17D78796@theqtcompany.com> <2751DBCD-0CE9-42B9-97C1-5AA9B2D4E4C3@theqtcompany.com> Message-ID: On 2015-12-22 05:26, Ziller Eike wrote: > So, directly after the above example in Item 5, Item 6 in Effective > Modern C++ continues with the examples of how you can shoot yourself > in the foot _because_ you used auto. [...] > > We have something similar in Qt: > > QString a = "ABC"; > QString b = "abc"; > auto result = a + b; > a.replace("A", "C"); > qDebug() << result; > > prints “CBCabc” instead of “ABCabc” when QT_USE_FAST_OPERATOR_PLUS is > defined, because result is not a QString in that case. Someone ought to note... one of the arguments for AAA is that it avoids uninitialized variables. It's actually still AAA to write: auto result = QString{a + b}; ...and in fact that is what AAA recommends when you need to ensure a specific type. -- Matthew From mwoehlke.floss at gmail.com Tue Dec 22 15:40:01 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 22 Dec 2015 09:40:01 -0500 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512221550.31408.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> <201512221328.45657.marc.mutz@kdab.com> <201512221550.31408.marc.mutz@kdab.com> Message-ID: On 2015-12-22 09:50, Marc Mutz wrote: > foreach(const QString &s : someLongExpression()->fooBar().names()) > > const auto strings = someLongExpression()->fooBar().names(); > for (const QString &s : strings) On that note, is there any case in which Q_FOREACH is superior to a range-based for? (Besides the obvious one where the original list is modified from within the loop?) -- Matthew From marc.mutz at kdab.com Tue Dec 22 17:08:52 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 22 Dec 2015 17:08:52 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <201512221550.31408.marc.mutz@kdab.com> Message-ID: <201512221708.52978.marc.mutz@kdab.com> On Tuesday 22 December 2015 15:40:01 Matthew Woehlke wrote: > On 2015-12-22 09:50, Marc Mutz wrote: > > foreach(const QString &s : someLongExpression()->fooBar().names()) > > > > const auto strings = someLongExpression()->fooBar().names(); > > for (const QString &s : strings) > > On that note, is there any case in which Q_FOREACH is superior to a > range-based for? (Besides the obvious one where the original list is > modified from within the loop?) No. range-for and for (auto it = begin(), end = end(); it != end; ++it) are equivalent. indexed access is less efficient (both from text size pov as well as address generation, where e.g. Haswell, where offsetting into L1 has latency 4 whereas going though a pointer has latency 3), and foreach, due to the copy, is always much, much worse. Even when the RHS is an rvalue and you do the replacement you quoted above, the range-for is more efficient, probably Q_FOREACH forces another copy while assigning to const-auto uses (N)RVO. Even in the case where the original list is modified in the loop, taking a copy and then using range-for may be more efficient. It is surely more readable, because you can (and should) comment on why the copy is necessary. That said, such loops as you describe will usually have very poor performance. Either due to the detach() that necessarily happens, or due to quadratic behaviour, e.g. calling erase(it) on a vector or QList while iterating. Try to port all your Q_FOREACH to range-for loops. You will be surprised how much digging is required if you don't always want to take the hit of taking a copy. In a change of mine, I estimated that by removing all Q_FOREACH uses in qtbase/src (all 880+ of them) would save 80KiB in text size across the qtbase libraries. I now think that it will be more, because QtCore is compiled with exceptions enabled, and then Q_FOREACH is really, really, horrendous. I posted side-by-side asm here: https://codereview.qt-project.org/112431 Thiago claims to have fixed that particular code explosion, but I think that the correct fix is to deprecate and port all Q_FOREACH/foreach to range-for. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From mwoehlke.floss at gmail.com Tue Dec 22 17:10:08 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 22 Dec 2015 11:10:08 -0500 Subject: [Development] foreach (was: RFC: more liberal 'auto' rules?) In-Reply-To: <201512221708.52978.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> <201512221550.31408.marc.mutz@kdab.com> <201512221708.52978.marc.mutz@kdab.com> Message-ID: On 2015-12-22 11:08, Marc Mutz wrote: > Try to port all your Q_FOREACH to range-for loops. You will be surprised how > much digging is required if you don't always want to take the hit of taking a > copy. Okay, thanks for the info. (One reason I ask is because qtExtensions¹ actually replaces 'foreach' with either a real range-based for, or - for pre-C++11 compilers - a clever construct that is very nearly equivalent²³.) (¹ https://github.com/kitware/qtextensions, although the public version doesn't have the relevant changes yet.) (² See https://github.com/Kitware/vital/blob/master/vital/vital_foreach.h... qtExtensions QTE_FOREACH omits the BOOST_FOREACH flavor but is otherwise identical. We do require that the compiler supports at least partial C++11, including auto.) (³ I believe the only significant difference from how range-based for is specified is that our version currently requires begin and end to be methods on the container. That's mostly laziness; if it ever becomes an issue, we could try to improve this.) -- Matthew From thiago.macieira at intel.com Tue Dec 22 17:42:57 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 22 Dec 2015 14:42:57 -0200 Subject: [Development] wec2013 build fails with qt 5.6 beta in dbus. In-Reply-To: References: <2178999.9sA4qhKYRB@tjmaciei-mobl4> Message-ID: <2113108.gc8EJfrGiG@tjmaciei-mobl4> On Tuesday 22 December 2015 15:07:51 Gunnar Roth wrote: > You tested the code on wince with which dbus component? No. It's untested. The QtDBus parts of the code should have no problem, since they are cross-platform. It's libdbus-1 that needs testing and that's out-of- scope for me. (KDAB did a lot of work on this in the past) But QtDBus should now compile regardless of whether libdbus-1 is found at build time. You can link your applications to it. If libdbus-1 isn't found at runtime, you'll simply get all QDBusConnections as disconnected. > windows.h probaly got included by the special qt wince headers. > > I wonder why there is a CI for wec2012, which did not catch that problem. Probably because it has -no-dbus. All CI platforms must either have -no-dbus or have libdbus-1 so the tests can run. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Joerg.Bornemann at theqtcompany.com Tue Dec 22 18:07:13 2015 From: Joerg.Bornemann at theqtcompany.com (Bornemann Joerg) Date: Tue, 22 Dec 2015 17:07:13 +0000 Subject: [Development] wec2013 build fails with qt 5.6 beta in dbus. In-Reply-To: <2113108.gc8EJfrGiG@tjmaciei-mobl4> References: <2178999.9sA4qhKYRB@tjmaciei-mobl4> , <2113108.gc8EJfrGiG@tjmaciei-mobl4> Message-ID: On Monday 21 December 2015 21:58:46 Gunnar Roth wrote: > It's an unfortunate side effect of the configure.exe changes that enable QtDBus > on all platforms. The code does work on Windows CE, but you have to figure out > why windows.h got included when it shouldn't have or tell it to stop > #define'ing interface. There's a include in mkspecs/common/wince/qplatformdefs.h. All of this sounds a lot like we need something like 32f957ccc68084fe11fcf23823c5094a1833a790 for this mkspec. Gunnar, does https://codereview.qt-project.org/#/c/144600/ fix the problem for you? BR, Joerg From gunnar.roth at gmx.de Tue Dec 22 18:21:57 2015 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Tue, 22 Dec 2015 18:21:57 +0100 Subject: [Development] Solution for Build errors in Qt Commercial Charts module 2.1 in qt 5.6 beta Message-ID: An HTML attachment was scrubbed... URL: From gunnar.roth at gmx.de Tue Dec 22 21:56:47 2015 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Tue, 22 Dec 2015 21:56:47 +0100 Subject: [Development] wec2013 build fails with qt 5.6 beta in dbus. In-Reply-To: References: <2178999.9sA4qhKYRB@tjmaciei-mobl4> <2113108.gc8EJfrGiG@tjmaciei-mobl4> Message-ID: <8BD93897-3199-4DBF-8CF3-630EDF650629@gmx.de> Sorry but 1. -no-dbus is sufficient for me. 2. i am on leave now and will return to work not before Epiphany . Regards, Gunnar > Am 22.12.2015 um 18:07 schrieb Bornemann Joerg : > > On Monday 21 December 2015 21:58:46 Gunnar Roth wrote: > >> It's an unfortunate side effect of the configure.exe changes that enable QtDBus >> on all platforms. The code does work on Windows CE, but you have to figure out >> why windows.h got included when it shouldn't have or tell it to stop >> #define'ing interface. > > There's a include in mkspecs/common/wince/qplatformdefs.h. > All of this sounds a lot like we need something like 32f957ccc68084fe11fcf23823c5094a1833a790 for this mkspec. > Gunnar, does https://codereview.qt-project.org/#/c/144600/ fix the problem for you? > > > BR, > > Joerg > _______________________________________________ > 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 Jukka.Jokiniva at theqtcompany.com Wed Dec 23 08:37:45 2015 From: Jukka.Jokiniva at theqtcompany.com (Jokiniva Jukka) Date: Wed, 23 Dec 2015 07:37:45 +0000 Subject: [Development] Heads up for Qt Bug Report & Code Review users In-Reply-To: References: Message-ID: On 22/12/15 16:22, "Giuseppe D'Angelo" wrote: >On Tue, Dec 22, 2015 at 11:37 AM, Jokiniva Jukka > wrote: >> Qt Account won¹t be created automatically. If you don¹t have one, you >>need >> to register at https://login.qt.io/register > >Ok, but what happens if I don't do that before the deadline? Will my >account go into a black hole? Can't a matching Qt Account >automatically be created? :) If you have a valid email on Bug Reports/Code Review, you can create the Qt Account with the same email also after the deadline. It will work fine. But if you don’t, you cannot create Qt Account with invalid email and can’t login. (There is a recovery option to make the link with Bug Reports/Code Review username&password. But I don’t want to promote this as things will go smoother with matching emails. We will keep this option running for some months.) ―Jukka From alexander.blasche at theqtcompany.com Wed Dec 23 15:23:22 2015 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Wed, 23 Dec 2015 14:23:22 +0000 Subject: [Development] Nominating Samuli Pippo for Approver status In-Reply-To: References: Message-ID: Congrats to Samuli. The Jira/Gerrit rights have been set. -- Alex ________________________________ From: Development on behalf of Agocs Laszlo Sent: Wednesday, December 2, 2015 15:13 To: development at qt-project.org Subject: [Development] Nominating Samuli Pippo for Approver status Hello, I would like to nominate Samuli Piippo for Approver status in the Qt Project. Samuli has been working on Qt's Embedded Linux support and Qt for Device Creation during the past few years. He is our resident Yocto expert and is contributing to meta-qt5 as well. Public Gerrit dashboard: https://codereview.qt-project.org/#/q/owner:samuli.piippo,n,z meta-qt5 contributions: https://github.com/meta-qt5/meta-qt5/commits/master?author=sapiippo Best regards, Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruanrln at gmail.com Wed Dec 23 17:34:53 2015 From: ruanrln at gmail.com (=?UTF-8?B?UnVhbiBsZWl0w6Nv?=) Date: Wed, 23 Dec 2015 16:34:53 +0000 Subject: [Development] Setting QTreeView selected item style in qss Message-ID: Hello, I already have post this question in Stack Overflow , but a have no answer. Now a friend tell me to talk on the mailing list. I need to change the background color of the *selected item* on a QTreeView. I already tried using the Qt examples and other SO questions. The style applied to the ::branch subcontrol works fine, but none of the commands in the ::item subcontrols works. Here my current result: [image: enter image description here] But I want a result like this: [image: enter image description here] Can someone help me, thanks in advance. Ruan L. Nunes -- Ruan L. Nunes -------------- next part -------------- An HTML attachment was scrubbed... URL: From dima00782 at gmail.com Thu Dec 24 10:47:11 2015 From: dima00782 at gmail.com (Dmitriy -) Date: Thu, 24 Dec 2015 15:47:11 +0600 Subject: [Development] V4 porting Message-ID: Hi! I want to port v4 engine to the new platform. The platform is Linux OS and new processor. The processor looks like intel itanium. It is VLIW and EPIC. I have a c++/c compilers for the new architecture. I want to design qt quic qml application for the new platform. As a can see in code, I need v4vm backend for this purpose. I'm see this: case use_moth: { QV4::EvalISelFactory* iSelFactory = 0; if (mode == use_moth) { iSelFactory = new QV4::Moth::ISelFactory;#ifdef V4_ENABLE_JIT } else { iSelFactory = new QV4::JIT::ISelFactory;#endif // V4_ENABLE_JIT } QV4::ExecutionEngine vm(iSelFactory); QV4::Scope scope(&vm); QV4::ScopedContext ctx(scope, vm.rootContext()); As I understand v4vm has two backends - Moth and Masm. What is Moth? -- Regards, Dmitry Bezheckov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at theqtcompany.com Thu Dec 24 12:18:11 2015 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Thu, 24 Dec 2015 11:18:11 +0000 Subject: [Development] V4 porting In-Reply-To: References: Message-ID: <20151224111811.5922896.50992.54182@theqtcompany.com> Hi, Moth is the portable interpreter that will be used instead of the just-in-time compiler if your platform doesn't support it. It should be chosen automatically for you according to the #ifdefs in qv4global_p.h. So if you have qtbase compiling, then qml should also work. If you want things to run faster, then you will have to port the JIT. Simon From: Dmitriy - Sent: Thursday, December 24, 2015 10:47 To: development at qt-project.org Subject: [Development] V4 porting Hi! I want to port v4 engine to the new platform. The platform is Linux OS and new processor. The processor looks like intel itanium. It is VLIW and EPIC. I have a c++/c compilers for the new architecture. I want to design qt quic qml application for the new platform. As a can see in code, I need v4vm backend for this purpose. I'm see this: case use_moth: { QV4::EvalISelFactory* iSelFactory = 0; if (mode == use_moth) { iSelFactory = new QV4::Moth::ISelFactory; #ifdef V4_ENABLE_JIT } else { iSelFactory = new QV4::JIT::ISelFactory; #endif // V4_ENABLE_JIT } QV4::ExecutionEngine vm(iSelFactory); QV4::Scope scope(&vm); QV4::ScopedContext ctx(scope, vm.rootContext()); As I understand v4vm has two backends - Moth and Masm. What is Moth? -- Regards, Dmitry Bezheckov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dima00782 at gmail.com Thu Dec 24 12:42:07 2015 From: dima00782 at gmail.com (Dmitriy -) Date: Thu, 24 Dec 2015 17:42:07 +0600 Subject: [Development] V4 porting In-Reply-To: <20151224111811.5922896.50992.54182@theqtcompany.com> References: <20151224111811.5922896.50992.54182@theqtcompany.com> Message-ID: Thank. I want to port JIT. Where should I start? You have any roadmap for this? Now I'm using qmljs tool for testing purpose. I has seen in qt-5.5.1/qtdeclarative/src/qml/jsruntime/qv4script.cpp: Script::parse(): ... RuntimeCodegen cg(v4, strictMode); cg.generateFromProgram(sourceFile, sourceCode, program, &module, QQmlJS::Codegen::EvalCode, inheritedLocals); if (v4->hasException) return; QV4::Compiler::JSUnitGenerator jsGenerator(&module); QScopedPointer isel(...); ... QQmlRefPointer compilationUnit = isel->compile(); vmFunction = compilationUnit->linkToEngine(v4); ... Why do you compile script while parse it? Do you use AOT compiling? On Thu, Dec 24, 2015 at 5:18 PM, Hausmann Simon < Simon.Hausmann at theqtcompany.com> wrote: > Hi, > > Moth is the portable interpreter that will be used instead of the > just-in-time compiler if your platform doesn't support it. It should be > chosen automatically for you according to the #ifdefs in qv4global_p.h. > > So if you have qtbase compiling, then qml should also work. If you want > things to run faster, then you will have to port the JIT. > > Simon > > *From: *Dmitriy - > *Sent: *Thursday, December 24, 2015 10:47 > *To: *development at qt-project.org > *Subject: *[Development] V4 porting > > Hi! > I want to port v4 engine to the new platform. The platform is Linux OS and > new processor. The processor looks like intel itanium. It is VLIW and EPIC. > I have a c++/c compilers for the new architecture. > > I want to design qt quic qml application for the new platform. As a can > see in code, I need v4vm backend for this purpose. > > I'm see this: > > case use_moth: { > QV4::EvalISelFactory* iSelFactory = 0; > if (mode == use_moth) { > iSelFactory = new QV4::Moth::ISelFactory;#ifdef V4_ENABLE_JIT > } else { > iSelFactory = new QV4::JIT::ISelFactory;#endif // V4_ENABLE_JIT > } > > QV4::ExecutionEngine vm(iSelFactory); > > QV4::Scope scope(&vm); > QV4::ScopedContext ctx(scope, vm.rootContext()); > > As I understand v4vm has two backends - Moth and Masm. > > What is Moth? > > -- > Regards, > Dmitry Bezheckov. > -- Regards, Dmitry Bezheckov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dima00782 at gmail.com Thu Dec 24 14:11:17 2015 From: dima00782 at gmail.com (Dmitriy -) Date: Thu, 24 Dec 2015 19:11:17 +0600 Subject: [Development] V4 porting In-Reply-To: References: <20151224111811.5922896.50992.54182@theqtcompany.com> Message-ID: One more question: qt-5.5.1/qtdeclarative/src/qml/jit/qv4assembler_p.h // V4 uses two stacks: one stack with QV4::Value items, which is checked by the garbage // collector, and one stack used by the native C/C++/ABI code. This C++ stack is not scanned // by the garbage collector, so if any JS object needs to be retained, it should be put on the // JS stack. // // The "saved reg arg X" are on the C++ stack is used to store values in registers that need to // be passed by reference to native functions. It is fine to use the C++ stack, because only // non-object values can be stored in registers. // // Stack layout for the C++ stack: // return address // old FP <- FP // callee saved reg n // ... // callee saved reg 0 // saved reg arg n // ... // saved reg arg 0 <- SP // // Stack layout for the JS stack: // function call argument n <- LocalsRegister // ... // function call argument 0 // local 0 // ... // local n // First save any arguments that reside in registers, because they could be overwritten // if that register is also used to pass arguments. saveOutRegister<5>(arg6); saveOutRegister<4>(arg5); saveOutRegister<3>(arg4); saveOutRegister<2>(arg3); saveOutRegister<1>(arg2); saveOutRegister<0>(arg1); ... What kind of stack use for saving registers? Is it c++/ABI stack (I hope) or Js stack? On Thu, Dec 24, 2015 at 5:42 PM, Dmitriy - wrote: > Thank. > I want to port JIT. Where should I start? > You have any roadmap for this? > > Now I'm using qmljs tool for testing purpose. > I has seen in qt-5.5.1/qtdeclarative/src/qml/jsruntime/qv4script.cpp: > > Script::parse(): > > ... > > RuntimeCodegen cg(v4, strictMode); > > cg.generateFromProgram(sourceFile, sourceCode, program, &module, QQmlJS::Codegen::EvalCode, inheritedLocals); > > if (v4->hasException) return; > > QV4::Compiler::JSUnitGenerator jsGenerator(&module); > > QScopedPointer isel(...); > > ... > > QQmlRefPointer compilationUnit = isel->compile(); > > vmFunction = compilationUnit->linkToEngine(v4); > > ... > > > Why do you compile script while parse it? Do you use AOT compiling? > > > On Thu, Dec 24, 2015 at 5:18 PM, Hausmann Simon < > Simon.Hausmann at theqtcompany.com> wrote: > >> Hi, >> >> Moth is the portable interpreter that will be used instead of the >> just-in-time compiler if your platform doesn't support it. It should be >> chosen automatically for you according to the #ifdefs in qv4global_p.h. >> >> So if you have qtbase compiling, then qml should also work. If you want >> things to run faster, then you will have to port the JIT. >> >> Simon >> >> *From: *Dmitriy - >> *Sent: *Thursday, December 24, 2015 10:47 >> *To: *development at qt-project.org >> *Subject: *[Development] V4 porting >> >> Hi! >> I want to port v4 engine to the new platform. The platform is Linux OS >> and new processor. The processor looks like intel itanium. It is VLIW and >> EPIC. >> I have a c++/c compilers for the new architecture. >> >> I want to design qt quic qml application for the new platform. As a can >> see in code, I need v4vm backend for this purpose. >> >> I'm see this: >> >> case use_moth: { >> QV4::EvalISelFactory* iSelFactory = 0; >> if (mode == use_moth) { >> iSelFactory = new QV4::Moth::ISelFactory;#ifdef V4_ENABLE_JIT >> } else { >> iSelFactory = new QV4::JIT::ISelFactory;#endif // V4_ENABLE_JIT >> } >> >> QV4::ExecutionEngine vm(iSelFactory); >> >> QV4::Scope scope(&vm); >> QV4::ScopedContext ctx(scope, vm.rootContext()); >> >> As I understand v4vm has two backends - Moth and Masm. >> >> What is Moth? >> >> -- >> Regards, >> Dmitry Bezheckov. >> > > > > -- > Regards, > Dmitry Bezheckov. > -- Regards, Dmitry Bezheckov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Dec 24 14:12:58 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 24 Dec 2015 11:12:58 -0200 Subject: [Development] wec2013 build fails with qt 5.6 beta in dbus. In-Reply-To: <3373366.Wl3LCLtKrD@tjmaciei-mobl4> References: <9074C2E2-8009-41FA-94B8-FB34D37463E6@gmx.de> <3373366.Wl3LCLtKrD@tjmaciei-mobl4> Message-ID: <48433783.6aIVeNyvGV@tjmaciei-mobl4> On Tuesday 22 December 2015 12:01:41 Thiago Macieira wrote: > On Monday 21 December 2015 23:43:15 Gunnar Roth wrote: > > Hi Simon. > > The conflict happens in a dozen files in qtbase/src/dbus/ and > > qttools/src/qdbus. > > I can add the #undef to qdbusmessage.h. It has a function called > interface(). Do you want me to insert the #undefs at strategic places too? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at theqtcompany.com Thu Dec 24 15:01:14 2015 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Thu, 24 Dec 2015 14:01:14 +0000 Subject: [Development] V4 porting In-Reply-To: References: <20151224111811.5922896.50992.54182@theqtcompany.com>, Message-ID: <20151224140114.5902414.36524.54195@theqtcompany.com> Hi, The method parse implies a transformation from source code to a form that we can interpret, so technically the name of the method isn't quite accurate. Nevertheless it does what you can see in the implementation, which includes parsing into a syntax tree structure, transformation into an intermediate representation (codegen), optimizations in that IR and finally register allocation and native code generation or byte code generation. I'm afraid that I don't have a road map for your porting efforts. Simon From: Dmitriy - Sent: Thursday, December 24, 2015 12:42 To: Hausmann Simon Cc: development at qt-project.org Subject: Re: [Development] V4 porting Thank. I want to port JIT. Where should I start? You have any roadmap for this? Now I'm using qmljs tool for testing purpose. I has seen in qt-5.5.1/qtdeclarative/src/qml/jsruntime/qv4script.cpp: Script::parse(): ... RuntimeCodegen cg(v4, strictMode); cg.generateFromProgram(sourceFile, sourceCode, program, &module, QQmlJS::Codegen::EvalCode, inheritedLocals); if (v4->hasException) return; QV4::Compiler::JSUnitGenerator jsGenerator(&module); QScopedPointer isel(...); ... QQmlRefPointer compilationUnit = isel->compile(); vmFunction = compilationUnit->linkToEngine(v4); ... Why do you compile script while parse it? Do you use AOT compiling? On Thu, Dec 24, 2015 at 5:18 PM, Hausmann Simon > wrote: Hi, Moth is the portable interpreter that will be used instead of the just-in-time compiler if your platform doesn't support it. It should be chosen automatically for you according to the #ifdefs in qv4global_p.h. So if you have qtbase compiling, then qml should also work. If you want things to run faster, then you will have to port the JIT. Simon From: Dmitriy - Sent: Thursday, December 24, 2015 10:47 To: development at qt-project.org Subject: [Development] V4 porting Hi! I want to port v4 engine to the new platform. The platform is Linux OS and new processor. The processor looks like intel itanium. It is VLIW and EPIC. I have a c++/c compilers for the new architecture. I want to design qt quic qml application for the new platform. As a can see in code, I need v4vm backend for this purpose. I'm see this: case use_moth: { QV4::EvalISelFactory* iSelFactory = 0; if (mode == use_moth) { iSelFactory = new QV4::Moth::ISelFactory; #ifdef V4_ENABLE_JIT } else { iSelFactory = new QV4::JIT::ISelFactory; #endif // V4_ENABLE_JIT } QV4::ExecutionEngine vm(iSelFactory); QV4::Scope scope(&vm); QV4::ScopedContext ctx(scope, vm.rootContext()); As I understand v4vm has two backends - Moth and Masm. What is Moth? -- Regards, Dmitry Bezheckov. -- Regards, Dmitry Bezheckov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at theqtcompany.com Thu Dec 24 15:02:26 2015 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Thu, 24 Dec 2015 14:02:26 +0000 Subject: [Development] V4 porting In-Reply-To: References: <20151224111811.5922896.50992.54182@theqtcompany.com> , Message-ID: <20151224140226.5902414.32181.54198@theqtcompany.com> Hi, Registers that are native to the processor are saved on the regular stack. Simon From: Dmitriy - Sent: Thursday, December 24, 2015 14:11 To: Hausmann Simon Cc: development at qt-project.org Subject: Re: [Development] V4 porting One more question: qt-5.5.1/qtdeclarative/src/qml/jit/qv4assembler_p.h // V4 uses two stacks: one stack with QV4::Value items, which is checked by the garbage // collector, and one stack used by the native C/C++/ABI code. This C++ stack is not scanned // by the garbage collector, so if any JS object needs to be retained, it should be put on the // JS stack. // // The "saved reg arg X" are on the C++ stack is used to store values in registers that need to // be passed by reference to native functions. It is fine to use the C++ stack, because only // non-object values can be stored in registers. // // Stack layout for the C++ stack: // return address // old FP <- FP // callee saved reg n // ... // callee saved reg 0 // saved reg arg n // ... // saved reg arg 0 <- SP // // Stack layout for the JS stack: // function call argument n <- LocalsRegister // ... // function call argument 0 // local 0 // ... // local n // First save any arguments that reside in registers, because they could be overwritten // if that register is also used to pass arguments. saveOutRegister<5>(arg6); saveOutRegister<4>(arg5); saveOutRegister<3>(arg4); saveOutRegister<2>(arg3); saveOutRegister<1>(arg2); saveOutRegister<0>(arg1); ... What kind of stack use for saving registers? Is it c++/ABI stack (I hope) or Js stack? On Thu, Dec 24, 2015 at 5:42 PM, Dmitriy - > wrote: Thank. I want to port JIT. Where should I start? You have any roadmap for this? Now I'm using qmljs tool for testing purpose. I has seen in qt-5.5.1/qtdeclarative/src/qml/jsruntime/qv4script.cpp: Script::parse(): ... RuntimeCodegen cg(v4, strictMode); cg.generateFromProgram(sourceFile, sourceCode, program, &module, QQmlJS::Codegen::EvalCode, inheritedLocals); if (v4->hasException) return; QV4::Compiler::JSUnitGenerator jsGenerator(&module); QScopedPointer isel(...); ... QQmlRefPointer compilationUnit = isel->compile(); vmFunction = compilationUnit->linkToEngine(v4); ... Why do you compile script while parse it? Do you use AOT compiling? On Thu, Dec 24, 2015 at 5:18 PM, Hausmann Simon > wrote: Hi, Moth is the portable interpreter that will be used instead of the just-in-time compiler if your platform doesn't support it. It should be chosen automatically for you according to the #ifdefs in qv4global_p.h. So if you have qtbase compiling, then qml should also work. If you want things to run faster, then you will have to port the JIT. Simon From: Dmitriy - Sent: Thursday, December 24, 2015 10:47 To: development at qt-project.org Subject: [Development] V4 porting Hi! I want to port v4 engine to the new platform. The platform is Linux OS and new processor. The processor looks like intel itanium. It is VLIW and EPIC. I have a c++/c compilers for the new architecture. I want to design qt quic qml application for the new platform. As a can see in code, I need v4vm backend for this purpose. I'm see this: case use_moth: { QV4::EvalISelFactory* iSelFactory = 0; if (mode == use_moth) { iSelFactory = new QV4::Moth::ISelFactory; #ifdef V4_ENABLE_JIT } else { iSelFactory = new QV4::JIT::ISelFactory; #endif // V4_ENABLE_JIT } QV4::ExecutionEngine vm(iSelFactory); QV4::Scope scope(&vm); QV4::ScopedContext ctx(scope, vm.rootContext()); As I understand v4vm has two backends - Moth and Masm. What is Moth? -- Regards, Dmitry Bezheckov. -- Regards, Dmitry Bezheckov. -- Regards, Dmitry Bezheckov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Fri Dec 25 01:16:54 2015 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 25 Dec 2015 01:16:54 +0100 Subject: [Development] RFC: more liberal 'auto' rules? References: <201512031949.46920.marc.mutz@kdab.com> <4606126.Pqxnumcx4H@finn> <04544583-2102-4BE6-8232-D12634E879E7@theqtcompany.com> <201512071544.42707.marc.mutz@kdab.com> <1BD99747-4E60-4C76-8612-DE744E1CCA14@theqtcompany.com> <592A0CC7-1F6F-4F31-8B91-BF1C17D78796@theqtcompany.com> <2751DBCD-0CE9-42B9-97C1-5AA9B2D4E4C3@theqtcompany.com> Message-ID: Matthew Woehlke wrote: > auto result = QString{a + b}; IMHO, that's just a complicated and ugly way to write: QString result = a + b; There is no way the variable can be uninitialized if you initialize it right there in the declaration. Kevin Kofler From marc.mutz at kdab.com Fri Dec 25 10:35:02 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 25 Dec 2015 10:35:02 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> Message-ID: <201512251035.02188.marc.mutz@kdab.com> On Friday 25 December 2015 01:16:54 Kevin Kofler wrote: > Matthew Woehlke wrote: > > auto result = QString{a + b}; > > IMHO, that's just a complicated and ugly way to write: > QString result = a + b; > > There is no way the variable can be uninitialized if you initialize it > right there in the declaration. Actually, the point here is that this construction with an explicit type name is rare and signals an explicit type conversion, or a type constructor. In the AAA style I know, this should have been a static_cast(a+b), btw, because it is a conversion. The {}, in general, is preferred because it prevents narrowing conversions. There are a lot of problems with the C declarator syntax (implicit narrowing conversions, hard-to-parse for humans, "most vexing parse", non-uniformity), and auto and uniform init and template aliases are the fixes. If you don't use them, then you're stuck in the C declarator syntax. You need to use a radically different syntax to get the nicer rules. And yes, I also abhor QString s{a}, but in five years time, every C++ programmer's eyes will have become used to it. They must, if they don't want to be stuck in the past. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Fri Dec 25 13:24:03 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 25 Dec 2015 10:24:03 -0200 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <201512251035.02188.marc.mutz@kdab.com> References: <201512031949.46920.marc.mutz@kdab.com> <201512251035.02188.marc.mutz@kdab.com> Message-ID: <2323685.vkVtsPsi3H@tjmaciei-mobl4> On Friday 25 December 2015 10:35:02 Marc Mutz wrote: > There are a lot of problems with the C declarator syntax (implicit > narrowing conversions, hard-to-parse for humans, "most vexing parse", > non-uniformity), and auto and uniform init and template aliases are the > fixes. If you don't use them, then you're stuck in the C declarator syntax. > You need to use a radically different syntax to get the nicer rules. Except when they mean different things. auto v1 = QVector{1, 2}; auto v2 = QVector(1, 2); -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Marco.Bubke at theqtcompany.com Sat Dec 26 14:14:57 2015 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Sat, 26 Dec 2015 13:14:57 +0000 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: <2323685.vkVtsPsi3H@tjmaciei-mobl4> References: <201512031949.46920.marc.mutz@kdab.com> <201512251035.02188.marc.mutz@kdab.com> <2323685.vkVtsPsi3H@tjmaciei-mobl4> Message-ID: On December 25, 2015 13:24:43 Thiago Macieira wrote: > On Friday 25 December 2015 10:35:02 Marc Mutz wrote: >> There are a lot of problems with the C declarator syntax (implicit >> narrowing conversions, hard-to-parse for humans, "most vexing parse", >> non-uniformity), and auto and uniform init and template aliases are the >> fixes. If you don't use them, then you're stuck in the C declarator syntax. >> You need to use a radically different syntax to get the nicer rules. > > Except when they mean different things. > > auto v1 = QVector{1, 2}; > auto v2 = QVector(1, 2); > The second contructor looks misleading. ;-) Actually I never used size in the constructor. And if you need something like that a factory function would would be much nicer. What I using today is function({1, 2, 3}) for testing if the function expect an vector. And auto values = createValues({{"one", 1}, {"two", 2} , {"three", 3}); If I use value classes. It makes test driven development much easier because I can change things easier. And the test code is more readable. or I use Vector values; values.reserve(4096); To initialize a vector. auto values = reserve(Vector(), 4046); Could be nice too but that is C++ 17. After using python for years C++ syntax looks still ugly to me but you get used to it. So my advice is that you use it for some time and then judge. Taste is changing. ;-) From kevin.kofler at chello.at Sun Dec 27 02:17:00 2015 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 27 Dec 2015 02:17 +0100 Subject: [Development] RFC: more liberal 'auto' rules? References: <201512031949.46920.marc.mutz@kdab.com> <201512251035.02188.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > There are a lot of problems with the C declarator syntax (implicit > narrowing conversions, hard-to-parse for humans, "most vexing parse", > non-uniformity), and auto and uniform init and template aliases are the > fixes. If you don't use them, then you're stuck in the C declarator > syntax. You need to use a radically different syntax to get the nicer > rules. I consider the C declarator syntax just fine, it is very intuitive and has served us well for 26 years, so I don't see a need to change it. Implicit narrowing conversions are a feature. And what is hard to parse for humans? The "char* p,q" "issue"? That's a formatting bug then, this ought to be written "char *p, q", which makes it very clear what is going on. Kevin Kofler From suy at badopi.org Sun Dec 27 23:05:38 2015 From: suy at badopi.org (Alejandro Exojo) Date: Sun, 27 Dec 2015 23:05:38 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <201512251035.02188.marc.mutz@kdab.com> Message-ID: <201512272305.39042.suy@badopi.org> El Sunday 27 December 2015, Kevin Kofler escribió: > I consider the C declarator syntax just fine, it is very intuitive and has > served us well for 26 years, so I don't see a need to change it. That some things have served up well for some time, that doesn't mean we can't find better things (either to complement, or completely replace the old ones). That doesn't mean the AAA style is better just because it's new, of course. I just state no opinion. But your justification is wrong. > Implicit narrowing conversions are a feature. const qlonglong pi = 3.141592653589793238462643383; That compiles and runs without warnings or errors. A line exactly like this ended up in a real application for some alpha version. I don't like this feature at all, and I'm glad there is a way to guard you against it (I might not like how it has to be done yet, but there are good reasons for wanting to avoid this feature). -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net From mike.krus at kdab.com Sun Dec 27 23:56:59 2015 From: mike.krus at kdab.com (Mike Krus) Date: Sun, 27 Dec 2015 22:56:59 +0000 Subject: [Development] allow Qt for iOS to be built as shared libraries In-Reply-To: <580E2E5C-F39A-4463-9EB8-DC54920C1A3E@petroules.com> References: <55F55D74.1090800@divideconcept.net> <580E2E5C-F39A-4463-9EB8-DC54920C1A3E@petroules.com> Message-ID: <0A07E78C-A038-4B0A-AA39-36F227237955@kdab.com> Hi has anybody taken this any further? Enabling dynamic builds as frameworks causes link errors. For example, when linking QtNetwork.framework for the simulator, I get: ld: warning: ignoring file /.../qt5_ios/qtbase/lib/QtCore.framework/QtCore, missing required architecture i386 in file /.../qt5_ios/qtbase/lib/QtCore.framework/QtCore (2 slices) This is because QtCore.framework/QtCore is a device build (armv7 arm64). However, QtCore.framework/QtCore_iphonesimulator does exist but ld does not know to use it at that point. Tried restricting the build to one platform only, restricting sdk to iphoneos works, but not iphonesimulator: Project ERROR: iOS simulator is handled automatically for iphonesimulator_and_iphoneos May need to do separate device and simulator builds or at least build into separate bundles (at the cost of duplicating headers). Thought we could use lipo to build a fat binary but I believe that functionality has been removed from qt’s build system. (plus the SDKs aren’t the same so I’m not sure it can be made to work anyway) Other options? things I missed? Mike > On 13 Sep 2015, at 22:28, Jake Petroules wrote: > > >> On Sep 13, 2015, at 4:26 AM, Robin Lobel wrote: >> >> Hi Jake, >> >> Do you have any update on this ? >> https://codereview.qt-project.org/#/c/123023/ >> >> I agree It'd be great to have such option starting with iOS 8. >> >> thanks >> Robin Lobel > > Yes, I'm going to do some more testing on this today. > -- > Jake Petroules - jake.petroules at petroules.com > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Mike Krus | mike.krus at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44 1625 809908 Mobile +44 7833 491941 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3859 bytes Desc: not available URL: From Jake.Petroules at theqtcompany.com Mon Dec 28 00:18:48 2015 From: Jake.Petroules at theqtcompany.com (Petroules Jake) Date: Sun, 27 Dec 2015 23:18:48 +0000 Subject: [Development] allow Qt for iOS to be built as shared libraries In-Reply-To: <0A07E78C-A038-4B0A-AA39-36F227237955@kdab.com> References: <55F55D74.1090800@divideconcept.net> <580E2E5C-F39A-4463-9EB8-DC54920C1A3E@petroules.com> <0A07E78C-A038-4B0A-AA39-36F227237955@kdab.com> Message-ID: On Dec 27, 2015, at 2:56 PM, Mike Krus > wrote: Hi has anybody taken this any further? Just pushed a new patch set which should be mergeable now pending no further complaints. Enabling dynamic builds as frameworks causes link errors. For example, when linking QtNetwork.framework for the simulator, I get: ld: warning: ignoring file /.../qt5_ios/qtbase/lib/QtCore.framework/QtCore, missing required architecture i386 in file /.../qt5_ios/qtbase/lib/QtCore.framework/QtCore (2 slices) This is because QtCore.framework/QtCore is a device build (armv7 arm64). However, QtCore.framework/QtCore_iphonesimulator does exist but ld does not know to use it at that point. Tried restricting the build to one platform only, restricting sdk to iphoneos works, but not iphonesimulator: Project ERROR: iOS simulator is handled automatically for iphonesimulator_and_iphoneos At this point, only -sdk iphoneos will work, yes. May need to do separate device and simulator builds or at least build into separate bundles (at the cost of duplicating headers). Thought we could use lipo to build a fat binary but I believe that functionality has been removed from qt’s build system. (plus the SDKs aren’t the same so I’m not sure it can be made to work anyway) iOS and iOS Simulator are two different platforms on the Apple side. They should NOT be lipo'ed together and the fact that we've been trying to pretend they are one platform adds a ton of complexity of the build system. It should have never been done this way. It may not even be worth fixing until Qbs is Qt's build system. Other options? things I missed? Mike On 13 Sep 2015, at 22:28, Jake Petroules > wrote: On Sep 13, 2015, at 4:26 AM, Robin Lobel > wrote: Hi Jake, Do you have any update on this ? https://codereview.qt-project.org/#/c/123023/ I agree It'd be great to have such option starting with iOS 8. thanks Robin Lobel Yes, I'm going to do some more testing on this today. -- Jake Petroules - jake.petroules at petroules.com _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Mike Krus | mike.krus at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44 1625 809908 Mobile +44 7833 491941 KDAB - The Qt Experts -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.krus at kdab.com Mon Dec 28 16:38:54 2015 From: mike.krus at kdab.com (Mike Krus) Date: Mon, 28 Dec 2015 15:38:54 +0000 Subject: [Development] allow Qt for iOS to be built as shared libraries In-Reply-To: References: <55F55D74.1090800@divideconcept.net> <580E2E5C-F39A-4463-9EB8-DC54920C1A3E@petroules.com> <0A07E78C-A038-4B0A-AA39-36F227237955@kdab.com> Message-ID: <5288997F-8771-4D87-A265-C45687526D36@kdab.com> > On 27 Dec 2015, at 23:18, Petroules Jake wrote: > >> has anybody taken this any further? > > Just pushed a new patch set which should be mergeable now pending no further complaints. nice, I think though that if you’re doing a shared build, the sdk should default to iphoneos (not iphonesimulator_and_iphoneos) Taking this further, have you got a workable build with not further changes? I’m finding that the iOS qpa needs tweaking (at least) Mike -- Mike Krus | mike.krus at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44 1625 809908 Mobile +44 7833 491941 KDAB - The Qt Experts -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3859 bytes Desc: not available URL: From waldmanns at gmx.de Mon Dec 28 21:50:18 2015 From: waldmanns at gmx.de (Die Waldmanns) Date: Mon, 28 Dec 2015 21:50:18 +0100 Subject: [Development] High-DPI on Win Message-ID: An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Dec 28 22:54:25 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 28 Dec 2015 19:54:25 -0200 Subject: [Development] High-DPI on Win In-Reply-To: References: Message-ID: <2191061.VlNhs8K83m@tjmaciei-mobl4> On Monday 28 December 2015 21:50:18 Die Waldmanns wrote: > (2) Allow setting the devicePixelRatio programatically. The current method > via an environment variable might not be considered acceptable, or a > programmer might want to modify the built-in method of how it is determined > automatically. Im not sure if this could be achieved now by e.g. calling > QHighDpiScaling::setGlobalFactor(). Anyway, I think the mechanism should be > part of the API, i.e. be simple, official, and documented (e.g. a virtual > method which can be overloaded). It would avoid clumpsy work-arounds such > as calling os.environ['QT_DEVICE_PIXEL_RATIO'] = str( int(winScale) ) from > within the code. That is definitely not going to happen. Applications should never have to override the value. Either it is correctly guessed by Qt based on system defaults or the user set the value that is correct for that system. The application must never override it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mark.dewit at iesve.com Tue Dec 29 10:45:19 2015 From: mark.dewit at iesve.com (Mark De Wit) Date: Tue, 29 Dec 2015 09:45:19 +0000 Subject: [Development] High-DPI on Win In-Reply-To: References: Message-ID: <3709A7D425EE8C45991DB29EC2FACA882721C5DB@GL-EXC-01.iesve.com> Keep in mind that from Windows 8.1 onwards, DPI can be set per-screen (I myself have a 4K screen (240 dpi, 250% scaling) + regular HD screen (120 dpi, 125% scaling)). Qt appears to already handle the appropriate new dpi-aware APIs (Qt defaults to per-monitor DPI aware on Windows 8.1+). Sadly, I must agree with you that Qt does indeed not handle high-dpi windows very well ☹ I have Qt applications that I cannot use on my system, and have resorted to qt.conf to turn off DPI-awareness for them; fuzzy scaling was preferable to not being able to use the application. Mind you, I have not found many Windows applications that handle high-dpi correctly, software is definitely lagging behind hardware here. Mark From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Die Waldmanns Sent: 28 December 2015 20:51 To: development at qt-project.org Subject: [Development] High-DPI on Win Hey Everyone, first, I'd like to apologize if that is the wrong place for the following, but I've seen the "High-DPI 5.6 beta update" thread, which encouraged me to post here. Second, you'll quickly realize that I'm new to QT, so not everything I'm saying might be prefectly on spot, I beg for pardon, but I think the main message is, so please rather look for that. (BTW, I'm using PyQT5.5 as provided by WinPython-64bit-3.4.3.5 on a Win7 Pc and a Win8.1 high-dpi laptop). Third, I also write because after my first amazement with how nicely the first steps with PyQT5 worked out I was - yes - shocked to see how badly QT handles high-dpi on Win. I think one can't be happy with the current situation, and - although I can't claim to really have penetrated QT5.6 beta1 - I'm worried that it won't be satisfactorily resolved in QT5.6 either, even though it is - IMHO - of immediate relevance. I'd like to suggest this: (1) Support of fractional scaling (devicePixelRatio). This ratio is qreal, but in QT5.5 it nevertheless seems not be possible to set it to fractional values (I could get it only to 1.0,2.0,3.0 etc). In 5.6-beta1 the new environment SCALE mechanisms seem to allow setting it to real values, but the examples in the docu are mentioning only devicePixelRatios of 1 and 2, which makes me wonder. If in QT5.6 it's now possible to acieve devicePixelRatios of 1.0, 1.25, 1.5, 2.0, and 2.5, then this point is obsolete; if not I think this neeeds to be enabled. (2) Allow setting the devicePixelRatio programatically. The current method via an environment variable might not be considered acceptable, or a programmer might want to modify the built-in method of how it is determined automatically. Im not sure if this could be achieved now by e.g. calling QHighDpiScaling::setGlobalFactor(). Anyway, I think the mechanism should be part of the API, i.e. be simple, official, and documented (e.g. a virtual method which can be overloaded). It would avoid clumpsy work-arounds such as calling os.environ['QT_DEVICE_PIXEL_RATIO'] = str( int(winScale) ) from within the code. Ideally the mechanism would allow one to set devicePixelRatio at a point in time where the fonts are already accessible (app.font(),QFontInfo()). (not sure if that's possible, but the current mechanism seems to set the pixel ratio in two steps, so I recon it might be) (3) Don't calculate the scale from the display resolution (QPlatformScreen::pixelDensity()). In QT5.5 the devicePixelRatio is obviously set to either 1.0 or 2.0 depending on the resolution of the display. I'm not sure for Qt5.6, but it seems to be alike here. However, in Win the user can set a scaling such as 100%, 125%, 150%, 200%, and 250%, and the user can do so - and may want to do so - for whatever display she/he is using (anyone with ailing eyes is happy to use 125% on regular screens, or 250% on HDPI screens ;)). So - IMHO - the devicePixelRatio should actually be set to exactly this value, independent on any display resolution. In QT5.5 the font sizes are apparently set "correctly", i.e. scale with the Windows scaling set by the user. Thus, for the 125%, 150%, and 250% scalings ugly GUIs result, since the font sizes do not fit to the renderings produced by QT5.5 (which are scaled only by 1.0, 2.0, 3.0,...). I'm not sure how exactly QT manages the font sizing, but I guess it's just that the font sizes are specified as points, and Win when does the correct scaling. Anyway, since the fonts scale with the Windows scaling it seems obvious to me that also the rest of the GUI should be scaled with this very same factor, at least it's the best bet on getting a properly rendered GUI. As a work-around to the limitations of QT5.5 I tried doing all scaling by hand, i.e. to enforce devicePixelRatio=1.0 and scale all Widgets by using my own scale factors. This works quite well ... for most parts, it fails e.g. for a QMessageBox. So, this approach doesn't yield a fully satisfying result either (I note that QtDesigner suffers from the same artefacts, implying that even expert Qt programmers didn't get around it). I got however the clear impression that if I could set devicePixelRatio to 2.5 when using a scaling of 250%, I would get a perfect GUI, which suggests the above 3 points, since with (1) and (2) one could determine the Windows scale and set devicePixelRatio accordingly. Ideally, Qt would be "smart" enough to do that by itself, which is (3). As regards determining the Windows scale, I could not identify an API function which would give it directly. The most robust approach I found is to go via the fonts: winScale = ( 3.0 * QFontInfo(app.font()).pixelSize() )/( 4.0 * QFontInfo(app.font()).pointSizeF() ) I tested this for a couple of fonts and font sizes, and in all cases without exception this formula delivered the correct Windows scaling. Unfortunately, this works only after the app is created (app = QApplication([])). As alternative I found: winScaledYRes = GetSystemMetrics(1) #1 = SM_CYSCREEN dc= windll.user32.GetDC(0) winYRes = windll.gdi32.GetDeviceCaps(dc,117) #117 = DESKTOPVERTRES winScale = float(winYRes)/float(winScaledYRes) This works before the app is created, and thus can be used to set the devicePixelration by calling os.environ['QT_DEVICE_PIXEL_RATIO'] = str( int(winScale) ), but, at least on my systems, it provides the correct value only for the 100%, 150%, 200%, and 250% scalings. For some reasons I don't understand it yields 1.0 instead of 1.25 for the 125% scaling. Maybe better methods exist. Anyway, since the font method works so well it would be nice if fonts could be accessed in (2). Sorry for the long post, to summarize in a nutshell: I came to the conclusion that one would/could get nice QT GUIs, for all Windows scalings and any display, if one could set the devicePixelRatio to real values which match the Windows user scaling. This led me to the above 3 suggestions. I'd like to add again, that a working HDPI is IMHO of immediate importance, and thus would think that it should become part of QT5.6, besides its feature freeze. I think the 3 points are easy to implement, which warrants this. Finally, again, if any of the above just reflects my inablitity to discover the proper Qt methods to deal with high-DPI on Win systems, then please accept my applogies; please consider when to provide a bit more guidance in the docu :) Cheers, and thanks for all your great work !! Olli -------------- next part -------------- An HTML attachment was scrubbed... URL: From Morten.Sorvig at theqtcompany.com Tue Dec 29 11:47:05 2015 From: Morten.Sorvig at theqtcompany.com (Sorvig Morten) Date: Tue, 29 Dec 2015 10:47:05 +0000 Subject: [Development] High-DPI on Win In-Reply-To: References: Message-ID: <124ADFB9-BB39-4137-A607-8A63D4FC9D8A@digia.com> Hello! > On 28 Dec 2015, at 21:50, Die Waldmanns wrote: > > (1) Support of fractional scaling (devicePixelRatio). > This ratio is qreal, but in QT5.5 it nevertheless seems not be possible to set it to fractional values (I could get it only to 1.0,2.0,3.0 etc). In 5.6-beta1 the new environment SCALE mechanisms seem to allow setting it to real values, but the examples in the docu are mentioning only devicePixelRatios of 1 and 2, which makes me wonder. If in QT5.6 it's now possible to acieve devicePixelRatios of 1.0, 1.25, 1.5, 2.0, and 2.5, then this point is obsolete; if not I think this neeeds to be enabled. (talking about 5.6 here) We use qreal in the API, and using QT_SCALE_FACTOR it is indeed possible to set a fractional scale factor. The Windows and Xcb platform plugins rounds the scale factor returned by pixelDensity() and returns integer values only. You could patch out the qRound() calls and test how this works. Note that we don’t support or guarantee glitch free graphics at fractional scale factors (hence the qRound calls in pixelDensity()). There is a possibility that a solution like codereview.qt-project.org/#/c/143819 may be available in the future, but not for 5.6. > > (2) Allow setting the devicePixelRatio programatically. > The current method via an environment variable might not be considered acceptable, or a programmer might want to modify the built-in method of how it is determined automatically. Im not sure if this could be achieved now by e.g. calling QHighDpiScaling::setGlobalFactor(). Anyway, I think the mechanism should be part of the API, i.e. be simple, official, and documented (e.g. a virtual method which can be overloaded). It would avoid clumpsy work-arounds such as calling os.environ['QT_DEVICE_PIXEL_RATIO'] = str( int(winScale) ) from within the code. > > Ideally the mechanism would allow one to set devicePixelRatio at a point in time where the fonts are already accessible (app.font(),QFontInfo()). (not sure if that's possible, but the current mechanism seems to set the pixel ratio in two steps, so I recon it might be) Closest thing I've considered for public API is QWindow::setScaleFactor, which might have sufficiently strong use cases (simulation etc). We really want the platform plugin to do the right thing though, optionally with user input if correct display metrics are not available. > > (3) Don't calculate the scale from the display resolution (QPlatformScreen::pixelDensity()). > In QT5.5 the devicePixelRatio is obviously set to either 1.0 or 2.0 depending on the resolution of the display. I'm not sure for Qt5.6, but it seems to be alike here. However, in Win the user can set a scaling such as 100%, 125%, 150%, 200%, and 250%, and the user can do so - and may want to do so - for whatever display she/he is using (anyone with ailing eyes is happy to use 125% on regular screens, or 250% on HDPI screens ;)). So - IMHO - the devicePixelRatio should actually be set to exactly this value, independent on any display resolution. As far as I can see the Windows platform plugin uses GetDpiForMonitor() for both the font DPI and pixelDensity(). Then as noted above the DPI value is rounded by pixelDensity(). See also QTBUG-50120 for a summary of native API use. Morten From thiago.macieira at intel.com Tue Dec 29 13:18:21 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 29 Dec 2015 10:18:21 -0200 Subject: [Development] High-DPI on Win In-Reply-To: <3709A7D425EE8C45991DB29EC2FACA882721C5DB@GL-EXC-01.iesve.com> References: <3709A7D425EE8C45991DB29EC2FACA882721C5DB@GL-EXC-01.iesve.com> Message-ID: <2309553.y6aCcg1HXa@tjmaciei-mobl4> On Tuesday 29 December 2015 09:45:19 Mark De Wit wrote: > Sadly, I must agree with you that Qt does indeed not handle high-dpi windows > very well ☹ I have Qt applications that I cannot use on my system, and > have resorted to qt.conf to turn off DPI-awareness for them; fuzzy scaling > was preferable to not being able to use the application. Using 5.6? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mark.dewit at iesve.com Tue Dec 29 15:18:20 2015 From: mark.dewit at iesve.com (Mark De Wit) Date: Tue, 29 Dec 2015 14:18:20 +0000 Subject: [Development] High-DPI on Win In-Reply-To: <2309553.y6aCcg1HXa@tjmaciei-mobl4> References: <3709A7D425EE8C45991DB29EC2FACA882721C5DB@GL-EXC-01.iesve.com> <2309553.y6aCcg1HXa@tjmaciei-mobl4> Message-ID: <3709A7D425EE8C45991DB29EC2FACA882721C642@GL-EXC-01.iesve.com> Good point - not my app, but I checked the Qt version number of the one that annoys me most, and it's using 5.4.1. Most of the stuff we write here we test at high-dpi, and it's generally working ok (tested only at 5.4, not tested 5.6 because we have a dependency on webkit). Some things don't scale properly in Qt (UI elements such as splitter bar gripper + corresponding splitter cursor comes to mind). We've also been hit by SVG images not upscaling beyond their "native" size (from memory, they're not rendered larger than their viewport?), had to wrap the images in a transform to make them scale to 250%. Mark -----Original Message----- From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Thiago Macieira Sent: 29 December 2015 12:19 To: development at qt-project.org Subject: Re: [Development] High-DPI on Win On Tuesday 29 December 2015 09:45:19 Mark De Wit wrote: > Sadly, I must agree with you that Qt does indeed not handle high-dpi windows > very well ☹ I have Qt applications that I cannot use on my system, and > have resorted to qt.conf to turn off DPI-awareness for them; fuzzy > scaling was preferable to not being able to use the application. Using 5.6? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From rjvbertin at gmail.com Tue Dec 29 15:32:52 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 29 Dec 2015 15:32:52 +0100 Subject: [Development] [OS X] does AA_MacDontSwapCtrlAndMeta really work as it should in Qt 5? Message-ID: <4017599.INlZaU016X@portia.local> Hello, I'm currently trying to get my head around how AA_MacDontSwapCtrlAndMeta is supposed to work on OS X, and the fact that setting the attribute in a Qt5-based terminal emulator doesn't appear to have the intended effect of allowing the usual Ctrl-C and family shell shortcuts to be issues using the Ctrl key. When I scan the Qt code for AA_MacDontSwapCtrlAndMeta, I see things like if (qApp->testAttribute(Qt::AA_MacDontSwapCtrlAndMeta) && (macSymbol == kControlUnicode || macSymbol == kCommandUnicode)) { if (macSymbol == kControlUnicode) macSymbol = kCommandUnicode; else macSymbol = kControlUnicode; } or static inline int maybeSwapShortcut(int shortcut) { if (qApp->testAttribute(Qt::AA_MacDontSwapCtrlAndMeta)) { uint oldshortcut = shortcut; shortcut &= ~(Qt::CTRL | Qt::META); if (oldshortcut & Qt::CTRL) shortcut |= Qt::META; if (oldshortcut & Qt::META) shortcut |= Qt::CTRL; } and if (qApp->testAttribute(Qt::AA_MacDontSwapCtrlAndMeta)) { int oldModifiers = ret; ret &= ~(controlKeyBit | cmdKeyBit); if (oldModifiers & controlKeyBit) ret |= cmdKeyBit; if (oldModifiers & cmdKeyBit) ret |= controlKeyBit; } and I cannot help but wonder why that appears to be the opposite of what should be done. Hence my question: just how is this supposed to work, and more importantly, is there still support for not swapping the Command ("META") and Ctrl keys? And as a bonus: wouldn't it have been better to provide a platform-specific Qt::ACCEL constant instead of swapping key modifiers back and forth at runtime (and probably the wrong number of times in some places; that's what the current issue looks like)? Thanks, René From mwoehlke.floss at gmail.com Tue Dec 29 18:39:58 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 29 Dec 2015 12:39:58 -0500 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <4606126.Pqxnumcx4H@finn> <04544583-2102-4BE6-8232-D12634E879E7@theqtcompany.com> <201512071544.42707.marc.mutz@kdab.com> <1BD99747-4E60-4C76-8612-DE744E1CCA14@theqtcompany.com> <592A0CC7-1F6F-4F31-8B91-BF1C17D78796@theqtcompany.com> <2751DBCD-0CE9-42B9-97C1-5AA9B2D4E4C3@theqtcompany.com> Message-ID: On 2015-12-24 19:16, Kevin Kofler wrote: > Matthew Woehlke wrote: >> auto result = QString{a + b}; > > IMHO, that's just a complicated and ugly way to write: > QString result = a + b; > > There is no way the variable can be uninitialized if you initialize it right > there in the declaration. That's nice, but what about when you forget to initialize something? If you (almost) always use auto, the compiler will squawk. The benefit comes from *consistency*. Anyway, I'm not trying to argue passionately that Qt should follow AAA. I'm just saying that it's incorrect to state that you have to deviate from AAA because it might give you the wrong type. (And, as Marc notes, AAA, used correctly, actually *better* documents code in such case.) -- Matthew From mwoehlke.floss at gmail.com Tue Dec 29 18:47:41 2015 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 29 Dec 2015 12:47:41 -0500 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <201512251035.02188.marc.mutz@kdab.com> Message-ID: On 2015-12-26 20:17, Kevin Kofler wrote: > And what is hard to parse for humans? The "char* p,q" "issue"? That's a > formatting bug then, this ought to be written "char *p, q", which makes it > very clear what is going on. That's... debatable. Personally, I dislike combining names and type information. And it doesn't always work out so nicely. What, for example, is the type of 'q' here?: char const* const *p, q; Explicit pointer/reference types and multiple declarations should simply not appear in the same statement¹. Period. -- Matthew From bo at vikingsoft.eu Wed Dec 30 11:01:34 2015 From: bo at vikingsoft.eu (Bo Thorsen) Date: Wed, 30 Dec 2015 11:01:34 +0100 Subject: [Development] RFC: more liberal 'auto' rules? In-Reply-To: References: <201512031949.46920.marc.mutz@kdab.com> <201512251035.02188.marc.mutz@kdab.com> Message-ID: <5683AB7E.3030903@vikingsoft.eu> Den 29-12-2015 kl. 18:47 skrev Matthew Woehlke: > On 2015-12-26 20:17, Kevin Kofler wrote: >> And what is hard to parse for humans? The "char* p,q" "issue"? That's a >> formatting bug then, this ought to be written "char *p, q", which makes it >> very clear what is going on. > > That's... debatable. Personally, I dislike combining names and type > information. And it doesn't always work out so nicely. What, for > example, is the type of 'q' here?: > > char const* const *p, q; > > Explicit pointer/reference types and multiple declarations should simply > not appear in the same statement¹. Period. This is getting quite off-topic, even for this thread. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From jani.heikkinen at theqtcompany.com Wed Dec 30 11:12:45 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Wed, 30 Dec 2015 10:12:45 +0000 Subject: [Development] Qt 5.6.0 String freeze Message-ID: Hi all, As warned a week ago string freeze is now in effect. Please, no changes to translatable strings from now on, unless approved by the documentation team. Br, Jani From: Heikkinen Jani Sent: 21. joulukuuta 2015 9:56 To: localization at qt-project.org Cc: development at qt-project.org Subject: HEADS UP - Qt 5.6.0 String freeze coming Importance: High Hi, Beta is finally out & work for finalizing Qt 5.6 continues. One milestone for that is string freeze which will be 30.12.2015. So it is time to start keeping the translatable strings as it is and fix remaining important issues. br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlayt at kde.org Wed Dec 30 19:42:44 2015 From: jlayt at kde.org (John Layt) Date: Wed, 30 Dec 2015 18:42:44 +0000 Subject: [Development] Minimum Deployment Platforms for 5.7 onwards? Message-ID: Hi, Can I just clarify what the minimum deployment platforms are for 5.7 onwards? That is, the lowest version of each OS that the code must still run on? Far as I can tell it's something like: Windows 7 (or Vista?) Windows Embedded Compact 2013 OSX 10.8 iOS 5.0? Android 4.1 (API Level 16)? RHEL 6.6 Ubuntu 11.10? There really should be a wiki page for this... Cheers! John. -------------- next part -------------- An HTML attachment was scrubbed... URL: From waldmanns at gmx.de Thu Dec 31 20:01:03 2015 From: waldmanns at gmx.de (Waldmanns) Date: Thu, 31 Dec 2015 20:01:03 +0100 Subject: [Development] High-DPI on Win Message-ID: <826CA0F7A0D04135ABAB3EB3E5241998@OlliPC> thanks to all the good responses ! “Mind you, I have not found many Windows applications that handle high-dpi correctly, software is definitely lagging behind hardware here.” I’m using my HDPI laptop since 2 years, and at that time many programs had issues but nowadays I find it hard to find one not rendering well so, I’d like to disagree, this might have been true 2 years ago but – IMHO - is not nowadays “The Windows ... platform plugins rounds the scale factor” “the DPI value is rounded “ “there is a possibility that a solution like codereview.qt-project.org/#/c/143819 may be available in the future, but not for 5.6” this then effectively means that QT will not be able to work properly on Win for a long time to come ... very sad to hear that please note that the issue at hand is not only HDPI, in fact, in some ways it’s not HDPI at all but Win basic the point is that Win allows for a user scaling (on my Win7 PC its by 100%,125%,150%, and on my Win8.1 lappi its by 100%,125%,150%200%,250%) even on a “normal” display, such as the 1920x1080 display on my Win7 PC, QT doesn’t produce acceptable results with 125% or 150% choosen ... the issue with HDPI is only that it needs a larger scaling factor so, the need of fractional scale factors isn’t something “new” but would have been needed for “ages” (at least since the introduction of Vista, not sure about earlier versions) from it’s behavior in version 5.5, and from the above, it seems that QT totally fails to realize the Win ways of doing things I don’t really understand why it should be that hard to allow for scalings of 1.25,1.5,2.0, and 2.5, I actually thought that QT is very close since much in the behind seems to be prepared for or do qreal scaling already, but obviously I’m very mistaken anyhow, since an acceptable solution doesn’t seem to be near I guess I have to conclude that with deciding for QT I jumped on the wrong horse and have to swallow the bitter pill of having to go with Chrome apps Thx a lot again for your comments, I’m sorry that my impression that this could be an easy to solve issue was wrong, and wish you all a Happy New Year, Olli -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Dec 31 23:00:32 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 31 Dec 2015 20:00:32 -0200 Subject: [Development] High-DPI on Win In-Reply-To: <826CA0F7A0D04135ABAB3EB3E5241998@OlliPC> References: <826CA0F7A0D04135ABAB3EB3E5241998@OlliPC> Message-ID: <1841756.KGpfvjCsJl@tjmaciei-mobl4> On Thursday 31 December 2015 20:01:03 Waldmanns wrote: > “there is a possibility that a solution like > codereview.qt-project.org/#/c/143819 may be available in the future, but > not for 5.6” > > this then effectively means that QT will not be able to work properly on Win > for a long time to come ... very sad to hear that Yes, six months. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center