From lars.knoll at qt.io Wed Aug 1 09:43:37 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 1 Aug 2018 07:43:37 +0000 Subject: [Development] Requesting Repository For Python Extension Support in QtCreator In-Reply-To: References: Message-ID: <230B928C-EBB7-4B2E-A587-401C162BA116@qt.io> Sounds good to me. Cheers, Lars On 27 Jul 2018, at 14:37, Tilman Röder > wrote: Hello there, My name is Tilman and I am a software engineering intern at the Qt office in Berlin. I'm working on combining PySide2, Shiboken and QtCreator to enable Python based extensions in the later. I think that this project has now matured enough to be put under proper version control and to show the world a first proof of concept. That being said, pretty much everything in the project is still subject to change and there will probably be quite a few bugs that have not been discovered yet. Description: Support Python Extensions by creating bindings for the Core module and Utils library of QtCreator (using Shiboken) and by providing a new C++ plugin that uses these bindings to execute Python scripts that can interact with QtCreator. This is an early proof of concept and currently includes the following: - Some parts of the Core module included as bindings - MacroExpander from utils as binding (note: due to not unsupported function pointers, there are still problems with registering new macros from Python) - A somewhat isolated embedded CPython runtime for the Python extensions - Setup mechanism that allows extensions to install dependencies etc. - Included extension manager written in Python - Build scripts that should work on most Linux systems, provided the required dependencies are installed correctly (for more details, see the existing GitHub repository) Responsible: Tilman Roeder Repository: qt-creator/plugin-pythonextensions Existing code: https://github.com/dyedgreen/qt-creator-python-extensions _______________________________________________ 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 nevion at gmail.com Wed Aug 1 10:24:42 2018 From: nevion at gmail.com (Jason Newton) Date: Wed, 1 Aug 2018 01:24:42 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: Message-ID: On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke wrote: > > On 2018-07-21 19:52, Jason Newton wrote: > > I wanted to mention that this is on my mind alot for a few years days > > as a user for a plethora of libraries. My conclusion for the build > > system with the brightest future is bazel [...] > > No. Just, *no*. > > Persistent build server? Java? No, thanks. This is an option, you can keep it in a preference file, or you can use it as a command line switch to not use this . stat time performance when monitoring many files, between invocations, especially if globbing is involved and if you don't have a process watching with inotify you will need to O(N) check every file for modification and to hope your platform/hardware makes that check cheap (windows doesn't, https://github.com/mesonbuild/meson/blob/master/docs/markdown/FAQ.md#but-i-really-want-to-use-wildcards) Better to have a plan to deal with the case than not. As for java in the loop - this is a a build system, how much does it matter with what it is written in if the implementation is good? I am not saying 0 but you should keep this number in check. Make is made out of something far more terrible than java. Cmake is built on c++ but is difficult to modify and the language they made is a mess. Java works in many situations and provides a write-once run anywhere mode that works most of the time without issue and is performant enough for most everyday tasks (better than python, and not always a long shot off from all kinds of c/c++ depending on the application and exact algorithms ), and importantly it works in this one without any notable complaints. OpenJDK has wide coverage for host-build environments: http://openjdk.java.net - and is packaged by all major distributions, first class. > > Maybe it's gotten better, but last I knew, bazel had no notion of > "installing" software, which is just a non-starter. It's also heavily > optimized for Google's internal usage, and (partly as a result) > basically does not play at all nicely with software that's intended to > exist in an open source, package-managed ecosystem. It works well with open source actually, git is a first class data source, mainly targeting external repositories, frequently github. Source archive files are too. The convention is that projects using it embrace that and don't care about the most system packages if they can get away with it. Streamline switching out pkg_config based results and package-kit or other kinds of datasources and really this just works. Discussing this problem upstream will probably get better capabilities in the box well before expected shift time but your beef is with closing the gap on package-managed dependencies outside of bazel, and I'm all for closing it, although even now it is workable. > (I'd be interested to know if there is *any* software packaged by any > FLOSS distribution that uses bazel...) > > Basically, ask your distributors before even *considering* bazel. My > suspicion is they're going to tell you that they refuse to package > anything using it. > > And... seriously, *Java*?! Talk about bloat-ware... As dependencies for > *a build tool* go, that's pretty insane. Especially if you're not > planning to use it to build Java code. As I said, ~300-400 megabytes for a JRE (~90MiB DL), in particular openjdk , prospectively in a development environment where you've got devel headers and packages installed. The cost of the dependency is neither bloat nor unbounded, it really is just that size on a machine that's prepared to build software in 2018. Please explain what issue this presents. > > By comparison, CMake+ninja depend on... a C++ compiler. (Which is also > needed for Qt itself, of course, so...) I haven't really looked, but I'd > guess qmake is also pretty light-weight in the dependency department. > > > Why the qt project may be interested in this in short is: > > -Fast and scaling bazel uses a long lived server technique that hangs > > around > > Yeah... that's *just* the sort of thing we should be forcing on users... > It's even *more* of an anti-feature if some other build systems needs to > build Qt. (Yes, that happens.) > > On a related note, "hermetic builds" is pretty ironic. Your *build* > might be hermetic, but bazel itself is *far* from... it's very reliant > on putting all its garbage in "magic locations" in your home directory, > unlike most build tools that only need to write to your build directory. > Again, *not* friendly for anyone that needs to build Qt as an external > dependency. Actually that's just a default location - the output location you're talking about is the outputRoot/output_base setting: https://docs.bazel.build/versions/master/output_directories.html Again, like gitignore or clang-format, a project can specify it's own settings and the point of contention is default values with persecution on capability. I think there's open path ways for change behaviors that should be changed if there's lingering concern over features like this that deal with use cases and problems rather than a build system which does less and has less to worry about, notably the cost of a build system that's too simple is a build system that's too limit. One of the things I like about the way bazel keeps this is I can jump back and forth between an optimized build and a full debug build (for example) - they don't erase eachother and you can only achieve that jumping capability, being cheap, if you add a file-level layer of indirection. The magic locations actually aren't magic at all and are fully deterministic, hashes like git commits essentially with 1 level of symlinks sitting in the users build directory. You could easily have all your outputs live adjacent to (at minimum) to your project/src directory, somewhat like the build convention in cmake/autotools. > > > The amount of time that useful work is being performed is greater > > than I've observed in large cmake projects, even using ninja (assuming > > ninja would work across projects that size, due to frequent make > > sensitivities) > > Um... very few projects don't work with Ninja, and I've seen plenty of > very large projects that *do*. Yes, this has changed with time but sensitives can exist, I'd still say it's a crap shoot when pulling down sources. > > > -Ability to build external libraries from source > > Yeah... no. Building third party libraries yourself is *evil*. And a > great way to piss off package maintainers. No open source project should > *EVER* rely on, or preferably even use by default, this ability. > It is not evil in any way. It's a different approach that works well for different concerns to attempt to make a ~constant cost vs a linear cost in os * distribution * version. What is needed is a way to do both and make both sides of this happy. Ways to easily lean on a system install or if you're a dev on a system that doesn't play ball well (version, timing, whatever), provide gradieted ways to use source build overlays without tremendous headaches - for getting the latest stable without going ppa for instance and working in custom build flags for any sources of interest. Bazel doesn't deal with system packages in a first class way - there's no direct pkg_config integration, though there are simple trivial scripts that use it that are third party that should move to the builtins. I can help make those kinds of changes, if need be. However I've had no problems pulling in system libs (pkg-config or otherwise) and most of the time packing up a library is smooth sailing, when building from source. As I said you get both and you don't have to pay the penalty of out of band source builds just because by convention people not on a distro-packagers side do. And it's nice when you're working on a software application and want to be distribution agnostic, as is frequently the case if you are not a packager for a distribution. Again pointing out sources-JIT package services like vcpkg, buckaroo, and conan exist and have been gaining traction (users and word of mouth). The want for these capabilities in c++ is growing and bazel provides a streamlined mechanism for it, but it is not generally coupled to the internet for it, and allows gradiantions/mixes of that JIT-from-sources and the system libraries. On JIT from sources, that gives you better support for esoteric platforms that receive little to no TLC from package maintainers, for instance on why that has value (S390 or arm distros are good examples) Also wanted to mention a few things I forgot previously: -Analysis tools for the dependencies, like graphviz, but also memory usage and timing info. A legitimate profiler, have a look: https://docs.bazel.build/versions/master/skylark/performance.html https://www.kchodorow.com/blog/2015/09/18/build-y-u-go-slow/ (admittedly few online examples of this output and this is looks different now IIRC) -Does a good job of controlling verbosity while keeping the user informed on the running targets being processed concurrently while giving a quick way to hop out, go serial or show commands executed -Workable, like cmake workable, visual studio generator, and xcode outputs. -clion has a plugin good direct plugin for it, though more will follow and they tried to make it easy for IDEs to incorporate ( https://blog.bazel.build/2016/06/10/ide-support.html we can agree it'd be create if more build systems did this, right? https://docs.bazel.build/versions/master/ide.html for fuller list ) -Jason From edward.welbourne at qt.io Wed Aug 1 11:01:40 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 1 Aug 2018 09:01:40 +0000 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: , Message-ID: Singling out just one tiny corner of all that for a passing remark: Jason Newton (1 August 2018 10:24) > One of the things I like about the way bazel keeps this is I can jump > back and forth between an optimized build and a full debug build (for > example) - they don't erase eachother This is easy to do in any build system that supports out-of-source (a.k.a. "shadow") builds - notably including the existing qmake-based builds for Qt. I never want to do an in-source build of anything. > and you can only achieve that jumping capability, being cheap, if you > add a file-level layer of indirection. Not sure what you're claiming here, or what system you're claiming lacks it. If you've got both optimised and debug builds, you're going to have both sets of files *somewhere* (whether jumbled up in one directory or kept separate in two out-of-source build trees). Eddy. From Kai.Koehne at qt.io Wed Aug 1 15:45:20 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Wed, 1 Aug 2018 13:45:20 +0000 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: <4435284.KOGfq56aWA@tjmaciei-mobl1> References: <4435284.KOGfq56aWA@tjmaciei-mobl1> Message-ID: Alright, so it seems we have to prefix the symbols we can't hide by static or anonymous namespaces ... For logging categories, I'd like to start using 'qlc' as prefix. See also change https://codereview.qt-project.org/#/c/235631/ for qtbase. Ossi pointed out in the review that, because it is a private symbol, the 'qt_' prefix would be more correct. Anyhow, that just gets too long ... So I'm asking whether anybody objects making an exception for logging categories. Regards Kai > -----Original Message----- > From: Development > On Behalf Of Thiago Macieira > Sent: Tuesday, July 31, 2018 4:58 PM > To: development at qt-project.org > Subject: Re: [Development] Symbol clashes with static Qt libraries > > On Tuesday, 31 July 2018 05:46:44 PDT Simon Hausmann wrote: > > I favor (a) along with the existing test, because of the issues > > Giuseppe outlined with (b) and I'm sceptical about how realistic (c) is for us. > > We will not be able to get (c) working everywhere. I remember trying objcopy > some years ago messing with symbol properties and I know I wasn't successful. > I don't remember what I was trying, though, so this is not a showstopper for > our current problem. Just don't get your hopes up. > > I think we need (a) and we can apply (c) if possible. > > > If we wanted to make this test work again (and produce errors with > > your logging category examples), then we would need a configuration in > > the CI that builds on Linux without ELF visibility. At least that's > > one of the ways it could be done with minimal effort. > > Why can't the test run on .a files? > > > It however does not protect us from the issue on Windows and macOS, > > but it covers the cross-platform code. > > nm exists on both too. We won't get it on MSVC, though. > > -- > 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 Tor.arne.Vestbo at qt.io Wed Aug 1 15:48:40 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Wed, 1 Aug 2018 13:48:40 +0000 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: References: <4435284.KOGfq56aWA@tjmaciei-mobl1> Message-ID: <0B557CE4-0EA0-4F80-9030-510F8A02868F@qt.io> > On 1 Aug 2018, at 15:45, Kai Koehne wrote: > > Alright, so it seems we have to prefix the symbols we can't hide by static or anonymous namespaces ... > > For logging categories, I'd like to start using 'qlc' as prefix. See also change https://codereview.qt-project.org/#/c/235631/ for qtbase. Namespaces doesn’t work for that? > Ossi pointed out in the review that, because it is a private symbol, the 'qt_' prefix would be more correct. Anyhow, that just gets too long ... So I'm asking whether anybody objects making an exception for logging categories. Agreed, qt_ gets unwieldy, qlc is fine. (Assuming we can’t use a namespace instead) Tor Arne > > Regards > > Kai > >> -----Original Message----- >> From: Development >> On Behalf Of Thiago Macieira >> Sent: Tuesday, July 31, 2018 4:58 PM >> To: development at qt-project.org >> Subject: Re: [Development] Symbol clashes with static Qt libraries >> >> On Tuesday, 31 July 2018 05:46:44 PDT Simon Hausmann wrote: >>> I favor (a) along with the existing test, because of the issues >>> Giuseppe outlined with (b) and I'm sceptical about how realistic (c) is for us. >> >> We will not be able to get (c) working everywhere. I remember trying objcopy >> some years ago messing with symbol properties and I know I wasn't successful. >> I don't remember what I was trying, though, so this is not a showstopper for >> our current problem. Just don't get your hopes up. >> >> I think we need (a) and we can apply (c) if possible. >> >>> If we wanted to make this test work again (and produce errors with >>> your logging category examples), then we would need a configuration in >>> the CI that builds on Linux without ELF visibility. At least that's >>> one of the ways it could be done with minimal effort. >> >> Why can't the test run on .a files? >> >>> It however does not protect us from the issue on Windows and macOS, >>> but it covers the cross-platform code. >> >> nm exists on both too. We won't get it on MSVC, though. >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From mwoehlke.floss at gmail.com Wed Aug 1 16:33:43 2018 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 1 Aug 2018 10:33:43 -0400 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: Message-ID: <4a6fc377-1cb6-e5a7-1921-d49b17f9aa05@gmail.com> On 2018-08-01 04:24, Jason Newton wrote: > On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke wrote: >> On 2018-07-21 19:52, Jason Newton wrote: >>> I wanted to mention that this is on my mind alot for a few years days >>> as a user for a plethora of libraries. My conclusion for the build >>> system with the brightest future is bazel [...] >> >> No. Just, *no*. >> >> Persistent build server? Java? No, thanks. > > This is an option, you can keep it in a preference file, or you can > use it as a command line switch to not use this. ...and how many naïve users that "just want to build Qt" are going to know about that? > As for java in the loop - this is a a build system, how much does it > matter with what it is written in if the implementation is good? ...because Java is an *enormous* added dependency for something that *ought* to be light-weight. >> Maybe it's gotten better, but last I knew, bazel had no notion of >> "installing" software, which is just a non-starter. It's also heavily >> optimized for Google's internal usage, and (partly as a result) >> basically does not play at all nicely with software that's intended to >> exist in an open source, package-managed ecosystem. > > The convention is that projects using it embrace that and don't care > about the most system packages if they can get away with it. Which is *exactly backwards* from what an open source package should be doing (but typical of *proprietary* software). In fact, it's the very antithesis of (L)GPL. Bazel encourages practices that are *bad* for software that wants to play nicely in an open source ecosystem. >> On a related note, "hermetic builds" is pretty ironic. Your *build* >> might be hermetic, but bazel itself is *far* from... it's very reliant >> on putting all its garbage in "magic locations" in your home directory, >> unlike most build tools that only need to write to your build directory. >> Again, *not* friendly for anyone that needs to build Qt as an external >> dependency. > > Actually that's just a default location - the output location you're > talking about is the outputRoot/output_base setting: > https://docs.bazel.build/versions/master/output_directories.html Again, stuff that users that want it to Just Work aren't going to know about. And/or that consumers of Qt are going to have to (know to) muck with. With other build systems, this isn't an issue *in the first place*. >>> -Ability to build external libraries from source >> >> Yeah... no. Building third party libraries yourself is *evil*. And a >> great way to piss off package maintainers. No open source project should >> *EVER* rely on, or preferably even use by default, this ability. > > It is not evil in any way. Every disto, ever, disagrees. > Bazel doesn't deal with system packages in a first class way. Right. And this is a big problem for an open source package. > -Analysis tools for the dependencies, like graphviz, but also memory > usage and timing info. A legitimate profiler, have a look: > https://docs.bazel.build/versions/master/skylark/performance.html > https://www.kchodorow.com/blog/2015/09/18/build-y-u-go-slow/ > (admittedly few online examples of this output and this is looks > different now IIRC) > -Does a good job of controlling verbosity while keeping the user > informed on the running targets being processed concurrently while > giving a quick way to hop out, go serial or show commands executed > -Workable, like cmake workable, visual studio generator, and xcode outputs. > -clion has a plugin good direct plugin for it, though more will follow > and they tried to make it easy for IDEs to incorporate ( > https://blog.bazel.build/2016/06/10/ide-support.html we can agree it'd > be create if more build systems did this, right? > https://docs.bazel.build/versions/master/ide.html for fuller list ) Pretty much all of which you *also* have with CMake/ninja... -- Matthew From ville.voutilainen at gmail.com Wed Aug 1 16:40:10 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Wed, 1 Aug 2018 17:40:10 +0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: Message-ID: On 1 August 2018 at 11:24, Jason Newton wrote: >> And... seriously, *Java*?! Talk about bloat-ware... As dependencies for >> *a build tool* go, that's pretty insane. Especially if you're not >> planning to use it to build Java code. > > As I said, ~300-400 megabytes for a JRE (~90MiB DL), in particular > openjdk , prospectively in a development environment where you've got > devel headers and packages installed. The cost of the dependency is > neither bloat nor unbounded, it really is just that size on a machine > that's prepared to build software in 2018. Please explain what issue > this presents. The prospect of having to install a JRE to build Qt or eventually Qt applications solicits a fairly loud "I think I'll pass" from me. I don't use java for anything. Having it around for a supposedly simple and easy-to-adopt build system is a cost that I am not eager to pay. Do we expect to package a JRE with Qt? Do we expect a JRE to be a package dependency of Qt for distro vendors? From Luca.Beldi at twentyfouram.com Wed Aug 1 18:17:39 2018 From: Luca.Beldi at twentyfouram.com (Luca Beldi) Date: Wed, 1 Aug 2018 16:17:39 +0000 Subject: [Development] QAbstractItemModel::setItemData behaviour Message-ID: <641B65E58A04934CA96AFBC7BD48036E19433FA6@joi-exm03.justoneinbox.com> Hi everyone, While trying to submit a patch to fix QStringListModel::setItemData https://codereview.qt-project.org/235730 we opened a much larger discussion on QAbstractItemModel, that expanded on the forum https://forum.qt.io/topic/93207/qabstractitemmodel-setitemdata-partial-success but that I ultimately would like your opinion on: At the moment, QAbstractItemModel::setItemData calls setData for each role until the first failure and returns false if that happens. This opens up 2 issues: * QAbstractItemModel::setItemData returns false even when some but not all data was actually set without rolling back the changes * QAbstractItemModel::setItemData depends on the ordering of the roles For the second point, an example that illustrates the problem is (QStringListModel::setItemData just uses the base class implementation): QStringListModel::setItemData({{Qt::DisplayRole,QVariant("test")},{ Qt::DecorationRole,QVariant(QIcon())}) will return false but actually set the string to "test" QStringListModel::setItemData({{Qt::EditRole,QVariant("test")},{ Qt::DecorationRole,QVariant(QIcon())}) will return false and do nothing on the model My proposal is: * Remove the ordering-dependency QAbstractItemModel::setItemData (i.e. sets all the roles it can and returns false if any of them failed) * Make setItemData in subclasses of QAbstractItemModel behave transaction-like (i.e. try to set all the roles, if any fails rollback the other changes and return false) This however is technically a change of behaviour so I would like people way smarter than me to agree on the way forward. Thanks, Regards, Luca Beldi (aka VRonin) -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Aug 1 18:37:13 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 1 Aug 2018 09:37:13 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: Message-ID: <3064669.B08pFmf73C@tjmaciei-mobl1> On Wednesday, 1 August 2018 02:01:40 PDT Edward Welbourne wrote: > This is easy to do in any build system that supports out-of-source > (a.k.a. "shadow") builds - notably including the existing qmake-based > builds for Qt. I never want to do an in-source build of anything. And not just that. Building out-of-source is an absolute requirement. With one set of Qt sources, I build: - debug - release - clang release - icc release - i386 release namespace - MSVC 2017 (source dir is mounted read-only in the VM) Plus discontinued (used to build, haven't in over 2 years): - ARM 32-bit - MIPS 32-bit - static Ditto on the Windows machine, where the same set up, I build: - MSVC 2017 64-bit - MSVC 2015 64-bit - MSVC 2013 64-bit (will stop) - ICC 18 MSVC 2017 64-bit (configure only) - ICC 18 MSVC 2015 64-bit (only qtbase) And on the Mac, the same sources builds both frameworks and no-frameworks, though I think I haven't built the latter in several years (unlike the Mac and Windows laptops, the Mac machine is from 2012, so it has old stuff). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Aug 1 18:41:54 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 1 Aug 2018 09:41:54 -0700 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: <0B557CE4-0EA0-4F80-9030-510F8A02868F@qt.io> References: <0B557CE4-0EA0-4F80-9030-510F8A02868F@qt.io> Message-ID: <5519405.hrhqRWN74R@tjmaciei-mobl1> On Wednesday, 1 August 2018 06:48:40 PDT Tor Arne Vestbø wrote: > > On 1 Aug 2018, at 15:45, Kai Koehne wrote: > > > > Alright, so it seems we have to prefix the symbols we can't hide by static > > or anonymous namespaces ... > > For logging categories, I'd like to start using 'qlc' as prefix. See also > > change https://codereview.qt-project.org/#/c/235631/ for qtbase. > > Namespaces doesn’t work for that? Namespaces do. Unnamed namespaces don't (used across multiple files). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Aug 1 18:44:07 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 1 Aug 2018 09:44:07 -0700 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: <6186155.Plj3Ov170P@tjmaciei-mobl1> References: <6186155.Plj3Ov170P@tjmaciei-mobl1> Message-ID: <4028501.icTCLCZ1VQ@tjmaciei-mobl1> On Tuesday, 31 July 2018 07:52:37 PDT Thiago Macieira wrote: > Well, it could be much worse. There are a couple of low-hanging fruits > there that we can easily fix. I'll take a look later today on those > applying to QtCore. Done almost all for qtbase, from Kai's listing: https://codereview.qt-project.org/235707 https://codereview.qt-project.org/235708 https://codereview.qt-project.org/235709 https://codereview.qt-project.org/235710 https://codereview.qt-project.org/235711 The only one I couldn't easily fix were the SHA{224,256,384,512} symbols from qcryptographichash.cpp. It's doable but I might have to suppress some warnings. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From bogdan.vatra at kdab.com Wed Aug 1 20:58:02 2018 From: bogdan.vatra at kdab.com (BogDan Vatra) Date: Wed, 01 Aug 2018 21:58:02 +0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <3064669.B08pFmf73C@tjmaciei-mobl1> References: <3064669.B08pFmf73C@tjmaciei-mobl1> Message-ID: Hi, Did you knew that qbs can build all but windows targets at once from your Linux machine? Using mingw you can cross compile Qt for windows, but you probably want to run tests and to check if the code compiles with msvc. This feature might not seem pretty useful for linux, but is very useful for Android where we can bundle multiple platforms in the same package. Cheers, BogDan. On August 1, 2018 7:37:13 PM GMT+03:00, Thiago Macieira wrote: >On Wednesday, 1 August 2018 02:01:40 PDT Edward Welbourne wrote: >> This is easy to do in any build system that supports out-of-source >> (a.k.a. "shadow") builds - notably including the existing qmake-based >> builds for Qt. I never want to do an in-source build of anything. > >And not just that. Building out-of-source is an absolute requirement. > >With one set of Qt sources, I build: > - debug > - release > - clang release > - icc release > - i386 release namespace > - MSVC 2017 (source dir is mounted read-only in the VM) > >Plus discontinued (used to build, haven't in over 2 years): > - ARM 32-bit > - MIPS 32-bit > - static > >Ditto on the Windows machine, where the same set up, I build: > - MSVC 2017 64-bit > - MSVC 2015 64-bit > - MSVC 2013 64-bit (will stop) > - ICC 18 MSVC 2017 64-bit (configure only) > - ICC 18 MSVC 2015 64-bit (only qtbase) > >And on the Mac, the same sources builds both frameworks and >no-frameworks, >though I think I haven't built the latter in several years (unlike the >Mac and >Windows laptops, the Mac machine is from 2012, so it has old stuff). > >-- >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 my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Aug 1 21:27:03 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 1 Aug 2018 12:27:03 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <3064669.B08pFmf73C@tjmaciei-mobl1> Message-ID: <31293315.YJnyDxB6C7@tjmaciei-mobl1> On Wednesday, 1 August 2018 11:58:02 PDT BogDan Vatra via Development wrote: > Hi, > > Did you knew that qbs can build all but windows targets at once from your > Linux machine? That's not news. qmake can do that, provided you have the toolchains. You could compile for Mac and MSVC too, if you had them (for MSVC, via Wine, like godbolt.org). > Using mingw you can cross compile Qt for windows, but you > probably want to run tests and to check if the code compiles with msvc. > This feature might not seem pretty useful for linux, but is very useful for > Android where we can bundle multiple platforms in the same package. Agreed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From bogdan.vatra at kdab.com Wed Aug 1 21:46:04 2018 From: bogdan.vatra at kdab.com (BogDan Vatra) Date: Wed, 01 Aug 2018 22:46:04 +0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <31293315.YJnyDxB6C7@tjmaciei-mobl1> References: <3064669.B08pFmf73C@tjmaciei-mobl1> <31293315.YJnyDxB6C7@tjmaciei-mobl1> Message-ID: Hi, qmake can't compile them all *at once* e.g. $ qmake && make will compile only one target at the time not all. AFAIK QBS and iirc gn too, are the only few that have this cool feature. Cheers, BogDan. On August 1, 2018 10:27:03 PM GMT+03:00, Thiago Macieira wrote: >On Wednesday, 1 August 2018 11:58:02 PDT BogDan Vatra via Development >wrote: >> Hi, >> >> Did you knew that qbs can build all but windows targets at once >from your >> Linux machine? > >That's not news. qmake can do that, provided you have the toolchains. >You >could compile for Mac and MSVC too, if you had them (for MSVC, via >Wine, like >godbolt.org). > >> Using mingw you can cross compile Qt for windows, but you >> probably want to run tests and to check if the code compiles with >msvc. >> This feature might not seem pretty useful for linux, but is very >useful for >> Android where we can bundle multiple platforms in the same package. > >Agreed. > >-- >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 my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From iamsergio at gmail.com Wed Aug 1 22:14:32 2018 From: iamsergio at gmail.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Wed, 1 Aug 2018 21:14:32 +0100 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <4853329.uIsbQuBGgb@tjmaciei-mobl1> References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> Message-ID: On Sat, Jul 21, 2018 at 3:35 AM, Thiago Macieira wrote: > Hello > > Having spent far too much time trying to figure out why crappy buildsystems > cause failures in distros (like TensorFlow or libvpx - see > https://plus.google.com/+ThiagoMacieira/posts/DqTKdRGfuwR ), I'd like to make > sure this doesn't happen to Qt 6. For that, I'd like to add the following > extra requirements to the buildsystem we choose to use. This is in addition to > the functionality requirements. > > These apply to the buildsystem at the time of Qt's the switch to it. Will the switch coincide with 6.0 ? If yes, does it have to or could the switch happen at Qt > 6.0.0 whenever we have a *good* solution ? Regards, Sergio Martins From iamsergio at gmail.com Wed Aug 1 22:17:28 2018 From: iamsergio at gmail.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Wed, 1 Aug 2018 21:17:28 +0100 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <3064669.B08pFmf73C@tjmaciei-mobl1> <31293315.YJnyDxB6C7@tjmaciei-mobl1> Message-ID: On Wed, Aug 1, 2018 at 8:46 PM, BogDan Vatra via Development wrote: > Hi, > > qmake can't compile them all *at once* e.g. $ qmake && make will compile > only one target at the time not all. > > AFAIK QBS and iirc gn too, are the only few that have this cool feature. And probably do a single moc and uic pass if you want ? The rules system is pretty flexible. Regards, Sergio Martins > > On August 1, 2018 10:27:03 PM GMT+03:00, Thiago Macieira > wrote: >> >> On Wednesday, 1 August 2018 11:58:02 PDT BogDan Vatra via Development >> wrote: >>> >>> Hi, >>> >>> Did you knew that qbs can build all but windows targets at once from >>> your >>> Linux machine? >> >> >> That's not news. qmake can do that, provided you have the toolchains. You >> could compile for Mac and MSVC too, if you had them (for MSVC, via Wine, >> like >> godbolt.org). >> >>> Using mingw you can cross compile Qt for windows, but you >>> probably want to run tests and to check if the code compiles with msvc. >>> This feature might not seem pretty useful for linux, but is very useful >>> for >>> Android where we can bundle multiple platforms in the same package. >> >> >> Agreed. > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From apoenitz at t-online.de Wed Aug 1 10:50:31 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Wed, 1 Aug 2018 10:50:31 +0200 Subject: [Development] gsl::owner (Was: Setters: Clarifying the ownership) In-Reply-To: References: <3843684.v7fED68053@tjmaciei-mobl1> Message-ID: <20180801085031.GA15377@klara.mpi.htwm.de> On Tue, Jul 31, 2018 at 02:51:41PM +0200, Giuseppe D'Angelo via Development wrote: > Hi, > > On 31/07/18 13:11, Sérgio Martins via Development wrote: > > I would recommend however that our docs show T* instead of gsl::owner > > and continue to include "Takes ownership of foo" in the text. > > While I believe in self-documenting signatures I think it's too much > > noise and hurts readability, and most devs never heard of gsl. > > > > Should be just an aid for tooling IMO. > > I agree with the rest of your email, but I kind of disagree with this > particular point, for different reasons: > > > * Because we need to educate our users that there's more C++ than Qt out > there, and the Core Guidelines and the GSL are a fundamental part of > knowledge for a C++ developer. Pluralis Majestatis? "Educating [o]ur users" etc are not exactly unworthy goals, but when it comes to using that as reason *against* traditional Qt principles like "consistent API", "ease of use" I don't think this "[w]e" covers everybody here. Certainly not "Us". > [...] > * Leaving gsl::owner in the signature of a function documentation can help > clarify situations where the textual documentation does not say anything > about the ownership. And that can and should be solved be adding the corresponding stanza to the docs, not by doc uglification. In case they were really missing, and this is not just speculation. > However, from a practical point of view, unless someone adds gsl::owner > _everywhere_ to Qt, we can't report it in the docs, as they would otherwise > be inconsistent :-( "We" appreciate that You consider inconsistency a problem. 1/2 ;-) Andre' From thiago.macieira at intel.com Thu Aug 2 00:27:40 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 1 Aug 2018 15:27:40 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> Message-ID: <1923358.GkRdrsm5FE@tjmaciei-mobl1> On Wednesday, 1 August 2018 13:14:32 PDT Sérgio Martins wrote: > On Sat, Jul 21, 2018 at 3:35 AM, Thiago Macieira > > wrote: > > Hello > > > > Having spent far too much time trying to figure out why crappy > > buildsystems > > cause failures in distros (like TensorFlow or libvpx - see > > https://plus.google.com/+ThiagoMacieira/posts/DqTKdRGfuwR ), I'd like to > > make sure this doesn't happen to Qt 6. For that, I'd like to add the > > following extra requirements to the buildsystem we choose to use. This is > > in addition to the functionality requirements. > > > > These apply to the buildsystem at the time of Qt's the switch to it. > > Will the switch coincide with 6.0 ? If yes, does it have to or could > the switch happen at Qt > 6.0.0 whenever we have a *good* solution ? The plan was to switch for 6.0. It could happen later if we don't get consensus and is too disruptive earlier, though. But 6.0 is the perfect time, as we drop old platforms and can reliably require people to upgrade to new things. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Aug 2 00:31:10 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 1 Aug 2018 15:31:10 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <31293315.YJnyDxB6C7@tjmaciei-mobl1> Message-ID: <1543826.WRIXLhRFPs@tjmaciei-mobl1> On Wednesday, 1 August 2018 12:46:04 PDT BogDan Vatra via Development wrote: > Hi, > > qmake can't compile them all *at once* e.g. $ qmake && make will compile > only one target at the time not all. > > AFAIK QBS and iirc gn too, are the only few that have this cool feature. Now that is nice, as we know that the moc, uic, rcc outputs are platform- independent. That should help reduce the build times on Windows for debug-and- release builds, as running moc is a significant portion of the build time. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nevion at gmail.com Thu Aug 2 08:08:13 2018 From: nevion at gmail.com (Jason Newton) Date: Wed, 1 Aug 2018 23:08:13 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <1543826.WRIXLhRFPs@tjmaciei-mobl1> References: <31293315.YJnyDxB6C7@tjmaciei-mobl1> <1543826.WRIXLhRFPs@tjmaciei-mobl1> Message-ID: Bazel's caching mechanism would also optimize away regeneration of generated outputs (via genrules) across the different toolchains, provided the tools/scripts and important environmental variables/files do not change (which would hash to different keys). Further you could run a disk local cache or a network one - the network one letting say spun up VMs to take advantage of out of VM results, or windows/macos. https://docs.bazel.build/versions/master/remote-caching.html, or CI/build servers turn around builds very quickly. Deals with branch changes and build config changes directly. As far as I know the disk local is concurrent build safe, while the http one is obviously safe - though usually bazel will utilize your machine (doing useful work, not something like java garbage collections) such that only one bazel build at a time makes sense for, but you can do multiple too. I'm not aware of a better solution to cached build products than bazel's. While there is a pathway for generating visual studio project files, you can also use cl.exe (with or without MSVC installed), the state of direct cl.exe support for most build systems hasn't always been great... Also since it is on intelij products, that covers the official android sdk since it uses IDEA for a few years now, though in this case it understands the build system directly rather than intermediate project files. Support of android is first class: https://docs.bazel.build/versions/master/be/android.html and support for to maven et al package services for jar files. On downloaded assets, the builtin downloader is parallel and generally smarter than single tasking wget, as such it tends to outperform cmake's downloading mechanisms (I believe these are only done serially?) by quite a bit for pulling down online resources of any type, provided your project explicitly used that capability. >> -Analysis tools for the dependencies, like graphviz, but also memory >> usage and timing info. A legitimate profiler, have a look: >> https://docs.bazel.build/versions/master/skylark/performance.html >> https://www.kchodorow.com/blog/2015/09/18/build-y-u-go-slow/ >> (admittedly few online examples of this output and this is looks >> different now IIRC) >> -Does a good job of controlling verbosity while keeping the user >> informed on the running targets being processed concurrently while >> giving a quick way to hop out, go serial or show commands executed >> -Workable, like cmake workable, visual studio generator, and xcode outputs. >> -clion has a plugin good direct plugin for it, though more will follow >> and they tried to make it easy for IDEs to incorporate ( >> https://blog.bazel.build/2016/06/10/ide-support.html we can agree it'd >> be create if more build systems did this, right? >> https://docs.bazel.build/versions/master/ide.html for fuller list ) >Pretty much all of which you *also* have with CMake/ninja... That's why I listed this section, though the analysis tools are far better on bazel's outputs than cmakes's you get actual profiler analysis on the build process with bazel, not just a DAG. Not many build systems have pathways on visual studio or xcode, in particular besides cmake. Bazel is afaik the only build system that tried to make it easy to integrate it into an IDE interactively, short of perhaps qbs (qmake...?). -Jason On Wed, Aug 1, 2018 at 3:31 PM Thiago Macieira wrote: > > On Wednesday, 1 August 2018 12:46:04 PDT BogDan Vatra via Development wrote: > > Hi, > > > > qmake can't compile them all *at once* e.g. $ qmake && make will compile > > only one target at the time not all. > > > > AFAIK QBS and iirc gn too, are the only few that have this cool feature. > > Now that is nice, as we know that the moc, uic, rcc outputs are platform- > independent. That should help reduce the build times on Windows for debug-and- > release builds, as running moc is a significant portion of the build time. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From bogdan at kdab.com Thu Aug 2 08:13:13 2018 From: bogdan at kdab.com (BogDan Vatra) Date: Thu, 02 Aug 2018 09:13:13 +0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <1543826.WRIXLhRFPs@tjmaciei-mobl1> References: <1543826.WRIXLhRFPs@tjmaciei-mobl1> Message-ID: <10953066.bVjT5czqOF@debian> Hi, În ziua de joi, 2 august 2018, la 01:31:10 EEST, Thiago Macieira a scris: > On Wednesday, 1 August 2018 12:46:04 PDT BogDan Vatra via Development wrote: > > Hi, > > > > qmake can't compile them all *at once* e.g. $ qmake && make will compile > > only one target at the time not all. > > > > AFAIK QBS and iirc gn too, are the only few that have this cool feature. > > Now that is nice, as we know that the moc, uic, rcc outputs are platform- > independent. That should help reduce the build times on Windows for > debug-and- release builds, as running moc is a significant portion of the > build time. It will be nice if this feature is mandatory for Qt 6, so let's add it to your requirements list. BTW, not only moc, uic & rcc are platform-independent, but also the headers (except a few that are generated by configure script which can be moved to platform libs dir). What will be cool really is to unify headers, examples & demos for the Qt SDKs, this way we'll save a lot of space. Cheers, BogDan. From Simon.Hausmann at qt.io Thu Aug 2 08:18:51 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 2 Aug 2018 06:18:51 +0000 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <1543826.WRIXLhRFPs@tjmaciei-mobl1> References: <31293315.YJnyDxB6C7@tjmaciei-mobl1> <1543826.WRIXLhRFPs@tjmaciei-mobl1> Message-ID: <7086F215-D2F2-46D3-BF2F-D38072104EF2@qt.io> Hi, Given that the output of the moc changes depending on what platform and compiler dependent pre-processor macros are supplied, I would say that the output is not cross-platform. Simon >> On 2. Aug 2018, at 00:31, Thiago Macieira wrote: >> >> On Wednesday, 1 August 2018 12:46:04 PDT BogDan Vatra via Development wrote: >> Hi, >> >> qmake can't compile them all *at once* e.g. $ qmake && make will compile >> only one target at the time not all. >> >> AFAIK QBS and iirc gn too, are the only few that have this cool feature. > > Now that is nice, as we know that the moc, uic, rcc outputs are platform- > independent. That should help reduce the build times on Windows for debug-and- > release builds, as running moc is a significant portion of the build time. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From lars.knoll at qt.io Thu Aug 2 08:18:50 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 2 Aug 2018 06:18:50 +0000 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <1923358.GkRdrsm5FE@tjmaciei-mobl1> References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <1923358.GkRdrsm5FE@tjmaciei-mobl1> Message-ID: <77689D7D-2D9E-4D2A-B2E0-DCA95A6A0F4D@qt.io> On 2 Aug 2018, at 00:27, Thiago Macieira > wrote: On Wednesday, 1 August 2018 13:14:32 PDT Sérgio Martins wrote: On Sat, Jul 21, 2018 at 3:35 AM, Thiago Macieira > wrote: Hello Having spent far too much time trying to figure out why crappy buildsystems cause failures in distros (like TensorFlow or libvpx - see https://plus.google.com/+ThiagoMacieira/posts/DqTKdRGfuwR ), I'd like to make sure this doesn't happen to Qt 6. For that, I'd like to add the following extra requirements to the buildsystem we choose to use. This is in addition to the functionality requirements. These apply to the buildsystem at the time of Qt's the switch to it. Will the switch coincide with 6.0 ? If yes, does it have to or could the switch happen at Qt > 6.0.0 whenever we have a *good* solution ? The plan was to switch for 6.0. It could happen later if we don't get consensus and is too disruptive earlier, though. But 6.0 is the perfect time, as we drop old platforms and can reliably require people to upgrade to new things. Yes, 6.0 is the time I’d like to move away from qmake for building Qt. It’s a time when we do larger changes anyway, so this fits in. I don’t really see us doing such a switch for a minor release anymore, because I think such a change is difficult to make happen without compromising the 6 months release cycle. Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From joerg.bornemann at qt.io Thu Aug 2 08:33:10 2018 From: joerg.bornemann at qt.io (Joerg Bornemann) Date: Thu, 2 Aug 2018 08:33:10 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <7086F215-D2F2-46D3-BF2F-D38072104EF2@qt.io> References: <31293315.YJnyDxB6C7@tjmaciei-mobl1> <1543826.WRIXLhRFPs@tjmaciei-mobl1> <7086F215-D2F2-46D3-BF2F-D38072104EF2@qt.io> Message-ID: <9b2440e5-28af-cbff-e3d7-5c7fe5bbca8a@qt.io> On 08/02/2018 08:18 AM, Simon Hausmann wrote: > Given that the output of the moc changes depending on what platform and compiler dependent pre-processor macros are supplied, I would say that the output is not cross-platform. ...which is why qbs does *not* have such a feature. moc_XXX.cpp and XXX.moc files are generated per build configuration. The output is not shared. Joerg From bogdan at kdab.com Thu Aug 2 08:38:09 2018 From: bogdan at kdab.com (BogDan Vatra) Date: Thu, 02 Aug 2018 09:38:09 +0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <9b2440e5-28af-cbff-e3d7-5c7fe5bbca8a@qt.io> References: <7086F215-D2F2-46D3-BF2F-D38072104EF2@qt.io> <9b2440e5-28af-cbff-e3d7-5c7fe5bbca8a@qt.io> Message-ID: <1761500.m510sxNcWZ@debian> Hi În ziua de joi, 2 august 2018, la 09:33:10 EEST, Joerg Bornemann a scris: > On 08/02/2018 08:18 AM, Simon Hausmann wrote: > > Given that the output of the moc changes depending on what platform and > > compiler dependent pre-processor macros are supplied, I would say that > > the output is not cross-platform. > ...which is why qbs does *not* have such a feature. > moc_XXX.cpp and XXX.moc files are generated per build configuration. The > output is not shared. > Right, moc files are not cross-platform but I think rcc & uic files are. BogDan. From lars.knoll at qt.io Thu Aug 2 08:40:40 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 2 Aug 2018 06:40:40 +0000 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <1761500.m510sxNcWZ@debian> References: <7086F215-D2F2-46D3-BF2F-D38072104EF2@qt.io> <9b2440e5-28af-cbff-e3d7-5c7fe5bbca8a@qt.io> <1761500.m510sxNcWZ@debian> Message-ID: <4B390AE3-5EE2-42E7-AC23-873C71F3ECC2@qt.io> > On 2 Aug 2018, at 08:38, BogDan Vatra via Development wrote: > > Hi > În ziua de joi, 2 august 2018, la 09:33:10 EEST, Joerg Bornemann a scris: >> On 08/02/2018 08:18 AM, Simon Hausmann wrote: >>> Given that the output of the moc changes depending on what platform and >>> compiler dependent pre-processor macros are supplied, I would say that >>> the output is not cross-platform. >> ...which is why qbs does *not* have such a feature. >> moc_XXX.cpp and XXX.moc files are generated per build configuration. The >> output is not shared. >> > > Right, moc files are not cross-platform but I think rcc & uic files are. They are still build artefacts, and trying to add logic to figure out which of those can be shared between different targets and which can’t sounds like a nice way to introduce complexity that will bite us at some point. Cheers, Lars From lars.knoll at qt.io Thu Aug 2 08:49:48 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 2 Aug 2018 06:49:48 +0000 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <10953066.bVjT5czqOF@debian> References: <1543826.WRIXLhRFPs@tjmaciei-mobl1> <10953066.bVjT5czqOF@debian> Message-ID: <52B12B55-9DDF-42C4-AD34-D167B9B37380@qt.io> > On 2 Aug 2018, at 08:13, BogDan Vatra via Development wrote: > […] > It will be nice if this feature is mandatory for Qt 6, so let's add it to > your requirements list. Let’s be careful not to add too many requirements upfront or we’ll never get anywhere. For me the hard requirements are: 1. Better maintainability than with qmake. I don’t want things to become more complicated with the new system. 2. Open source and cross-platform. A given. 3. Easy to install, few external dependencies. Can be compiled form source, no circular dependencies (1b and 1c from Thiago, should also solve 1a implicitly) 4. Usable for packagers. But let’s make sure we’re not only looking at Linux distributions, but also macOS (homebrew), Windows (e.g. vcpkg) and the needs we have for our own binary packages. 5. Simple cross-compilation support. What we don’t need is the mixed mode we currently have where we build host and target binaries at the same time. For Qt 6, I’d like to fully separate that, so that a cross build will use the host tools from a previous host build. 6. Decently documented, and there are places where you can get help 7. Good integration with the world around us. That implies that the build system needs to spit out at the minimum the required files so that our users can seamlessly use both qmake and cmake for their own projects. It should also handle things the other way round so that we can depend on other projects that are build using other build systems. Cheers, Lars From bogdan at kdab.com Thu Aug 2 09:52:19 2018 From: bogdan at kdab.com (BogDan Vatra) Date: Thu, 02 Aug 2018 10:52:19 +0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <52B12B55-9DDF-42C4-AD34-D167B9B37380@qt.io> References: <10953066.bVjT5czqOF@debian> <52B12B55-9DDF-42C4-AD34-D167B9B37380@qt.io> Message-ID: <1561811.bTObn39Srd@debian> În ziua de joi, 2 august 2018, la 09:49:48 EEST, Lars Knoll a scris: > > On 2 Aug 2018, at 08:13, BogDan Vatra via Development > > wrote: […] > > > > It will be nice if this feature is mandatory for Qt 6, so let's add it to > > > > > > your requirements list. > > > > Let’s be careful not to add too many requirements upfront or we’ll never get > anywhere. [...] Well, if we want to have first class Qt on Android support, this feature is a must. Now, if we can use it also for other platforms that's a bonus. Cheers, BogDan. From lars.knoll at qt.io Thu Aug 2 10:02:30 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 2 Aug 2018 08:02:30 +0000 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <1561811.bTObn39Srd@debian> References: <10953066.bVjT5czqOF@debian> <52B12B55-9DDF-42C4-AD34-D167B9B37380@qt.io> <1561811.bTObn39Srd@debian> Message-ID: > On 2 Aug 2018, at 09:52, BogDan Vatra wrote: > > În ziua de joi, 2 august 2018, la 09:49:48 EEST, Lars Knoll a scris: >>> On 2 Aug 2018, at 08:13, BogDan Vatra via Development >>> wrote: > […] >>> >>> It will be nice if this feature is mandatory for Qt 6, so let's add it to >>> >>> >>> your requirements list. >> >> >> >> Let’s be careful not to add too many requirements upfront or we’ll never get >> anywhere. > > [...] > > Well, if we want to have first class Qt on Android support, this feature is a > must. Now, if we can use it also for other platforms that's a bonus. Which feature exactly? Creating binaries for multiple targets in on compile run? Or also only calling rcc once? The first one I can see, the second one would be just an optimisation when creating multiple binaries. Cheers, Lars From bogdan at kdab.com Thu Aug 2 10:05:21 2018 From: bogdan at kdab.com (BogDan Vatra) Date: Thu, 02 Aug 2018 11:05:21 +0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <1561811.bTObn39Srd@debian> Message-ID: <1733786.xDlINr4Fm0@debian> În ziua de joi, 2 august 2018, la 11:02:30 EEST, Lars Knoll a scris: > > On 2 Aug 2018, at 09:52, BogDan Vatra wrote: > > > > În ziua de joi, 2 august 2018, la 09:49:48 EEST, Lars Knoll a scris: > > > >>> On 2 Aug 2018, at 08:13, BogDan Vatra via Development > >>> wrote: > > > > […] > > > >>> > >>> It will be nice if this feature is mandatory for Qt 6, so let's add it > >>> to > >>> > >>> > >>> your requirements list. > >> > >> > >> > >> > >> Let’s be careful not to add too many requirements upfront or we’ll never > >> get anywhere. > > > > > > [...] > > > > Well, if we want to have first class Qt on Android support, this feature > > is a must. Now, if we can use it also for other platforms that's a > > bonus. > > Which feature exactly? Creating binaries for multiple targets in on compile > run? Or also only calling rcc once? > The first one I can see, the second one would be just an optimisation when > creating multiple binaries. First one. From joerg.bornemann at qt.io Thu Aug 2 10:56:44 2018 From: joerg.bornemann at qt.io (Joerg Bornemann) Date: Thu, 2 Aug 2018 10:56:44 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <1733786.xDlINr4Fm0@debian> References: <1561811.bTObn39Srd@debian> <1733786.xDlINr4Fm0@debian> Message-ID: On 08/02/2018 10:05 AM, BogDan Vatra via Development wrote: >>> Well, if we want to have first class Qt on Android support, this feature >>> is a > must. Now, if we can use it also for other platforms that's a >>> bonus. >> >> Which feature exactly? Creating binaries for multiple targets in on compile >> run? Or also only calling rcc once? > >> The first one I can see, the second one would be just an optimisation when >> creating multiple binaries. > > First one. We're now talking about three different things. 1. Build multiple configurations in one go E.g. I want to build my project on Linux for Linux x86_64 and cross-compile at the same time with MinGW. The project knows nothing about this. This is supported by qbs. [1] 2. Build for multiple platforms in one go E.g. I want to cross-compile Qt with MinGW on Linux. Host tools (moc, rcc, qlalr, qwhatnot) which are built for Linux x86_64. Libs are cross-build for Windows in both, release and debug versions. The project knows about host tools and "multiplexing". Other famous use cases are: building for Android and iOS. This is supported by qbs. [2] 3. Build something via 1 or 2 and share equal generated artifacts We're calling rcc once, because we somehow know that the output will be the same for all variants of the build products. This is not supported by qbs at the moment. [3] Cheers, Joerg [1] http://doc.qt.io/qbs/building-applications.html [2] http://doc.qt.io/qbs/multiplexing.html [3] https://memegenerator.net/img/instances/61770863/im-sorry-do-u-still-love-me-.jpg From oswald.buddenhagen at qt.io Thu Aug 2 14:34:35 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 2 Aug 2018 14:34:35 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: Message-ID: <20180802123435.GE28072@troll08> On Wed, Aug 01, 2018 at 09:01:40AM +0000, Edward Welbourne wrote: > Jason Newton (1 August 2018 10:24) > > One of the things I like about the way bazel keeps this is I can jump > > back and forth between an optimized build and a full debug build (for > > example) - they don't erase eachother > > This is easy to do in any build system that supports out-of-source > (a.k.a. "shadow") builds - notably including the existing qmake-based > builds for Qt. I never want to do an in-source build of anything. > indeed, that's why the example was badly chosen. > > and you can only achieve that jumping capability, being cheap, if you > > add a file-level layer of indirection. > > Not sure what you're claiming here, or what system you're claiming lacks > it. If you've got both optimised and debug builds, you're going to have > both sets of files *somewhere* (whether jumbled up in one directory or > kept separate in two out-of-source build trees). > but having fully separate trees for only mildly different builds is wasteful. a smart developer addresses that by having ccache in the background, but the solution is more efficient and comprehensive when the build tool itself implements it. hence https://bugreports.qt.io/browse/QBS-57 From oswald.buddenhagen at qt.io Thu Aug 2 15:03:04 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 2 Aug 2018 15:03:04 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <4a6fc377-1cb6-e5a7-1921-d49b17f9aa05@gmail.com> References: <4a6fc377-1cb6-e5a7-1921-d49b17f9aa05@gmail.com> Message-ID: <20180802130304.GF28072@troll08> On Wed, Aug 01, 2018 at 10:33:43AM -0400, Matthew Woehlke wrote: > On 2018-08-01 04:24, Jason Newton wrote: > > On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke wrote: > >> On 2018-07-21 19:52, Jason Newton wrote: > >>> I wanted to mention that this is on my mind alot for a few years days > >>> as a user for a plethora of libraries. My conclusion for the build > >>> system with the brightest future is bazel [...] > >> > >> No. Just, *no*. > >> > >> Persistent build server? Java? No, thanks. > > > > This is an option, you can keep it in a preference file, or you can > > use it as a command line switch to not use this. > > ...and how many naïve users that "just want to build Qt" are going to > know about that? > and why exactly would a user who doesn't care ... care? > > As for java in the loop - this is a a build system, how much does it > > matter with what it is written in if the implementation is good? > > ...because Java is an *enormous* added dependency > the actual toolchain and external dependencies play in the same league. ... which is still dwarfed by the size of a single qt debug build. > for something that *ought* to be light-weight. > says *who*? it's not that i *like* big dependencies, but there is a trade-off to be made, and bazel is *by far* the most advanced build tool on the market today when it comes to optimizing rebuilds of massive projects (esp. when you have a homogeneous IT environment in your intranet). that might not be the decisive factor when it comes to choosing a build tool for qt, but blanket statements like yours don't exactly sound like rational decision making. if the spectre of bazel scares you, make your contribution to make sure qbs makes the cut. ;) https://www.qt.io/open-positions/software-engineer-build-systems for that matter ... From perezmeyer at gmail.com Thu Aug 2 15:23:12 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Thu, 02 Aug 2018 10:23:12 -0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <20180802130304.GF28072@troll08> References: <4a6fc377-1cb6-e5a7-1921-d49b17f9aa05@gmail.com> <20180802130304.GF28072@troll08> Message-ID: <2896146.IyJcsZBgxe@tonks> El jueves, 2 de agosto de 2018 10:03:04 -03 Oswald Buddenhagen escribió: [snip] > > > As for java in the loop - this is a a build system, how much does it > > > matter with what it is written in if the implementation is good? > > > > ...because Java is an *enormous* added dependency > > the actual toolchain and external dependencies play in the same league. > ... which is still dwarfed by the size of a single qt debug build. But would be problematic when building for other archs not that powerful as "the normal ones". > > for something that *ought* to be light-weight. > > says *who*? Good point here. But if I may: largely preferred by distro maintainers. Also I don't see bazel packaged in Debian, is it in other distros? -- 1: Una computadora sirve: * Para tratar de dominar el mundo, un caso conocido de esto fue el de Skinet Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From perezmeyer at gmail.com Thu Aug 2 15:34:02 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Thu, 02 Aug 2018 10:34:02 -0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <2896146.IyJcsZBgxe@tonks> References: <20180802130304.GF28072@troll08> <2896146.IyJcsZBgxe@tonks> Message-ID: <1749546.0rqr8A8lZY@tonks> El jueves, 2 de agosto de 2018 10:23:12 -03 Lisandro Damián Nicanor Pérez Meyer escribió: > El jueves, 2 de agosto de 2018 10:03:04 -03 Oswald Buddenhagen escribió: > [snip] > > > > > As for java in the loop - this is a a build system, how much does it > > > > matter with what it is written in if the implementation is good? > > > > > > ...because Java is an *enormous* added dependency > > > > the actual toolchain and external dependencies play in the same league. > > ... which is still dwarfed by the size of a single qt debug build. > > But would be problematic when building for other archs not that powerful as > "the normal ones". > > > > for something that *ought* to be light-weight. > > > > says *who*? > > Good point here. But if I may: largely preferred by distro maintainers. > > Also I don't see bazel packaged in Debian, is it in other distros? Looking at: It will take time to get bazel in Debian. And then it will need to fulfill Thiago's 2.c points. But it still has two years to accomplish it, as qbs does. -- 14: Para acceder y navegar en internet * Debe tener conexion a Internet Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From mathias at taschenorakel.de Thu Aug 2 15:41:45 2018 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Thu, 2 Aug 2018 15:41:45 +0200 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: References: <8bae81f7-96b2-236b-942a-2458fd7d76e7@kdab.com> Message-ID: Am 31.07.2018 um 14:58 schrieb Edward Welbourne: > Giuseppe D'Angelo (31 July 2018 14:38) >> It will likely break every single application that has never used a >> namespaced build of Qt. Which is a significant percentage of all the Qt >> apps out there... > > I'm guessing you mean "... used a static build of Qt." since they're the > only ones (b) would change, if made the default. Otherwise, please > explain how namespaced builds get broken by this - if they were static > before, then this just makes them the default, so no change; if they > weren't static, this change won't affect them. > > I can believe static-built apps are common; You are talking about any single Qt application that's built for iOS. Even worse: Making statically linked Qt use a namespace by default, but dynamically linked not would seriously break Qt's "write once, build and run everywhere" promise as there suddenly would be significant differences between Qt for iOS and Qt for any other platform. To me enabling namespaces by default seems like a terrible idea. A total no-go. Ciao, Mathias From kotov.valery at gmail.com Thu Aug 2 15:44:53 2018 From: kotov.valery at gmail.com (Valery Kotov) Date: Thu, 2 Aug 2018 15:44:53 +0200 Subject: [Development] JS Engine: callAsConstructor vs. virtualCallAsConstructor Message-ID: Hello all, I have a question about recent introduction of "virtual" functions in JavaScript engine. Now objects have both virtualCallAsConstructor function and callAsConstructor functions. Unfortunately, distinction between those is a little bit unclear to me. Is virtualCallAsConstructor is actually what is called when object is created on JS side (via new call)? Shall virtuallCallAsConstructor now be used when an JS Object is needed to be created from C++ side? I'm also a little bit puzzled about signature: static ReturnedValue virtualCallAsConstructor(const FunctionObject *f, const Value *argv, int argc, const Value *); What is the last const Value*? Shall I pass args as last the last arguments? Sincerely yours, Valery Kotov -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Thu Aug 2 15:45:00 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 2 Aug 2018 13:45:00 +0000 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: References: <8bae81f7-96b2-236b-942a-2458fd7d76e7@kdab.com> , Message-ID: Hi, Before concluding that a namespaced Qt is a terrible idea, I recommend trying out the feature. It is intended to work transparently and not require any changes to the application, nothing like having to type MyNS::QString everywhere. It may be problematic with forward declarations of Qt types, but the fix for that (surrounding with QT_BEGIN/END_NAMESPACE) is entirely compatible between NS and non-NS builds and does not violate the write once goal. Simon ________________________________ From: Development on behalf of Mathias Hasselmann Sent: Thursday, August 2, 2018 3:41:45 PM To: development at qt-project.org Subject: Re: [Development] Symbol clashes with static Qt libraries Am 31.07.2018 um 14:58 schrieb Edward Welbourne: > Giuseppe D'Angelo (31 July 2018 14:38) >> It will likely break every single application that has never used a >> namespaced build of Qt. Which is a significant percentage of all the Qt >> apps out there... > > I'm guessing you mean "... used a static build of Qt." since they're the > only ones (b) would change, if made the default. Otherwise, please > explain how namespaced builds get broken by this - if they were static > before, then this just makes them the default, so no change; if they > weren't static, this change won't affect them. > > I can believe static-built apps are common; You are talking about any single Qt application that's built for iOS. Even worse: Making statically linked Qt use a namespace by default, but dynamically linked not would seriously break Qt's "write once, build and run everywhere" promise as there suddenly would be significant differences between Qt for iOS and Qt for any other platform. To me enabling namespaces by default seems like a terrible idea. A total no-go. Ciao, Mathias _______________________________________________ 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 christian.kandeler at qt.io Thu Aug 2 15:57:42 2018 From: christian.kandeler at qt.io (Christian Kandeler) Date: Thu, 2 Aug 2018 15:57:42 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <2896146.IyJcsZBgxe@tonks> References: <4a6fc377-1cb6-e5a7-1921-d49b17f9aa05@gmail.com> <20180802130304.GF28072@troll08> <2896146.IyJcsZBgxe@tonks> Message-ID: <20180802155713.7203572d@ckandeler-archlinux> On Thu, 2 Aug 2018 10:23:12 -0300 Lisandro Damián Nicanor Pérez Meyer wrote: > El jueves, 2 de agosto de 2018 10:03:04 -03 Oswald Buddenhagen escribió: > [snip] > > > > As for java in the loop - this is a a build system, how much does it > > > > matter with what it is written in if the implementation is good? > > > > > > ...because Java is an *enormous* added dependency > > > > the actual toolchain and external dependencies play in the same league. > > ... which is still dwarfed by the size of a single qt debug build. > > But would be problematic when building for other archs not that powerful as > "the normal ones". You mean *on* other archs? Because the (cross-)compiler does not care how powerful the target architecture is. Christian From annulen at yandex.ru Thu Aug 2 16:16:18 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 02 Aug 2018 17:16:18 +0300 Subject: [Development] Qt 6 buildsystem support requirements References: <4a6fc377-1cb6-e5a7-1921-d49b17f9aa05@gmail.com> <20180802130304.GF28072@troll08> <2896146.IyJcsZBgxe@tonks> <20180802155713.7203572d@ckandeler-archlinux> Message-ID: <6464261533219378@myt3-c7e5d17fe013.qloud-c.yandex.net> 02.08.2018, 16:58, "Christian Kandeler" : > On Thu, 2 Aug 2018 10:23:12 -0300 > Lisandro Damián Nicanor Pérez Meyer wrote: > >>  El jueves, 2 de agosto de 2018 10:03:04 -03 Oswald Buddenhagen escribió: >>  [snip] >>  > > > As for java in the loop - this is a a build system, how much does it >>  > > > matter with what it is written in if the implementation is good? >>  > > >>  > > ...because Java is an *enormous* added dependency >>  > >>  > the actual toolchain and external dependencies play in the same league. >>  > ... which is still dwarfed by the size of a single qt debug build. >> >>  But would be problematic when building for other archs not that powerful as >>  "the normal ones". > > You mean *on* other archs? Because the (cross-)compiler does not care how powerful the target architecture is. Unfortunately, Debian does not use cross-compilation for building packages (Here should be a photo of cluster of low-power SH4 boards which I've seen somewhere) > > Christian > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From adam.treat at qt.io Thu Aug 2 17:02:41 2018 From: adam.treat at qt.io (Adam Treat) Date: Thu, 2 Aug 2018 11:02:41 -0400 Subject: [Development] Repository request: HTTP server In-Reply-To: <7FECC0A8-3964-4372-A77E-E925854A0D9A@qt.io> References: <7FECC0A8-3964-4372-A77E-E925854A0D9A@qt.io> Message-ID: <25d8a8b6-c87b-a216-d3db-326870bed3f7@qt.io> What came of this? On 10/06/2017 07:10 AM, Fredrik de Vibe wrote: > Hi all, > > We have recently been working on a research project looking into the possibilities for creating a lightweight server component that can easily enable Qt applications to serve over HTTP. We would like to make this work public and therefore request a repository. > > This work is intended to continue as a research project, to explore alternatives and reveal areas that need work, so it should be under qt-labs. > > Name of the project: Qt HTTP Server > Responsible person: Fredrik de Vibe > Gerrit user/email: fredrik.devibe at qt.io > Desired repository name: qthttpserver > > From thiago.macieira at intel.com Thu Aug 2 17:06:02 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 2 Aug 2018 08:06:02 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <10953066.bVjT5czqOF@debian> References: <1543826.WRIXLhRFPs@tjmaciei-mobl1> <10953066.bVjT5czqOF@debian> Message-ID: <12270285.0g7gfsGHTX@tjmaciei-mobl1> On Wednesday, 1 August 2018 23:13:13 PDT BogDan Vatra via Development wrote: > > Now that is nice, as we know that the moc, uic, rcc outputs are platform- > > independent. That should help reduce the build times on Windows for > > debug-and- release builds, as running moc is a significant portion of the > > build time. > > It will be nice if this feature is mandatory for Qt 6, so let's add it to > your requirements list. No, this is "nice to have", not mandatory. A reduction in build time would be very welcome, but if we don't have it, the build still works. > BTW, not only moc, uic & rcc are platform-independent, but also the > headers (except a few that are generated by configure script which can be > moved to platform libs dir). What will be cool really is to unify headers, > examples & demos for the Qt SDKs, this way we'll save a lot of space. Sorry, I didn't get it. Can you clarify? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Aug 2 17:09:45 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 2 Aug 2018 08:09:45 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <7086F215-D2F2-46D3-BF2F-D38072104EF2@qt.io> References: <1543826.WRIXLhRFPs@tjmaciei-mobl1> <7086F215-D2F2-46D3-BF2F-D38072104EF2@qt.io> Message-ID: <4622647.GdcjZhF1eI@tjmaciei-mobl1> On Wednesday, 1 August 2018 23:18:51 PDT Simon Hausmann wrote: > Given that the output of the moc changes depending on what platform and > compiler dependent pre-processor macros are supplied, I would say that the > output is not cross-platform. True, even in debug-and-relaese they could change, as QT_NO_DEBUG changes. Someone could #ifdef on it and add properties, signals or slots based on it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Aug 2 17:11:05 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 2 Aug 2018 08:11:05 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <4B390AE3-5EE2-42E7-AC23-873C71F3ECC2@qt.io> References: <1761500.m510sxNcWZ@debian> <4B390AE3-5EE2-42E7-AC23-873C71F3ECC2@qt.io> Message-ID: <2657141.qhNECMWgOb@tjmaciei-mobl1> On Wednesday, 1 August 2018 23:40:40 PDT Lars Knoll wrote: > > Right, moc files are not cross-platform but I think rcc & uic files are. > > They are still build artefacts, and trying to add logic to figure out which > of those can be shared between different targets and which can’t sounds > like a nice way to introduce complexity that will bite us at some point. Right, and rcc is definitely not a significant portion of the build. We have usually at most one rcc run per module. UIC ones are also often limited in count, as are the other tools. moc is the only one that in my mind is "significant portion of the build" and Simon is right that we can't share its output. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mwoehlke.floss at gmail.com Thu Aug 2 18:33:40 2018 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Thu, 2 Aug 2018 12:33:40 -0400 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <20180802130304.GF28072@troll08> References: <4a6fc377-1cb6-e5a7-1921-d49b17f9aa05@gmail.com> <20180802130304.GF28072@troll08> Message-ID: <11a3a98b-a430-c7a9-acc5-423285c79013@gmail.com> On 2018-08-02 09:03, Oswald Buddenhagen wrote: > On Wed, Aug 01, 2018 at 10:33:43AM -0400, Matthew Woehlke wrote: >> On 2018-08-01 04:24, Jason Newton wrote: >>> On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke wrote: >>>> Persistent build server? Java? No, thanks. >>> >>> This is an option, you can keep it in a preference file, or you can >>> use it as a command line switch to not use this. >> >> ...and how many naïve users that "just want to build Qt" are going to >> know about that? >> > and why exactly would a user who doesn't care ... care? ...because building Qt just spawned a process that is never going to terminate, is going to sit around pointlessly monitoring their file system, and is going to potentially cause who-knows-what issues? If I want to just download and build some package (i.e. I'm not *actively developing* that software), doing so shouldn't "infect" my machine with zombie processes. When the build is done, it should be *done*. > it's not that i *like* big dependencies, but there is a trade-off to be > made, and bazel is *by far* the most advanced build tool on the market > today when it comes to optimizing rebuilds of massive projects ...which is *totally irrelevant* to everyone that is not a Qt developer. Just like software is written once and read many times, it is developed by a few and deployed by many. Optimizing for development *at the expense* of deployment strikes me as... questionable. If the penalty to deployment cost was minimal, that would be one thing, but with bazel, it isn't. -- Matthew From mwoehlke.floss at gmail.com Thu Aug 2 18:33:40 2018 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Thu, 2 Aug 2018 12:33:40 -0400 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <20180802130304.GF28072@troll08> References: <4a6fc377-1cb6-e5a7-1921-d49b17f9aa05@gmail.com> <20180802130304.GF28072@troll08> Message-ID: <11a3a98b-a430-c7a9-acc5-423285c79013@gmail.com> On 2018-08-02 09:03, Oswald Buddenhagen wrote: > On Wed, Aug 01, 2018 at 10:33:43AM -0400, Matthew Woehlke wrote: >> On 2018-08-01 04:24, Jason Newton wrote: >>> On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke wrote: >>>> Persistent build server? Java? No, thanks. >>> >>> This is an option, you can keep it in a preference file, or you can >>> use it as a command line switch to not use this. >> >> ...and how many naïve users that "just want to build Qt" are going to >> know about that? >> > and why exactly would a user who doesn't care ... care? ...because building Qt just spawned a process that is never going to terminate, is going to sit around pointlessly monitoring their file system, and is going to potentially cause who-knows-what issues? If I want to just download and build some package (i.e. I'm not *actively developing* that software), doing so shouldn't "infect" my machine with zombie processes. When the build is done, it should be *done*. > it's not that i *like* big dependencies, but there is a trade-off to be > made, and bazel is *by far* the most advanced build tool on the market > today when it comes to optimizing rebuilds of massive projects ...which is *totally irrelevant* to everyone that is not a Qt developer. Just like software is written once and read many times, it is developed by a few and deployed by many. Optimizing for development *at the expense* of deployment strikes me as... questionable. If the penalty to deployment cost was minimal, that would be one thing, but with bazel, it isn't. -- Matthew From thiago.macieira at intel.com Thu Aug 2 18:49:51 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 2 Aug 2018 09:49:51 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <6464261533219378@myt3-c7e5d17fe013.qloud-c.yandex.net> References: <20180802155713.7203572d@ckandeler-archlinux> <6464261533219378@myt3-c7e5d17fe013.qloud-c.yandex.net> Message-ID: <4500778.NE4GuXKDPM@tjmaciei-mobl1> On Thursday, 2 August 2018 07:16:18 PDT Konstantin Tokarev wrote: > Unfortunately, Debian does not use cross-compilation for building packages Which is unfortunately the case for most (if not all) Linux distributions as a significant number of frameworks and applications don't cross compile at all. So they need to compile on target. Sometimes it's an option to use an emulated environment (qemu), but often that's even slower than on target. A hybrid approach that runs under qemu and runs a native cross compiler disguised as a target compiler is also possible, but not easy to achieve. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From edward.welbourne at qt.io Thu Aug 2 19:02:39 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 2 Aug 2018 17:02:39 +0000 Subject: [Development] Repository request: HTTP server In-Reply-To: <25d8a8b6-c87b-a216-d3db-326870bed3f7@qt.io> References: <7FECC0A8-3964-4372-A77E-E925854A0D9A@qt.io>, <25d8a8b6-c87b-a216-d3db-326870bed3f7@qt.io> Message-ID: On 10/06/2017 07:10 AM, Fredrik de Vibe wrote: >> We have recently been working on a research project looking into the possibilities for creating a lightweight server component that can easily enable Qt applications to serve over HTTP. We would like to make this work public and therefore request a repository. >> >> This work is intended to continue as a research project, to explore alternatives and reveal areas that need work, so it should be under qt-labs. >> >> Name of the project: Qt HTTP Server >> Responsible person: Fredrik de Vibe >> Gerrit user/email: fredrik.devibe at qt.io >> Desired repository name: qthttpserver Adam Treat (2 August 2018 17:02) > What came of this? Good question. It's currently on qt-labs, see https://codereview.qt-project.org/#/q/project:qt-labs/qthttpserver,n,z for recent reviews. Eddy. From perezmeyer at gmail.com Thu Aug 2 19:17:39 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Thu, 02 Aug 2018 14:17:39 -0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <20180802155713.7203572d@ckandeler-archlinux> References: <2896146.IyJcsZBgxe@tonks> <20180802155713.7203572d@ckandeler-archlinux> Message-ID: <1603735.586GGet5jW@tonks> El jueves, 2 de agosto de 2018 10:57:42 -03 Christian Kandeler escribió: [snip] > > But would be problematic when building for other archs not that powerful > > as > > "the normal ones". > > You mean *on* other archs? Because the (cross-)compiler does not care how > powerful the target architecture is. Yes, exactly. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From annulen at yandex.ru Thu Aug 2 19:36:11 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 02 Aug 2018 20:36:11 +0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <4500778.NE4GuXKDPM@tjmaciei-mobl1> References: <20180802155713.7203572d@ckandeler-archlinux> <6464261533219378@myt3-c7e5d17fe013.qloud-c.yandex.net> <4500778.NE4GuXKDPM@tjmaciei-mobl1> Message-ID: <7495021533231371@iva1-16f33c6a446b.qloud-c.yandex.net> 02.08.2018, 19:50, "Thiago Macieira" : > On Thursday, 2 August 2018 07:16:18 PDT Konstantin Tokarev wrote: >>  Unfortunately, Debian does not use cross-compilation for building packages > > Which is unfortunately the case for most (if not all) Linux distributions as a > significant number of frameworks and applications don't cross compile at all. > So they need to compile on target. Do you have any prominent examples? I'm working on embedded software for 8 years, me and my colleagues have dealt with various open source packages, we've never needed to resort to compilation on target or qemu environment. There are cross-compiled embedded distros like Buildroot which include thousands of packages. > > Sometimes it's an option to use an emulated environment (qemu), but often > that's even slower than on target. A hybrid approach that runs under qemu and > runs a native cross compiler disguised as a target compiler is also possible, > but not easy to achieve. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From nevion at gmail.com Thu Aug 2 20:00:27 2018 From: nevion at gmail.com (Jason Newton) Date: Thu, 2 Aug 2018 11:00:27 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <11a3a98b-a430-c7a9-acc5-423285c79013@gmail.com> References: <4a6fc377-1cb6-e5a7-1921-d49b17f9aa05@gmail.com> <20180802130304.GF28072@troll08> <11a3a98b-a430-c7a9-acc5-423285c79013@gmail.com> Message-ID: On Thu, Aug 2, 2018 at 9:34 AM Matthew Woehlke wrote: > > On 2018-08-02 09:03, Oswald Buddenhagen wrote: > > On Wed, Aug 01, 2018 at 10:33:43AM -0400, Matthew Woehlke wrote: > >> On 2018-08-01 04:24, Jason Newton wrote: > >>> On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke wrote: > >>>> Persistent build server? Java? No, thanks. > >>> > >>> This is an option, you can keep it in a preference file, or you can > >>> use it as a command line switch to not use this. > >> > >> ...and how many naïve users that "just want to build Qt" are going to > >> know about that? > >> > > and why exactly would a user who doesn't care ... care? > > ...because building Qt just spawned a process that is never going to > terminate, is going to sit around pointlessly monitoring their file > system, and is going to potentially cause who-knows-what issues? > > If I want to just download and build some package (i.e. I'm not > *actively developing* that software), doing so shouldn't "infect" my > machine with zombie processes. When the build is done, it should be *done*. This is arguing over defaults and for a hypothetical case. The daemon exits automatically after a preference-set threshold of time of idle. It was engineered and tested for many years to not have problems as to what you are describing, such as updates to the bazel installation itself, but it is possible something goes wrong . The capability makes sense to everyday developers so the it earns it's place in the world. There's a flag to opt out and projects can set defaults that bazel will respect. Users can also disable it permanently in their home preference files and invoke bazel with the switch to disable. If that is not sufficient, upstream may listen to behavioral changes such as opt-out by default and opt-in with flags. > > > it's not that i *like* big dependencies, but there is a trade-off to be > > made, and bazel is *by far* the most advanced build tool on the market > > today when it comes to optimizing rebuilds of massive projects > > ...which is *totally irrelevant* to everyone that is not a Qt developer. > Just like software is written once and read many times, it is developed > by a few and deployed by many. Optimizing for development *at the > expense* of deployment strikes me as... questionable. If the penalty to > deployment cost was minimal, that would be one thing, but with bazel, it > isn't. Perhaps there are strategies to make it reduced by stripping out things in packages and not depending on a full JRE. Without swing, some people have reported getting JRE's down to 10 MiB. I'll remind again it depends on a JRE, not a JDK - there's some semblance to arguing about python usage, in that case. -Jason From perezmeyer at gmail.com Thu Aug 2 20:24:30 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Thu, 02 Aug 2018 15:24:30 -0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <7495021533231371@iva1-16f33c6a446b.qloud-c.yandex.net> References: <4500778.NE4GuXKDPM@tjmaciei-mobl1> <7495021533231371@iva1-16f33c6a446b.qloud-c.yandex.net> Message-ID: <2444741.Uvsrm7sg72@tonks> El jueves, 2 de agosto de 2018 14:36:11 -03 Konstantin Tokarev escribió: > 02.08.2018, 19:50, "Thiago Macieira" : > > On Thursday, 2 August 2018 07:16:18 PDT Konstantin Tokarev wrote: > >> Unfortunately, Debian does not use cross-compilation for building > >> packages > > > > Which is unfortunately the case for most (if not all) Linux distributions > > as a significant number of frameworks and applications don't cross > > compile at all. So they need to compile on target. > > Do you have any prominent examples? I'm working on embedded software for 8 > years, me and my colleagues have dealt with various open source packages, > we've never needed to resort to compilation on target or qemu environment. Out of the box Qt. You need to specifically build it to cross compile stuff, which is not what distros look for. What distros need is being able to use the real-arch binaries to build the target ones. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Thu Aug 2 21:35:49 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 2 Aug 2018 12:35:49 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <7495021533231371@iva1-16f33c6a446b.qloud-c.yandex.net> References: <4500778.NE4GuXKDPM@tjmaciei-mobl1> <7495021533231371@iva1-16f33c6a446b.qloud-c.yandex.net> Message-ID: <4467091.7xQpZAtxHU@tjmaciei-mobl1> On Thursday, 2 August 2018 10:36:11 PDT Konstantin Tokarev wrote: > Do you have any prominent examples? No, sorry. We don't need to cross-compile at the company I work for :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kollix at aon.at Fri Aug 3 08:03:06 2018 From: kollix at aon.at (Martin Koller) Date: Fri, 03 Aug 2018 08:03:06 +0200 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: References: Message-ID: <2738589.8Gku91fN3D@lapi.koller> On Donnerstag, 2. August 2018 15:45:00 CEST Simon Hausmann wrote: > Hi, > > > Before concluding that a namespaced Qt is a terrible idea, I recommend trying out the feature. > > > It is intended to work transparently and not require any changes to the application, nothing like having to type MyNS::QString everywhere. > > > It may be problematic with forward declarations of Qt types, but the fix for that (surrounding with QT_BEGIN/END_NAMESPACE) is entirely compatible between NS and non-NS builds and does not violate the write once goal. The correct way to use Qt classes forward declared with (and also without) a namespaced Qt build is e.g.: QT_FORWARD_DECLARE_CLASS(QTimer) The problem we had with a namespaced Qt were: using external Qt based libraries, which never tried to use a namespaced build, did not build due to forward declarations, so I had to patch some of them. But then, not all external library projects liked these patches so we'd have to patch them on our own increasing the workload when upgrading ... Also, when using squish you can no longer use a prebuilt version and have to compile squish from sources including also the namespace AFAIR. Eventually we could go back to non-namespaced builds, which makes your life simpler. -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at From lars.knoll at qt.io Fri Aug 3 08:04:11 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 3 Aug 2018 06:04:11 +0000 Subject: [Development] JS Engine: callAsConstructor vs. virtualCallAsConstructor In-Reply-To: References: Message-ID: <4C28DD11-4288-49DE-8565-AB6B756ECA41@qt.io> Hi Valery, On 2 Aug 2018, at 15:44, Valery Kotov > wrote: Hello all, I have a question about recent introduction of "virtual" functions in JavaScript engine. Now objects have both virtualCallAsConstructor function and callAsConstructor functions. Unfortunately, distinction between those is a little bit unclear to me. Is virtualCallAsConstructor is actually what is called when object is created on JS side (via new call)? Shall virtuallCallAsConstructor now be used when an JS Object is needed to be created from C++ side? As you know, we have some hand rolled vtables for QV4::Object and friends. The declarations of those can now be found in qv4vtable_p.h. Before, the ‘virtual’ and non regular methods where simply called the same, but had different signatures. That gave some conflicts, so I know renamed the ones that will be used by the vtable to have a ‘virtual’ prefix. So if you add your own re-implementation of callAsConstructor you’ll have to name it ‘virtualCallAsConstructor’. Like that it’ll end up in the vtable. If you call a constructor from C++, you can simply do functionObject->callAsConstructor() and it’ll forward it to the correct vtable method. If you ‘reimplement’ one of those methods (ie. implement a virtualCallAsConstructor) and need to call the base implementation, you’ll need to call the specific BaseClass::virtualCallAsConstructor method. I'm also a little bit puzzled about signature: static ReturnedValue virtualCallAsConstructor(const FunctionObject *f, const Value *argv, int argc, const Value *); What is the last const Value*? Shall I pass args as last the last arguments? The last value is the newTarget (see https://www.ecma-international.org/ecma-262/8.0/#sec-construct). It’s required for class constructors. In most cases it’ll be the same as the function object that is the constructor. Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik.holland at pelagicore.com Fri Aug 3 08:21:19 2018 From: dominik.holland at pelagicore.com (Dominik Holland) Date: Fri, 3 Aug 2018 08:21:19 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: Message-ID: <56ab7439-4988-5331-7701-a28de52df4fb@pelagicore.com> Am 01.08.18 um 16:40 schrieb Ville Voutilainen: > On 1 August 2018 at 11:24, Jason Newton wrote: >>> And... seriously, *Java*?! Talk about bloat-ware... As dependencies for >>> *a build tool* go, that's pretty insane. Especially if you're not >>> planning to use it to build Java code. >> As I said, ~300-400 megabytes for a JRE (~90MiB DL), in particular >> openjdk , prospectively in a development environment where you've got >> devel headers and packages installed. The cost of the dependency is >> neither bloat nor unbounded, it really is just that size on a machine >> that's prepared to build software in 2018. Please explain what issue >> this presents. > The prospect of having to install a JRE to build Qt or eventually Qt > applications > solicits a fairly loud "I think I'll pass" from me. I don't use java > for anything. Having > it around for a supposedly simple and easy-to-adopt build system is a cost > that I am not eager to pay. Do we expect to package a JRE with Qt? Do we > expect a JRE to be a package dependency of Qt for distro vendors? That would also have a big inpact on the yocto packages, as that would require building java itself to compile Qt (yocto usually doesn't use prepackaged binaries...), and also compile it again for the SDK architecture... For me JRE as a Qt build dependency is a no-go Dominik From olivier at woboq.com Fri Aug 3 08:27:50 2018 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 3 Aug 2018 08:27:50 +0200 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: <2738589.8Gku91fN3D@lapi.koller> References: <2738589.8Gku91fN3D@lapi.koller> Message-ID: On 2018-08-03 08:03, Martin Koller wrote: > On Donnerstag, 2. August 2018 15:45:00 CEST Simon Hausmann wrote: >> Hi, >> >> >> Before concluding that a namespaced Qt is a terrible idea, I recommend trying out the feature. >> >> >> It is intended to work transparently and not require any changes to the application, nothing like having to type MyNS::QString everywhere. >> >> >> It may be problematic with forward declarations of Qt types, but the fix for that (surrounding with QT_BEGIN/END_NAMESPACE) is entirely compatible between NS and non-NS builds and does not violate the write once goal. > > The correct way to use Qt classes forward declared with (and also without) a namespaced Qt build is e.g.: > QT_FORWARD_DECLARE_CLASS(QTimer) > > The problem we had with a namespaced Qt were: using external Qt based libraries, which never tried to use > a namespaced build, did not build due to forward declarations, so I had to patch some of them. > But then, not all external library projects liked these patches so we'd have to patch them on our own > increasing the workload when upgrading ... > Also, when using squish you can no longer use a prebuilt version and have to compile squish from sources > including also the namespace AFAIR. > > Eventually we could go back to non-namespaced builds, which makes your life simpler. Ideally, we should deprecate forward declarations of Qt classes. We should have a forwarding header, generated by syncqt, which would fordward declare all classes on a module. So one would do #include to forward declare all classes in QtCore. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From bogdan at kdab.com Fri Aug 3 08:42:08 2018 From: bogdan at kdab.com (BogDan Vatra) Date: Fri, 03 Aug 2018 09:42:08 +0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <12270285.0g7gfsGHTX@tjmaciei-mobl1> References: <10953066.bVjT5czqOF@debian> <12270285.0g7gfsGHTX@tjmaciei-mobl1> Message-ID: <36508308.LhyNAa6ULx@debian> În ziua de joi, 2 august 2018, la 18:06:02 EEST, Thiago Macieira a scris: > On Wednesday, 1 August 2018 23:13:13 PDT BogDan Vatra via Development wrote: > > > Now that is nice, as we know that the moc, uic, rcc outputs are > > > platform- > > > independent. That should help reduce the build times on Windows for > > > debug-and- release builds, as running moc is a significant portion of > > > the > > > build time. > > > > > It will be nice if this feature is mandatory for Qt 6, so let's add it > > to > > > > your requirements list. > > No, this is "nice to have", not mandatory. A reduction in build time would > be very welcome, but if we don't have it, the build still works. > > > BTW, not only moc, uic & rcc are platform-independent, but also the > > > > headers (except a few that are generated by configure script which can be > > moved to platform libs dir). What will be cool really is to unify headers, > > examples & demos for the Qt SDKs, this way we'll save a lot of space. > > Sorry, I didn't get it. Can you clarify? Sorry it's kinda off-topic. What I wanted to say is for Qt 6 to have a new SDK folders layout. Now each Qt target goes into a separate folder, but the bin, include (except a few files), doc, mkspecs, etc. folders are the same. The only platform-dependent folders are lib, plugins and qml. So, instead of: ~/Qt /5.11.1 /android_armv7 /bin /include /lib /gcc_64 /bin /include /lib we'll have: ~/Qt /6.0.0 /bin /include /lib /android_armv7 <-- here goes android armv7 libs /include <-- here goes only android specific headers /gcc_64 <-- here goes linux amd64 libs /include <-- here goes only linux 64 specific headers Platform specific headers are those that are generated by configure script. Of curse the build system must handle this new layout. Cheers, BogDan. From nevion at gmail.com Fri Aug 3 08:46:07 2018 From: nevion at gmail.com (Jason Newton) Date: Thu, 2 Aug 2018 23:46:07 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <56ab7439-4988-5331-7701-a28de52df4fb@pelagicore.com> References: <56ab7439-4988-5331-7701-a28de52df4fb@pelagicore.com> Message-ID: On Thu, Aug 2, 2018 at 11:21 PM Dominik Holland wrote: > > Am 01.08.18 um 16:40 schrieb Ville Voutilainen: > > > On 1 August 2018 at 11:24, Jason Newton wrote: > >>> And... seriously, *Java*?! Talk about bloat-ware... As dependencies for > >>> *a build tool* go, that's pretty insane. Especially if you're not > >>> planning to use it to build Java code. > >> As I said, ~300-400 megabytes for a JRE (~90MiB DL), in particular > >> openjdk , prospectively in a development environment where you've got > >> devel headers and packages installed. The cost of the dependency is > >> neither bloat nor unbounded, it really is just that size on a machine > >> that's prepared to build software in 2018. Please explain what issue > >> this presents. > > The prospect of having to install a JRE to build Qt or eventually Qt > > applications > > solicits a fairly loud "I think I'll pass" from me. I don't use java > > for anything. Having > > it around for a supposedly simple and easy-to-adopt build system is a cost > > that I am not eager to pay. Do we expect to package a JRE with Qt? Do we > > expect a JRE to be a package dependency of Qt for distro vendors? > That would also have a big inpact on the yocto packages, as that would > require building java itself to compile Qt (yocto usually doesn't use > prepackaged binaries...), > and also compile it again for the SDK architecture... > > For me JRE as a Qt build dependency is a no-go > Have a look at this: http://zlika.github.io/presentations/compile-openjdk8/slides_en.html#/_generation_of_compact_profiles If the java packager of the distribution puts in some time with the openjdk packages they support, they can get it down to 13-25 MiB, before compression, and 50% of those numbers with. Bazel doesn't need gui stuff. >From OpenSUSE build service, here is the build time for the full OpenJDK 8 build https://build.opensuse.org/public/build/Java:Factory/openSUSE_Leap_15.0/x86_64/java-1_8_0-openjdk/_log - 1976 seconds with what appears to be a single threaded build. It should be possible to considerably lean this down. For control, here is qt5's build file https://build.opensuse.org/public/build/KDE:Qt:5.11/openSUSE_Leap_15.0/x86_64/libqt5-qtbase/_log clocking in 2455s -Jason From Oliver.Wolff at qt.io Fri Aug 3 11:06:11 2018 From: Oliver.Wolff at qt.io (Oliver Wolff) Date: Fri, 3 Aug 2018 11:06:11 +0200 Subject: [Development] Change ANGLE 3rd party source from Google to Microsoft Message-ID: <1e6d2cca-dc18-f1ee-e4f8-ca819d878757@qt.io> Hi, I would like to propose a change of where we get the ANGLE sources we use in qtbase. At the moment we use Google's ANGLE (https://github.com/google/angle). Unfortunately they stopped supporting MSVC 2015 last year and their UWP code path does not build out of the box. Microsoft (https://github.com/Microsoft/angle) still actively maintains MSVC 2015 and also has a focus on UWP within their port. As far as I can tell there is no difference in the license used, so we should be fine from that point of view. Background info: ANGLE is used to translate OpenGL calls to Direct 3D. This is done for desktop Windows     - by default (when no "-opengl ..." is given (which arguably should be changed to dynamic))     - if native OpenGL fails (when configured with -opengl dynamic)  due to crappy opengl drivers or blacklisted GPU for example Is everyone ok with this change? The ANGLE update from Google (which uses a revision that still supports MSVC 2015) would be ready (https://codereview.qt-project.org/#/c/233385/), but we would like to use a newer version from Microsoft for 5.12 if we can agree on this change. Best regards, Olli From bstottle at ford.com Fri Aug 3 14:46:40 2018 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Fri, 3 Aug 2018 12:46:40 +0000 Subject: [Development] Change ANGLE 3rd party source from Google to Microsoft In-Reply-To: <1e6d2cca-dc18-f1ee-e4f8-ca819d878757@qt.io> References: <1e6d2cca-dc18-f1ee-e4f8-ca819d878757@qt.io> Message-ID: <53290915-6EF5-4C9E-9F34-AE3D9244F044@ford.com> On 8/3/18, 5:06 AM, "Development on behalf of Oliver Wolff" wrote: Hi, Is everyone ok with this change? The ANGLE update from Google (which uses a revision that still supports MSVC 2015) would be ready (https://codereview.qt-project.org/#/c/233385/), but we would like to use a newer version from Microsoft for 5.12 if we can agree on this change. Just a quick look at the commit history shows Google’s version is under active development (last commit today) while Microsoft’s version is not (last commit, as of just now, was Oct 9th, 2017). So, the choice is using an old sha on a maintained repo, or HEAD of an unmaintained one? Hopefully that isn’t the case. IIUC, Chromium moved to clang-cl builds for windows (see http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html). What/how is QtWebEngine building for 64+ (chromium) on windows? Thanks, Brett From thiago.macieira at intel.com Fri Aug 3 16:44:40 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 3 Aug 2018 07:44:40 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <36508308.LhyNAa6ULx@debian> References: <12270285.0g7gfsGHTX@tjmaciei-mobl1> <36508308.LhyNAa6ULx@debian> Message-ID: <1744013.hO7IBvXSqR@tjmaciei-mobl1> On Thursday, 2 August 2018 23:42:08 PDT BogDan Vatra via Development wrote: > Sorry it's kinda off-topic. What I wanted to say is for Qt 6 to have a new > SDK folders layout. Now each Qt target goes into a separate folder, but the > bin, include (except a few files), doc, mkspecs, etc. folders are the same. > The only platform-dependent folders are lib, plugins and qml. > So, instead of: We're actually going to get the bin dir shared if we start using the host tooling to build a cross-compiled Qt and cross-compiled application. Sharing the includes is possible, but tricky, like you said, because of the config files that do change across builds. So we'd need two sets of -I flags: one for cross-platform includes and one for the platform-dependent ones. Because of that, I don't see us doing this. > we'll have: > > ~/Qt > /6.0.0 > /bin > /include > /lib > /android_armv7 <-- here goes android armv7 libs > /include <-- here goes only android specific headers > /gcc_64 <-- here goes linux amd64 libs > /include <-- here goes only linux 64 specific headers Like you're suggesting. But the includes are hardly a disk space hog... Wait, I take that back. After checking my installed build, it turns out that the headers are a full fifth of the installed size (I don't build qtwebkit or qtwebengine). It might be interesting to explore this, but it would be just a "nice to have". Also note that QML files are usually cross-platform too and could be shared. Any non-cross-platform QML file should be selected by the source via QFileSelector. Plugins, however, are arch-dependent and should live in an arch-dependent dir. That would mean splitting the "qml" dir in two: /lib/qml /share/qml I don't see us spending the effort... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Aug 3 16:50:29 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 3 Aug 2018 07:50:29 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <56ab7439-4988-5331-7701-a28de52df4fb@pelagicore.com> Message-ID: <85187364.ntAfbXPSzg@tjmaciei-mobl1> On Thursday, 2 August 2018 23:46:07 PDT Jason Newton wrote: > From OpenSUSE build service, here is the build time for the full > OpenJDK 8 build > https://build.opensuse.org/public/build/Java:Factory/openSUSE_Leap_15.0/x86_ > 64/java-1_8_0-openjdk/_log - 1976 seconds with what appears to be a single > threaded build. It > should be possible to considerably lean this down. > > For control, here is qt5's build file > https://build.opensuse.org/public/build/KDE:Qt:5.11/openSUSE_Leap_15.0/x86_6 > 4/libqt5-qtbase/_log clocking in 2455s You're not going to convince a bunch of C++ developers to use a Java buildsystem. The solution you're proposing would need to be an order of magnitude better on everything else for that to be acceptable. And so far we have found it to be (subjectively) worse than the others. As for distros, Qt is usually on the critical build path, due to its size. Doubling the build time by inserting a dependency of equal size is not going to make you friends. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Aug 3 16:52:41 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 3 Aug 2018 07:52:41 -0700 Subject: [Development] Change ANGLE 3rd party source from Google to Microsoft In-Reply-To: <1e6d2cca-dc18-f1ee-e4f8-ca819d878757@qt.io> References: <1e6d2cca-dc18-f1ee-e4f8-ca819d878757@qt.io> Message-ID: <5309159.PWMocXm1QW@tjmaciei-mobl1> On Friday, 3 August 2018 02:06:11 PDT Oliver Wolff wrote: > Is everyone ok with this change? The ANGLE update from Google (which > uses a revision that still supports MSVC 2015) would be ready > (https://codereview.qt-project.org/#/c/233385/), but we would like to > use a newer version from Microsoft for 5.12 if we can agree on this change. Agreed, please switch to the Microsoft one and let's try and reduce our patch list (technical debt). Having instructions on how to build with an external ANGLE, possibly installed via vcpkg, would be very welcome. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Aug 3 16:55:09 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 3 Aug 2018 07:55:09 -0700 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: <2738589.8Gku91fN3D@lapi.koller> References: <2738589.8Gku91fN3D@lapi.koller> Message-ID: <2776305.1vXdtjejfv@tjmaciei-mobl1> On Thursday, 2 August 2018 23:03:06 PDT Martin Koller wrote: > QT_FORWARD_DECLARE_CLASS(QTimer) Easier to just put QT_BEGIN_NAMESPACE before and QT_END_NAMESPACE after. It's more verbose, but it's actually easier to read. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From khuram.ali at aim.com Fri Aug 3 17:22:06 2018 From: khuram.ali at aim.com (Khuram Ali) Date: Fri, 3 Aug 2018 11:22:06 -0400 Subject: [Development] QML AnimatedImage Memory usage - QTBUG-64272 Message-ID: <1650061acb8-c8f-17b17@webjas-vac176.srv.aolmail.net> Hi, I am suffering from the already reported bug https://bugreports.qt.io/browse/QTBUG-64272. I am adding a gif and the memory usage sky rocket to more than a GB. I have seen the bug is still open. is there any suggested workaround to this issue? I am using Qt 5.11.1. Thank you for your help! Regards, Khuram Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From apoenitz at t-online.de Fri Aug 3 07:19:09 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Fri, 3 Aug 2018 07:19:09 +0200 Subject: [Development] Symbol clashes with static Qt libraries In-Reply-To: References: <2738589.8Gku91fN3D@lapi.koller> Message-ID: <20180803051909.GA2106@klara.mpi.htwm.de> On Fri, Aug 03, 2018 at 08:27:50AM +0200, Olivier Goffart wrote: > > The problem we had with a namespaced Qt were: using external Qt > > based libraries, which never tried to use a namespaced build, did > > not build due to forward declarations, so I had to patch some of > > them. But then, not all external library projects liked these > > patches so we'd have to patch them on our own increasing the > > workload when upgrading ... Also, when using squish you can no > > longer use a prebuilt version and have to compile squish from > > sources including also the namespace AFAIR. > > > > Eventually we could go back to non-namespaced builds, which makes > > your life simpler. > > Ideally, we should deprecate forward declarations of Qt classes. We > should have a forwarding header, generated by syncqt, which would > fordward declare all classes on a module. So one would do #include > to forward declare all classes in QtCore. I would not *deprecate* forward declarations, but having the *Fwd headers would be really nice, also for the examples, as using QT_{DEGIN,END}_NAMESPACE there makes Qt look quirky, and using full includes makes it look inefficient. Andre' From kotov.valery at gmail.com Sat Aug 4 11:39:23 2018 From: kotov.valery at gmail.com (Valery Kotov) Date: Sat, 4 Aug 2018 11:39:23 +0200 Subject: [Development] JS Engine: callAsConstructor vs. virtualCallAsConstructor In-Reply-To: <4C28DD11-4288-49DE-8565-AB6B756ECA41@qt.io> References: <4C28DD11-4288-49DE-8565-AB6B756ECA41@qt.io> Message-ID: Hello Lars, Got it. Thank you for the explanation! Just a small question to see that I got it correctly. Then virtuallCall means the same but for JavaScript function invocation, does not it? And if I would like to call a JS function from C++ I simply do functionObject->call (as before) and it will automatically redirect to the appropriate virtualCall (re)implementation. Is that right? BR, Valery Sincerely yours, Valery Kotov On 3 August 2018 at 08:04, Lars Knoll wrote: > Hi Valery, > > On 2 Aug 2018, at 15:44, Valery Kotov wrote: > > Hello all, > > I have a question about recent introduction of "virtual" functions in > JavaScript engine. > > Now objects have both virtualCallAsConstructor function and > callAsConstructor functions. > Unfortunately, distinction between those is a little bit unclear to me. Is > virtualCallAsConstructor is actually what is called when object is created > on JS side (via new call)? Shall virtuallCallAsConstructor now be used when > an JS Object is needed to be created from C++ side? > > > As you know, we have some hand rolled vtables for QV4::Object and friends. > The declarations of those can now be found in qv4vtable_p.h. > > Before, the ‘virtual’ and non regular methods where simply called the > same, but had different signatures. That gave some conflicts, so I know > renamed the ones that will be used by the vtable to have a ‘virtual’ prefix. > > So if you add your own re-implementation of callAsConstructor you’ll have > to name it ‘virtualCallAsConstructor’. Like that it’ll end up in the > vtable. > > If you call a constructor from C++, you can simply do functionObject->callAsConstructor() > and it’ll forward it to the correct vtable method. If you ‘reimplement’ one > of those methods (ie. implement a virtualCallAsConstructor) and need to > call the base implementation, you’ll need to call the specific BaseClass::virtualCallAsConstructor > method. > > > I'm also a little bit puzzled about signature: > static ReturnedValue virtualCallAsConstructor(const FunctionObject *f, > const Value *argv, int argc, const Value *); > > What is the last const Value*? Shall I pass args as last the last > arguments? > > > The last value is the newTarget (see https://www.ecma- > international.org/ecma-262/8.0/#sec-construct). It’s required for class > constructors. In most cases it’ll be the same as the function object that > is the constructor. > > Cheers, > Lars > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aapo.keskimolo at qt.io Sat Aug 4 19:00:52 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Sat, 4 Aug 2018 17:00:52 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: References: Message-ID: Coin production was updated today at Fri Aug 4 17:03:18 EEST 2018 with new baseline. For CI related issues, you may create bug report as instructed in https://wiki.qt.io/Reporting_Bugs#Reporting_bugs_for_Coin and/or consult the internal #qtci IRC-channel. See change-list attached for related patches. Kind regards/Ystävällisin terveisin, Aapo Keskimölö -------------- next part -------------- A non-text attachment was scrubbed... Name: product_baseline_20180804.log Type: application/octet-stream Size: 2751 bytes Desc: product_baseline_20180804.log URL: From lars.knoll at qt.io Sat Aug 4 21:13:20 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Sat, 4 Aug 2018 19:13:20 +0000 Subject: [Development] JS Engine: callAsConstructor vs. virtualCallAsConstructor In-Reply-To: References: <4C28DD11-4288-49DE-8565-AB6B756ECA41@qt.io> Message-ID: On 4 Aug 2018, at 11:39, Valery Kotov > wrote: Hello Lars, Got it. Thank you for the explanation! Just a small question to see that I got it correctly. Then virtuallCall means the same but for JavaScript function invocation, does not it? And if I would like to call a JS function from C++ I simply do functionObject->call (as before) and it will automatically redirect to the appropriate virtualCall (re)implementation. Is that right? Yes, that's correct :) Cheers, Lars BR, Valery Sincerely yours, Valery Kotov On 3 August 2018 at 08:04, Lars Knoll > wrote: Hi Valery, On 2 Aug 2018, at 15:44, Valery Kotov > wrote: Hello all, I have a question about recent introduction of "virtual" functions in JavaScript engine. Now objects have both virtualCallAsConstructor function and callAsConstructor functions. Unfortunately, distinction between those is a little bit unclear to me. Is virtualCallAsConstructor is actually what is called when object is created on JS side (via new call)? Shall virtuallCallAsConstructor now be used when an JS Object is needed to be created from C++ side? As you know, we have some hand rolled vtables for QV4::Object and friends. The declarations of those can now be found in qv4vtable_p.h. Before, the ‘virtual’ and non regular methods where simply called the same, but had different signatures. That gave some conflicts, so I know renamed the ones that will be used by the vtable to have a ‘virtual’ prefix. So if you add your own re-implementation of callAsConstructor you’ll have to name it ‘virtualCallAsConstructor’. Like that it’ll end up in the vtable. If you call a constructor from C++, you can simply do functionObject->callAsConstructor() and it’ll forward it to the correct vtable method. If you ‘reimplement’ one of those methods (ie. implement a virtualCallAsConstructor) and need to call the base implementation, you’ll need to call the specific BaseClass::virtualCallAsConstructor method. I'm also a little bit puzzled about signature: static ReturnedValue virtualCallAsConstructor(const FunctionObject *f, const Value *argv, int argc, const Value *); What is the last const Value*? Shall I pass args as last the last arguments? The last value is the newTarget (see https://www.ecma-international.org/ecma-262/8.0/#sec-construct). It’s required for class constructors. In most cases it’ll be the same as the function object that is the constructor. Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From neundorf at kde.org Sun Aug 5 23:10:10 2018 From: neundorf at kde.org (Alexander Neundorf) Date: Sun, 05 Aug 2018 23:10:10 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <1dae8907-9f45-5dff-3d07-512dab9bddf9@kdab.com> References: <4853329.uIsbQuBGgb@tjmaciei-mobl1> <1dae8907-9f45-5dff-3d07-512dab9bddf9@kdab.com> Message-ID: <1861885.iWR5blaQ6p@linux-l7nd> On 2018 M07 21, Sat 18:24:23 CEST Giuseppe D'Angelo via Development wrote: > Il 21/07/2018 17:42, Jean-Michaël Celerier ha scritto: > > Besides... why would it matter that they are implemented in C++ instead > > of cmake-lang ? If anything, CMake's automoc is in my experience much > > faster to process the whole repo. > > Playing devil's advocate, please bear with me: > > > Because it makes people worry that cmake-lang is too limited, and if you > need to do certain things (*), you need to resort to patch the tool itself. > > Which opens other sets of problems, such as: > > * what are the things that I can do in cmake-lang and the things I can't > do? you can do almost everything in cmake-lang ;-) By now, in 2018, most build-related challenges should have been taken care of in CMake. I think the biggest issues are: - IDE integration: cmake server mode is still relatively new and and I don't know exactly how powerful it currently is - better documentation/tutorial especially for old vs. new-style cmake - new technology that appaers with new operating system features etc. often needs a new cmake release > * Does all of this imply having changes landing in CMake itself, or can > one have some sort of plugin system so that a project can ship the CMake > C++ plugins to build it? there is intentionally no plugin system/public API in CMake, to keep changing the internals of cmake itself easy. But really a lot can be done via cmake scripts. > * If the former, what happens if my users are running a "slightly older" > CMake that doesn't have my patches in it yet? The older cmake will error out saying that the project requires a newer version of CMake. Alex From Oliver.Wolff at qt.io Mon Aug 6 07:07:55 2018 From: Oliver.Wolff at qt.io (Oliver Wolff) Date: Mon, 6 Aug 2018 07:07:55 +0200 Subject: [Development] Change ANGLE 3rd party source from Google to Microsoft In-Reply-To: <53290915-6EF5-4C9E-9F34-AE3D9244F044@ford.com> References: <1e6d2cca-dc18-f1ee-e4f8-ca819d878757@qt.io> <53290915-6EF5-4C9E-9F34-AE3D9244F044@ford.com> Message-ID: Hi Brett, On 03/08/2018 14:46, Stottlemyer, Brett (B.S.) wrote: > On 8/3/18, 5:06 AM, "Development on behalf of Oliver Wolff" wrote: > > Hi, > > Is everyone ok with this change? The ANGLE update from Google (which > uses a revision that still supports MSVC 2015) would be ready > (https://codereview.qt-project.org/#/c/233385/), but we would like to > use a newer version from Microsoft for 5.12 if we can agree on this change. > > Just a quick look at the commit history shows Google’s version is under active development (last commit today) while Microsoft’s version is not (last commit, as of just now, was Oct 9th, 2017). So, the choice is using an old sha on a maintained repo, or HEAD of an unmaintained one? Hopefully that isn’t the case. you seem to be correct. I will try to get in touch with them and ask about the status. > > IIUC, Chromium moved to clang-cl builds for windows (see http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html). What/how is QtWebEngine building for 64+ (chromium) on windows? I think QtWebEngine does not use the ANGLE version shipped with qtbase, but has another version of ANGLE shipped, but I will let someone from the WebEngine team comment on that. For qtbase we need to build ANGLE with MSVC 2015 and 2017 and with MinGW. Changing to clang-cl is not an option there. > > Thanks, > Brett > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From paolo.angelelli at qt.io Mon Aug 6 13:43:06 2018 From: paolo.angelelli at qt.io (Paolo Angelelli) Date: Mon, 6 Aug 2018 13:43:06 +0200 Subject: [Development] Programmable delegate selection for QML views Message-ID: <20180806134306.4c39137d@qdesktop> Hi, as some of you might have noticed, it's several months that some are trying to remove a long-standing limitation of the current QtQuick architecture: the inability to dynamically select, at runtime, the delegate to use in a view, based on whatever approach, either data-driven (typically using row data, index, etc), or else. The workaround, so far, has been to use a Loader for this. The Loader approach has several notable drawbacks, most importantly - performance, under different situations - it can only nest (and thus load) QQuickItems, being a QQuickItem itself 3 possible solutions to this problem have been suggested in the past few months, but it seems that no consensus has been reached on what is the way to go. So what i want to present, in this message, is an overview of these proposed solutions, to: - understand what is the general preference among the proposed approaches - see if anyone has other approaches to suggest, that might have been overlooked so far Currently suggested solutions are all based on a so-called "delegate chooser" (or selector), that would be queried whenever a delegate is required. The differences are in how to provide such an element to the view from an API perspective: 1. Add a new property to all view classes (ListView, TableView, ***View etc.), where to specify the chooser. The delegate property would be used as fallback, if chooser not present. ( https://codereview.qt-project.org/206670/ ) 2. Make the chooser subclass QQmlComponent, and pass it through the delegate property in place of a regular delegate ( https://codereview.qt-project.org/228909/ , example usage https://github.com/paoletto/MIVQVariant ). 3. Do not make the chooser subclass QQmlComponent. Instead, use another separate base class, like some QQmlAbstractComponentSet. Then mangle things enough so that it could still be passed through the delegate property. Reason for 3. (as alternative to 2.) is that there's one school of thought that see such a chooser not as a QQmlComponent subclass, while still trying to avoid an additional property. Ideally, should there be a clear winner, targeting 5.12 could still be viable. Thoughts? From mitch.curtis at qt.io Mon Aug 6 14:22:43 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Mon, 6 Aug 2018 12:22:43 +0000 Subject: [Development] Programmable delegate selection for QML views In-Reply-To: <20180806134306.4c39137d@qdesktop> References: <20180806134306.4c39137d@qdesktop> Message-ID: > -----Original Message----- > From: Development project.org> On Behalf Of Paolo Angelelli > Sent: Monday, 6 August 2018 1:43 PM > To: development at qt-project.org > Subject: [Development] Programmable delegate selection for QML views > > Hi, > > as some of you might have noticed, it's several months that some are trying > to remove a long-standing limitation of the current QtQuick architecture: the > inability to dynamically select, at runtime, the delegate to use in a view, > based on whatever approach, either data-driven (typically using row data, > index, etc), or else. > > The workaround, so far, has been to use a Loader for this. > The Loader approach has several notable drawbacks, most importantly > - performance, under different situations > - it can only nest (and thus load) QQuickItems, being a QQuickItem itself > > > 3 possible solutions to this problem have been suggested in the past few > months, but it seems that no consensus has been reached on what is the > way to go. > So what i want to present, in this message, is an overview of these proposed > solutions, to: > - understand what is the general preference among the proposed > approaches > - see if anyone has other approaches to suggest, that might have been > overlooked so far > > Currently suggested solutions are all based on a so-called "delegate chooser" > (or selector), that would be queried whenever a delegate is required. > The differences are in how to provide such an element to the view from an > API perspective: > > 1. Add a new property to all view classes (ListView, TableView, ***View > etc.), where to specify the chooser. > The delegate property would be used as fallback, if chooser not present. > ( https://codereview.qt-project.org/206670/ ) > > 2. Make the chooser subclass QQmlComponent, and pass it through the > delegate property in place of a regular delegate > ( https://codereview.qt-project.org/228909/ , example usage > https://github.com/paoletto/MIVQVariant ). > > 3. Do not make the chooser subclass QQmlComponent. > Instead, use another separate base class, like some > QQmlAbstractComponentSet. > Then mangle things enough so that it could still be passed through the > delegate property. > Reason for 3. (as alternative to 2.) is that there's one school of thought that > see such a chooser not as a QQmlComponent subclass, while still trying to > avoid an additional property. >From reading the comments of https://codereview.qt-project.org/#/c/228909/, I see that it was Simon that doesn't think it should be a QQmlComponent subclass. It would be good to hear more from him about this. > > Ideally, should there be a clear winner, targeting 5.12 could still be viable. > Thoughts? At a quick glance, if we can do it with the existing delegate property (#2), it would be nice. That's less complex than having two delegate properties. One minor problem with this is what we do when none of the delegates match the data type. #1 seems to cover this (https://codereview.qt-project.org/#/c/206670/8/src/qml/types/qqmldelegatemodel.cpp) by requiring that delegate also be implemented if a delegateChooser is provided. How does #2 account for it? I guess with #2 there should be a way to provide a "default" delegate, by e.g. leaving all properties (indexValue, roleValue) unset so that it acts a sort of wildcard? > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From paolo.angelelli at qt.io Mon Aug 6 15:18:51 2018 From: paolo.angelelli at qt.io (Paolo Angelelli) Date: Mon, 6 Aug 2018 15:18:51 +0200 Subject: [Development] Programmable delegate selection for QML views In-Reply-To: References: <20180806134306.4c39137d@qdesktop> Message-ID: <20180806151851.4acff6e7@qdesktop> On Mon, 6 Aug 2018 14:22:43 +0200 Mitch Curtis wrote: > At a quick glance, if we can do it with the existing delegate property (#2), it would be nice. That's less complex than having two delegate properties. > > One minor problem with this is what we do when none of the delegates match the data type. #1 seems to cover this (https://codereview.qt-project.org/#/c/206670/8/src/qml/types/qqmldelegatemodel.cpp) by requiring that delegate also be implemented if a delegateChooser is provided. How does #2 account for it? I guess with #2 there should be a way to provide a "default" delegate, by e.g. leaving all properties (indexValue, roleValue) unset so that it acts a sort of wildcard? Correct, in this case it's the chooser element the one in charge of providing the delegate, so it should have a fallback nested inside. That's also the way the patch currently works. However, this approach also lets one define a completely opaque subclass of QQmlAbstractDelegateComponent (private API, mind you) that doesn't require nesting anything inside in QML, and does all the magic internally. For example, imagine having a special use case where you get the delegate QML code (or QQmlComponent*, if one wants to be efficient) from the model itself. The special chooser would just get the QQmlComponent from the model and return it. It may not be present, so in this case it would have to return a plain Item or whatever is situationally required (may have to be some other class). From py.siret at gmail.com Mon Aug 6 15:34:00 2018 From: py.siret at gmail.com (Pierre-Yves Siret) Date: Mon, 6 Aug 2018 15:34:00 +0200 Subject: [Development] Programmable delegate selection for QML views In-Reply-To: References: <20180806134306.4c39137d@qdesktop> Message-ID: 2018-08-06 14:22 GMT+02:00 Mitch Curtis : > > > > -----Original Message----- > > From: Development > project.org> On Behalf Of Paolo Angelelli > > Sent: Monday, 6 August 2018 1:43 PM > > To: development at qt-project.org > > Subject: [Development] Programmable delegate selection for QML views > > > > Hi, > > > > as some of you might have noticed, it's several months that some are > trying > > to remove a long-standing limitation of the current QtQuick > architecture: the > > inability to dynamically select, at runtime, the delegate to use in a > view, > > based on whatever approach, either data-driven (typically using row data, > > index, etc), or else. > > > > The workaround, so far, has been to use a Loader for this. > > The Loader approach has several notable drawbacks, most importantly > > - performance, under different situations > > - it can only nest (and thus load) QQuickItems, being a QQuickItem itself > > > > > > 3 possible solutions to this problem have been suggested in the past few > > months, but it seems that no consensus has been reached on what is the > > way to go. > > So what i want to present, in this message, is an overview of these > proposed > > solutions, to: > > - understand what is the general preference among the proposed > > approaches > > - see if anyone has other approaches to suggest, that might have been > > overlooked so far > > > > Currently suggested solutions are all based on a so-called "delegate > chooser" > > (or selector), that would be queried whenever a delegate is required. > > The differences are in how to provide such an element to the view from an > > API perspective: > > > > 1. Add a new property to all view classes (ListView, TableView, ***View > > etc.), where to specify the chooser. > > The delegate property would be used as fallback, if chooser not > present. > > ( https://codereview.qt-project.org/206670/ ) > > > > 2. Make the chooser subclass QQmlComponent, and pass it through the > > delegate property in place of a regular delegate > > ( https://codereview.qt-project.org/228909/ , example usage > > https://github.com/paoletto/MIVQVariant ). > > > > 3. Do not make the chooser subclass QQmlComponent. > > Instead, use another separate base class, like some > > QQmlAbstractComponentSet. > > Then mangle things enough so that it could still be passed through the > > delegate property. > > Reason for 3. (as alternative to 2.) is that there's one school of > thought that > > see such a chooser not as a QQmlComponent subclass, while still trying to > > avoid an additional property. > > From reading the comments of https://codereview.qt-project.org/#/c/228909/, > I see that it was Simon that doesn't think it should be a QQmlComponent > subclass. It would be good to hear more from him about this. > > > > > Ideally, should there be a clear winner, targeting 5.12 could still be > viable. > > Thoughts? > > At a quick glance, if we can do it with the existing delegate property > (#2), it would be nice. That's less complex than having two delegate > properties. > > One minor problem with this is what we do when none of the delegates match > the data type. #1 seems to cover this (https://codereview.qt- > project.org/#/c/206670/8/src/qml/types/qqmldelegatemodel.cpp) by > requiring that delegate also be implemented if a delegateChooser is > provided. How does #2 account for it? I guess with #2 there should be a way > to provide a "default" delegate, by e.g. leaving all properties > (indexValue, roleValue) unset so that it acts a sort of wildcard? > > > _______________________________________________ > > 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 > > - it can only nest (and thus load) QQuickItems, being a QQuickItem itself Loader can wrap QObject too. This works : Instantiator { Loader { QtObject {} } } http://doc.qt.io/qt-5/qml-qtquick-loader.html#sourceComponent-prop : "Since QtQuick 2.0, Loader is able to load any type of object; it is not restricted to Item types." For me 2 and 3 seem to best fit the QML mentality, it's analogous to the model property of views not necessarly being a QAbstractItemModel; it can also be a QList, an int, a QVariantList, etc. and the magic is done behind the curtains to work with all the different types. > One minor problem with this is what we do when none of the delegates match the data type. #1 seems to cover this (https://codereview.qt- project.org/#/c/206670/8/src/qml/types/qqmldelegatemodel.cpp) by requiring that delegate also be implemented if a delegateChooser is provided. How does #2 account for it? I guess with #2 there should be a way to provide a "default" delegate, by e.g. leaving all properties (indexValue, roleValue) unset so that it acts a sort of wildcard? A default delegate looks like the sensible way to go indeed. But should we REQUIRE one ? Why can't we just not instantiate something when no fitting delegate is found ? That's what I believe #1 is actually doing. I've not really followed all the development off this feature, but is there a consensus about the choice mechanism of the delegates (vague syntax, potential choice criteria)? >From what I remember it would be based on either index or a role value. For one of my project I've implemented a property editor with Loader and a c++ helper. Basically my helper was returning a list of properties with some info about it: name, type, some additional info when needed (values of an enum). The loader chose the correct source from the type, but it could chose a different delegate for a specific property name. Basically : if (propIngo.name == "myCustomProp") return myCustomComponent; switch (propInfo.type) { case "int": return intComponent; case "string": return stringComponent; // ... Do we want to support this scenario or should we stick with simpler ones ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefbon at gmail.com Mon Aug 6 15:36:03 2018 From: stefbon at gmail.com (Stef Bon) Date: Mon, 6 Aug 2018 15:36:03 +0200 Subject: [Development] About 3D desktop. Message-ID: Hi, There are various desktop effects which offer 3D effects (kube for example). I want to know I anyone knows about any plan to create a 3D desktop, eg a desktop with not only the coordinates height and width, but also depth. I want to work on this, maybe start it. It would be awesome. Stef From Shawn.Rutledge at qt.io Mon Aug 6 16:41:42 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Mon, 6 Aug 2018 14:41:42 +0000 Subject: [Development] About 3D desktop. In-Reply-To: References: Message-ID: <19705C49-6273-46C1-8E40-F638685168C1@qt.io> > On 6 Aug 2018, at 15:36, Stef Bon wrote: > > Hi, > > There are various desktop effects which offer 3D effects (kube for example). > > I want to know I anyone knows about any plan to create a 3D desktop, > eg a desktop with not only the coordinates height and width, but also > depth. > > I want to work on this, maybe start it. It would be awesome. Yeah, sounds like fun; I wanted to do that too, didn’t get very far with it. There are toys like https://github.com/paulolav/mazecompositor (or my fork which attempted to get Oculus Rift support, but it wasn’t very usable) and https://github.com/evil0sheep/motorcar and https://en.wikipedia.org/wiki/Project_Looking_Glass and https://www.youtube.com/watch?v=3-mhqYBm7Xo (an old Microsoft one). And nowadays maybe it looks like it will be subsumed under AR: you could leave windows open on your walls and they will still be there when you physically go back to that place, perhaps? Or use a VR headset to have virtual desktop space as far as the eye can see, while sitting at your desk as usual? From mitch.curtis at qt.io Mon Aug 6 17:03:35 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Mon, 6 Aug 2018 15:03:35 +0000 Subject: [Development] Programmable delegate selection for QML views In-Reply-To: References: <20180806134306.4c39137d@qdesktop> Message-ID: > -----Original Message----- > From: gr3cko at gmail.com On Behalf Of Pierre-Yves > Siret > Sent: Monday, 6 August 2018 3:34 PM > To: Mitch Curtis > Cc: Paolo Angelelli ; development at qt-project.org > Subject: Re: [Development] Programmable delegate selection for QML views > > > One minor problem with this is what we do when none of the delegates > match the data type. #1 seems to cover this (https://codereview.qt- > project.org/#/c/206670/8/src/qml/types/qqmldelegatemodel.cpp > project.org/#/c/206670/8/src/qml/types/qqmldelegatemodel.cpp> ) by > requiring that delegate also be implemented if a delegateChooser is > provided. How does #2 account for it? I guess with #2 there should be a way > to provide a "default" delegate, by e.g. leaving all properties (indexValue, > roleValue) unset so that it acts a sort of wildcard? > > > A default delegate looks like the sensible way to go indeed. > But should we REQUIRE one ? Why can't we just not instantiate something > when no fitting delegate is found ? That's what I believe #1 is actually doing. It's an interesting question. :D Personally I don't see the point. The behaviour for views has always been that there will always be a delegate available when it is needed. How would "missing" delegates work? I would imagine that would mess up something, somewhere internally in Qt Quick view classes. Or to ask it a different way: why do you have data in your model if it shouldn't be displayed? From stefbon at gmail.com Mon Aug 6 22:08:09 2018 From: stefbon at gmail.com (Stef Bon) Date: Mon, 6 Aug 2018 22:08:09 +0200 Subject: [Development] About 3D desktop. In-Reply-To: <19705C49-6273-46C1-8E40-F638685168C1@qt.io> References: <19705C49-6273-46C1-8E40-F638685168C1@qt.io> Message-ID: Thank you both for the info. I've been thinking about a desktop in the form of a cube, simular like the 3D cube ysed by KDE. This cube is only activated by the switching of the desktop (1->2) for example, and the ctrl-F11 key, sooming out of the cube. That cube is - I think - the basis for a good 3D desktop. The current desktop effects disappear when going back to the default state, I want them to be visible always. It's required to have a perspective of some kind, and coordinates like: - x (distand from left under corner horizontally) - y (distand from left under corner vertically) - z (depth from the "front") There are already rules to go from these 3d coordinates (x, y, z) to 2d (xx, yy). When doing so, it should be possible to put windows "futher" away, and get the window closer by moving the window to you, or closer by going closer yourself, possibly passing other windows. Other visual effects like a 3d presentation of the network would be very nice. And I don't think that heavy hardware is required. Maybe we should start a project somewhere, do you agree? Stef From stefbon at gmail.com Tue Aug 7 06:34:03 2018 From: stefbon at gmail.com (Stef Bon) Date: Tue, 7 Aug 2018 06:34:03 +0200 Subject: [Development] About 3D desktop. In-Reply-To: References: <19705C49-6273-46C1-8E40-F638685168C1@qt.io> Message-ID: Oeps, where I write distand I mean distance. In my language (Dutch) the word for distance is "afstand", notice the trailing d. But I can safely assume everybody who read my post did understand it.... ;) Stef From svenn-arne.dragly at qt.io Tue Aug 7 10:11:55 2018 From: svenn-arne.dragly at qt.io (Svenn-Arne Dragly) Date: Tue, 7 Aug 2018 10:11:55 +0200 Subject: [Development] Programmable delegate selection for QML views In-Reply-To: References: <20180806134306.4c39137d@qdesktop> Message-ID: On 08/06/2018 05:03 PM, Mitch Curtis wrote: >> -----Original Message----- >> From: gr3cko at gmail.com On Behalf Of Pierre-Yves >> >> >> A default delegate looks like the sensible way to go indeed. >> But should we REQUIRE one ? Why can't we just not instantiate something >> when no fitting delegate is found ? That's what I believe #1 is actually doing. > It's an interesting question. :D Personally I don't see the point. The behaviour for views has always been that there will always be a delegate available when it is needed. How would "missing" delegates work? I would imagine that would mess up something, somewhere internally in Qt Quick view classes. > > Or to ask it a different way: why do you have data in your model if it shouldn't be displayed? Sounds like it would be useful to filter data in a view. For instance, if you have multiple views of the same data, but want only certain data categories in each view. This could also be used to create dynamic filters with a custom delegate chooser. That being said, we already have existing and powerful mechanisms to filter data in Qt, and I'm not sure if adding yet another mechanism to choose from is a good idea. However, I see many users setting the "visible" property of their delegates based on some logic as a hacky filter implementation today (just search for "how to filter data in QML"). This is typically because subclassing QSortFilterProxyModel is too much hassle for a simple list, for instance if all you need is a ListModel with 50 items and a search box. I don't have a complete overview of models/views in QML, so please correct me if there are other simple, yet more elegant ways of filtering in these simple cases. Otherwise, this might be worth keeping in mind in this discussion. Svenn-Arne From paolo.angelelli at qt.io Tue Aug 7 11:16:09 2018 From: paolo.angelelli at qt.io (Paolo Angelelli) Date: Tue, 7 Aug 2018 11:16:09 +0200 Subject: [Development] Programmable delegate selection for QML views In-Reply-To: References: <20180806134306.4c39137d@qdesktop> Message-ID: <20180807111609.240617b4@qdesktop> On Mon, 6 Aug 2018 15:34:00 +0200 Pierre-Yves Siret wrote: > > - it can only nest (and thus load) QQuickItems, being a QQuickItem itself > Loader can wrap QObject too. This works : Instantiator { Loader { QtObject > {} } } > http://doc.qt.io/qt-5/qml-qtquick-loader.html#sourceComponent-prop : "Since > QtQuick 2.0, Loader is able to load any type of object; it is not > restricted to Item types." True, but that example is a bit artificial. How about nesting some other QObject * subclass that should be the delegate in a view? And, also, loaded elements are childItems of the Loader itself, if QQuickItems. If it's a QObject only, there's the "QObject *item" property instead. But then views should then handle the Loader case specifically to extract the QObject. If the view uses a delegate model, instead, at least with options 2. and 3., it would require no special handling. If the view is supposed to have QObject delegates and does not support (in principle) a Loader, no special handling would be required. From frederik.gladhorn at qt.io Tue Aug 7 11:46:12 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Tue, 07 Aug 2018 11:46:12 +0200 Subject: [Development] Closing issues automatically with new keyword Message-ID: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> Hi all, I've spend a bit of time writing a script that monitors gerrit and the git repositories to update JIRA statuses. It's not quite done yet, but getting there. Basically it should be able to set the fixed version and close tasks automatically. Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the keyword to trigger this. The plan is to update the fix versions and close the task as done when a line in the commit message starts with "Fixes:". If the issue is already closed (e.g. cherry-pick) it can add an additional fix version (e.g. 5.9.7). Note: Task-number will be used as before as "this is related to the issue in some way". Cheers, Frederik From Tor.arne.Vestbo at qt.io Tue Aug 7 11:52:26 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Tue, 7 Aug 2018 09:52:26 +0000 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> Message-ID: <1413CACE-7297-4C68-A703-2781E193CC44@qt.io> On 7 Aug 2018, at 11:46, Frederik Gladhorn wrote: > > Hi all, > > I've spend a bit of time writing a script that monitors gerrit and the git > repositories to update JIRA statuses. It's not quite done yet, but getting > there. > Basically it should be able to set the fixed version and close tasks > automatically. > Excellent! > Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the keyword > to trigger this. Sounds good! Perhaps the commit message template should include this field at the bottom too? > > The plan is to update the fix versions and close the task as done when a line > in the commit message starts with "Fixes:". > If the issue is already closed (e.g. cherry-pick) it can add an additional fix > version (e.g. 5.9.7). > > Note: Task-number will be used as before as "this is related to the issue in > some way”. Good :) Tor Arne > > Cheers, > Frederik > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From christian.kandeler at qt.io Tue Aug 7 13:07:12 2018 From: christian.kandeler at qt.io (Christian Kandeler) Date: Tue, 7 Aug 2018 13:07:12 +0200 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> Message-ID: <20180807130416.33992b0f@ckandeler-archlinux> On Tue, 7 Aug 2018 11:46:12 +0200 Frederik Gladhorn wrote: > I've spend a bit of time writing a script that monitors gerrit and the git > repositories to update JIRA statuses. It's not quite done yet, but getting > there. > Basically it should be able to set the fixed version and close tasks > automatically. > > Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the keyword > to trigger this. Sounds like an excellent plan. Thanks. Christian From jani.heikkinen at qt.io Tue Aug 7 13:59:02 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 7 Aug 2018 11:59:02 +0000 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> Message-ID: >________________________________________ >From: Development on behalf of Frederik Gladhorn >Sent: Tuesday, August 7, 2018 12:46 PM >To: development at qt-project.org >Subject: [Development] Closing issues automatically with new keyword > >Hi all, > >I've spend a bit of time writing a script that monitors gerrit and the git >repositories to update JIRA statuses. It's not quite done yet, but getting >there. >Basically it should be able to set the fixed version and close tasks >automatically. > >Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the keyword >to trigger this. > >The plan is to update the fix versions and close the task as done when a line >in the commit message starts with "Fixes:". >If the issue is already closed (e.g. cherry-pick) it can add an additional fix >version (e.g. 5.9.7). > >Note: Task-number will be used as before as "this is related to the issue in >some way". > >Cheers, >Frederik Hi, I see at least one problem there: If bug is affecting to several branches it will be closed when fix for first branch is done even in that case it shouldn't be closed until every branch has a fix... Another concern or question is that in which phase we should close the bug; is it done immediately when fix is in or should it be done when fix is in the packages and someone can verify that fix is there and really fixes the problem... br, Jani _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From alexander.blasche at qt.io Tue Aug 7 14:10:08 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Tue, 7 Aug 2018 12:10:08 +0000 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> Message-ID: > -----Original Message----- > From: Development project.org> On Behalf Of Jani Heikkinen > >The plan is to update the fix versions and close the task as done when > >a line in the commit message starts with "Fixes:". > >If the issue is already closed (e.g. cherry-pick) it can add an > >additional fix version (e.g. 5.9.7). The devil is in the detail. We don't want FixVersion to be set to 5.11 but set to 5.11.x. When you look at a bug 6 month down the road you don't want to know that it was fixed in 5.11 but you want to know the exact patch level release. Especially the LTS releases tend to have many patch lvl number. This implies that the script needs to know when 5.11.x was branched off and that every following commit to 5.11 branch will imply 5.11.x+1. Whether x+1 may never be released is irrelevant though as that's a simple bulk change when the decision to not have x+1 comes through. Is this what you intend to do? > I see at least one problem there: If bug is affecting to several branches it will be > closed when fix for first branch is done even in that case it shouldn't be closed > until every branch has a fix... That's the developer's decision as much as it is today already. If you know that the fix should go to multiple branches you should probably not use the "Fixes" keyword for the first commit but the existing "Task-number" keyword. > Another concern or question is that in which phase we should close the bug; is it > done immediately when fix is in or should it be done when fix is in the packages > and someone can verify that fix is there and really fixes the problem... It can only ever be when it is in the code line. That's correct for 90% of all cases. We cannot optimize for the case when releasing becomes creative and starts shifting around SHA's or decides to create the package. I am sure releasing does not want to be responsible for setting the fix version across all tasks. It does not scale. In other words the status quo applies. -- Alex From oswald.buddenhagen at qt.io Tue Aug 7 14:14:56 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 7 Aug 2018 14:14:56 +0200 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> Message-ID: <20180807121456.GC15176@troll08> On Tue, Aug 07, 2018 at 11:46:12AM +0200, Frederik Gladhorn wrote: > I've spend a bit of time writing a script that monitors gerrit and the git > repositories to update JIRA statuses. It's not quite done yet, but getting > there. > so why exactly are you doing this after i implied in https://bugreports.qt.io/browse/QTQAINFRA-171 that you should have a look at https://gerrit-review.googlesource.com/admin/repos/plugins/hooks-jira ? did your investigation reveal that it's unsalvagably bad? after the elusive gerrit upgrade (hey, we finally have someone assigned to that now (!)), either script based solution will be obsoleted by deploying https://gerrit-review.googlesource.com/admin/repos/plugins/its-jira anyway. From robert.loehning at qt.io Tue Aug 7 15:23:52 2018 From: robert.loehning at qt.io (=?UTF-8?Q?Robert_L=c3=b6hning?=) Date: Tue, 7 Aug 2018 15:23:52 +0200 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> Message-ID: <2a0b9a2b-9d70-b4fb-c061-0daa5f0f4699@qt.io> Am 07.08.2018 um 11:46 schrieb Frederik Gladhorn: > Hi all, > > I've spend a bit of time writing a script that monitors gerrit and the git > repositories to update JIRA statuses. It's not quite done yet, but getting > there. > Basically it should be able to set the fixed version and close tasks > automatically. > > Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the keyword > to trigger this. > > The plan is to update the fix versions and close the task as done when a line > in the commit message starts with "Fixes:". > If the issue is already closed (e.g. cherry-pick) it can add an additional fix > version (e.g. 5.9.7). > > Note: Task-number will be used as before as "this is related to the issue in > some way". > > Cheers, > Frederik Hi, would that work for all project in JIRA immediately or only in QTBUG? Cheers, Robert From frederik.gladhorn at qt.io Tue Aug 7 15:55:49 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Tue, 07 Aug 2018 15:55:49 +0200 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <2a0b9a2b-9d70-b4fb-c061-0daa5f0f4699@qt.io> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> <2a0b9a2b-9d70-b4fb-c061-0daa5f0f4699@qt.io> Message-ID: <7421781.eaTo4E01dM@frederik-thinkcentre-m93p> On tirsdag 7. august 2018 15.23.52 CEST Robert Löhning wrote: > Am 07.08.2018 um 11:46 schrieb Frederik Gladhorn: > > Hi all, > > > > I've spend a bit of time writing a script that monitors gerrit and the git > > repositories to update JIRA statuses. It's not quite done yet, but getting > > there. > > Basically it should be able to set the fixed version and close tasks > > automatically. > > > > Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the > > keyword to trigger this. > > > > The plan is to update the fix versions and close the task as done when a > > line in the commit message starts with "Fixes:". > > If the issue is already closed (e.g. cherry-pick) it can add an additional > > fix version (e.g. 5.9.7). > > > > Note: Task-number will be used as before as "this is related to the issue > > in some way". > > > > Cheers, > > Frederik > > Hi, > > would that work for all project in JIRA immediately or only in QTBUG? It should work for all. Frederik > > Cheers, > Robert > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From frederik.gladhorn at qt.io Tue Aug 7 16:06:38 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Tue, 07 Aug 2018 16:06:38 +0200 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <20180807121456.GC15176@troll08> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> <20180807121456.GC15176@troll08> Message-ID: <3530391.ICdTGMbFkB@frederik-thinkcentre-m93p> On tirsdag 7. august 2018 14.14.56 CEST Oswald Buddenhagen wrote: > On Tue, Aug 07, 2018 at 11:46:12AM +0200, Frederik Gladhorn wrote: > > I've spend a bit of time writing a script that monitors gerrit and the git > > repositories to update JIRA statuses. It's not quite done yet, but getting > > there. > > so why exactly are you doing this after i implied in > https://bugreports.qt.io/browse/QTQAINFRA-171 that you should have a > look at > https://gerrit-review.googlesource.com/admin/repos/plugins/hooks-jira ? > did your investigation reveal that it's unsalvagably bad? I guess it could work, it can close issues, but it doesn't have any idea about versions. I just looked at the code now. > > after the elusive gerrit upgrade (hey, we finally have someone assigned > to that now (!)), either script based solution will be obsoleted by > deploying > https://gerrit-review.googlesource.com/admin/repos/plugins/its-jira > anyway. I was not aware of/forgot that comment. I am also unsure if I want to wait for that gerrit update to manifest. I'd really like to get the fix version set, so that we can generate change logs more easily when it comes to fixed issues for each release. Cheers, Frederik > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Tor.arne.Vestbo at qt.io Tue Aug 7 16:10:13 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Tue, 7 Aug 2018 14:10:13 +0000 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <3530391.ICdTGMbFkB@frederik-thinkcentre-m93p> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> <20180807121456.GC15176@troll08> <3530391.ICdTGMbFkB@frederik-thinkcentre-m93p> Message-ID: > On 7 Aug 2018, at 16:06, Frederik Gladhorn wrote: > > On tirsdag 7. august 2018 14.14.56 CEST Oswald Buddenhagen wrote: >> On Tue, Aug 07, 2018 at 11:46:12AM +0200, Frederik Gladhorn wrote: >>> I've spend a bit of time writing a script that monitors gerrit and the git >>> repositories to update JIRA statuses. It's not quite done yet, but getting >>> there. >> >> so why exactly are you doing this after i implied in >> https://bugreports.qt.io/browse/QTQAINFRA-171 that you should have a >> look at >> https://gerrit-review.googlesource.com/admin/repos/plugins/hooks-jira ? >> did your investigation reveal that it's unsalvagably bad? > > I guess it could work, it can close issues, but it doesn't have any idea about > versions. I just looked at the code now. > >> >> after the elusive gerrit upgrade (hey, we finally have someone assigned >> to that now (!)), either script based solution will be obsoleted by >> deploying >> https://gerrit-review.googlesource.com/admin/repos/plugins/its-jira >> anyway. > > I was not aware of/forgot that comment. I am also unsure if I want to wait for > that gerrit update to manifest. Agreed, let’s decouple these two tasks for now. If it turns out the script will be obsoleted, so be it 😊 Tor Arne > I'd really like to get the fix version set, so that we can generate change > logs more easily when it comes to fixed issues for each release. > > Cheers, > Frederik > >> >> _______________________________________________ >> 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 thiago.macieira at intel.com Tue Aug 7 16:38:22 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 7 Aug 2018 07:38:22 -0700 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> Message-ID: <2089210.gsFpQPFeWQ@tjmaciei-mobl1> On Tuesday, 7 August 2018 04:59:02 PDT Jani Heikkinen wrote: > I see at least one problem there: If bug is affecting to several branches it > will be closed when fix for first branch is done even in that case it > shouldn't be closed until every branch has a fix... I usually close the bug when the first branch gets the fix. When the other branches get it, I just update the bug report with an extra Fix For and SHA-1. This is a nice way for the script to do the same. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Aug 7 16:39:28 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 7 Aug 2018 07:39:28 -0700 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> Message-ID: <2311687.Ih8nHYcld9@tjmaciei-mobl1> On Tuesday, 7 August 2018 02:46:12 PDT Frederik Gladhorn wrote: > The plan is to update the fix versions and close the task as done when a > line in the commit message starts with "Fixes:". Thanks, Frederik! Please update the changelog-creation script to detect this keyword too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From stefbon at gmail.com Tue Aug 7 16:54:32 2018 From: stefbon at gmail.com (Stef Bon) Date: Tue, 7 Aug 2018 16:54:32 +0200 Subject: [Development] About 3D desktop. In-Reply-To: References: <19705C49-6273-46C1-8E40-F638685168C1@qt.io> Message-ID: Thanks a lot for the time. I'm kind of busy now, but soon (2/3 days) I will come with a response. We'll build an awesome 3D desktop! Stef From jung at drimaes.com Tue Aug 7 17:40:27 2018 From: jung at drimaes.com (Young Moon Jung) Date: Wed, 8 Aug 2018 00:40:27 +0900 Subject: [Development] Question about qml compiler? Message-ID: Hi All of qt members. I have a question about qml compiler. I want to develop application which is based on QML with Qt 5.6.0. ( open source license ) When I checked below link, I saw that qml compiler is commercial license. *https://www.embeddeduse.com/2016/04/10/using-qt-5-6-and-later-under-lgpl/ * My Question is that Should I use qml compiler for developing QML application? I think I can develop QML application only use qmake like below. ( qmake /Users/josh/untitled7/untitled7.pro -spec macx-clang CONFIG+=debug CONFIG+=x86_64 CONFIG+=qml_debug && /usr/bin/make qmake_all ) Thanks & Regards, Josh. -- *Jung Young Moon DrimAES Inc.* *Address* *#803, Ace Twin Tower 2-cha, 273, Digital-ro, Guro-gu, Seoul, Korea * *Mobile* *+82 (0)10 - 4907 - 2117* *Mail* jung at drimaes.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Aug 7 19:32:17 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 7 Aug 2018 10:32:17 -0700 Subject: [Development] Question about qml compiler? In-Reply-To: References: Message-ID: <2864593.s6NA25UcZx@tjmaciei-mobl1> On Tuesday, 7 August 2018 08:40:27 PDT Young Moon Jung wrote: > My Question is that Should I use qml compiler for developing QML > application? It's your choice whether you want to use it or not. But as you noticed, the compiler is a tool only made available for commercial customers. If you want it, you have to obtain a commercial license. But if you upgrade to 5.9, you get qmlcachegen. Note that the cachegen tool is not a replacement for the compiler: it's a cache. The source of the QML still needs to be present somewhere. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oswald.buddenhagen at qt.io Tue Aug 7 21:27:14 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 7 Aug 2018 21:27:14 +0200 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <3530391.ICdTGMbFkB@frederik-thinkcentre-m93p> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> <20180807121456.GC15176@troll08> <3530391.ICdTGMbFkB@frederik-thinkcentre-m93p> Message-ID: <20180807192714.GD15176@troll08> On Tue, Aug 07, 2018 at 04:06:38PM +0200, Frederik Gladhorn wrote: > On tirsdag 7. august 2018 14.14.56 CEST Oswald Buddenhagen wrote: > > https://gerrit-review.googlesource.com/admin/repos/plugins/hooks-jira ? > > did your investigation reveal that it's unsalvagably bad? > > I guess it could work, it can close issues, > well, obviously. that's the preferred approach, because the gerrit-based trigger is easier to get reliable than an external script. > but it doesn't have any idea about versions. I just looked at the code > now. > your script should be integrated then. > > https://gerrit-review.googlesource.com/admin/repos/plugins/its-jira > > I'd really like to get the fix version set, so that we can generate change > logs more easily when it comes to fixed issues for each release. > yes, me as well. if that feature is missing in the plugin, let's contribute it - this really looks like something everyone would want. From roland.m.winklmeier at gmail.com Tue Aug 7 21:56:10 2018 From: roland.m.winklmeier at gmail.com (Roland Winklmeier) Date: Tue, 7 Aug 2018 21:56:10 +0200 Subject: [Development] How to create a Qt5 offline installer myself Message-ID: Dear Qt Devs, I think I asked this question in the past, but I never got a reasonable answer. The question is actually quite simple: How can I create a Qt5 offline installer for example for 5.11.1 MinGW 5.3.0 32 bit? I'm aware of the qt/qtsdk repository and its scripts. There is also some high level description in the READMEs. But following the coin builds, those are using GO scripts which are as far as I can see not public.So that means, Qt build servers have been using those python scripts in the past, but now they don't and that renders them in fact untested and unmaintained. I don't mind doing more steps manual (even if automating it fully would be super great), but I cannot even find a easy way of doing it manually. It was often mentioned in this mailing list, that users/developers can build their own version of Qt and the official binaries are just a subset. That's fair enough and I can and do regularly build Qt on my own. But my own build doesn't help me much, if I cannot bundle it into a proper installer and make it available to other people and/or build servers.To me, this is still a very important step which should be properly documented and as easy reproducable as the regular Qt5 build. So if anyone has a good and easy to follow guide, how to produce my own offline installer, please share it with me. Ideally we come up with a wiki page similar to https://wiki.qt.io/Building_Qt_5_from_Git. The reason why I'm asking is, that I would like to try and get some changes into the binaries (release build with debug symbols for crash dumps, MSVC 2017 32 and 64 bit builds etc). Looking forward to any help. Thanks, Roland -------------- next part -------------- An HTML attachment was scrubbed... URL: From jung at drimaes.com Wed Aug 8 03:19:10 2018 From: jung at drimaes.com (Young Moon Jung) Date: Wed, 8 Aug 2018 10:19:10 +0900 Subject: [Development] Question about qml compiler? In-Reply-To: References: Message-ID: Hi Thiago. Thank you for your reply! It was very helpful for me. I have a one more question. Actually I load .qml file in main.cpp by using QQmlApplicationEngine Class. Is it mean that I can compile qml application with qmake? Thanks & Regards, Josh. 2018-08-08 0:40 GMT+09:00 Young Moon Jung : > Hi All of qt members. > > I have a question about qml compiler. > I want to develop application which is based on QML with Qt 5.6.0. ( open > source license ) > > When I checked below link, I saw that qml compiler is commercial license. > > > > *https://www.embeddeduse.com/2016/04/10/using-qt-5-6-and-later-under-lgpl/ > * > My Question is that Should I use qml compiler for developing QML > application? > I think I can develop QML application only use qmake like below. > ( qmake /Users/josh/untitled7/untitled7.pro -spec macx-clang > CONFIG+=debug CONFIG+=x86_64 CONFIG+=qml_debug && /usr/bin/make qmake_all ) > > > > Thanks & Regards, > Josh. > > > -- > *Jung Young Moon DrimAES Inc.* > > *Address* *#803, Ace Twin Tower 2-cha, 273, Digital-ro, Guro-gu, Seoul, > Korea > * > *Mobile* *+82 (0)10 - 4907 - 2117* > *Mail* jung at drimaes.com > > > -- *Jung Young Moon DrimAES Inc.* *Address* *#803, Ace Twin Tower 2-cha, 273, Digital-ro, Guro-gu, Seoul, Korea * *Mobile* *+82 (0)10 - 4907 - 2117* *Mail* jung at drimaes.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kushnirtv at gmail.com Wed Aug 8 06:53:27 2018 From: kushnirtv at gmail.com (Taras Kushnir) Date: Wed, 8 Aug 2018 07:53:27 +0300 Subject: [Development] Automatic signal-slot statistics Message-ID: Hello I’ve been refactoring giant pieces (like 50-60%) of one project's codebase and I’m concerned about validity/quality of the result. Except different kinds of tests I’m thinking about statistical metrics one of which would be to get a feel how Qt-specific parts of the project have changes. Is there any way to produce statistics which signals got fired and how many times (+ the same for slots) automatically during any application runtime? (“any" way except of patching and recompiling Qt framework itself) Best regards, Taras Kushnir From olivier at woboq.com Wed Aug 8 07:15:02 2018 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 8 Aug 2018 07:15:02 +0200 Subject: [Development] Automatic signal-slot statistics In-Reply-To: References: Message-ID: <05c3e66d-f2c1-9bb0-2d3d-243ca70587d7@woboq.com> On 2018-08-08 06:53, Taras Kushnir wrote: > Hello > > I’ve been refactoring giant pieces (like 50-60%) of one project's codebase and I’m concerned about validity/quality of the result. Except different kinds of tests I’m thinking about statistical metrics one of which would be to get a feel how Qt-specific parts of the project have changes. > > Is there any way to produce statistics which signals got fired and how many times (+ the same for slots) automatically during any application runtime? > (“any" way except of patching and recompiling Qt framework itself) There is a way: There is some exported private API from qobject_p.h that you can trivially re-declare in your project: struct QSignalSpyCallbackSet { typedef void (*BeginCallback)(QObject *caller, int signal_or_method_index, void **argv); typedef void (*EndCallback)(QObject *caller, int signal_or_method_index); BeginCallback signal_begin_callback, slot_begin_callback; EndCallback signal_end_callback, slot_end_callback; }; void Q_CORE_EXPORT qt_register_signal_spy_callbacks(const QSignalSpyCallbackSet &callback_set); extern QSignalSpyCallbackSet Q_CORE_EXPORT qt_signal_spy_callback_set; https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qobject_p.h.html#73 All you need to do is to call qt_register_signal_spy_callbacks to register the signal_begin_callback, and this will be called everytime a signal is emited. So you can gather some statistics from that. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From kushnirtv at gmail.com Wed Aug 8 08:48:24 2018 From: kushnirtv at gmail.com (Taras Kushnir) Date: Wed, 8 Aug 2018 09:48:24 +0300 Subject: [Development] Automatic signal-slot statistics In-Reply-To: <05c3e66d-f2c1-9bb0-2d3d-243ca70587d7@woboq.com> References: <05c3e66d-f2c1-9bb0-2d3d-243ca70587d7@woboq.com> Message-ID: Hi Olivier Thanks for fast response. Sorry for asking trivial questions but I didn’t quite understand about “redeclaring” things in my project. As far as I understand all I need to do is pass an instance of [QSignalSpyCallbackSet] struct with my custom callbacks to [qt_register_signal_spy_callbacks], isn’t it? Can you please clarify “redeclaring”? Thanks, Taras > On Aug 8, 2018, at 08:15, Olivier Goffart wrote: > > On 2018-08-08 06:53, Taras Kushnir wrote: >> Hello >> I’ve been refactoring giant pieces (like 50-60%) of one project's codebase and I’m concerned about validity/quality of the result. Except different kinds of tests I’m thinking about statistical metrics one of which would be to get a feel how Qt-specific parts of the project have changes. >> Is there any way to produce statistics which signals got fired and how many times (+ the same for slots) automatically during any application runtime? >> (“any" way except of patching and recompiling Qt framework itself) > > > There is a way: > There is some exported private API from qobject_p.h that you can trivially re-declare in your project: > > > struct QSignalSpyCallbackSet > { > typedef void (*BeginCallback)(QObject *caller, int signal_or_method_index, void **argv); > typedef void (*EndCallback)(QObject *caller, int signal_or_method_index); > BeginCallback signal_begin_callback, > slot_begin_callback; > EndCallback signal_end_callback, > slot_end_callback; > }; > void Q_CORE_EXPORT qt_register_signal_spy_callbacks(const QSignalSpyCallbackSet &callback_set); > > extern QSignalSpyCallbackSet Q_CORE_EXPORT qt_signal_spy_callback_set; > > https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qobject_p.h.html#73 > > > All you need to do is to call qt_register_signal_spy_callbacks to register the signal_begin_callback, and this will be called everytime a signal is emited. So you can gather some statistics from that. > > > -- > Olivier > > Woboq - Qt services and support - https://woboq.com - https://code.woboq.org > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From olivier at woboq.com Wed Aug 8 08:52:25 2018 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 8 Aug 2018 08:52:25 +0200 Subject: [Development] Automatic signal-slot statistics In-Reply-To: References: <05c3e66d-f2c1-9bb0-2d3d-243ca70587d7@woboq.com> Message-ID: On 2018-08-08 08:48, Taras Kushnir wrote: > Hi Olivier > > Thanks for fast response. > > Sorry for asking trivial questions but I didn’t quite understand about “redeclaring” things in my project. > > As far as I understand all I need to do is pass an instance of [QSignalSpyCallbackSet] struct with my custom callbacks to [qt_register_signal_spy_callbacks], isn’t it? Can you please clarify “redeclaring”? That's right, you just need to pass an instance of QSignalSpyCallbackSet. Since you can't #include as it is a private header, you can just re-declare the relevant symbols. If you can include private headers, then simply include qobject_p.h. -- Olivier From kotov.valery at gmail.com Wed Aug 8 09:10:43 2018 From: kotov.valery at gmail.com (Valery Kotov) Date: Wed, 8 Aug 2018 09:10:43 +0200 Subject: [Development] Storing and managing ValueArray inside QV4::Heap objects Message-ID: Hello all, I have a question about QV4 heap objects and what could be stored in them. I would like to move data structure from c++ heap to GC heap. Unfortunately, my data structure stores a pair of QLists internally. As far as I'm aware, QV4::Heap objects should be "trivially constructible", and thus, cannot store QList(s). One option would be to store QList pointer and manage it's lifecycle manually. But that does not sound like a good idea. I've noticed though, that some of qv4 types are using DECLARE_MARKOBJECTS macro. By using DECLARE_MARKOBJECTS macro and ObjectMember(s) define I can actually store a ValueArray member in my QV4 heap object. #define MyObjectMembers(class, Member) \ Member(class, ValueArray, ValueArray, myValues) DECLARE_HEAP_OBJECT(MyObject, Object) { DECLARE_MARKOBJECTS(MyObject); In this case I can refer to myValues ValueArray type inside of MyObject. Unfortunately, it is a little bit unclear to me how to manage ValueArrays. >From what I can see from some examples in the code (qv4generatorobject, qv4arraydata), it seems that I need to manage ValueArray manually. What I'm missing at the moment a little bit is how the actually allocation for ValueArray.values is done. I suspect that it is probably not done via plain "new" call. Otherwise it is a little bit confusing why not just to store the pointer directly. Could you guys please give me a few hints how to go about ValueArray management? Thank you! Sincerely yours, Valery Kotov -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Wed Aug 8 09:32:52 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Wed, 8 Aug 2018 07:32:52 +0000 Subject: [Development] Storing and managing ValueArray inside QV4::Heap objects In-Reply-To: References: Message-ID: Hi, If you want to use the ValueArray, then you need to make sure that it's the last member of your type. Then encapsulate the creation if the type in a factory function that works a bit like ExecutionContext::newCallContext: (1) Calculate how much memory you're going to need for the type _and_ the value array (minus one Value). (2) Allocate the memory with one call to allocManaged. (3) call init() manually. (4) Set the alloc and size members of the value array to the amount of allocated values. While this approach is clever in the sense that it gives a compact memory representation and allocates object and array data in one shot, it also means that it's not so suitable for frequent dynamic resizing as it will require re-allocating the entire object. If you have a fully dynamic array, then the alternative would be to store a pointer to your QVector in the heap object. Heap::QQmlSequence does that, for example. Just make sure to use V4_NEEDS_DESTROY and provide a destroy() function to delete the vector. I'd probably go for the first approach with perhaps an indirect type (similar to how Object has MemberData) if the array contains references to the JS heap. If your array has only references to the C heap, then you're probably better off using a pointer to a regular vector. Simon ________________________________ From: Development on behalf of Valery Kotov Sent: Wednesday, August 8, 2018 9:10:43 AM To: Qt development mailing list Subject: [Development] Storing and managing ValueArray inside QV4::Heap objects Hello all, I have a question about QV4 heap objects and what could be stored in them. I would like to move data structure from c++ heap to GC heap. Unfortunately, my data structure stores a pair of QLists internally. As far as I'm aware, QV4::Heap objects should be "trivially constructible", and thus, cannot store QList(s). One option would be to store QList pointer and manage it's lifecycle manually. But that does not sound like a good idea. I've noticed though, that some of qv4 types are using DECLARE_MARKOBJECTS macro. By using DECLARE_MARKOBJECTS macro and ObjectMember(s) define I can actually store a ValueArray member in my QV4 heap object. #define MyObjectMembers(class, Member) \ Member(class, ValueArray, ValueArray, myValues) DECLARE_HEAP_OBJECT(MyObject, Object) { DECLARE_MARKOBJECTS(MyObject); In this case I can refer to myValues ValueArray type inside of MyObject. Unfortunately, it is a little bit unclear to me how to manage ValueArrays. >From what I can see from some examples in the code (qv4generatorobject, qv4arraydata), it seems that I need to manage ValueArray manually. What I'm missing at the moment a little bit is how the actually allocation for ValueArray.values is done. I suspect that it is probably not done via plain "new" call. Otherwise it is a little bit confusing why not just to store the pointer directly. Could you guys please give me a few hints how to go about ValueArray management? Thank you! Sincerely yours, Valery Kotov -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Wed Aug 8 09:34:50 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 8 Aug 2018 07:34:50 +0000 Subject: [Development] Storing and managing ValueArray inside QV4::Heap objects In-Reply-To: References: Message-ID: Hi Valery, > On 8 Aug 2018, at 09:10, Valery Kotov wrote: > > Hello all, > > I have a question about QV4 heap objects and what could be stored in them. > I would like to move data structure from c++ heap to GC heap. Unfortunately, my data structure stores a pair of QLists internally. > As far as I'm aware, QV4::Heap objects should be "trivially constructible", and thus, cannot store QList(s). > One option would be to store QList pointer and manage it's lifecycle manually. But that does not sound like a good idea. > I've noticed though, that some of qv4 types are using DECLARE_MARKOBJECTS macro. By using DECLARE_MARKOBJECTS macro and ObjectMember(s) define I can actually store a ValueArray member in my QV4 heap object. > > #define MyObjectMembers(class, Member) \ > Member(class, ValueArray, ValueArray, myValues) > > DECLARE_HEAP_OBJECT(MyObject, Object) { > DECLARE_MARKOBJECTS(MyObject); > > In this case I can refer to myValues ValueArray type inside of MyObject. > Unfortunately, it is a little bit unclear to me how to manage ValueArrays. > From what I can see from some examples in the code (qv4generatorobject, qv4arraydata), it seems that I need to manage ValueArray manually. > What I'm missing at the moment a little bit is how the actually allocation for ValueArray.values is done. > I suspect that it is probably not done via plain "new" call. Otherwise it is a little bit confusing why not just to store the pointer directly. > > Could you guys please give me a few hints how to go about ValueArray management? ValueArrays are allocated with a given size together with the object through the memory manager. They are rather low level, and can’t be resized after initial allocation. That means to get a larger ValueArray you need to allocate a new object. Maybe what you need is closer to a Pointer to a SimpleArrayData. Those are separately allocated by the memory manager, and you can grow the array using SimpleArrayData::reallocate(). Cheers, Lars From frederik.gladhorn at qt.io Wed Aug 8 11:58:08 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Wed, 08 Aug 2018 11:58:08 +0200 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> Message-ID: <5952608.qK8quW4kZP@frederik-thinkcentre-m93p> On tirsdag 7. august 2018 14.10.08 CEST Alex Blasche wrote: > > -----Original Message----- > > From: Development > project.org> On Behalf Of Jani Heikkinen > > > > >The plan is to update the fix versions and close the task as done when > > >a line in the commit message starts with "Fixes:". > > >If the issue is already closed (e.g. cherry-pick) it can add an > > >additional fix version (e.g. 5.9.7). > > The devil is in the detail. We don't want FixVersion to be set to 5.11 but > set to 5.11.x. When you look at a bug 6 month down the road you don't want > to know that it was fixed in 5.11 but you want to know the exact patch > level release. Especially the LTS releases tend to have many patch lvl > number. > > This implies that the script needs to know when 5.11.x was branched off and > that every following commit to 5.11 branch will imply 5.11.x+1. Whether x+1 > may never be released is irrelevant though as that's a simple bulk change > when the decision to not have x+1 comes through. Is this what you intend to > do? Indeed, I have to make some assumptions. Right now I have the simple case done: branch == x.y.z -> set fix version to x.y.z. Then there are two cases that I will handle: branch is 'dev' or 'master' -> find the next minor version branch is x.y -> find the next valid patch version Everything else (wip/foobar, other branch names) will be ignored, unless someone explains what to do with them otherwise. > > I see at least one problem there: If bug is affecting to several branches > > it will be closed when fix for first branch is done even in that case it > > shouldn't be closed until every branch has a fix... > > That's the developer's decision as much as it is today already. If you know > that the fix should go to multiple branches you should probably not use the > "Fixes" keyword for the first commit but the existing "Task-number" > keyword. My plan was to let the bot add additional fix versions as changes move through branches. So if a Fixes: QTBUG-9999 goes into 5.12.1, the bug gets closed and fix version set to 5.12.1. When it then gets cherry-picked to 5.9.8, the bot will see the change again and will add a fix version 5.9.8. > > Another concern or question is that in which phase we should close the > > bug; is it done immediately when fix is in or should it be done when fix > > is in the packages and someone can verify that fix is there and really > > fixes the problem... > It can only ever be when it is in the code line. That's correct for 90% of > all cases. We cannot optimize for the case when releasing becomes creative > and starts shifting around SHA's or decides to create the package. I am > sure releasing does not want to be responsible for setting the fix version > across all tasks. It does not scale. In other words the status quo applies. Agreed. There is no magic solution and we need to close bugs, even when the fix is not released yet, otherwise JIRA becomes useless. Everyone will understand that if something is closed for 5.12.0 today, it will not be in their copy of Qt 5.11.0. Right now we often don't set the fix version at all, which is even more harmful in my opinion. Frederik > > -- > Alex From Morten.Sorvig at qt.io Wed Aug 8 12:04:42 2018 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Wed, 8 Aug 2018 10:04:42 +0000 Subject: [Development] LLVM and Qt In-Reply-To: <1982548.xfmXKttzsI@tjmaciei-mobl1> References: <2230146.JdTnKv3ITY@tonks> <1982548.xfmXKttzsI@tjmaciei-mobl1> Message-ID: > On 30 Jul 2018, at 06:00, Thiago Macieira wrote: > > On Sunday, 29 July 2018 13:36:43 PDT Lisandro Damián Nicanor Pérez Meyer > wrote: >> It would also be pretty nice to know if there is a policy with respect the >> llvm supported version. As they do not keep ABI compatibility distros >> normally are forced to ship from two to three versions. As I understand the >> idea in Debian testing/unstable is to have the latest two always available, >> sometimes three of them. That already created some issues for us with Qt >> Creator, as at some point it required a version which was about to be >> removed. > > Same policy for third-party libraries: we work with the latest, unless that > release happened too late in our own release cycle. > > But where do we get LLVM from on a Mac? Is it from Apple? If so, we may need > to keep things working with an old, patched version, in addition to the > latest. Or we require an upgrade with Homebrew. For dev/5.12 we’re going to default to LLVM from homebrew if LLVM_INSTALL_DIR is not set. The Xcode toolchain does actually contain a libclang.dylib, but as far as I can see llvm-config and the clang-c/Index.h header are not included, which means we can’t use it for qdoc. Morten From Morten.Sorvig at qt.io Wed Aug 8 12:04:43 2018 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Wed, 8 Aug 2018 10:04:43 +0000 Subject: [Development] LLVM and Qt In-Reply-To: <1982548.xfmXKttzsI@tjmaciei-mobl1> References: <2230146.JdTnKv3ITY@tonks> <1982548.xfmXKttzsI@tjmaciei-mobl1> Message-ID: <3A79271E-DB64-4C02-83DB-4D558ACB9646@qt.io> > On 30 Jul 2018, at 06:00, Thiago Macieira wrote: > > On Sunday, 29 July 2018 13:36:43 PDT Lisandro Damián Nicanor Pérez Meyer > wrote: >> It would also be pretty nice to know if there is a policy with respect the >> llvm supported version. As they do not keep ABI compatibility distros >> normally are forced to ship from two to three versions. As I understand the >> idea in Debian testing/unstable is to have the latest two always available, >> sometimes three of them. That already created some issues for us with Qt >> Creator, as at some point it required a version which was about to be >> removed. > > Same policy for third-party libraries: we work with the latest, unless that > release happened too late in our own release cycle. > > But where do we get LLVM from on a Mac? Is it from Apple? If so, we may need > to keep things working with an old, patched version, in addition to the > latest. Or we require an upgrade with Homebrew. For dev/5.12 we’re going to default to LLVM from homebrew if LLVM_INSTALL_DIR is not set. The Xcode toolchain does actually contain a libclang.dylib, but as far as I can see llvm-config and the clang-c/Index.h header are not included, which means we can’t use it for qdoc. Morten From kushnirtv at gmail.com Wed Aug 8 12:04:14 2018 From: kushnirtv at gmail.com (Taras Kushnir) Date: Wed, 8 Aug 2018 13:04:14 +0300 Subject: [Development] Automatic signal-slot statistics In-Reply-To: References: <05c3e66d-f2c1-9bb0-2d3d-243ca70587d7@woboq.com> Message-ID: OK, now it's clear. I will try it out and report if that worked. Thanks for your help! ср, 8 серп. 2018 о 09:52 Olivier Goffart пише: > On 2018-08-08 08:48, Taras Kushnir wrote: > > Hi Olivier > > > > Thanks for fast response. > > > > Sorry for asking trivial questions but I didn’t quite understand about > “redeclaring” things in my project. > > > > As far as I understand all I need to do is pass an instance of > [QSignalSpyCallbackSet] struct with my custom callbacks to > [qt_register_signal_spy_callbacks], isn’t it? Can you please clarify > “redeclaring”? > > That's right, you just need to pass an instance of QSignalSpyCallbackSet. > > Since you can't #include as it is a private header, you can > just > re-declare the relevant symbols. If you can include private headers, then > simply include qobject_p.h. > > -- > Olivier > -- Best regards, Taras Kushnir. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre.hartmann at iseg-hv.de Wed Aug 8 12:13:46 2018 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Wed, 8 Aug 2018 12:13:46 +0200 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <5952608.qK8quW4kZP@frederik-thinkcentre-m93p> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> <5952608.qK8quW4kZP@frederik-thinkcentre-m93p> Message-ID: <20e24a2f-c829-3db7-794a-cdbaf1bb3a29@iseg-hv.de> Hi Frederik, one more question: does the script also sets the final Git-SHA1 in the Jira "commits" field? If yes, that would really be a *big* improvement. > Everything else (wip/foobar, other branch names) will be ignored, > unless someone explains what to do with them otherwise. I think that's acceptable. André Am 08.08.2018 um 11:58 schrieb Frederik Gladhorn: > On tirsdag 7. august 2018 14.10.08 CEST Alex Blasche wrote: >>> -----Original Message----- >>> From: Development >> project.org> On Behalf Of Jani Heikkinen >>> >>>> The plan is to update the fix versions and close the task as done when >>>> a line in the commit message starts with "Fixes:". >>>> If the issue is already closed (e.g. cherry-pick) it can add an >>>> additional fix version (e.g. 5.9.7). >> >> The devil is in the detail. We don't want FixVersion to be set to 5.11 but >> set to 5.11.x. When you look at a bug 6 month down the road you don't want >> to know that it was fixed in 5.11 but you want to know the exact patch >> level release. Especially the LTS releases tend to have many patch lvl >> number. >> >> This implies that the script needs to know when 5.11.x was branched off and >> that every following commit to 5.11 branch will imply 5.11.x+1. Whether x+1 >> may never be released is irrelevant though as that's a simple bulk change >> when the decision to not have x+1 comes through. Is this what you intend to >> do? > > Indeed, I have to make some assumptions. > Right now I have the simple case done: branch == x.y.z -> set fix version to > x.y.z. > > Then there are two cases that I will handle: > branch is 'dev' or 'master' -> find the next minor version > branch is x.y -> find the next valid patch version > > Everything else (wip/foobar, other branch names) will be ignored, unless > someone explains what to do with them otherwise. > >>> I see at least one problem there: If bug is affecting to several branches >>> it will be closed when fix for first branch is done even in that case it >>> shouldn't be closed until every branch has a fix... >> >> That's the developer's decision as much as it is today already. If you know >> that the fix should go to multiple branches you should probably not use the >> "Fixes" keyword for the first commit but the existing "Task-number" >> keyword. > > My plan was to let the bot add additional fix versions as changes move through > branches. > So if a Fixes: QTBUG-9999 goes into 5.12.1, the bug gets closed and fix > version set to 5.12.1. When it then gets cherry-picked to 5.9.8, the bot will > see the change again and will add a fix version 5.9.8. > >>> Another concern or question is that in which phase we should close the >>> bug; is it done immediately when fix is in or should it be done when fix >>> is in the packages and someone can verify that fix is there and really >>> fixes the problem... >> It can only ever be when it is in the code line. That's correct for 90% of >> all cases. We cannot optimize for the case when releasing becomes creative >> and starts shifting around SHA's or decides to create the package. I am >> sure releasing does not want to be responsible for setting the fix version >> across all tasks. It does not scale. In other words the status quo applies. > > Agreed. There is no magic solution and we need to close bugs, even when the > fix is not released yet, otherwise JIRA becomes useless. > Everyone will understand that if something is closed for 5.12.0 today, it will > not be in their copy of Qt 5.11.0. > Right now we often don't set the fix version at all, which is even more > harmful in my opinion. > > Frederik > >> >> -- >> Alex > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > From heikki.halmet at qt.io Wed Aug 8 13:07:38 2018 From: heikki.halmet at qt.io (Heikki Halmet) Date: Wed, 8 Aug 2018 11:07:38 +0000 Subject: [Development] Coin maintenance notification Message-ID: Coin production was updated today at Mon Aug 6 13:27:20 EEST 2018 with new baseline. For CI related issues, you may create bug report as instructed in https://wiki.qt.io/Reporting_Bugs#Reporting_bugs_for_Coin and/or consult the internal #qtci IRC-channel. See change-list attached for related patches. Kind regards Heikki Halmet -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: product_baseline_20180808.log Type: application/octet-stream Size: 290 bytes Desc: product_baseline_20180808.log URL: From frederik.gladhorn at qt.io Wed Aug 8 13:15:58 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Wed, 08 Aug 2018 13:15:58 +0200 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <20e24a2f-c829-3db7-794a-cdbaf1bb3a29@iseg-hv.de> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> <5952608.qK8quW4kZP@frederik-thinkcentre-m93p> <20e24a2f-c829-3db7-794a-cdbaf1bb3a29@iseg-hv.de> Message-ID: <14778275.r6jQ7yvqOX@frederik-thinkcentre-m93p> On onsdag 8. august 2018 12.13.46 CEST André Hartmann wrote: > Hi Frederik, > > one more question: does the script also sets the final Git-SHA1 in the > Jira "commits" field? > > If yes, that would really be a *big* improvement. Yes, that's the plan. Frederik > > > Everything else (wip/foobar, other branch names) will be ignored, > > unless someone explains what to do with them otherwise. > > I think that's acceptable. > > André > > Am 08.08.2018 um 11:58 schrieb Frederik Gladhorn: > > On tirsdag 7. august 2018 14.10.08 CEST Alex Blasche wrote: > >>> -----Original Message----- > >>> From: Development >>> project.org> On Behalf Of Jani Heikkinen > >>> > >>>> The plan is to update the fix versions and close the task as done when > >>>> a line in the commit message starts with "Fixes:". > >>>> If the issue is already closed (e.g. cherry-pick) it can add an > >>>> additional fix version (e.g. 5.9.7). > >> > >> The devil is in the detail. We don't want FixVersion to be set to 5.11 > >> but > >> set to 5.11.x. When you look at a bug 6 month down the road you don't > >> want > >> to know that it was fixed in 5.11 but you want to know the exact patch > >> level release. Especially the LTS releases tend to have many patch lvl > >> number. > >> > >> This implies that the script needs to know when 5.11.x was branched off > >> and > >> that every following commit to 5.11 branch will imply 5.11.x+1. Whether > >> x+1 > >> may never be released is irrelevant though as that's a simple bulk change > >> when the decision to not have x+1 comes through. Is this what you intend > >> to > >> do? > > > > Indeed, I have to make some assumptions. > > Right now I have the simple case done: branch == x.y.z -> set fix version > > to x.y.z. > > > > Then there are two cases that I will handle: > > branch is 'dev' or 'master' -> find the next minor version > > branch is x.y -> find the next valid patch version > > > > Everything else (wip/foobar, other branch names) will be ignored, unless > > someone explains what to do with them otherwise. > > > >>> I see at least one problem there: If bug is affecting to several > >>> branches > >>> it will be closed when fix for first branch is done even in that case it > >>> shouldn't be closed until every branch has a fix... > >> > >> That's the developer's decision as much as it is today already. If you > >> know > >> that the fix should go to multiple branches you should probably not use > >> the > >> "Fixes" keyword for the first commit but the existing "Task-number" > >> keyword. > > > > My plan was to let the bot add additional fix versions as changes move > > through branches. > > So if a Fixes: QTBUG-9999 goes into 5.12.1, the bug gets closed and fix > > version set to 5.12.1. When it then gets cherry-picked to 5.9.8, the bot > > will see the change again and will add a fix version 5.9.8. > > > >>> Another concern or question is that in which phase we should close the > >>> bug; is it done immediately when fix is in or should it be done when fix > >>> is in the packages and someone can verify that fix is there and really > >>> fixes the problem... > >> > >> It can only ever be when it is in the code line. That's correct for 90% > >> of > >> all cases. We cannot optimize for the case when releasing becomes > >> creative > >> and starts shifting around SHA's or decides to create the package. I am > >> sure releasing does not want to be responsible for setting the fix > >> version > >> across all tasks. It does not scale. In other words the status quo > >> applies. > > > > Agreed. There is no magic solution and we need to close bugs, even when > > the > > fix is not released yet, otherwise JIRA becomes useless. > > Everyone will understand that if something is closed for 5.12.0 today, it > > will not be in their copy of Qt 5.11.0. > > Right now we often don't set the fix version at all, which is even more > > harmful in my opinion. > > > > Frederik > > > >> -- > >> Alex > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development From edward.welbourne at qt.io Wed Aug 8 13:23:24 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 8 Aug 2018 11:23:24 +0000 Subject: [Development] Apparently dead code: GPU_BLACKLIST and friends Message-ID: Hi all, I notice that QTest includes support, in [0], alongside its BLACKLIST files for problematic tests, for a GPU_BLACKLIST file; there are, however, no GPU_BLACKLIST files anywhere in our source tree (in any currently live branch, from 5.6 to dev). There's a whole complex QTEST_ADD_GPU_BLACKLIST_SUPPORT macro set-up for a hook function named gpu_features() to control this; unless that's activated *and* a GPU_BLACKLIST file is found, the whole GPU blacklisting feature does nothing. * [0] qtbase/src/testlib/qtestblacklist.cpp Inevitably, I'm contemplating a featurectomy. Laszlo, who introduced this for some fragile embedded systems in 2015, doesn't believe it's in use, I don't see any evidence that it's documented anywhere (so I don't expect anyone to be using it outside Qt itself *and* I can only work out how it's supposed to work by reading its code), so I'm hoping no-one will object to this going, perhaps even as soon as 5.12. So, if you're using GPU_BLACKLIST files, please speak up now (or forever hold your peace); and, if you can think of a good reason why this can't be removed from 5.12 - assuming I get round to it before feature freeze - please also speak up, Eddy. From jeanmichael.celerier at gmail.com Wed Aug 8 13:33:06 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Wed, 8 Aug 2018 13:33:06 +0200 Subject: [Development] Apparently dead code: GPU_BLACKLIST and friends In-Reply-To: References: Message-ID: > Inevitably, I'm contemplating a featurectomy. Laszlo, who introduced this for some fragile embedded systems in 2015, doesn't believe it's in use, I don't see any evidence that it's documented anywhere (so I don't expect anyone to be using it outside Qt itself *and* I can only work out how it's supposed to work by reading its code), so I'm hoping no-one will object to this going, perhaps even as soon as 5.12. I remember using it to be able to run integration tests on a virtual X11 server in Travis CI. I'm not the only one : https://github.com/search?p=1&q=QTEST_ADD_GPU_BLACKLIST_SUPPORT_DEFS&type=Code ------- Jean-Michaël Celerier http://www.jcelerier.name On Wed, Aug 8, 2018 at 1:23 PM Edward Welbourne wrote: > Hi all, > > I notice that QTest includes support, in [0], alongside its BLACKLIST > files for problematic tests, for a GPU_BLACKLIST file; there are, > however, no GPU_BLACKLIST files anywhere in our source tree (in any > currently live branch, from 5.6 to dev). There's a whole complex > QTEST_ADD_GPU_BLACKLIST_SUPPORT macro set-up for a hook function named > gpu_features() to control this; unless that's activated *and* a > GPU_BLACKLIST file is found, the whole GPU blacklisting feature does > nothing. > > * [0] qtbase/src/testlib/qtestblacklist.cpp > > Inevitably, I'm contemplating a featurectomy. Laszlo, who introduced > this for some fragile embedded systems in 2015, doesn't believe it's in > use, I don't see any evidence that it's documented anywhere (so I don't > expect anyone to be using it outside Qt itself *and* I can only work out > how it's supposed to work by reading its code), so I'm hoping no-one > will object to this going, perhaps even as soon as 5.12. > > So, if you're using GPU_BLACKLIST files, please speak up now (or forever > hold your peace); and, if you can think of a good reason why this can't > be removed from 5.12 - assuming I get round to it before feature freeze > - please also speak up, > > Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Wed Aug 8 13:41:10 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 8 Aug 2018 11:41:10 +0000 Subject: [Development] Apparently dead code: GPU_BLACKLIST and friends In-Reply-To: References: , Message-ID: I wrote: >> Inevitably, I'm contemplating a featurectomy. Jean-Michaël Celerier (8 August 2018 13:33) replied > I remember using it to be able to run integration tests on a virtual X11 server in Travis CI. How long ago ? Are you *still* using it for this ? Do you anticipate using it with 5.12 or later ? > I'm not the only one : https://github.com/search?p=1&q=QTEST_ADD_GPU_BLACKLIST_SUPPORT_DEFS&type=Code This URL got me: We could not perform this search Must include at least one user, organization, or repository so I'm none the wiser for it. What did it reveal to you ? Eddy. From jedrzej.nowacki at qt.io Wed Aug 8 13:53:50 2018 From: jedrzej.nowacki at qt.io (Jedrzej Nowacki) Date: Wed, 08 Aug 2018 13:53:50 +0200 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <2647712.OyCeee2lpT@tjmaciei-mobl1> Message-ID: <12495556.3u3XyrRYqO@43> On Tuesday, July 31, 2018 8:15:50 PM CEST Ville Voutilainen wrote: > On 31 July 2018 at 20:49, Thiago Macieira wrote: > > I know CMake meets these requirements, but it has other problems and the > > fact that it currently does not build Qt. On that front, qbs is ahead. > > But qbs has a shorter track record. Since we're not switching > > buildsystems in the next 2 years, there's time for the proponents of qbs > > to take actions to achieve those requirements above. > > > > In other words: get others to adopt the buildsystem before we switch Qt. > > Prove that it can support Qt. > > > > I know switching Qt would gain it a big critical mass, the same way that > > KDE switching to CMake in 2006 gave CMake an important boost [*]. But > > we're not switching Qt just yet, so if you're saying the tool is ready, > > get others to use it now. > > This provoked a thought in me, a way to make qbs worth all its effort: > make debugging > a build so staggeringly ridiculously good that it becomes attractive > to use it. I don't know > what debugging builds done with python-based build systems is like, > but debugging make-based > builds is rather horrible. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Oh debugging... I would love a build system that actually thinks about real world in which sub-processes are crashing, getting locked or became unusually slow. One that automatically attach debugger and scans operating system for basic issues, for example I would like to see something like that: "error: ABC process crashed, here there is backtrace of it (...) at the time of the crash memory usage was ~ZZ% and avg load of Y, in parallel we were executing processes: BGD, SFD" "warning: CBA process seems to not doing anything for last X minutes, the avg load is 1% for the last 30s, maybe try strace with PID to debug it?" "warning: performance may be poor because of a heavy swap usage" "error: you are almost out of disk space (~300 MB) suspending the build" "warning: process HBG runs already for X minutes, constantly using whole CPU" A system that is aware of memory constrains and CPU limits. So I'm not surprised if like with make suddenly -j60 doesn't work as expected because I have changed to a network without icecream scheduler. A system that automatically limits number of parallel tasks if swap is getting full to avoid out of memory kills. Cheers, Jędrek From joerg.bornemann at qt.io Wed Aug 8 13:54:45 2018 From: joerg.bornemann at qt.io (Joerg Bornemann) Date: Wed, 8 Aug 2018 13:54:45 +0200 Subject: [Development] Apparently dead code: GPU_BLACKLIST and friends In-Reply-To: References: Message-ID: On 08/08/2018 01:41 PM, Edward Welbourne wrote: >> I'm not the only one : https://github.com/search?p=1&q=QTEST_ADD_GPU_BLACKLIST_SUPPORT_DEFS&type=Code > > This URL got me: > > We could not perform this search > Must include at least one user, organization, or repository > > so I'm none the wiser for it. What did it reveal to you ? Lots of cargo-culted altered copies of the QTEST_MAIN macro, like the one we have in QtWebEngine [1]. ---snip--- #define W_QTEST_MAIN(TestObject, params) \ QT_BEGIN_NAMESPACE \ QTEST_ADD_GPU_BLACKLIST_SUPPORT_DEFS \ QT_END_NAMESPACE \ int main(int argc, char *argv[]) \ { \ QVector w_argv(argc); \ for (int i = 0; i < argc; ++i) \ w_argv[i] = argv[i]; \ for (int i = 0; i < params.size(); ++i) \ w_argv.append(params[i].data()); \ int w_argc = w_argv.size(); \ \ QApplication app(w_argc, const_cast(w_argv.data())); \ app.setAttribute(Qt::AA_Use96Dpi, true); \ QTEST_DISABLE_KEYPAD_NAVIGATION \ QTEST_ADD_GPU_BLACKLIST_SUPPORT \ TestObject tc; \ QTEST_SET_MAIN_SOURCE_PATH \ return QTest::qExec(&tc, argc, argv); \ } ---snap--- [1]: http://code.qt.io/cgit/qt/qtwebengine.git/tree/tests/auto/widgets/util.h Cheers, Joerg From edward.welbourne at qt.io Wed Aug 8 14:13:07 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 8 Aug 2018 12:13:07 +0000 Subject: [Development] Apparently dead code: GPU_BLACKLIST and friends In-Reply-To: References: , Message-ID: >>> I'm not the only one : https://github.com/search?p=1&q=QTEST_ADD_GPU_BLACKLIST_SUPPORT_DEFS&type=Code On 08/08/2018 01:41 PM, Edward Welbourne wrote: >> This URL got me: >> >> We could not perform this search >> Must include at least one user, organization, or repository >> >> so I'm none the wiser for it. What did it reveal to you ? Joerg Bornemann (8 August 2018 13:54) replied: > Lots of cargo-culted altered copies of the QTEST_MAIN macro, like the > one we have in QtWebEngine [1]. OK, I'd spotted those in our other modules and include them as part of what I intend to rip out (first, since they depend on a macro I'll be removing). I guess I should keep vacuous versions of the macros to save everyone *having* to edit their cargo-cult code. Eddy. From edward.welbourne at qt.io Wed Aug 8 14:30:47 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 8 Aug 2018 12:30:47 +0000 Subject: [Development] Apparently dead code: GPU_BLACKLIST and friends In-Reply-To: References: Message-ID: I wrote: > I notice that QTest includes support, in [0], alongside its BLACKLIST > files for problematic tests, for a GPU_BLACKLIST file; [...] > > Inevitably, I'm contemplating a featurectomy. The reviews can be found here: https://codereview.qt-project.org/#/q/status:open+branch:dev+topic:gpu-blacklist,n,z Eddy. From thiago.macieira at intel.com Wed Aug 8 18:18:16 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 8 Aug 2018 09:18:16 -0700 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <5952608.qK8quW4kZP@frederik-thinkcentre-m93p> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> <5952608.qK8quW4kZP@frederik-thinkcentre-m93p> Message-ID: <5036859.H8A2o3Cpou@tjmaciei-mobl1> On Wednesday, 8 August 2018 02:58:08 PDT Frederik Gladhorn wrote: > branch is x.y -> find the next valid patch version Suggestion: use the x.y release and when we make that release, we rename it in JIRA. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Aug 8 19:38:57 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 8 Aug 2018 10:38:57 -0700 Subject: [Development] Question about qml compiler? In-Reply-To: References: Message-ID: <2293460.MDZz70TKzj@tjmaciei-mobl1> On Tuesday, 7 August 2018 18:19:10 PDT Young Moon Jung wrote: > Hi Thiago. > > Thank you for your reply! > It was very helpful for me. > > I have a one more question. > Actually I load .qml file in main.cpp by using QQmlApplicationEngine Class. > Is it mean that I can compile qml application with qmake? Yes, you can compile with qmake as well as cmake or other solutions. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kotov.valery at gmail.com Thu Aug 9 08:20:44 2018 From: kotov.valery at gmail.com (Valery Kotov) Date: Thu, 9 Aug 2018 08:20:44 +0200 Subject: [Development] Storing and managing ValueArray inside QV4::Heap objects In-Reply-To: References: Message-ID: Hi Lars, Simon, I think I got it. Thanks a lot for your tips! Sincerely yours, Valery Kotov On 8 August 2018 at 09:32, Simon Hausmann wrote: > Hi, > > > If you want to use the ValueArray, then you need to make sure that it's > the last member of your type. Then encapsulate the creation if the type in > a factory function that works a bit like ExecutionContext::newCallContext: > > > (1) Calculate how much memory you're going to need for the type _and_ > the value array (minus one Value). > > (2) Allocate the memory with one call to allocManaged. > > (3) call init() manually. > > (4) Set the alloc and size members of the value array to the amount of > allocated values. > > > While this approach is clever in the sense that it gives a compact memory > representation and allocates object and array data in one shot, it also > means that it's not so suitable for frequent dynamic resizing as it will > require re-allocating the entire object. > > > If you have a fully dynamic array, then the alternative would be to store > a pointer to your QVector in the heap object. Heap::QQmlSequence does that, > for example. Just make sure to use V4_NEEDS_DESTROY and provide a destroy() > function to delete the vector. > > > I'd probably go for the first approach with perhaps an indirect type > (similar to how Object has MemberData) if the array contains references to > the JS heap. If your array has only references to the C heap, then you're > probably better off using a pointer to a regular vector. > > > Simon > > ------------------------------ > *From:* Development qt.io at qt-project.org> on behalf of Valery Kotov > *Sent:* Wednesday, August 8, 2018 9:10:43 AM > *To:* Qt development mailing list > *Subject:* [Development] Storing and managing ValueArray inside QV4::Heap > objects > > Hello all, > > I have a question about QV4 heap objects and what could be stored in them. > I would like to move data structure from c++ heap to GC heap. > Unfortunately, my data structure stores a pair of QLists internally. > As far as I'm aware, QV4::Heap objects should be "trivially > constructible", and thus, cannot store QList(s). > One option would be to store QList pointer and manage it's lifecycle > manually. But that does not sound like a good idea. > I've noticed though, that some of qv4 types are using DECLARE_MARKOBJECTS > macro. By using DECLARE_MARKOBJECTS macro and ObjectMember(s) define I can > actually store a ValueArray member in my QV4 heap object. > > #define MyObjectMembers(class, Member) \ > Member(class, ValueArray, ValueArray, myValues) > > DECLARE_HEAP_OBJECT(MyObject, Object) { > DECLARE_MARKOBJECTS(MyObject); > > In this case I can refer to myValues ValueArray type inside of MyObject. > Unfortunately, it is a little bit unclear to me how to manage ValueArrays. > From what I can see from some examples in the code (qv4generatorobject, > qv4arraydata), it seems that I need to manage ValueArray manually. > What I'm missing at the moment a little bit is how the actually allocation > for ValueArray.values is done. > I suspect that it is probably not done via plain "new" call. Otherwise it > is a little bit confusing why not just to store the pointer directly. > > Could you guys please give me a few hints how to go about ValueArray > management? > > Thank you! > Sincerely yours, > Valery Kotov > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at qt.io Thu Aug 9 08:39:16 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Thu, 9 Aug 2018 06:39:16 +0000 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <5036859.H8A2o3Cpou@tjmaciei-mobl1> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> <5952608.qK8quW4kZP@frederik-thinkcentre-m93p>, <5036859.H8A2o3Cpou@tjmaciei-mobl1> Message-ID: ________________________________________ From: Development on behalf of Thiago Macieira >Suggestion: use the x.y release and when we make that release, we rename it in >JIRA. That is the current approach and it does not work or scale. Between branching time and release time is a fairly long time. By then the x.y branch contains already x.y.(z+1) fixes (assuming the latest release branch is x.y.z). It is a big pita going through the issues figuring out which is where. I tried this for some time and found it a waste of time. A better approach might be to have some flag in the gerrit/git system that announces that the last merge for x.y.z was done. The script could then automatically mark fixes targeting the x.y branch as x.y.(z+1) -- Alex From maxwell130631 at gmail.com Thu Aug 9 10:24:26 2018 From: maxwell130631 at gmail.com (James Maxwell) Date: Thu, 9 Aug 2018 10:24:26 +0200 Subject: [Development] New Qml Tableview Message-ID: I read that you target a new QML TableView for Qt5.12. In one of my projects I will need to do a lot with TreeViews. Will the new TableView also serve as a TreeView (This would be helpful information so I can decide whether I wait for the new TreeView)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederik.gladhorn at qt.io Thu Aug 9 11:07:45 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Thu, 09 Aug 2018 11:07:45 +0200 Subject: [Development] New Qml Tableview In-Reply-To: References: Message-ID: <7774396.BgdkVNbjC6@frederik-thinkcentre-m93p> Hi James, On torsdag 9. august 2018 10.24.26 CEST James Maxwell wrote: > I read that you target a new QML TableView for Qt5.12. In one of my > projects I will need to do a lot with TreeViews. Will the new TableView > also serve as a TreeView (This would be helpful information so I can decide > whether I wait for the new TreeView)? We want to get the table view right and it will do exactly that, display tables. For tree views, either use the one from Controls 1 or roll your own. Of course it's possible to help us make progress towards a tree view in Qt Quick, but we'll first evaluate what we learned from the table view and then eventually move towards a good implementation of the tree. Some future version is the current estimate. Cheers, Frederik From Shawn.Rutledge at qt.io Thu Aug 9 15:32:30 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Thu, 9 Aug 2018 13:32:30 +0000 Subject: [Development] QML AnimatedImage Memory usage - QTBUG-64272 In-Reply-To: <1650061acb8-c8f-17b17@webjas-vac176.srv.aolmail.net> References: <1650061acb8-c8f-17b17@webjas-vac176.srv.aolmail.net> Message-ID: > On 3 Aug 2018, at 17:22, Khuram Ali via Development wrote: > > Hi, > > I am suffering from the already reported bug https://bugreports.qt.io/browse/QTBUG-64272. I am adding a gif and the memory usage sky rocket to more than a GB. I have seen the bug is still open. is there any suggested workaround to this issue? > I am using Qt 5.11.1. Thank you for your help! Well there is a patch, you could try it out and measure how much it helps in your case. https://codereview.qt-project.org/#/c/218460/ In an ideal world I think we should not consume any more memory than a couple of frames’ worth, CPU cycles being cheaper than memory nowadays. Why not decode frames on the fly? Worst case, you wouldn’t even have to load the whole gif into memory, just keep reading it from disk over and over (or maybe mmap it if that helps), and let the kernel cache take care of making that faster. Nowadays instead of “disk” we could as well call it “non-volatile memory that’s somewhat slower than RAM”. But I suppose there’s a boundary where a really big animated gif is going to be a pig no matter what, and maybe it does take too much CPU to keep decoding frames, so you need caching after all. Or, for small animations it might be worthwhile to upload all the frames to GPU memory (even put them together into an atlas if possible) to eliminate all disk-reading and most of the GPU bandwidth during steady-state run conditions. So (again in an ideal world) maybe we could auto-detect where to draw the line, do a sort of hot-spot optimization where we detect that one way takes too big a percentage of total memory, or the other way is not keeping up with the frame rate, or taking too big a percentage of CPU cycles. (Or is that hopeless because it’s too much magic, and we’d be sure to get it wrong in some cases?) (I keep wondering why there is still so little emphasis on portable software dynamically taking system resources into account and choosing appropriate optimizations automatically. We don’t seem to be doing much of that in Qt, and we aren’t doing much to help the users do it either.) But I guess we have too many layers of code involved to make any of that easy. The "two layers of caches” comment in that patch is enough to make me want to have a try at starting over; but I haven’t tried, and I figure nobody will approve a patch to do that anyway. Maybe it’s an opportunity for a third-party QtQuick Item that directly uses libgif to get just that kind of animation done as straightforwardly as possible, without supporting other types of movies. Yeah, taking hundreds of megs for smallish gifs is crazy. But so far the only patches I’ve seen are for small non-invasive optimizations. From thiago.macieira at intel.com Thu Aug 9 20:15:03 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 9 Aug 2018 11:15:03 -0700 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> <5036859.H8A2o3Cpou@tjmaciei-mobl1> Message-ID: <1735486.UplEiuYlNy@tjmaciei-mobl1> On Wednesday, 8 August 2018 23:39:16 PDT Alex Blasche wrote: > That is the current approach and it does not work or scale. Between > branching time and release time is a fairly long time. By then the x.y > branch contains already x.y.(z+1) fixes (assuming the latest release branch > is x.y.z). It is a big pita going through the issues figuring out which is > where. I tried this for some time and found it a waste of time. > > A better approach might be to have some flag in the gerrit/git system that > announces that the last merge for x.y.z was done. The script could then > automatically mark fixes targeting the x.y branch as x.y.(z+1) Why can't the renaming in JIRA be done at that exact time? That way, we wouldn't get a mass update of tasks with the version changed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From khuram.ali at aim.com Fri Aug 10 00:37:30 2018 From: khuram.ali at aim.com (Khuram Ali) Date: Thu, 9 Aug 2018 18:37:30 -0400 Subject: [Development] QML AnimatedImage Memory usage - QTBUG-64272 In-Reply-To: Message-ID: <16520d6739f-c8a-2b0bf@webjas-vaa203.srv.aolmail.net> Thank you very much Shawn! I will certainly try it out. my problem is that application needs to run on a striped Linux OS with a lot of memory, where it is the only app running so it is not really matter if it is taking too much memory. But it will also run on some old Windows systems where the memory is limited and it is taking up more than half of it. Regards, Khuram Ali -----Original Message----- From: Shawn Rutledge To: Khuram Ali Cc: development Sent: Thu, Aug 9, 2018 3:32 pm Subject: Re: [Development] QML AnimatedImage Memory usage - QTBUG-64272 > On 3 Aug 2018, at 17:22, Khuram Ali via Development wrote: > > Hi, > > I am suffering from the already reported bug https://bugreports.qt.io/browse/QTBUG-64272. I am adding a gif and the memory usage sky rocket to more than a GB. I have seen the bug is still open. is there any suggested workaround to this issue? > I am using Qt 5.11.1. Thank you for your help! Well there is a patch, you could try it out and measure how much it helps in your case. https://codereview.qt-project.org/#/c/218460/ In an ideal world I think we should not consume any more memory than a couple of frames’ worth, CPU cycles being cheaper than memory nowadays. Why not decode frames on the fly? Worst case, you wouldn’t even have to load the whole gif into memory, just keep reading it from disk over and over (or maybe mmap it if that helps), and let the kernel cache take care of making that faster. Nowadays instead of “disk” we could as well call it “non-volatile memory that’s somewhat slower than RAM”. But I suppose there’s a boundary where a really big animated gif is going to be a pig no matter what, and maybe it does take too much CPU to keep decoding frames, so you need caching after all. Or, for small animations it might be worthwhile to upload all the frames to GPU memory (even put them together into an atlas if possible) to eliminate all disk-reading and most of the GPU bandwidth during steady-state run conditions. So (again in an ideal world) maybe we could auto-detect where to draw the line, do a sort of hot-spot optimization where we detect that one way takes too big a percentage of total memory, or the other way is not keeping up with the frame rate, or taking too big a percentage of CPU cycles. (Or is that hopeless because it’s too much magic, and we’d be sure to get it wrong in some cases?) (I keep wondering why there is still so little emphasis on portable software dynamically taking system resources into account and choosing appropriate optimizations automatically. We don’t seem to be doing much of that in Qt, and we aren’t doing much to help the users do it either.) But I guess we have too many layers of code involved to make any of that easy. The "two layers of caches” comment in that patch is enough to make me want to have a try at starting over; but I haven’t tried, and I figure nobody will approve a patch to do that anyway. Maybe it’s an opportunity for a third-party QtQuick Item that directly uses libgif to get just that kind of animation done as straightforwardly as possible, without supporting other types of movies. Yeah, taking hundreds of megs for smallish gifs is crazy. But so far the only patches I’ve seen are for small non-invasive optimizations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at qt.io Fri Aug 10 10:38:46 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Fri, 10 Aug 2018 08:38:46 +0000 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <1735486.UplEiuYlNy@tjmaciei-mobl1> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> <5036859.H8A2o3Cpou@tjmaciei-mobl1> , <1735486.UplEiuYlNy@tjmaciei-mobl1> Message-ID: ________________________________________ From: Development on behalf of Thiago Macieira On Wednesday, 8 August 2018 23:39:16 PDT Alex Blasche wrote: > That is the current approach and it does not work or scale. Between > branching time and release time is a fairly long time. By then the x.y > branch contains already x.y.(z+1) fixes (assuming the latest release branch > is x.y.z). It is a big pita going through the issues figuring out which is > where. I tried this for some time and found it a waste of time. > >> A better approach might be to have some flag in the gerrit/git system that >> announces that the last merge for x.y.z was done. The script could then >> automatically mark fixes targeting the x.y branch as x.y.(z+1) >Why can't the renaming in JIRA be done at that exact time? That way, we >wouldn't get a mass update of tasks with the version changed. It can and it should probably be done by the release manager. We have never consistently done it so far though. I find an automated version much cleaner and scalable. Hence my hope fregl can pick this up. -- Alex From aapo.keskimolo at qt.io Fri Aug 10 11:31:47 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Fri, 10 Aug 2018 09:31:47 +0000 Subject: [Development] Coin maintenance notification: Master machine distro will be upgraded on Monday Message-ID: Coin master Ubuntu distribution will be updated on the coming Monday 13-Aug-2018 between 09:00-12:00 EEST. Before the upgrade, the ci storage cache will be reset to free up storage space to make the process smoother. We do not expect any major problems, except for some delay with starting up the services on Monday and rebuilding cache binaries. IMPORTANT: If you have anything important on the Coin master machine, I would advice to back it up. Kind regards/Ystävällisin terveisin, Aapo Keskimölö From denis.shienkov at gmail.com Fri Aug 10 11:45:23 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 10 Aug 2018 12:45:23 +0300 Subject: [Development] Create native FileDialog for Android Message-ID: Hi guys, Is it possible to add an own code to use the Android's native file picker dialog? For example, I want (I think) to use a following framework (it introduced to Android since v4.4): https://developer.android.com/guide/topics/providers/document-provider But a problem is that an Android's platform plugin from the: qtbase\src\plugins\platforms\android\qandroidplatformtheme.cpp ignores a file dialogs at all: {code} QPlatformDialogHelper *QAndroidPlatformTheme::createPlatformDialogHelper(QPlatformTheme::DialogType type) const {     switch (type) {     case MessageDialog:         return new QtAndroidDialogHelpers::QAndroidPlatformMessageDialogHelper;     default:         return 0;     } } {code} So, is it possible to override this behavior somehow? Or e.g. to create an own QAndroidPlatformTheme ? It it possible in Qt at all? PS: What is reason that the Android's theme does not support the Color && File Dialogs? BR, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Fri Aug 10 12:07:51 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 10 Aug 2018 12:07:51 +0200 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> <5036859.H8A2o3Cpou@tjmaciei-mobl1> <1735486.UplEiuYlNy@tjmaciei-mobl1> Message-ID: <20180810100751.GB6842@troll08> On Fri, Aug 10, 2018 at 08:38:46AM +0000, Alexander Blasche wrote: > Thiago Macieira wrote: > > On Wednesday, 8 August 2018 23:39:16 PDT Alex Blasche wrote: > > > That is the current approach and it does not work or scale. > > > Between branching time and release time is a fairly long time. By > > > then the x.y branch contains already x.y.(z+1) fixes (assuming the > > > latest release branch is x.y.z). It is a big pita going through > > > the issues figuring out which is where. I tried this for some time > > > and found it a waste of time. > > > this is rather obviously something that should be automated. the system can easily query the sha1 from the ticket, see what the lowest branch it appears on in git is, and update the ticket's fix-version if it's wrong. > > > A better approach might be to have some flag in the gerrit/git > > > system that announces that the last merge for x.y.z was done. The > > > script could then automatically mark fixes targeting the x.y > > > branch as x.y.(z+1) > > > i previously thought that this is a good idea, too, but a) there is inherently a race condition here due to the downmerge, and b) it's an additional meta data store that needs to be 1) created and 2) maintained. so now i think the hook/intergration should just set the fix version to the target branch name. yes, that implies that we should have the version "dev" in jira. a note on the "changes" field: it's kind of redundant with the automated gerrit link derived from the task-number footer, and consequently many people _refuse_ to set it "out of principle". however, it has the big advantage that it allows fixing things up retroactively, both when a bug link turned out to be bogus and when it was not done to start with. so the hook should definitely populate it. > > Why can't the renaming in JIRA be done at that exact time? That way, > > we wouldn't get a mass update of tasks with the version changed. > > that's not a problem. notifications can be suppressed. > It can and it should probably be done by the release manager. We have > never consistently done it so far though. > yes, because the effort was ridiculous as you noticed yourself. > I find an automated version much cleaner and scalable. Hence my hope > fregl can pick this up. > yes, as a separate script that is operated "off-line" by the release manager (or the guy doing the downmerge, which was me so far). From Shawn.Rutledge at qt.io Fri Aug 10 14:42:59 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Fri, 10 Aug 2018 12:42:59 +0000 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <20180810100751.GB6842@troll08> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> <5036859.H8A2o3Cpou@tjmaciei-mobl1> <1735486.UplEiuYlNy@tjmaciei-mobl1> <20180810100751.GB6842@troll08> Message-ID: <30DD2748-6FA8-403F-B9AD-A55C89F60FFA@qt.io> > On 10 Aug 2018, at 12:07, Oswald Buddenhagen wrote: > > so now i think the hook/intergration should just set the fix version to > the target branch name. yes, that implies that we should have the > version "dev" in jira. Why? I think you can check the tags in git and find out that the highest numbered release was 5.11.1 so far, so dev has to be 5.12? (until Qt 6 anyway) And Jira knows which future versions are not released yet. So when I mark fixed a bug that I fixed on dev, manually, I choose 5.12 alpha, because that’s not released yet. I’d think the script could that too. From oswald.buddenhagen at qt.io Fri Aug 10 15:14:15 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 10 Aug 2018 15:14:15 +0200 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <30DD2748-6FA8-403F-B9AD-A55C89F60FFA@qt.io> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> <5036859.H8A2o3Cpou@tjmaciei-mobl1> <1735486.UplEiuYlNy@tjmaciei-mobl1> <20180810100751.GB6842@troll08> <30DD2748-6FA8-403F-B9AD-A55C89F60FFA@qt.io> Message-ID: <20180810131415.GD6842@troll08> On Fri, Aug 10, 2018 at 02:42:59PM +0200, Shawn Rutledge wrote: > On 10 Aug 2018, at 12:07, Oswald Buddenhagen wrote: > > so now i think the hook/intergration should just set the fix version to > > the target branch name. yes, that implies that we should have the > > version "dev" in jira. > > Why? I think you can check the tags in git and find out that the highest numbered release was 5.11.1 so far, so dev has to be 5.12? (until Qt 6 anyway) And Jira knows which future versions are not released yet. So when I mark fixed a bug that I fixed on dev, manually, I choose 5.12 alpha, because that’s not released yet. I’d think the script could that too. > firstly, adding a git query to the hook complicates it and reduces its reliability. secondly, as your own caveat highlights, you need to encode and maintain policy in the script to make that work. thirdly, your proposed heuristics are wrong, because there is a window of time where changes integrated into dev do *not* target the next minor release (or a pre-release thereof): the time between the final downmerge form dev and the actual release. and we see in practice that people *do* get it wrong all the time, despite the announcement mails. dealing with that requires additional meta data, which is precisely what much of the previous mails was about. stick to your guns, maybe? From Shawn.Rutledge at qt.io Fri Aug 10 15:57:31 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Fri, 10 Aug 2018 13:57:31 +0000 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <20180810131415.GD6842@troll08> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> <5036859.H8A2o3Cpou@tjmaciei-mobl1> <1735486.UplEiuYlNy@tjmaciei-mobl1> <20180810100751.GB6842@troll08> <30DD2748-6FA8-403F-B9AD-A55C89F60FFA@qt.io> <20180810131415.GD6842@troll08> Message-ID: <78ACC4A0-6858-414F-9205-FD6A5CB5508F@qt.io> > On 10 Aug 2018, at 15:14, Oswald Buddenhagen wrote: > > On Fri, Aug 10, 2018 at 02:42:59PM +0200, Shawn Rutledge wrote: >> On 10 Aug 2018, at 12:07, Oswald Buddenhagen wrote: >>> so now i think the hook/intergration should just set the fix version to >>> the target branch name. yes, that implies that we should have the >>> version "dev" in jira. >> >> Why? I think you can check the tags in git and find out that the highest numbered release was 5.11.1 so far, so dev has to be 5.12? (until Qt 6 anyway) And Jira knows which future versions are not released yet. So when I mark fixed a bug that I fixed on dev, manually, I choose 5.12 alpha, because that’s not released yet. I’d think the script could that too. >> > firstly, adding a git query to the hook complicates it and reduces its > reliability. > > secondly, as your own caveat highlights, you need to encode and maintain > policy in the script to make that work. Starting to use the Fixes: tag at all is a policy, and writing code that reacts to it amounts to encoding a policy. It’s not the first script which does something like that. > thirdly, your proposed heuristics are wrong, because there is a window > of time where changes integrated into dev do *not* target the next minor > release (or a pre-release thereof): the time between the final downmerge > form dev and the actual release. The window between the first creation of a new branch (on Monday) and the final merge from dev to that branch (a week from Monday) is more of a concern; during that time we have a 5.12 branch (assuming we check the highest branch rather than tag) but changes to dev are still for 5.12. Maybe read .qmake.conf then? From oswald.buddenhagen at qt.io Fri Aug 10 19:26:54 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 10 Aug 2018 19:26:54 +0200 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <78ACC4A0-6858-414F-9205-FD6A5CB5508F@qt.io> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> <5036859.H8A2o3Cpou@tjmaciei-mobl1> <1735486.UplEiuYlNy@tjmaciei-mobl1> <20180810100751.GB6842@troll08> <30DD2748-6FA8-403F-B9AD-A55C89F60FFA@qt.io> <20180810131415.GD6842@troll08> <78ACC4A0-6858-414F-9205-FD6A5CB5508F@qt.io> Message-ID: <20180810172654.GE6842@troll08> On Fri, Aug 10, 2018 at 03:57:31PM +0200, Shawn Rutledge wrote: > On 10 Aug 2018, at 15:14, Oswald Buddenhagen wrote: > > secondly, as your own caveat highlights, you need to encode and > > maintain policy in the script to make that work. > > Starting to use the Fixes: tag at all is a policy, and writing code > that reacts to it amounts to encoding a policy. It’s not the first > script which does something like that. > yes, but it's bad engineering to hard-code the policy if it's implicitly available from somewhere else as data. > > thirdly, your proposed heuristics are wrong, because there is a window > > of time where changes integrated into dev do *not* target the next minor > > release (or a pre-release thereof): the time between the final downmerge > > form dev and the actual release. > > The window between the first creation of a new branch (on Monday) and > the final merge from dev to that branch (a week from Monday) is more > of a concern; > during that time we have a 5.12 branch (assuming we check the highest > branch rather than tag) but changes to dev are still for 5.12. > that's completely true. how is that a concern? > Maybe read .qmake.conf then? > you just topped yourself: now we not only read the git repo's meta data, but also its content, to extract data in a format that is bound to the current version of a certain subset of the repositories. also, this won't work, because the contents of these files intentionally lag the downmerges - just in case somebody comes to request another downmerge in some repo, because they've been living under a rock and missed the deadline (happens on a somewhat regular basis). From mathias at taschenorakel.de Fri Aug 10 22:09:24 2018 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Fri, 10 Aug 2018 22:09:24 +0200 Subject: [Development] Create native FileDialog for Android In-Reply-To: References: Message-ID: <0609367a-9e43-0759-7879-ac1fe7f3417c@taschenorakel.de> Heya, The general approach to this kind of tasks is to: - add your own Android activity that extends org.qtproject.qt5.android.bindings.QtActivity - have that activity provide a public method doing all the native Android calls - and to finally invoke this method from C++ via QtAndroid::androidActivity().callMethod() Hopefully this helps you, Mathias Am 10.08.2018 um 11:45 schrieb Denis Shienkov: > Hi guys, > > Is it possible to add an own code to use the Android's native file > picker dialog? > > For example, I want (I think) to use a following framework (it > introduced to Android since v4.4): > https://developer.android.com/guide/topics/providers/document-provider > > But a problem is that an Android's platform plugin from the: > > qtbase\src\plugins\platforms\android\qandroidplatformtheme.cpp > > ignores a file dialogs at all: > > {code} > QPlatformDialogHelper > *QAndroidPlatformTheme::createPlatformDialogHelper(QPlatformTheme::DialogType > type) const > { >     switch (type) { >     case MessageDialog: >         return new > QtAndroidDialogHelpers::QAndroidPlatformMessageDialogHelper; >     default: >         return 0; >     } > } > {code} > > So, is it possible to override this behavior somehow? Or e.g. to create > an own > QAndroidPlatformTheme ? It it possible in Qt at all? > > PS: What is reason that the Android's theme does not support the Color > && File Dialogs? > > BR, > Denis > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From aapo.keskimolo at qt.io Mon Aug 13 10:52:41 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Mon, 13 Aug 2018 08:52:41 +0000 Subject: [Development] Coin maintenance notification: Master machine distro will be upgraded on Monday In-Reply-To: References: Message-ID: The update was a success, but the process took a bit longer than expected. Coin is currently busy with building qt/qt5 binaries for dev+5.11 and this should take couple of hours. The service will come back up after the binaries are rebuilt. I apologize for the delay. -----Original Message----- From: Aapo Keskimölö Sent: perjantai 10. elokuuta 2018 12.32 To: 'development at qt-project.org' ; Qt CI ; 'sampo.heikkinen at nebula.fi' Cc: Olli Hirvonen Subject: Coin maintenance notification: Master machine distro will be upgraded on Monday Coin master Ubuntu distribution will be updated on the coming Monday 13-Aug-2018 between 09:00-12:00 EEST. Before the upgrade, the ci storage cache will be reset to free up storage space to make the process smoother. We do not expect any major problems, except for some delay with starting up the services on Monday and rebuilding cache binaries. IMPORTANT: If you have anything important on the Coin master machine, I would advice to back it up. Kind regards/Ystävällisin terveisin, Aapo Keskimölö From Liang.Qi at qt.io Mon Aug 13 11:29:49 2018 From: Liang.Qi at qt.io (Liang Qi) Date: Mon, 13 Aug 2018 09:29:49 +0000 Subject: [Development] Merge and Integration status report - 2018.08.13 Message-ID: <0606C937-44E0-4CD0-A247-F2123C9E7C7D@qt.io> Integrations * qt5 5.11 integration is healthy, last one is yesterday, August 12 * qt5 dev, last one is August 11, excluding qtbase since August 8 * * http://bugreports.qt.io/browse/QTBUG-69891 tests/auto/quick/drawingmodes hanging Tor Arne is working on that. But if can't get fix soon, suggest to revert https://codereview.qt-project.org/#/c/235685/ for now, because there are about 20-30 changes including a 5.11->dev merge in qtbase which are not integrated in qt5 dev yet. Merges - healthy! Thanks Simon and Edward for their work during July! -- Liang From jani.heikkinen at qt.io Mon Aug 13 12:18:13 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 13 Aug 2018 10:18:13 +0000 Subject: [Development] Merge and Integration status report - 2018.08.13 In-Reply-To: <0606C937-44E0-4CD0-A247-F2123C9E7C7D@qt.io> References: <0606C937-44E0-4CD0-A247-F2123C9E7C7D@qt.io> Message-ID: > -----Original Message----- > From: Development project.org> On Behalf Of Liang Qi > Sent: maanantai 13. elokuuta 2018 12.30 > To: development at qt-project.org > Subject: [Development] Merge and Integration status report - 2018.08.13 > > Integrations > > * qt5 5.11 integration is healthy, last one is yesterday, August 12 > > * qt5 dev, last one is August 11, excluding qtbase since August 8 > * * http://bugreports.qt.io/browse/QTBUG-69891 > tests/auto/quick/drawingmodes hanging > Tor Arne is working on that. But if can't get fix soon, suggest to revert > https://codereview.qt-project.org/#/c/235685/ for now, because there are > about 20-30 > changes including a 5.11->dev merge in qtbase which are not integrated in > qt5 dev yet. As discussed earlier we should do reverts much easier to avoid blocking of other's work. We will start branching from 'dev' -> '5.12' today and we should get latest changes in qtbase as soon as possible as well. So in my opinion we should just do the revert & bring the change back when fix is available. br, Jani > > Merges - healthy! > > Thanks Simon and Edward for their work during July! > > -- Liang > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Tor.arne.Vestbo at qt.io Mon Aug 13 16:40:17 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Mon, 13 Aug 2018 14:40:17 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> Message-ID: Bringing this up again in light of e.g. https://codereview.qt-project.org/#/c/235167/ When I gave my support to this I thought we were talking about global enums. I do not think that using class enums inside existing classes is a win for code readability/writability: When you have switch (point->state()) { It's pretty obvious what case QQuickEventPoint::Pressed: refers to. being overly explicit with case QQuickEventPoint::State::Pressed: just adds more to type for no reason. Or: if (event->device()->pointerType() != QQuickPointerDevice::Finger Gives me all the info I need, and having to type or read this instead is worse in my opinion: if (event->device()->pointerType() != QQuickPointerDevice::PointerType::Finger && I think we should revisit this policy, and only use it when there’s actually a clash. Tor Arne > On 22 May 2018, at 10:04, Alex Blasche wrote: > > I updated the enum section: > > https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values > > -- > Alex > > ________________________________________ > From: Development on behalf of Lars Knoll > Sent: Tuesday, 22 May 2018 9:30:18 AM > To: Christian Kandeler > Cc: Qt development mailing list > Subject: Re: [Development] Naming convention for (scoped) enums > > > >> On 17 May 2018, at 11:35, Christian Kandeler wrote: >> >> On Thu, 17 May 2018 08:14:15 +0000 >> Alex Blasche wrote: >> >>> The naming conventions for enums state that each enum value name must repeat a part of the enum Type name (for details see https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values) >>> >>> In case of scoped enums this becomes a superfluous rule as the type has to be mentioned anyway. Does anybody object to modifying the above definition by adding an exception for scoped enums where you do not have to repeat a part of the enum type name? >> >> I would not have even assumed that the rule applies to scoped enums, but it can't hurt to write it down explicitly. Perhaps the section should be rewritten so that the unscoped enums are the special case rather than the other way around. > > Agree. The default for new enums should be scoped enums. > > Cheers, > Lars > > _______________________________________________ > 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 aapo.keskimolo at qt.io Mon Aug 13 18:02:38 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Mon, 13 Aug 2018 16:02:38 +0000 Subject: [Development] Coin maintenance notification: Master machine distro will be upgraded on Monday In-Reply-To: References: Message-ID: The Coin service is running again after some struggles with CI master disk running out of space so the storage had to be wiped again. The influxb observer is now enabled and is submitting data to Grafana. We will keep monitoring it to ensure that it does not cause any problems. -----Original Message----- From: Aapo Keskimölö Sent: maanantai 13. elokuuta 2018 11.53 To: 'development at qt-project.org' ; Qt CI ; 'sampo.heikkinen at nebula.fi' Cc: Olli Hirvonen Subject: RE: Coin maintenance notification: Master machine distro will be upgraded on Monday The update was a success, but the process took a bit longer than expected. Coin is currently busy with building qt/qt5 binaries for dev+5.11 and this should take couple of hours. The service will come back up after the binaries are rebuilt. I apologize for the delay. -----Original Message----- From: Aapo Keskimölö Sent: perjantai 10. elokuuta 2018 12.32 To: 'development at qt-project.org' ; Qt CI ; 'sampo.heikkinen at nebula.fi' Cc: Olli Hirvonen Subject: Coin maintenance notification: Master machine distro will be upgraded on Monday Coin master Ubuntu distribution will be updated on the coming Monday 13-Aug-2018 between 09:00-12:00 EEST. Before the upgrade, the ci storage cache will be reset to free up storage space to make the process smoother. We do not expect any major problems, except for some delay with starting up the services on Monday and rebuilding cache binaries. IMPORTANT: If you have anything important on the Coin master machine, I would advice to back it up. Kind regards/Ystävällisin terveisin, Aapo Keskimölö From giuseppe.dangelo at kdab.com Mon Aug 13 18:12:16 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 13 Aug 2018 18:12:16 +0200 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> Message-ID: <4e331cfc-271f-98f0-53e8-e8b99af9ef5a@kdab.com> Il 13/08/2018 16:40, Tor Arne Vestbø ha scritto: > Or: > > if (event->device()->pointerType() != QQuickPointerDevice::Finger > > Gives me all the info I need, and having to type or read this instead is worse in my opinion: This is actually against the old "non-enum class" coding standards: one must repeat the enumeration name in the enumerators. Then, the difference is between something like QQuickPointerDevice::FingerPointerType (?) and QQuickPointerDevice::PointerType::Finger So quite minor, all in all... > > if (event->device()->pointerType() != QQuickPointerDevice::PointerType::Finger && > > I think we should revisit this policy, and only use it when there’s actually a clash. Which is always "too late" if we're talking about public APIs, as they're set in stone. By the way, the C++ community has already recognized the excessive verbosity of enum classes, and there are proposals such as http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1099r0.html that would drastically simplify the syntax. In the meanwhile, I would not work around it -- we need *some* enum scoping anyhow, and enum classes are the simplest way possible to not forget about it. My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From Tor.arne.Vestbo at qt.io Mon Aug 13 18:19:30 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Mon, 13 Aug 2018 16:19:30 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: <4e331cfc-271f-98f0-53e8-e8b99af9ef5a@kdab.com> References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <4e331cfc-271f-98f0-53e8-e8b99af9ef5a@kdab.com> Message-ID: On 13 Aug 2018, at 18:12, Giuseppe D'Angelo via Development wrote: > > Il 13/08/2018 16:40, Tor Arne Vestbø ha scritto: >> Or: >> if (event->device()->pointerType() != QQuickPointerDevice::Finger >> Gives me all the info I need, and having to type or read this instead is worse in my opinion: > > This is actually against the old "non-enum class" coding standards: one must repeat the enumeration name in the enumerators. Just because the old standard was also promoting less readable/writable code doesn’t make it a good thing that we should keep 😊 The coding standard was likely based on global enums, and somehow we didn’t account for enums inside classes. Even today https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values doesn’t mention enums inside classes, and the example only shows global enums. >> if (event->device()->pointerType() != QQuickPointerDevice::PointerType::Finger && >> I think we should revisit this policy, and only use it when there’s actually a clash. > > Which is always "too late" if we're talking about public APIs, as they're set in stone. Of course. I’m just arguing that we shouldn’t continue down this road now that we’ve learned that the coding standard produces worse results for the specific case of enums inside classes. > In the meanwhile, I would not work around it -- we need *some* enum scoping anyhow, and enum classes are the simplest way possible to not forget about it. Enum scoping is already achieved by the enum living inside a class. You already have your goal met 😊 If it’s a global enum, sure, make it a class enum instead of QQuickPointerDevice::FingerPointerType. And if it’s inside a class, and clashes, sure, make it a class enum. But for the common case, let’s prioritise readability/writability. Tor Arne From edward.welbourne at qt.io Mon Aug 13 19:30:42 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 13 Aug 2018 17:30:42 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <4e331cfc-271f-98f0-53e8-e8b99af9ef5a@kdab.com>, Message-ID: Il 13/08/2018 16:40, Tor Arne Vestbø ha scritto: >>> Or: >>> if (event->device()->pointerType() != QQuickPointerDevice::Finger >>> Gives me all the info I need, and having to type or read this >>> instead is worse in my opinion: On 13 Aug 2018, at 18:12, Giuseppe D'Angelo via Development wrote: >> This is actually against the old "non-enum class" coding standards: >> one must repeat the enumeration name in the enumerators. ... and yet we have violations of that in public APIs. e.g. QValidator::State, with values { Invalid, Intermediate, Acceptable } Tor Arne Vestbø (13 August 2018 18:19) > Just because the old standard was also promoting less > readable/writable code doesn’t make it a good thing that we should > keep 😊 > The coding standard was likely based on global enums, and somehow we > didn’t account for enums inside classes. Even today > https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values > doesn’t mention enums inside classes, and the example only shows > global enums. and the rationale for the rule doesn't really need it applied except to global enums (and, rarely, within a class if there's a clash). >>> if (event->device()->pointerType() != QQuickPointerDevice::PointerType::Finger && >>> I think we should revisit this policy, and only use it when there’s >>> actually a clash. >> Which is always "too late" if we're talking about public APIs, as >> they're set in stone. including the ones set in stone that violate the policy we've not been rigorous abut following. Meanwhile, when it comes to adding *new* enums, do we really want to continue following this rule ? > Of course. I’m just arguing that we shouldn’t continue down this road > now that we’ve learned that the coding standard produces worse results > for the specific case of enums inside classes. +1 >> In the meanwhile, I would not work around it -- we need *some* enum >> scoping anyhow, and enum classes are the simplest way possible to >> not forget about it. > Enum scoping is already achieved by the enum living inside a > class. You already have your goal met 😊 If it’s a global enum, sure, > make it a class enum instead of > QQuickPointerDevice::FingerPointerType. And if it’s inside a class, > and clashes, sure, make it a class enum. But for the common case, > let’s prioritise readability/writability. ... and avoid pointless duplication. Yes please, Eddy. From edward.welbourne at qt.io Mon Aug 13 20:03:46 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 13 Aug 2018 18:03:46 +0000 Subject: [Development] Calendar classes: API review request In-Reply-To: <1550986.sEj2LahhzR@ubuntu> References: , <1550986.sEj2LahhzR@ubuntu> Message-ID: On Dienstag, 31. Juli 2018 14:25:21 CEST Edward Welbourne wrote: >>> My primary concern with this API is that it promotes an unclear >>> ownership model. >> hmm ... this is partly a symptom of most QAbstractCalendar instances >> being dataless. Each calendar has different code to implement its >> behaviour. Or, to put it another way, the vtable is the data. >> >> Admittedly, I can imagine uses for derived classes that do have data >> (e.g. for historians of Europe, taking into account the use of Julian >> for part of history, Gregorian for other parts, with diverse dates for >> the transition - and some foibles in between), so we should make it >> possible for them to have data. >>> Typically we have API that is either a sub-class of QObject (where the >>> parent may delete the children, such as QFile) or we have value based >>> classes (such as QDateTime). There is also a slightly less common, >>> third model with explicitly shared types, I think mostly acting as >>> singletons. >> All of which is mostly about how *the data* is shared. >>> With QAbstractCalendar there's an entirely new model (which also >>> includes a clone() method). I think that model should [be] >>> reconsidered, >> Can you suggest an alternative ? Simon Hausmann (31 July 2018 14:34) offered: > If you are sure that there is no data to be dealt with, that the calendars are > free of state, then they should probably become singletons. Well, as I noted, some relatively specialised implementations may need some data, such as the date at which a country (whose full calendar a given instance is) made the transition from Julian to Gregorian. > You can still have a factory on the backend, but for the users of API there > would be only pointers to calendar objects that are supposed to remain valid > for the life time of the program. So you'd be perfectly happy with a pimpl having virtual methods, that a client-supplied implementation could over-ride ? Then we could have an enum on the front-end to select which singleton is saved in the back-end as the pimpl for each enum member; and client code would register a new implementation and get back a "user-defined" value of the enum to use in fetching the instance they passed to the registration. Or have I mis-understood ? Because I don't really see how this helps, when the API the pimpl has to implement is effectively public and you have exactly the same (theoretical) problem that any change to that is a backwards-compatibility break for those who have implemented their own calendars. So all I see is a bunch of extra bureacracy (the enum and some mapping from enum members to singletons). It would seem to make more sense to simply declare the calendar classes not covered by our usual backwards compatibility ambitions - albeit with a very high probability that their API won't ever change. >>> but if not, then it needs to be documented and it needs to be >>> clarified how this model applies to the exposure of calendars to >>> QML. Otherwise you easily risk creating dangling pointers (as pointed >>> out in the QML review). >>> >>> A secondary concern is that the API, once submitted, is not >>> extensible. We cannot add new properties without breaking binary >>> compatibility, due to the use of virtual functions in the frontend. >> Again, please suggest some good ways to do this for the case of >> calendars, where only rather obscure ones have any data; the differences >> among widely-used calendars are all in code. > My preference is the nice-frontend-enum-on-the-backend approach. Absent a mechanism for extending the enum at run-time, this locks us down to whatever short-list of calendars we implement in Qt-as-shipped; which means we'll be under pressure to take in more calendars than we really want to be left maintaining. So I'm hoping you're OK with an "extensible" enum, e.g. one with a UserSupplied = 100 entry and some mechanism for registering what goes beyond that. Albeit, as noted above, I'm failing to see how it really wins us much. >>> I think in the past we've solved this by having a nice front-end API >>> with non-virtual functions (those we can add) and channeling this >>> through to a backend that uses fewer virtual functions but enums (that >>> can be extended) to dispatch. >> The problem with that is that you're stuck with the calendars that Qt >> ships. We're never going to ship every calendar that the long tail of >> potential users might want. We can probably manage the dozen-or-two >> calendars that the ECMAScript spec mentions in this context, but I want >> it to be easy for some minority population to be able to implement their >> own calendar and have Qt transparently use it. The present design >> supports that. > Why does such a separation impose limitations on the API? I'm failing to understand the question. >> As an example of the long tail, AIUI, a fully faithful implementation of >> the islamic calendar (as distinct from the fairly widely-adopted "civil" >> islamic calendar) needs a distinct calendar for each community. It >> would, IIUC, need data about the user's (community's) local ephemrides >> (when, exactly, the full or new moon is seen rising there, each month); >> and I want to leave open the option of some population, who want it, >> doing that for themselves without us having to take in patches for them >> to get what they want. There are likewise variants of the Julian >> calendar still in use by some communities - each its own variant - and I >> want to let them do their thing in their diverse own ways without us >> needing to take in patches. Then, as alluded to above, there's the >> historians ... >> >>> Another alternative is the extension mechanism that we've used with >>> QFile/QIODevice. >> >> I don't know that one. > It's best demonstrated with the map support in the resource file engine: > http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qresource.cpp#n1482 > A virtual function in the back-end that is lower-level API (not so > nice to use) but extensible within our constraints. On the frontend > the API is nice (QFile::map) and it was possible to add this while > maintaining binary compatibility. It's as if QFile got a new virtual > function, except it didn't :) Can you describe how this extension mechanism works, in an overview style ? I'm wary of the amount of time it's going to take me to make sense of this ... >> I just know that there's a bewildering tangle of >> abstractions behind QFile, seemingly to handle different file systems, >> that I sometimes manage to make enough sense of to fix things. I hope >> we can avoid having such vast complexity for calendars. They're not >> (individually) actually that complicated (well, except for France and >> Sweden a couple of centuries ago); its the variations between them that >> complicate life. >> >> All of the extension mechanisms you talk about depend on us writing yet >> another back-end for each supported case. With calendars, it must be >> possible for some community to support its own, without needing us to >> know about it or do more than provide the infrastructure theirs slots >> into. >> >> So yes, the thing I neglected to mention in my previous mail is: do we >> have any suggestions for how to design an API that'll let app authors >> implement the calendars they want to support (for their possibly very >> minority user-bases) and have them work transparently with Qt, just as >> well as any other calendar that we support ? Bonus points if there's a >> way for app-authors to implement a plugin API that lets several of them >> share the same plugin-implemented calendars (without us having to care >> how they do it). The present design does support all of that. >> Using a classic (but not-so-Qt-ish) C++ virtual method API. > I don't see a way around achieving this without Qt declaring an interface that > contains the features it expects the app author supplied calendar to > implement. > If we want both, ease of use of calendar API itself as well ease of supplying > custom calendars to Qt, then we may have to settle for an API that is less > convenient to use but extensible without breaking source and binary > compatibility perhaps? How do we avoid breaking source and binary compatibility for those clients who've implemented back-ends ? When, that is, we're making some change to the design that would otherwise have produced a breakage of backwards compatibility in the front-end. I'm also struggling to make sense of what API changes in the front-end you're imagining, that would be hard to implement without breaking backwards compatibility. Calendars have very different kinds of weirdness from file-systems ... Eddy. From Shawn.Rutledge at qt.io Mon Aug 13 20:19:57 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Mon, 13 Aug 2018 18:19:57 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: <4e331cfc-271f-98f0-53e8-e8b99af9ef5a@kdab.com> References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <4e331cfc-271f-98f0-53e8-e8b99af9ef5a@kdab.com> Message-ID: On Aug 13, 2018, at 18:12, Giuseppe D'Angelo via Development wrote: > Il 13/08/2018 16:40, Tor Arne Vestbø ha scritto: >> Or: >> if (event->device()->pointerType() != QQuickPointerDevice::Finger >> Gives me all the info I need, and having to type or read this instead is worse in my opinion: > > This is actually against the old "non-enum class" coding standards: one must repeat the enumeration name in the enumerators. Then, the difference is between something like > > QQuickPointerDevice::FingerPointerType (?) > > and > > QQuickPointerDevice::PointerType::Finger > > So quite minor, all in all… I would prefer the enum class over prefixing. But it works fine to do without both, too. It came up because I tried to add Scroll as a DeviceType, so there was a clash in that patch. But then I decided the reason I wanted that was not a great one anyway. So this change is not urgently needed now, it’s just a matter of doing what will make the most sense for the eventual supported API (when we get around to making QQuickPointerHandler and its subclasses public, which is not for 5.12, then users will be able to subclass it and handle events) and for future-proofing (prevent clashes later). >> if (event->device()->pointerType() != QQuickPointerDevice::PointerType::Finger && >> I think we should revisit this policy, and only use it when there’s actually a clash. > > Which is always "too late" if we're talking about public APIs, as they're set in stone. For the record, the class is still private for now. From alexander.blasche at qt.io Tue Aug 14 09:16:40 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Tue, 14 Aug 2018 07:16:40 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> Message-ID: > -----Original Message----- > From: Tor Arne Vestbø > Sent: Monday, 13 August 2018 16:40 > To: Alex Blasche > Cc: development at qt-project.org; Simon Hausmann > Subject: Re: [Development] Naming convention for (scoped) enums > > Bringing this up again in light of e.g. https://codereview.qt- > project.org/#/c/235167/ > > When I gave my support to this I thought we were talking about global enums. I was certainly not limiting myself to those only. That's just a coincidence that I chose a global enum for the policy. > I > do not think that using class enums inside existing classes is a win for code > readability/writability: > > When you have > > switch (point->state()) { > > It's pretty obvious what case QQuickEventPoint::Pressed: refers to. being overly > explicit with case QQuickEventPoint::State::Pressed: just adds more to type for > no reason. Similar to Guiseppe, I would argue that the above enum does not comply with the convention for unscoped enums either. The enum value would have to repeat at least some part of the enum type. That's a rule that has existed for decades now. Therefore QQuickEventPoint::State::Pressed is no more verbose than QQuickEventPoint::PressedState. In summary, there is very little verbosity added even by existing rules. Mind you, Qt has always favoured readability and accepted verbosity as a consequence in times of code completion. There is one more very important aspect. Scoped enums can have dedicated types and are type safe. This could have easily caught issues like (which coincidently was pointed out to me this morning): https://codereview.qt-project.org/#/c/236736/ And I believe that is a very good reason to still prefer scoped enums. -- Alex From Tor.arne.Vestbo at qt.io Tue Aug 14 11:30:26 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Tue, 14 Aug 2018 09:30:26 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> Message-ID: <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> > On 14 Aug 2018, at 09:16, Alex Blasche wrote: > >> I >> do not think that using class enums inside existing classes is a win for code >> readability/writability: >> >> When you have >> >> switch (point->state()) { >> >> It's pretty obvious what case QQuickEventPoint::Pressed: refers to. being overly >> explicit with case QQuickEventPoint::State::Pressed: just adds more to type for >> no reason. > > Similar to Guiseppe, I would argue that the above enum does not comply with the convention for unscoped enums either. I would disagree with that interpretation. > The enum value would have to repeat at least some part of the enum type. That's a rule that has existed for decades now. That circular logic 😊 Or at least arguing that we should maintain the policy not because it makes sense, but just because we’ve done so in the past. You are not questioning _why_ we have done so in the past (for decades as you say), which should be the input to whether or not we want to maintain the policy as is, or update it to match the current landscape of Qt and C++. The mere fact that we’ve had a policy does not have any value. > Therefore QQuickEventPoint::State::Pressed is no more verbose than QQuickEventPoint::PressedState. Again, the policy does not mandate that in it’s current form in my reading of it, and even if it did, that would be a bad policy and we should fix it, not just blindly accept it as set in stone, because we’ve followed it "for decades". > In summary, there is very little verbosity added even by existing rules. Mind you, Qt has always favoured readability and accepted verbosity as a consequence in times of code completion. Code completion (for those that use it), only helps with writing code, and as we all know, most time is spent reading code 😊 > There is one more very important aspect. Scoped enums can have dedicated types and are type safe. This could have easily caught issues like (which coincidently was pointed out to me this morning): > > https://codereview.qt-project.org/#/c/236736/ > > And I believe that is a very good reason to still prefer scoped enums. How frequent is this class of bugs? Clang warns about this with -Wenum-compare for both unstopped and scoped enums, we could easily make that and error and have the best of both. Cheers, Tor Arne > > -- > Alex > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From tony.sarajarvi at qt.io Tue Aug 14 11:56:23 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Tue, 14 Aug 2018 09:56:23 +0000 Subject: [Development] Redeploying hosts with original kernel Message-ID: Hi It seems like a culprit for our extremely odd behaving windows VMs might be the custom kernel we are applying (that tried to fix an NFS issue). After using the original kernel again, it seems at least for now we can run full speed on a host again. So I'll redeploy all hosts (some done already). This will slow down CI for a while, but as things are quite horrible currently, you won't probably notice anything but a better performance in a few hours. This could bring back the NFS bug, but as fix for it was proposed in kernel -38 and MAAS is giving us the kernel -46 now by default, it could either be fixed in the newest hosts we deploy, or the fix never worked to begin with. Anyway, I'll pick the least harmful of the 2 problems we have. Good luck to us! -T -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at qt.io Tue Aug 14 12:13:14 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Tue, 14 Aug 2018 10:13:14 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> Message-ID: > -----Original Message----- > From: Tor Arne Vestbø > That circular logic 😊 Or at least arguing that we should maintain the policy not > because it makes sense, but just because we’ve done so in the past. > > You are not questioning _why_ we have done so in the past (for decades as you > say), which should be the input to whether or not we want to maintain the policy > as is, or update it to match the current landscape of Qt and C++. > > The mere fact that we’ve had a policy does not have any value. Well, so far you only questioned the scoped enum case and making an argument for the scoped enum case based on so far accepted rules for unscoped ones is valid. > > Therefore QQuickEventPoint::State::Pressed is no more verbose than > QQuickEventPoint::PressedState. > > Again, the policy does not mandate that in it’s current form in my reading of it, > and even if it did, that would be a bad policy and we should fix it, not just blindly > accept it as set in stone, because we’ve followed it "for decades". To quote the policy: "By comparison the following example illustrates the dangers of missing type safety and giving general names to conventional enum values:" ... " One guideline for naming enum types is to repeat at least one element of the enum type name in each of the enum values" I think the policy is explicit. Whether you think it is bad is a different kind of thing. Please don't mix that. Personally, I think this naming rule has served us well and although it is not consistently applied the majority of enums does follow them. > > In summary, there is very little verbosity added even by existing rules. Mind > you, Qt has always favoured readability and accepted verbosity as a > consequence in times of code completion. > > Code completion (for those that use it), only helps with writing code, and as we > all know, most time is spent reading code 😊 > > > There is one more very important aspect. Scoped enums can have dedicated > types and are type safe. This could have easily caught issues like (which > coincidently was pointed out to me this morning): > > > > https://codereview.qt-project.org/#/c/236736/ > > > > And I believe that is a very good reason to still prefer scoped enums. > > How frequent is this class of bugs? Frequent enough for it being the primary driver behind the introduction of scoped enums?!? Mind you even our own policies state this limitation of unscoped enums. -- Alex From Tor.arne.Vestbo at qt.io Tue Aug 14 12:30:06 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Tue, 14 Aug 2018 10:30:06 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> Message-ID: <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> > On 14 Aug 2018, at 12:13, Alex Blasche wrote: > > > >> -----Original Message----- >> From: Tor Arne Vestbø >> That circular logic 😊 Or at least arguing that we should maintain the policy not >> because it makes sense, but just because we’ve done so in the past. >> >> You are not questioning _why_ we have done so in the past (for decades as you >> say), which should be the input to whether or not we want to maintain the policy >> as is, or update it to match the current landscape of Qt and C++. >> >> The mere fact that we’ve had a policy does not have any value. > > Well, so far you only questioned the scoped enum case and making an argument for the scoped enum case based on so far accepted rules for unscoped ones is valid. So let’s explicitly make this a discussion about the whole policy then, since it seems that wasn’t obvious 😊 > > >>> Therefore QQuickEventPoint::State::Pressed is no more verbose than >> QQuickEventPoint::PressedState. >> >> Again, the policy does not mandate that in it’s current form in my reading of it, >> and even if it did, that would be a bad policy and we should fix it, not just blindly >> accept it as set in stone, because we’ve followed it "for decades". > > To quote the policy: > > "By comparison the following example illustrates the dangers of missing type safety and giving general names to conventional enum values:" > ... > " One guideline for naming enum types is to repeat at least one element of the enum type name in each of the enum values" > > I think the policy is explicit. The policy uses a global enum as an example. Obviously we need some sort of scoping there, either in the enum value names, or by using scoped enums. We agree there, and can leave that part of the discussion as solved. The discussion here is about what to do when the enum lives inside a class, which would already solve the naming clash issue in most cases. > Whether you think it is bad is a different kind of thing. Please don't mix that. That’s kind of the point of bringing up a policy on the mailing list, to argue that it’s bad, and we should change it… > Personally, I think this naming rule has served us well and although it is not consistently applied the majority of enums does follow them. > >>> In summary, there is very little verbosity added even by existing rules. Mind >> you, Qt has always favoured readability and accepted verbosity as a >> consequence in times of code completion. >> >> Code completion (for those that use it), only helps with writing code, and as we >> all know, most time is spent reading code 😊 >> >>> There is one more very important aspect. Scoped enums can have dedicated >> types and are type safe. This could have easily caught issues like (which >> coincidently was pointed out to me this morning): >>> >>> https://codereview.qt-project.org/#/c/236736/ >>> >>> And I believe that is a very good reason to still prefer scoped enums. >> >> How frequent is this class of bugs? > > Frequent enough for it being the primary driver behind the introduction of scoped enums?!? Do you have a source for this, that specifically mentions the enum inside a class use case a primary driver? You conveniently left out this part of my reply: >> Clang warns about this with -Wenum-compare for both unstopped and scoped enums, we could easily make that and error and have the best of both. Cheers, Tor Arne > > -- > Alex > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Eike.Ziller at qt.io Tue Aug 14 13:13:31 2018 From: Eike.Ziller at qt.io (Eike Ziller) Date: Tue, 14 Aug 2018 11:13:31 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> Message-ID: > On 14. Aug 2018, at 12:30, Tor Arne Vestbø wrote: > >> >> On 14 Aug 2018, at 12:13, Alex Blasche wrote: >> >> >> >>> -----Original Message----- >>> From: Tor Arne Vestbø >>> That circular logic 😊 Or at least arguing that we should maintain the policy not >>> because it makes sense, but just because we’ve done so in the past. >>> >>> You are not questioning _why_ we have done so in the past (for decades as you >>> say), which should be the input to whether or not we want to maintain the policy >>> as is, or update it to match the current landscape of Qt and C++. >>> >>> The mere fact that we’ve had a policy does not have any value. >> >> Well, so far you only questioned the scoped enum case and making an argument for the scoped enum case based on so far accepted rules for unscoped ones is valid. > > So let’s explicitly make this a discussion about the whole policy then, since it seems that wasn’t obvious 😊 > >> >> >>>> Therefore QQuickEventPoint::State::Pressed is no more verbose than >>> QQuickEventPoint::PressedState. >>> >>> Again, the policy does not mandate that in it’s current form in my reading of it, >>> and even if it did, that would be a bad policy and we should fix it, not just blindly >>> accept it as set in stone, because we’ve followed it "for decades". >> >> To quote the policy: >> >> "By comparison the following example illustrates the dangers of missing type safety and giving general names to conventional enum values:" >> ... >> " One guideline for naming enum types is to repeat at least one element of the enum type name in each of the enum values" >> >> I think the policy is explicit. > > The policy uses a global enum as an example. Obviously we need some sort of scoping there, either in the enum value names, or by using scoped enums. We agree there, and can leave that part of the discussion as solved. > > The discussion here is about what to do when the enum lives inside a class, which would already solve the naming clash issue in most cases. > >> Whether you think it is bad is a different kind of thing. Please don't mix that. > > That’s kind of the point of bringing up a policy on the mailing list, to argue that it’s bad, and we should change it… > >> Personally, I think this naming rule has served us well and although it is not consistently applied the majority of enums does follow them. >> >>>> In summary, there is very little verbosity added even by existing rules. Mind >>> you, Qt has always favoured readability and accepted verbosity as a >>> consequence in times of code completion. >>> >>> Code completion (for those that use it), only helps with writing code, and as we >>> all know, most time is spent reading code 😊 >>> >>>> There is one more very important aspect. Scoped enums can have dedicated >>> types and are type safe. This could have easily caught issues like (which >>> coincidently was pointed out to me this morning): >>>> >>>> https://codereview.qt-project.org/#/c/236736/ >>>> >>>> And I believe that is a very good reason to still prefer scoped enums. >>> >>> How frequent is this class of bugs? >> >> Frequent enough for it being the primary driver behind the introduction of scoped enums?!? > > Do you have a source for this, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf states the problems that were the driver for creating strongly typed enums: 1. Implicit conversion to integer 2. Inability to specify underlying type 3. Scoping > that specifically mentions the enum inside a class use case a primary driver? Why would the implicit conversion problem be any different for enums inside a class? > > You conveniently left out this part of my reply: > >>> Clang warns about this with -Wenum-compare for both unstopped and scoped enums, we could easily make that and error and have the best of both. > > > Cheers, > Tor Arne > >> >> -- >> Alex >> >> _______________________________________________ >> 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 -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Tor.arne.Vestbo at qt.io Tue Aug 14 13:18:15 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Tue, 14 Aug 2018 11:18:15 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> Message-ID: <738A8F0F-5F4C-4D31-8AF9-1A719699D69C@qt.io> > On 14 Aug 2018, at 13:13, Eike Ziller wrote: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf states the problems that were the driver for creating strongly typed enums: > > 1. Implicit conversion to integer > 2. Inability to specify underlying type https://en.cppreference.com/w/cpp/language/enum describes types for unscoped enums too, curious, what’s the difference for the scoped enums? > 3. Scoping > >> that specifically mentions the enum inside a class use case a primary driver? > > Why would the implicit conversion problem be any different for enums inside a class? It wouldn’t. I was referring to the scoping/name clash, which is what this discussion has been largely focusing on (so far). Tor Arne From jani.heikkinen at qt.io Tue Aug 14 13:48:23 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 14 Aug 2018 11:48:23 +0000 Subject: [Development] HEADS-UP: Branching from 'dev' to '5.12' started Message-ID: Hi! We have soft branched '5.12' from 'dev' today. We are planning to have final downmerge and Qt 5.12 Feature Freeze Monday 20.8.2018. So there is still time to finalize ongoing task in 'dev' and start using '5.12' for new changes targeted to Qt 5.12 release. br, Jani Heikkinen Release Manager From alexander.blasche at qt.io Tue Aug 14 14:27:27 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Tue, 14 Aug 2018 12:27:27 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> Message-ID: > -----Original Message----- > From: Tor Arne Vestbø > > To quote the policy: > > > > "By comparison the following example illustrates the dangers of missing type > safety and giving general names to conventional enum values:" > > ... > > " One guideline for naming enum types is to repeat at least one element of the > enum type name in each of the enum values" > > > > I think the policy is explicit. > > The policy uses a global enum as an example. Obviously we need some sort of > scoping there, either in the enum value names, or by using scoped enums. We > agree there, and can leave that part of the discussion as solved. > > The discussion here is about what to do when the enum lives inside a class, > which would already solve the naming clash issue in most cases. This is not about namespace clashes or inside or outside classes. It is about readability. Unscoped enums don’t require the enum type to be mentioned although the type name tremendously helps as context info for enum values. Without this context the enum is harder to understand. Hence a more verbose name (repeating essential part of the type) is chosen. And we have not even talked about strong typing of scoped versions (see Eike's comment) Scoped enums have a few advantages which are sufficient for me to accept its use. Combine that with a naming policy that is close to what we had for unscoped enums and you got a winner for me 😉 -- Alex From Eike.Ziller at qt.io Tue Aug 14 15:00:34 2018 From: Eike.Ziller at qt.io (Eike Ziller) Date: Tue, 14 Aug 2018 13:00:34 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: <738A8F0F-5F4C-4D31-8AF9-1A719699D69C@qt.io> References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> <738A8F0F-5F4C-4D31-8AF9-1A719699D69C@qt.io> Message-ID: > On 14. Aug 2018, at 13:18, Tor Arne Vestbø wrote: > > >> On 14 Aug 2018, at 13:13, Eike Ziller wrote: >> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf states the problems that were the driver for creating strongly typed enums: >> >> 1. Implicit conversion to integer >> 2. Inability to specify underlying type > > https://en.cppreference.com/w/cpp/language/enum describes types for unscoped enums too, curious, what’s the difference for the scoped enums? > >> 3. Scoping >> >>> that specifically mentions the enum inside a class use case a primary driver? >> >> Why would the implicit conversion problem be any different for enums inside a class? > > It wouldn’t. I was referring to the scoping/name clash, which is what this discussion has been largely focusing on (so far). Now you cut off context. I was answering to: >>>> >>>> There is one more very important aspect. Scoped enums can have dedicated >>> types and are type safe. This could have easily caught issues like (which >>> coincidently was pointed out to me this morning): >>>> >>>> https://codereview.qt-project.org/#/c/236736/ >>>> >>>> And I believe that is a very good reason to still prefer scoped enums. >>> >>> How frequent is this class of bugs? >> >> Frequent enough for it being the primary driver behind the introduction of scoped enums?!? > > Do you have a source for this, that specifically mentions the enum inside a class use case a primary driver? Which is about type-safety, not scoping. -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From kde at carewolf.com Tue Aug 14 15:29:21 2018 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Tue, 14 Aug 2018 15:29:21 +0200 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> Message-ID: <9079957.coCNVf3Vdy@twilight> On Dienstag, 14. August 2018 14:27:27 CEST Alex Blasche wrote: > > -----Original Message----- > > From: Tor Arne Vestbø > > > > > > To quote the policy: > > > > > > > > > > > > "By comparison the following example illustrates the dangers of missing > > > type > > > safety and giving general names to conventional enum values:" > > > > > ... > > > " One guideline for naming enum types is to repeat at least one element > > > of the > > > enum type name in each of the enum values" > > > > > > > > > > > I think the policy is explicit. > > > > > > The policy uses a global enum as an example. Obviously we need some sort > > of scoping there, either in the enum value names, or by using scoped > > enums. We agree there, and can leave that part of the discussion as > > solved. > > The discussion here is about what to do when the enum lives inside a > > class, which would already solve the naming clash issue in most cases. > > > This is not about namespace clashes or inside or outside classes. It is > about readability. Unscoped enums don’t require the enum type to be > mentioned although the type name tremendously helps as context info for > enum values. Without this context the enum is harder to understand. Hence a > more verbose name (repeating essential part of the type) is chosen. > And we have not even talked about strong typing of scoped versions (see > Eike's comment) > Scoped enums have a few advantages which are sufficient for me to accept its > use. Combine that with a naming policy that is close to what we had for > unscoped enums and you got a winner for me 😉 I agree, at least in most cases. There are still cases where I would prefer unscoped enums. For instance in my recent QColorSpace patch, I ended up using both types of enums under QColorSpace. The enum that represented specific colorspaces that looked best without an extra scope I left unscoped (e.g. QColorSpace::SRgb as opposed to QColorSpace::PredefinedColorSpace::SRgb), enums that represented specific property types that couldn't be used alone to construct a QColorSpace, I scoped (E.g. QColorSpace::Gamut::AdobeRgb). If we applied a policy like that to all of Qt, most enums would be scoped, but a few such as the special types of QJsonValue would not be. Best regards 'Allan From Tor.arne.Vestbo at qt.io Tue Aug 14 15:35:11 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Tue, 14 Aug 2018 13:35:11 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> <738A8F0F-5F4C-4D31-8AF9-1A719699D69C@qt.io> Message-ID: I’ve lost track of what you are arguing for here 😊 To bring the discussion back, here are my main points: 1. Scoped enums (enum class) for the sake of avoiding name clashes is useful for global enums, but when the enum lives inside a class, the chance that we’ll see a naming clash is minor, and using scoped enums in that case arguably has negative effects on code writability/readability. As a result, we should update the policy to not mandate scoped enums when the enum lives inside a class. 2. Scoped enums for the sake of type safety is a valid use case, but can be solved by promoting a warning to an error, and as such shouldn’t block us moving forward with #1. Cheers, Tor Arne > On 14 Aug 2018, at 15:00, Eike Ziller wrote: > > > >> On 14. Aug 2018, at 13:18, Tor Arne Vestbø wrote: >> >> >>> On 14 Aug 2018, at 13:13, Eike Ziller wrote: >>> >>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf states the problems that were the driver for creating strongly typed enums: >>> >>> 1. Implicit conversion to integer >>> 2. Inability to specify underlying type >> >> https://en.cppreference.com/w/cpp/language/enum describes types for unscoped enums too, curious, what’s the difference for the scoped enums? >> >>> 3. Scoping >>> >>>> that specifically mentions the enum inside a class use case a primary driver? >>> >>> Why would the implicit conversion problem be any different for enums inside a class? >> >> It wouldn’t. I was referring to the scoping/name clash, which is what this discussion has been largely focusing on (so far). > > Now you cut off context. I was answering to: > >>>>> >>>>> There is one more very important aspect. Scoped enums can have dedicated >>>> types and are type safe. This could have easily caught issues like (which >>>> coincidently was pointed out to me this morning): >>>>> >>>>> https://codereview.qt-project.org/#/c/236736/ >>>>> >>>>> And I believe that is a very good reason to still prefer scoped enums. >>>> >>>> How frequent is this class of bugs? >>> >>> Frequent enough for it being the primary driver behind the introduction of scoped enums?!? >> >> Do you have a source for this, that specifically mentions the enum inside a class use case a primary driver? > > Which is about type-safety, not scoping. > > -- > Eike Ziller > Principal Software Engineer > > The Qt Company GmbH > Rudower Chaussee 13 > D-12489 Berlin > eike.ziller at qt.io > http://qt.io > Geschäftsführer: Mika Pälsi, > Juha Varelius, Mika Harjuaho > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Tor.arne.Vestbo at qt.io Tue Aug 14 15:38:31 2018 From: Tor.arne.Vestbo at qt.io (=?iso-8859-1?Q?Tor_Arne_Vestb=F8?=) Date: Tue, 14 Aug 2018 13:38:31 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: <9079957.coCNVf3Vdy@twilight> References: <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> <9079957.coCNVf3Vdy@twilight> Message-ID: <4AFC098F-3FC7-4108-A928-08532553D202@qt.io> > On 14 Aug 2018, at 15:29, Allan Sandfeld Jensen wrote: > > I agree, at least in most cases. There are still cases where I would prefer > unscoped enums. For instance in my recent QColorSpace patch, I ended up using > both types of enums under QColorSpace. The enum that represented specific > colorspaces that looked best without an extra scope I left unscoped (e.g. > QColorSpace::SRgb as opposed to QColorSpace::PredefinedColorSpace::SRgb), > enums that represented specific property types that couldn't be used alone to > construct a QColorSpace, I scoped (E.g. QColorSpace::Gamut::AdobeRgb). A policy not mandating use of scoped enums everywhere would still allow you to use them where it makes sense :) Tor Arne From jani.heikkinen at qt.io Wed Aug 15 06:50:08 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 15 Aug 2018 04:50:08 +0000 Subject: [Development] Qt 5.12 new features Message-ID: Hi, Qt 5.12 Feature Freeze will be in effect Mon 20th August and we should have already now pretty good understanding what is new in Qt 5.12. So please update 5.12 new features page here: https://wiki.qt.io/New_Features_in_Qt_5.12 br, Jani From alexander.blasche at qt.io Wed Aug 15 09:32:48 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Wed, 15 Aug 2018 07:32:48 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> <738A8F0F-5F4C-4D31-8AF9-1A719699D69C@qt.io> Message-ID: > -----Original Message----- > From: Tor Arne Vestbø > 1. Scoped enums (enum class) for the sake of avoiding name clashes is useful for > global enums, but when the enum lives inside a class, the chance that we’ll see a > naming clash is minor, and using scoped enums in that case arguably has > negative effects on code writability/readability. As a result, we should update > the policy to not mandate scoped enums when the enum lives inside a class. I don't think we have ever not permitted exceptions to official policy. Therefore, take it for granted that the policy can be ignored such as in the case presented by Allan. Having said that the default should be the use of scoped enums even inside of classes. I don't consider the longer names detrimental for writability and usability. Writability is easily solved with code completion and readability is actually better because the type adds additional context info. To cite an example from Shawn's patch: QQuickPointerDevice::Finger QQuickPointerDevice::Mouse is far less descriptive than (and not compliant to current naming convention) QQuickPointerDevice::PointerType::Finger QQuickPointerDevice::DeviceType::Mouse. The uninitiated reader of the code cannot see the additional type context when reading code and therefore someone might interpret Finger as a device type too. That's exactly what the existing unscoped enum policy tries to fix. Scoped enums provide this feature out of the box. Another example of a good naming policy (IMO) is QAbstractSocket (never mind the technical limitations). Here we could shorten the enum names using scoped enums: QAbstractSocket::SocketError::ConnectionRefusedError -> QAbstractSocket::SocketError::ConnectionRefused (or even QAbstractSocket::Error::ConnectionRefused) Name clash prevention was only ever secondary to readability. > 2. Scoped enums for the sake of type safety is a valid use case, but can be solved > by promoting a warning to an error, and as such shouldn’t block us moving > forward with #1. I don't see how a policy of elevating warnings to errors is better that using a language inbuilt error due to strong type safety. -- Alex From Tor.arne.Vestbo at qt.io Wed Aug 15 11:33:36 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Wed, 15 Aug 2018 09:33:36 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> <738A8F0F-5F4C-4D31-8AF9-1A719699D69C@qt.io> Message-ID: > On 15 Aug 2018, at 09:32, Alex Blasche wrote: > > > >> -----Original Message----- >> From: Tor Arne Vestbø >> 1. Scoped enums (enum class) for the sake of avoiding name clashes is useful for >> global enums, but when the enum lives inside a class, the chance that we’ll see a >> naming clash is minor, and using scoped enums in that case arguably has >> negative effects on code writability/readability. As a result, we should update >> the policy to not mandate scoped enums when the enum lives inside a class. > > I don't think we have ever not permitted exceptions to official policy. Therefore, take it for granted that the policy can be ignored such as in the case presented by Allan. Having said that the default should be the use of scoped enums even inside of classes. Fair enough, but having the policy means following that by default, resulting in patches defaulting to the policy because it’s a policy, not taking each individual case into consideration. Since I’m arguing that the default of preferring scoped enums inside classes will in most cases result in less writable/readable code, I don’t want us to default to something that produces worse results than defaulting to the opposite. > I don't consider the longer names detrimental for writability and usability. Writability is easily solved with code completion and readability is actually better because the type adds additional context info. To cite an example from Shawn's patch: > > QQuickPointerDevice::Finger > QQuickPointerDevice::Mouse > > is far less descriptive than (and not compliant to current naming convention) > > QQuickPointerDevice::PointerType::Finger > QQuickPointerDevice::DeviceType::Mouse. > When you write these enums in isolation, yes. But that’s not how the enums are used in actual code: if (eventPoint->state() != QQuickEventPoint::Released && wantsEventPoint(eventPoint)) if (dev->type() == QQuickPointerDevice::TouchScreen) vs if (eventPoint->state() != QQuickEventPoint::State::Released && wantsEventPoint(eventPoint)) if (dev->type() == QQuickPointerDevice::DeviceType::TouchScreen) The context is already there in most cases, which makes forcing the name of the enum into the code redundant. And if the context is not there, you can still write QQuickPointerDevice::DeviceType::TouchScreen to be more explicit _when_ needed, even without scoped enums. Or just DeviceType::TouchScreen, if you are inside the class. Or even just TouchScreen if the context is obvious from the rest of the call. Using scoped enums removes this flexibility. > The uninitiated reader of the code cannot see the additional type context when reading code and therefore someone might interpret Finger as a device type too. As argued above, the uninitiated reader _can_. > >> 2. Scoped enums for the sake of type safety is a valid use case, but can be solved >> by promoting a warning to an error, and as such shouldn’t block us moving >> forward with #1. > > I don't see how a policy of elevating warnings to errors is better that using a language inbuilt error due to strong type safety. Of course it’s not better, if you focus only on that. The use of a warning-as-error instead of a language inbuilt is a workable practical compromise because the language inbuilt comes with other downside, as discussed above. Tor Arne From Eike.Ziller at qt.io Wed Aug 15 13:48:56 2018 From: Eike.Ziller at qt.io (Eike Ziller) Date: Wed, 15 Aug 2018 11:48:56 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> <738A8F0F-5F4C-4D31-8AF9-1A719699D69C@qt.io> Message-ID: > On 15. Aug 2018, at 11:33, Tor Arne Vestbø wrote: > > > >> On 15 Aug 2018, at 09:32, Alex Blasche wrote: >> >> >> >>> -----Original Message----- >>> From: Tor Arne Vestbø >>> 1. Scoped enums (enum class) for the sake of avoiding name clashes is useful for >>> global enums, but when the enum lives inside a class, the chance that we’ll see a >>> naming clash is minor, and using scoped enums in that case arguably has >>> negative effects on code writability/readability. As a result, we should update >>> the policy to not mandate scoped enums when the enum lives inside a class. >> >> I don't think we have ever not permitted exceptions to official policy. Therefore, take it for granted that the policy can be ignored such as in the case presented by Allan. Having said that the default should be the use of scoped enums even inside of classes. > > Fair enough, but having the policy means following that by default, resulting in patches defaulting to the policy because it’s a policy, not taking each individual case into consideration. Since I’m arguing that the default of preferring scoped enums inside classes will in most cases result in less writable/readable code, I don’t want us to default to something that produces worse results than defaulting to the opposite. > >> I don't consider the longer names detrimental for writability and usability. Writability is easily solved with code completion and readability is actually better because the type adds additional context info. To cite an example from Shawn's patch: >> >> QQuickPointerDevice::Finger >> QQuickPointerDevice::Mouse >> >> is far less descriptive than (and not compliant to current naming convention) >> >> QQuickPointerDevice::PointerType::Finger >> QQuickPointerDevice::DeviceType::Mouse. >> > > When you write these enums in isolation, yes. > > But that’s not how the enums are used in actual code: > > if (eventPoint->state() != QQuickEventPoint::Released && wantsEventPoint(eventPoint)) > > if (dev->type() == QQuickPointerDevice::TouchScreen) > > vs > > if (eventPoint->state() != QQuickEventPoint::State::Released && wantsEventPoint(eventPoint)) > > if (dev->type() == QQuickPointerDevice::DeviceType::TouchScreen) > > The context is already there in most cases, which makes forcing the name of the enum into the code redundant. > > And if the context is not there, you can still write QQuickPointerDevice::DeviceType::TouchScreen to be more explicit _when_ needed, even without scoped enums. > > Or just DeviceType::TouchScreen, if you are inside the class. Or even just TouchScreen if the context is obvious from the rest of the call. > > Using scoped enums removes this flexibility. > >> The uninitiated reader of the code cannot see the additional type context when reading code and therefore someone might interpret Finger as a device type too. > > As argued above, the uninitiated reader _can_. > >> >>> 2. Scoped enums for the sake of type safety is a valid use case, but can be solved >>> by promoting a warning to an error, and as such shouldn’t block us moving >>> forward with #1. >> >> I don't see how a policy of elevating warnings to errors is better that using a language inbuilt error due to strong type safety. > > Of course it’s not better, if you focus only on that. The use of a warning-as-error instead of a language inbuilt is a workable practical compromise because the language inbuilt comes with other downside, as discussed above. Note that this warning does not cover all cases where conversions of enums to int are done where they where probably not intended. E.g. if (dev->type()) // forgot to add the actual comparison itemModel->sort(Qt::AscendingOrder); // forgot the column as the first argument Br, Eike -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From thiago.macieira at intel.com Wed Aug 15 17:58:22 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 15 Aug 2018 08:58:22 -0700 Subject: [Development] MSVC 2017 15.8 upgrade Message-ID: <1692403.fqLxdzxPmg@tjmaciei-mobl1> If you upgraded MSVC 2017 to 15.8 yesterday and you try to build qtbase, you'll get a build error. This is fixed, but you need to make sure you erase .qmake.stash files everywhere, since they contain the cached version of the compiler. And since neither nmake nor jom update Makefiles on their own, erase them all too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mingw.android at gmail.com Wed Aug 15 18:10:36 2018 From: mingw.android at gmail.com (Ray Donnelly) Date: Wed, 15 Aug 2018 17:10:36 +0100 Subject: [Development] MSVC 2017 15.8 upgrade In-Reply-To: <1692403.fqLxdzxPmg@tjmaciei-mobl1> References: <1692403.fqLxdzxPmg@tjmaciei-mobl1> Message-ID: Hi Thiago, Do you know what sort of state Qt is in w.r.t. VS 2017 15.8? The Anaconda Distribution team is considering whether to update to it and this would be great to know. On Wed, Aug 15, 2018 at 4:58 PM, Thiago Macieira wrote: > If you upgraded MSVC 2017 to 15.8 yesterday and you try to build qtbase, > you'll get a build error. This is fixed, but you need to make sure you erase > .qmake.stash files everywhere, since they contain the cached version of the > compiler. > > And since neither nmake nor jom update Makefiles on their own, erase them all > too. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Wed Aug 15 18:18:56 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 15 Aug 2018 09:18:56 -0700 Subject: [Development] MSVC 2017 15.8 upgrade In-Reply-To: References: <1692403.fqLxdzxPmg@tjmaciei-mobl1> Message-ID: <3331573.gVU1r7BZXY@tjmaciei-mobl1> On Wednesday, 15 August 2018 09:10:36 PDT Ray Donnelly wrote: > Hi Thiago, > > Do you know what sort of state Qt is in w.r.t. VS 2017 15.8? The > Anaconda Distribution team is considering whether to update to it and > this would be great to know. It should just work. Obviously, please give us a bit more than 24 hours since the compiler release to know more. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mingw.android at gmail.com Wed Aug 15 19:08:10 2018 From: mingw.android at gmail.com (Ray Donnelly) Date: Wed, 15 Aug 2018 18:08:10 +0100 Subject: [Development] MSVC 2017 15.8 upgrade In-Reply-To: <3331573.gVU1r7BZXY@tjmaciei-mobl1> References: <1692403.fqLxdzxPmg@tjmaciei-mobl1> <3331573.gVU1r7BZXY@tjmaciei-mobl1> Message-ID: On Wed, Aug 15, 2018 at 5:18 PM, Thiago Macieira wrote: > On Wednesday, 15 August 2018 09:10:36 PDT Ray Donnelly wrote: >> Hi Thiago, >> >> Do you know what sort of state Qt is in w.r.t. VS 2017 15.8? The >> Anaconda Distribution team is considering whether to update to it and >> this would be great to know. > > It should just work. Obviously, please give us a bit more than 24 hours since > the compiler release to know more. > Sure thing, thanks. > -- > 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 apoenitz at t-online.de Wed Aug 15 09:04:30 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Wed, 15 Aug 2018 09:04:30 +0200 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> <738A8F0F-5F4C-4D31-8AF9-1A719699D69C@qt.io> Message-ID: <20180815070430.GA2298@klara.mpi.htwm.de> On Wed, Aug 15, 2018 at 07:32:48AM +0000, Alex Blasche wrote: > I don't think we have ever not permitted exceptions to official > policy. Therefore, take it for granted that the policy can be ignored > such as in the case presented by Allan. Having said that the default > should be the use of scoped enums even inside of classes. [...] More a general remark than a response to this particular message, or even thread. Still: One thing that severely annoys me, and has done so for a few years now, especially in leaf modules, is the piecemeal introduction of API style changes. While good old Qt API may look a bit unfashionable and outdated at times, it had the huge advantage of being consistent. The new styles usually do have some benefit, but their use starts by doing actual damage due to the introduced inconsistency. I'd rather stay consistent as long as reasonably possible, and then do big jumps, instead of seeing this GTK-style jumble all day. Andre' From thiago.macieira at intel.com Wed Aug 15 23:08:40 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 15 Aug 2018 14:08:40 -0700 Subject: [Development] MSVC 2017 15.8 upgrade In-Reply-To: <1692403.fqLxdzxPmg@tjmaciei-mobl1> References: <1692403.fqLxdzxPmg@tjmaciei-mobl1> Message-ID: <5242895.GWTGxQFC93@tjmaciei-mobl1> On Wednesday, 15 August 2018 08:58:22 PDT Thiago Macieira wrote: > If you upgraded MSVC 2017 to 15.8 yesterday and you try to build qtbase, > you'll get a build error. This is fixed, but you need to make sure you erase > .qmake.stash files everywhere, since they contain the cached version of the > compiler. > > And since neither nmake nor jom update Makefiles on their own, erase them > all too. Another issue: 5.9 doesn't build in 32-bit x86. Fix is in https://codereview.qt-project.org/236948 (backport of c59cb9809559f0aae6be8544cb2049e41f8040e9). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kotov.valery at gmail.com Thu Aug 16 08:06:41 2018 From: kotov.valery at gmail.com (Valery Kotov) Date: Thu, 16 Aug 2018 08:06:41 +0200 Subject: [Development] Storing and managing ValueArray inside QV4::Heap objects In-Reply-To: References: Message-ID: Hello all, I'm trying to wrap my head around SimpleArrayData API. And I might actually need a bit of help here. Instead of using ValueArray now I declare myValues to be SimpleArrayData*: #define MyObjectMembers(class, Member) \ Member(class, Pointer, SimpleArrayData*, myValues) DECLARE_HEAP_OBJECT(MyObject, Object) { DECLARE_MARKOBJECTS(MyObject); In MyObjects' init function I'm creating and initializing myValues: const size_t size = sizeof(Heap::ArrayData) + length*sizeof(Value); // I still can have 0 length array, right? Heap::SimpleArrayData *d = e->memoryManager->allocManaged(size); d->init(); d->type = Heap::ArrayData::Simple; d->offset = 0; d->values.alloc = length; d->values.size = length; myValues.set(e, d); Later I'm trying to add a new item to myValues: ScopedArrayObject a(scope, scope.engine->memoryManager->allocate()); a->d()->arrayData.set(scope.engine, d()->myValues); Scoped sa(scope, d()->myValues); sa->push_front(a, newValue, 1); Clearly I'm doing something wrong. push_front adds a new item to array indeed, but not to myValues SimpleArrayData memeber. Internally, from what I could observe, realloc creates a new SimpleArrayData and new item actually added to it. What I have a little bit of trouble to understand, is how to use SimpleArrayData API. It has to be used in conjunction with ArrayObject somehow, right? Or shall I store ArrayObject pointer instead of SimpleArrayData? >> If you have a fully dynamic array, then the alternative would be to store a pointer to your QVector in the heap object. Yes, that is a good point. Thank you. Though, I have a small concern here. >From what I could see, QQmlSequence does not store JS heap objects in QVector (or did I miss it somehow?). Whereas I would like my container to: * be dynamically resizable, since amount of it's items is not known in advance * be able to store JS heap objects What would you suggest to use in this case? Shall I still go for SimpleArrayData and make it work? Or shall I use QVector instead? In case of QVector would it be safe to store JS Object pointers or it should be QVector of PersistentValues? Thank you! Sincerely yours, Valery Kotov On Thu, 9 Aug 2018 at 08:20, Valery Kotov wrote: > Hi Lars, Simon, > > I think I got it. Thanks a lot for your tips! > > Sincerely yours, > Valery Kotov > > On 8 August 2018 at 09:32, Simon Hausmann wrote: > >> Hi, >> >> >> If you want to use the ValueArray, then you need to make sure that it's >> the last member of your type. Then encapsulate the creation if the type in >> a factory function that works a bit like ExecutionContext::newCallContext: >> >> >> (1) Calculate how much memory you're going to need for the type _and_ >> the value array (minus one Value). >> >> (2) Allocate the memory with one call to allocManaged. >> >> (3) call init() manually. >> >> (4) Set the alloc and size members of the value array to the amount >> of allocated values. >> >> >> While this approach is clever in the sense that it gives a compact memory >> representation and allocates object and array data in one shot, it also >> means that it's not so suitable for frequent dynamic resizing as it will >> require re-allocating the entire object. >> >> >> If you have a fully dynamic array, then the alternative would be to store >> a pointer to your QVector in the heap object. Heap::QQmlSequence does that, >> for example. Just make sure to use V4_NEEDS_DESTROY and provide a destroy() >> function to delete the vector. >> >> >> I'd probably go for the first approach with perhaps an indirect type >> (similar to how Object has MemberData) if the array contains references to >> the JS heap. If your array has only references to the C heap, then you're >> probably better off using a pointer to a regular vector. >> >> >> Simon >> >> ------------------------------ >> *From:* Development > qt.io at qt-project.org> on behalf of Valery Kotov >> *Sent:* Wednesday, August 8, 2018 9:10:43 AM >> *To:* Qt development mailing list >> *Subject:* [Development] Storing and managing ValueArray inside >> QV4::Heap objects >> >> Hello all, >> >> I have a question about QV4 heap objects and what could be stored in them. >> I would like to move data structure from c++ heap to GC heap. >> Unfortunately, my data structure stores a pair of QLists internally. >> As far as I'm aware, QV4::Heap objects should be "trivially >> constructible", and thus, cannot store QList(s). >> One option would be to store QList pointer and manage it's lifecycle >> manually. But that does not sound like a good idea. >> I've noticed though, that some of qv4 types are using DECLARE_MARKOBJECTS >> macro. By using DECLARE_MARKOBJECTS macro and ObjectMember(s) define I can >> actually store a ValueArray member in my QV4 heap object. >> >> #define MyObjectMembers(class, Member) \ >> Member(class, ValueArray, ValueArray, myValues) >> >> DECLARE_HEAP_OBJECT(MyObject, Object) { >> DECLARE_MARKOBJECTS(MyObject); >> >> In this case I can refer to myValues ValueArray type inside of MyObject. >> Unfortunately, it is a little bit unclear to me how to manage ValueArrays. >> From what I can see from some examples in the code (qv4generatorobject, >> qv4arraydata), it seems that I need to manage ValueArray manually. >> What I'm missing at the moment a little bit is how the actually >> allocation for ValueArray.values is done. >> I suspect that it is probably not done via plain "new" call. Otherwise it >> is a little bit confusing why not just to store the pointer directly. >> >> Could you guys please give me a few hints how to go about ValueArray >> management? >> >> Thank you! >> Sincerely yours, >> Valery Kotov >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at qt.io Thu Aug 16 14:29:17 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Thu, 16 Aug 2018 12:29:17 +0000 Subject: [Development] Nominating Miguel Costa for Approver In-Reply-To: References: Message-ID: Congratulations to Miguel. Approver rights have been granted. -- Alex ________________________________________ From: Alex Blasche Sent: Wednesday, 25 July 2018 5:12:47 PM To: development at qt-project.org Subject: Nominating Miguel Costa for Approver Hi, I'd like to nominate Miguel for approver rights. He has been with us at the TQtC for a year. His largest contributions have been to the Visual Studio addin which he properly ported to the latest VS incarnations/APIs. More recently he has started to look at the WinRT port and the Angle integration in particular. His work: https://codereview.qt-project.org/#/q/owner:+miguel.costa,n,z His reviews: https://codereview.qt-project.org/#/q/reviewer:+miguel.costa,n,z -- Alex From alexander.blasche at qt.io Thu Aug 16 14:30:25 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Thu, 16 Aug 2018 12:30:25 +0000 Subject: [Development] =?iso-8859-1?q?Noninating_Andr=E9_de_la_Rocha_for_?= =?iso-8859-1?q?Approver?= In-Reply-To: References: Message-ID: Congratulations to André. Approver rights have been granted. -- Alex ________________________________________ From: Development on behalf of Alex Blasche Sent: Wednesday, 25 July 2018 5:12:39 PM To: development at qt-project.org Subject: [Development] Noninating André de la Rocha for Approver Hi, I'd like to nominate André for approver rights. He has been with us at the TQtC for almost a year. He has mainly contributed to the Win32 port (e.g. Windows UI Automation adoption & Windows Pointer Input Message Support) but you may have seen an occasional iOS fix too. His work: https://codereview.qt-project.org/#/q/owner:+andre.rocha,n,z His reviews: https://codereview.qt-project.org/#/q/reviewer:+andre.rocha,n,z -- Alex _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jhihn at gmx.com Thu Aug 16 16:02:36 2018 From: jhihn at gmx.com (Jason H) Date: Thu, 16 Aug 2018 16:02:36 +0200 Subject: [Development] Qt 5.12 new features In-Reply-To: References: Message-ID: 5.11 included WebGL TP2. Is there any change? Why is it staying TP2, or should it be TP3? 5.12 looks like it'll be a pretty great update! I'm not sure what's on the agenda for 5.13... but as I mentioned on interest, one pain point I continually have is the amount of custom platform integrations for mobile. This is one area where Xamrain excels, as they have a simple property on an object you can set to control things like the status bar visibility, the screen brightness, etc. The downside is the Xamarin stuff is all platform-specific so using a iOS property on Android won't work. This is one area where Qt can leapfrog the other platforms including React Native by being cross platform. Anything that doesn't require me to write Obj-C is a very good thing! I figure this would need to be a few Qt Quick/QObject Singletons. Notifications should be supported too, and this could also be used for desktop platform notifications as well. The notifications support would only need to cover being messaged my the platform, and not any display - this would get me out of having to deal with Obj-C almost completely. (My beef with ObjC is other than being not good at it, is whatever I'm writing isn't cross-platform. Java I am more comfortable with, so I complain less, but I still cringe on the non-portability!) Looking forward to 5.12! > Sent: Wednesday, August 15, 2018 at 12:50 AM > From: "Jani Heikkinen" > To: "development at qt-project.org" > Subject: [Development] Qt 5.12 new features > > Hi, > > Qt 5.12 Feature Freeze will be in effect Mon 20th August and we should have already now pretty good understanding what is new in Qt 5.12. So please update 5.12 new features page here: https://wiki.qt.io/New_Features_in_Qt_5.12 > > br, > Jani > > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From vladstelmahovsky at gmail.com Thu Aug 16 16:16:46 2018 From: vladstelmahovsky at gmail.com (Vlad Stelmahovsky) Date: Thu, 16 Aug 2018 16:16:46 +0200 Subject: [Development] Qt 5.12 new features In-Reply-To: References: Message-ID: A bit unclear about deprecating QQC1 Since in QQC2 no TreeView and even no plans for this, isn't it a bit too early to deprecate QQC1? thanks On Thu, Aug 16, 2018 at 4:02 PM Jason H wrote: > 5.11 included WebGL TP2. Is there any change? Why is it staying TP2, or > should it be TP3? > > 5.12 looks like it'll be a pretty great update! > > I'm not sure what's on the agenda for 5.13... but as I mentioned on > interest, one pain point I continually have is the amount of custom > platform integrations for mobile. This is one area where Xamrain excels, as > they have a simple property on an object you can set to control things like > the status bar visibility, the screen brightness, etc. The downside is the > Xamarin stuff is all platform-specific so using a iOS property on Android > won't work. This is one area where Qt can leapfrog the other platforms > including React Native by being cross platform. Anything that doesn't > require me to write Obj-C is a very good thing! I figure this would need > to be a few Qt Quick/QObject Singletons. Notifications should be supported > too, and this could also be used for desktop platform notifications as > well. The notifications support would only need to cover being messaged my > the platform, and not any display - this would get me out of having to deal > with Obj-C almost completely. (My beef wi > th ObjC is other than being not good at it, is whatever I'm writing isn't > cross-platform. Java I am more comfortable with, so I complain less, but I > still cringe on the non-portability!) > > Looking forward to 5.12! > > > Sent: Wednesday, August 15, 2018 at 12:50 AM > > From: "Jani Heikkinen" > > To: "development at qt-project.org" > > Subject: [Development] Qt 5.12 new features > > > > Hi, > > > > Qt 5.12 Feature Freeze will be in effect Mon 20th August and we should > have already now pretty good understanding what is new in Qt 5.12. So > please update 5.12 new features page here: > https://wiki.qt.io/New_Features_in_Qt_5.12 > > > > 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 > -- Best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From markg85 at gmail.com Thu Aug 16 17:20:54 2018 From: markg85 at gmail.com (Mark Gaiser) Date: Thu, 16 Aug 2018 17:20:54 +0200 Subject: [Development] Qt 5.12 new features In-Reply-To: References: Message-ID: On Thu, Aug 16, 2018 at 4:17 PM Vlad Stelmahovsky < vladstelmahovsky at gmail.com> wrote: > A bit unclear about deprecating QQC1 > Since in QQC2 no TreeView and even no plans for this, isn't it a bit too > early to deprecate QQC1? > > thanks > > On Thu, Aug 16, 2018 at 4:02 PM Jason H wrote: > >> 5.11 included WebGL TP2. Is there any change? Why is it staying TP2, or >> should it be TP3? >> >> 5.12 looks like it'll be a pretty great update! >> >> I'm not sure what's on the agenda for 5.13... but as I mentioned on >> interest, one pain point I continually have is the amount of custom >> platform integrations for mobile. This is one area where Xamrain excels, as >> they have a simple property on an object you can set to control things like >> the status bar visibility, the screen brightness, etc. The downside is the >> Xamarin stuff is all platform-specific so using a iOS property on Android >> won't work. This is one area where Qt can leapfrog the other platforms >> including React Native by being cross platform. Anything that doesn't >> require me to write Obj-C is a very good thing! I figure this would need >> to be a few Qt Quick/QObject Singletons. Notifications should be supported >> too, and this could also be used for desktop platform notifications as >> well. The notifications support would only need to cover being messaged my >> the platform, and not any display - this would get me out of having to deal >> with Obj-C almost completely. (My beef wi >> th ObjC is other than being not good at it, is whatever I'm writing >> isn't cross-platform. Java I am more comfortable with, so I complain less, >> but I still cringe on the non-portability!) >> >> Looking forward to 5.12! >> >> > Sent: Wednesday, August 15, 2018 at 12:50 AM >> > From: "Jani Heikkinen" >> > To: "development at qt-project.org" >> > Subject: [Development] Qt 5.12 new features >> > >> > Hi, >> > >> > Qt 5.12 Feature Freeze will be in effect Mon 20th August and we should >> have already now pretty good understanding what is new in Qt 5.12. So >> please update 5.12 new features page here: >> https://wiki.qt.io/New_Features_in_Qt_5.12 >> > >> > br, >> > Jani >> > > > Why deprecate QQC1? If you aim for a native looking QML application in Windows 7 then QQC1 is basically the only viable way to go. I know there is a third party plugin for QQC2 and the QWidgets style (thus also Windows 7) integration, but it's a third party one [1] and not shipped with Qt. I have no clue how much of the QWidgets style is supported by that plugin. I think it would be nice to not deprecate the only QML way to make native looking Windows 7 applications in the Qt 5.xx lifecycle. Or do deprecate it, but offer the plugin [1] from within the Qt installer as an alternative. Also, i vaguely remember that QQC1 was meant for integrating applications in QML with your host OS and QQC2 was targeted at mobile and to be free of QWidgets to allow for performance improvements. So they both serve a different target group despite having quite some overlap in functionality. [1] https://github.com/KDE/qqc2-desktop-style -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Aug 16 22:11:05 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 16 Aug 2018 13:11:05 -0700 Subject: [Development] unified data model API in QtCore => thin wrapper proposal In-Reply-To: References: Message-ID: <1983779.PT3qfJPyb1@tjmaciei-mobl1> On Wednesday, 20 June 2018 06:05:35 PDT Arnaud Clère wrote: > Hi, > Thiago, did you decide on something regarding QCborValue in Qt5.12? Hello Arnaud, all No, I have not. I have not had the time to read your email yet and nor have I had time to even test if the API I designed does what we discussed in Oslo. I will not have time to do any of that before the 5.12 feature freeze. So we need a summary decision: a) yank it out b) leave it as is and damn the torpedoes Unless someone can volunteer to test. I *think* my design is slightly better than QJsonValue, so the following should work: value[1]["hello"][32] = false; -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jesus.fernandez at qt.io Fri Aug 17 10:13:15 2018 From: jesus.fernandez at qt.io (Jesus Fernandez) Date: Fri, 17 Aug 2018 08:13:15 +0000 Subject: [Development] Qt 5.12 new features In-Reply-To: References: , Message-ID: Fixed! WebGL plugin has no relevant changes for 5.12. Some stability & performance tweaks that are available also in 5.11.1. Thank you! Best regards, Jesús ________________________________ From: Development on behalf of Jason H Sent: Thursday, August 16, 2018 16:02 Cc: development at qt-project.org Subject: Re: [Development] Qt 5.12 new features 5.11 included WebGL TP2. Is there any change? Why is it staying TP2, or should it be TP3? 5.12 looks like it'll be a pretty great update! I'm not sure what's on the agenda for 5.13... but as I mentioned on interest, one pain point I continually have is the amount of custom platform integrations for mobile. This is one area where Xamrain excels, as they have a simple property on an object you can set to control things like the status bar visibility, the screen brightness, etc. The downside is the Xamarin stuff is all platform-specific so using a iOS property on Android won't work. This is one area where Qt can leapfrog the other platforms including React Native by being cross platform. Anything that doesn't require me to write Obj-C is a very good thing! I figure this would need to be a few Qt Quick/QObject Singletons. Notifications should be supported too, and this could also be used for desktop platform notifications as well. The notifications support would only need to cover being messaged my the platform, and not any display - this would get me out of having to deal with Obj-C almost completely. (My beef wi th ObjC is other than being not good at it, is whatever I'm writing isn't cross-platform. Java I am more comfortable with, so I complain less, but I still cringe on the non-portability!) Looking forward to 5.12! > Sent: Wednesday, August 15, 2018 at 12:50 AM > From: "Jani Heikkinen" > To: "development at qt-project.org" > Subject: [Development] Qt 5.12 new features > > Hi, > > Qt 5.12 Feature Freeze will be in effect Mon 20th August and we should have already now pretty good understanding what is new in Qt 5.12. So please update 5.12 new features page here: https://wiki.qt.io/New_Features_in_Qt_5.12 > > 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 vincenthk007 at gmail.com Fri Aug 17 11:43:34 2018 From: vincenthk007 at gmail.com (Vincent Hui) Date: Fri, 17 Aug 2018 17:43:34 +0800 Subject: [Development] What are new features of Qt3D in Qt 5.12? In-Reply-To: <89d2d80d-2075-d975-0778-1f11ea09eba2@qt.io> References: <87a7qduzt4.fsf@posteo.net> <89d2d80d-2075-d975-0778-1f11ea09eba2@qt.io> Message-ID: According to https://wiki.qt.io/New_Features_in_Qt_5.12, there will be no new features in Qt3D? I hope I am wrong. Thanks, Vincent On Fri, 27 Jul 2018 at 18:55, Robert Löhning wrote: > Am 27.07.2018 um 05:23 schrieb Brett Gilio: > > > > Vincent Hui writes:> > >> What are new features of Qt3D in Qt 5.12? Will Rigid body and soft body > >> physics simulation be included? > >> > >> I hope there will be new features of Qt3D in Qt 5.12. > > > > > > Hello Vincent, > > > > Unless I am mistaken, there should be a Changelog available for a > > collection such modifications including feature additions available in > > the Qt3D git repository on the Qt website. > > > > Best > > > > > > Hello Vincent, Brett, > > these change logs do not exist yet for 5.12. They are usually written > shortly before the release. > > When we will approach the release, you will find more and more > information on > https://wiki.qt.io/Qt_5.12_Release > > Cheers, > Robert > _______________________________________________ > 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 Tor.arne.Vestbo at qt.io Fri Aug 17 11:50:32 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Fri, 17 Aug 2018 09:50:32 +0000 Subject: [Development] unified data model API in QtCore => thin wrapper proposal In-Reply-To: <1983779.PT3qfJPyb1@tjmaciei-mobl1> References: <1983779.PT3qfJPyb1@tjmaciei-mobl1> Message-ID: > On 16 Aug 2018, at 22:11, Thiago Macieira wrote: > > On Wednesday, 20 June 2018 06:05:35 PDT Arnaud Clère wrote: >> Hi, >> Thiago, did you decide on something regarding QCborValue in Qt5.12? > > Hello Arnaud, all > > No, I have not. I have not had the time to read your email yet and nor have I > had time to even test if the API I designed does what we discussed in Oslo. > > I will not have time to do any of that before the 5.12 feature freeze. > > So we need a summary decision: > a) yank it out > b) leave it as is and damn the torpedoes > > Unless someone can volunteer to test. I *think* my design is slightly better > than QJsonValue, so the following should work: > > value[1]["hello"][32] = false; That’s great news. I assume it’s also easy to convert from and to JSON, so that one could use QCbor as an intermediate data format if one needs to modify JSON In place and write it out again? Tor Arne From jani.heikkinen at qt.io Fri Aug 17 12:02:38 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 17 Aug 2018 10:02:38 +0000 Subject: [Development] What are new features of Qt3D in Qt 5.12? In-Reply-To: References: <87a7qduzt4.fsf@posteo.net> <89d2d80d-2075-d975-0778-1f11ea09eba2@qt.io>, Message-ID: Hi, As stated the page is still under construction so don't worry; I think there is something new in qt3d side as well br, Jani ________________________________________ From: Development on behalf of Vincent Hui Sent: Friday, August 17, 2018 12:43 PM To: Robert Loehning Cc: development at qt-project.org Subject: Re: [Development] What are new features of Qt3D in Qt 5.12? According to https://wiki.qt.io/New_Features_in_Qt_5.12, there will be no new features in Qt3D? I hope I am wrong. Thanks, Vincent On Fri, 27 Jul 2018 at 18:55, Robert Löhning > wrote: Am 27.07.2018 um 05:23 schrieb Brett Gilio: > > Vincent Hui writes:> >> What are new features of Qt3D in Qt 5.12? Will Rigid body and soft body >> physics simulation be included? >> >> I hope there will be new features of Qt3D in Qt 5.12. > > > Hello Vincent, > > Unless I am mistaken, there should be a Changelog available for a > collection such modifications including feature additions available in > the Qt3D git repository on the Qt website. > > Best > > Hello Vincent, Brett, these change logs do not exist yet for 5.12. They are usually written shortly before the release. When we will approach the release, you will find more and more information on https://wiki.qt.io/Qt_5.12_Release Cheers, Robert _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Fri Aug 17 17:08:52 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 17 Aug 2018 08:08:52 -0700 Subject: [Development] unified data model API in QtCore => thin wrapper proposal In-Reply-To: References: <1983779.PT3qfJPyb1@tjmaciei-mobl1> Message-ID: <1764957.X2QKQoLrbe@tjmaciei-mobl1> On Friday, 17 August 2018 02:50:32 PDT Tor Arne Vestbø wrote: > > Unless someone can volunteer to test. I *think* my design is slightly > > better than QJsonValue, so the following should work: > > > > value[1]["hello"][32] = false; > > That’s great news. I assume it’s also easy to convert from and to JSON, so > that one could use QCbor as an intermediate data format if one needs to > modify JSON In place and write it out again? Please note I said that I *think* it should work, not that it does work. Could you give it a try and see if it makes your life easier? Now, looking at the code, I don't think it does work. I thought that QCborValue::operator[] returned QCborValueRefs, but it doesn't. Adding a set of non-const overloads returning QCborValueRef might be the trick. And it's a trick we can add to QJsonValue too. Converting from JSON is lossless and converting that content back to JSON is lossless too. It's just not particularly efficient today. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Tor.arne.Vestbo at qt.io Fri Aug 17 17:13:21 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Fri, 17 Aug 2018 15:13:21 +0000 Subject: [Development] unified data model API in QtCore => thin wrapper proposal In-Reply-To: <1764957.X2QKQoLrbe@tjmaciei-mobl1> References: <1983779.PT3qfJPyb1@tjmaciei-mobl1> <1764957.X2QKQoLrbe@tjmaciei-mobl1> Message-ID: <14AD680F-03F7-4348-9FA1-4EB232666EA6@qt.io> > On 17 Aug 2018, at 17:08, Thiago Macieira wrote: > > On Friday, 17 August 2018 02:50:32 PDT Tor Arne Vestbø wrote: >>> Unless someone can volunteer to test. I *think* my design is slightly >>> better than QJsonValue, so the following should work: >>> >>> value[1]["hello"][32] = false; >> >> That’s great news. I assume it’s also easy to convert from and to JSON, so >> that one could use QCbor as an intermediate data format if one needs to >> modify JSON In place and write it out again? > > Please note I said that I *think* it should work, not that it does work. Could > you give it a try and see if it makes your life easier? > > Now, looking at the code, I don't think it does work. I thought that > QCborValue::operator[] returned QCborValueRefs, but it doesn't. Adding a set > of non-const overloads returning QCborValueRef might be the trick. That would be great to have as part of the API yes > And it's a trick we can add to QJsonValue too. That would be great, but I think it was kind of tricky with the current design of QJsonValue. Tor Arne From jani.heikkinen at qt.io Fri Aug 17 17:18:48 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 17 Aug 2018 15:18:48 +0000 Subject: [Development] HEADS UP: Branching from '5.11' to '5.11.2' started Message-ID: Hi, We have soft branched '5.11.2' from '5.11' today. Target is to finalize branching Fri 24th August 2018. So please finalize ongoing changes in '5.11' and start using '5.11.2' for new changes targeted to Qt 5.11.2 release br, Jani From thiago.macieira at intel.com Fri Aug 17 19:48:54 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 17 Aug 2018 10:48:54 -0700 Subject: [Development] unified data model API in QtCore => thin wrapper proposal In-Reply-To: <14AD680F-03F7-4348-9FA1-4EB232666EA6@qt.io> References: <1764957.X2QKQoLrbe@tjmaciei-mobl1> <14AD680F-03F7-4348-9FA1-4EB232666EA6@qt.io> Message-ID: <1545879.ExQsGfyq71@tjmaciei-mobl1> On Friday, 17 August 2018 08:13:21 PDT Tor Arne Vestbø wrote: > > Now, looking at the code, I don't think it does work. I thought that > > QCborValue::operator[] returned QCborValueRefs, but it doesn't. Adding a > > set of non-const overloads returning QCborValueRef might be the trick. > That would be great to have as part of the API yes I won't have time to experiment with it before feature freeze. Technically, the API freeze doesn't happen until Beta, so we have a few more weeks, but I wouldn't hold my hopes up that I will have time to trial this. Any chance you can give it a go? Or someone else? > > And it's a trick we can add to QJsonValue too. > > That would be great, but I think it was kind of tricky with the current > design of QJsonValue. Fair enough. My long-term goal is to replace the QJsonDocument internals with QCborContainerPrivate. That way, the conversion from JSON to CBOR is O(1) and the conversion backwards is just a validation. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lars.knoll at qt.io Mon Aug 20 09:04:51 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 20 Aug 2018 07:04:51 +0000 Subject: [Development] Storing and managing ValueArray inside QV4::Heap objects In-Reply-To: References: Message-ID: <16CDC633-9E3A-4152-9F13-5D421CE8D0F9@qt.io> Hi Valery, On 16 Aug 2018, at 08:06, Valery Kotov > wrote: Hello all, I'm trying to wrap my head around SimpleArrayData API. And I might actually need a bit of help here. Instead of using ValueArray now I declare myValues to be SimpleArrayData*: #define MyObjectMembers(class, Member) \ Member(class, Pointer, SimpleArrayData*, myValues) DECLARE_HEAP_OBJECT(MyObject, Object) { DECLARE_MARKOBJECTS(MyObject); In MyObjects' init function I'm creating and initializing myValues: const size_t size = sizeof(Heap::ArrayData) + length*sizeof(Value); // I still can have 0 length array, right? Heap::SimpleArrayData *d = e->memoryManager->allocManaged(size); d->init(); d->type = Heap::ArrayData::Simple; d->offset = 0; d->values.alloc = length; d->values.size = length; myValues.set(e, d); Later I'm trying to add a new item to myValues: ScopedArrayObject a(scope, scope.engine->memoryManager->allocate()); a->d()->arrayData.set(scope.engine, d()->myValues); Scoped sa(scope, d()->myValues); sa->push_front(a, newValue, 1); Clearly I'm doing something wrong. push_front adds a new item to array indeed, but not to myValues SimpleArrayData memeber. Internally, from what I could observe, realloc creates a new SimpleArrayData and new item actually added to it. What I have a little bit of trouble to understand, is how to use SimpleArrayData API. It has to be used in conjunction with ArrayObject somehow, right? Or shall I store ArrayObject pointer instead of SimpleArrayData? Yes, you’re right that will be problematic, as SimpleArrayData is meant to be used together with the Object it belongs to. So either use an ArrayObject, or a QVector then. >> If you have a fully dynamic array, then the alternative would be to store a pointer to your QVector in the heap object. Yes, that is a good point. Thank you. Though, I have a small concern here. From what I could see, QQmlSequence does not store JS heap objects in QVector (or did I miss it somehow?). Whereas I would like my container to: * be dynamically resizable, since amount of it's items is not known in advance * be able to store JS heap objects What would you suggest to use in this case? Shall I still go for SimpleArrayData and make it work? Or shall I use QVector instead? In case of QVector would it be safe to store JS Object pointers or it should be QVector of PersistentValues? You can use a QVector, but then you need to reimplement the markObjects() method manually to loop over the vector and call mark() on all the values. Best regards, Lars Thank you! Sincerely yours, Valery Kotov On Thu, 9 Aug 2018 at 08:20, Valery Kotov > wrote: Hi Lars, Simon, I think I got it. Thanks a lot for your tips! Sincerely yours, Valery Kotov On 8 August 2018 at 09:32, Simon Hausmann > wrote: Hi, If you want to use the ValueArray, then you need to make sure that it's the last member of your type. Then encapsulate the creation if the type in a factory function that works a bit like ExecutionContext::newCallContext: (1) Calculate how much memory you're going to need for the type _and_ the value array (minus one Value). (2) Allocate the memory with one call to allocManaged. (3) call init() manually. (4) Set the alloc and size members of the value array to the amount of allocated values. While this approach is clever in the sense that it gives a compact memory representation and allocates object and array data in one shot, it also means that it's not so suitable for frequent dynamic resizing as it will require re-allocating the entire object. If you have a fully dynamic array, then the alternative would be to store a pointer to your QVector in the heap object. Heap::QQmlSequence does that, for example. Just make sure to use V4_NEEDS_DESTROY and provide a destroy() function to delete the vector. I'd probably go for the first approach with perhaps an indirect type (similar to how Object has MemberData) if the array contains references to the JS heap. If your array has only references to the C heap, then you're probably better off using a pointer to a regular vector. Simon ________________________________ From: Development > on behalf of Valery Kotov > Sent: Wednesday, August 8, 2018 9:10:43 AM To: Qt development mailing list Subject: [Development] Storing and managing ValueArray inside QV4::Heap objects Hello all, I have a question about QV4 heap objects and what could be stored in them. I would like to move data structure from c++ heap to GC heap. Unfortunately, my data structure stores a pair of QLists internally. As far as I'm aware, QV4::Heap objects should be "trivially constructible", and thus, cannot store QList(s). One option would be to store QList pointer and manage it's lifecycle manually. But that does not sound like a good idea. I've noticed though, that some of qv4 types are using DECLARE_MARKOBJECTS macro. By using DECLARE_MARKOBJECTS macro and ObjectMember(s) define I can actually store a ValueArray member in my QV4 heap object. #define MyObjectMembers(class, Member) \ Member(class, ValueArray, ValueArray, myValues) DECLARE_HEAP_OBJECT(MyObject, Object) { DECLARE_MARKOBJECTS(MyObject); In this case I can refer to myValues ValueArray type inside of MyObject. Unfortunately, it is a little bit unclear to me how to manage ValueArrays. From what I can see from some examples in the code (qv4generatorobject, qv4arraydata), it seems that I need to manage ValueArray manually. What I'm missing at the moment a little bit is how the actually allocation for ValueArray.values is done. I suspect that it is probably not done via plain "new" call. Otherwise it is a little bit confusing why not just to store the pointer directly. Could you guys please give me a few hints how to go about ValueArray management? Thank you! Sincerely yours, Valery Kotov _______________________________________________ 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 markus.maier.sw at gmail.com Mon Aug 20 09:26:26 2018 From: markus.maier.sw at gmail.com (Markus Maier) Date: Mon, 20 Aug 2018 09:26:26 +0200 Subject: [Development] How to create a Qt5 offline installer myself In-Reply-To: References: Message-ID: Hi, I had a similar problem as you some time ago: I didn't want to run all offline installers on my build machine, copy the pdb's in manually and so on ... My solution was pretty simple: I used the online installer to create an installation with everything I needed, and I simply copied the base folder of this installation to the build machine. Everything works perfectly for me as long as the folder location remains the same on both machines - the installers don't seem to do much but fix this absolute path in the installation. I also do the same thing with my own builds of Qt (copy from my build server to my development machine, keeping the INSTALL location) and never experienced any problems here. I am developing on Windows, not sure if this also works as smoothly on other operating systems. Best regards Markus Am Di., 7. Aug. 2018 um 21:56 Uhr schrieb Roland Winklmeier < roland.m.winklmeier at gmail.com>: > Dear Qt Devs, > > I think I asked this question in the past, but I never got a reasonable > answer. The question is actually quite simple: > > How can I create a Qt5 offline installer for example for 5.11.1 MinGW > 5.3.0 32 bit? > > I'm aware of the qt/qtsdk repository and its scripts. There is also some > high level description in the READMEs. But following the coin builds, those > are using GO scripts which are as far as I can see not public.So that > means, Qt build servers have been using those python scripts in the past, > but now they don't and that renders them in fact untested and unmaintained. > I don't mind doing more steps manual (even if automating it fully would be > super great), but I cannot even find a easy way of doing it manually. > > It was often mentioned in this mailing list, that users/developers can > build their own version of Qt and the official binaries are just a subset. > That's fair enough and I can and do regularly build Qt on my own. But my > own build doesn't help me much, if I cannot bundle it into a proper > installer and make it available to other people and/or build servers.To me, > this is still a very important step which should be properly documented and > as easy reproducable as the regular Qt5 build. > > So if anyone has a good and easy to follow guide, how to produce my own > offline installer, please share it with me. Ideally we come up with a wiki > page similar to https://wiki.qt.io/Building_Qt_5_from_Git. > The reason why I'm asking is, that I would like to try and get some > changes into the binaries (release build with debug symbols for crash > dumps, MSVC 2017 32 and 64 bit builds etc). > > Looking forward to any help. > > Thanks, > Roland > _______________________________________________ > 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 samuel.gaist at edeltech.ch Mon Aug 20 09:28:18 2018 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Mon, 20 Aug 2018 09:28:18 +0200 Subject: [Development] HEADS-UP: Branching from 'dev' to '5.12' started In-Reply-To: References: Message-ID: > On 14 Aug 2018, at 13:48, Jani Heikkinen wrote: > > Hi! > > We have soft branched '5.12' from 'dev' today. We are planning to have final downmerge and Qt 5.12 Feature Freeze Monday 20.8.2018. So there is still time to finalize ongoing task in 'dev' and start using '5.12' for new changes targeted to Qt 5.12 release. > > br, > Jani Heikkinen > Release Manager > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Hi, I just received approval for an API addition to QTextEdit and QPlainTextEdit (QRegularExpression find overload). Is it still on time for feature freeze since it happens today ? It’s nothing vital, I just want to know whether I should change the documentation to 5.13 and resubmit. Thanks Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From arnaud.clere at minmaxmedical.com Mon Aug 20 10:42:51 2018 From: arnaud.clere at minmaxmedical.com (=?utf-8?B?QXJuYXVkIENsw6hyZQ==?=) Date: Mon, 20 Aug 2018 08:42:51 +0000 Subject: [Development] unified data model API in QtCore => thin wrapper proposal In-Reply-To: <1983779.PT3qfJPyb1@tjmaciei-mobl1> References: <1983779.PT3qfJPyb1@tjmaciei-mobl1> Message-ID: Hi, Unfortunately I do not think I can help with the QCborValue development and Json/Cbor refactoring. Just, from my experience, Json and Cbor share so much that the refactoring makes a lot of sense and having an efficient, editable, in-memory representation of the underlying data is a nice goal for many use cases (was not it the idea of a "JsonDb"?). Now, regarding the "structured traces" use case, converting the user-defined data types (and Qt types) to such representation at the tracepoint would only make sense performance-wise if the in-memory representation: - require one or very few heap allocations per tracepoint - can be copied to the log as a single chunk Does the new design would allow that? Even in this case, it would probably be better performance-wise to use the kind of thin-wrapper "QBind" API that I am pushing since we managed to implement it without heap allocation and with only 20% CPU overhead compared to hand-written serialisation (be it QDebug or QDataStream, etc.). Finally, as a user, I can cope with reasonable API changes but new features suck if they do not work, so I would probably stay away from the "torpedoes" unless I am sure they are targeting the right thing 😊 Cheers, Arnaud -----Original Message----- From: Thiago Macieira Sent: jeudi 16 août 2018 22:11 To: development at qt-project.org Subject: Re: [Development] unified data model API in QtCore => thin wrapper proposal On Wednesday, 20 June 2018 06:05:35 PDT Arnaud Clère wrote: > Hi, > Thiago, did you decide on something regarding QCborValue in Qt5.12? Hello Arnaud, all No, I have not. I have not had the time to read your email yet and nor have I had time to even test if the API I designed does what we discussed in Oslo. I will not have time to do any of that before the 5.12 feature freeze. So we need a summary decision: a) yank it out b) leave it as is and damn the torpedoes Unless someone can volunteer to test. I *think* my design is slightly better than QJsonValue, so the following should work: value[1]["hello"][32] = false; -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Mon Aug 20 11:24:09 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 20 Aug 2018 09:24:09 +0000 Subject: [Development] HEADS-UP: Branching from 'dev' to '5.12' started In-Reply-To: References: Message-ID: > -----Original Message----- > From: Samuel Gaist > Sent: maanantai 20. elokuuta 2018 10.28 > To: Jani Heikkinen > Cc: development at qt-project.org; releasing at qt-project.org > Subject: Re: [Development] HEADS-UP: Branching from 'dev' to '5.12' started > > > > On 14 Aug 2018, at 13:48, Jani Heikkinen wrote: > > > > Hi! > > > > We have soft branched '5.12' from 'dev' today. We are planning to have > final downmerge and Qt 5.12 Feature Freeze Monday 20.8.2018. So there is > still time to finalize ongoing task in 'dev' and start using '5.12' for new > changes targeted to Qt 5.12 release. > > > > br, > > Jani Heikkinen > > Release Manager > > > > > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > Hi, > > I just received approval for an API addition to QTextEdit and QPlainTextEdit > (QRegularExpression find overload). > > Is it still on time for feature freeze since it happens today ? > > It’s nothing vital, I just want to know whether I should change the > documentation to 5.13 and resubmit. Please do. We will do final downmerge soon so if the change isn't in yet it is better to put it in 5.13 now br, Jani Heikkinen > > > Thanks > > Samuel From alexander.blasche at qt.io Mon Aug 20 12:48:52 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Mon, 20 Aug 2018 10:48:52 +0000 Subject: [Development] Proposing Samuel Gaist for approver status In-Reply-To: References: Message-ID: Congratulations to Samuel. OGApprover rights have been set. -- Alex ________________________________________ From: Development on behalf of André Sent: Saturday, 28 July 2018 10:56:37 AM To: development at qt-project.org; samuel.gaist at idiap.ch Subject: [Development] Proposing Samuel Gaist for approver status Hello all, I'd like to propose Samuel as approver. He has been active in the Qt project for ages. He not only provides code changes [0], he is also active reviewing others changes [1]. But that's not all: Samuel is *extremly* active in the Qt Forum [2], where he works as moderator and answers plenty of questions every day. Some of his patches arised from forum questions, therefore Samuel perfectly bridges between the end users and the Qt main developers. I think this all qualifies Samuel for the approver status. Best regards, André [0] https://codereview.qt-project.org/#/q/owner:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z [1] https://codereview.qt-project.org/#/q/reviewer:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z [2] https://forum.qt.io/user/sgaist _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From alexander.blasche at qt.io Mon Aug 20 13:29:46 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Mon, 20 Aug 2018 11:29:46 +0000 Subject: [Development] Jira changes going forward In-Reply-To: References: , , Message-ID: The last disruptive change is about to happen. The upcoming changes concern the workflows: 1.) The workflow for requirements (Epic, User Story, Change Requests) related issues will be streamlined. The "Implemented" & "Verified" states (served no purpose anymore) will be removed and a "Blocked" state is introduced. The "Blocked" state is meant to be used to when some external (to the developer) conditions or dependencies are not met. Note that a blocked issue still maintains the "unresolved" resolution. 2.) The bug workflow is made a bit more convenient by introducing the direct transitons to the "Need more info" state. So far only "Reported" issues could transition to NMI. "Open" and "In progress" will obtain the same right. The changes have the nice side effect that Kanban boards can issue the full scope of possible issue transitions. You might want to add the additional states to your board too. -- Alex ________________________________________ From: Development on behalf of Alex Blasche Sent: Monday, 18 June 2018 1:08:35 PM To: development at qt-project.org; interest at qt-project.org Interest Subject: Re: [Development] Jira changes going forward This implementation has started. Please be aware of changing component names. -- Alex ________________________________________ From: Development on behalf of Alex Blasche Sent: Thursday, 31 May 2018 2:42:51 PM To: development at qt-project.org; interest at qt-project.org Interest Subject: Re: [Development] Jira changes going forward This review has come to a conclusion. Based on reviews the major points have settled. The highlights of the changes are: - Internal Qt company requirements management will shift to public projects - Renaming and reordering of components (breaks existing filters) - Additional fields for Jira issues - Automatic closure/check of long pending "Need more Info" bugs where the bug reporter fails to provide information Implementation of those changes will happen during June. -- Alex ________________________________________ From: Development on behalf of Alex Blasche Sent: Wednesday, 2 May 2018 2:18:54 PM To: development at qt-project.org Subject: [Development] Jira changes going forward Hi, there are quite a few changes to Jira on my todo list. Some of them result from some internal TQtC process changes (related to public requirements mgmt) and others were put forward by individuals with a keen interest in improving things (thank you for that). Unfortunately some of proposals will break existing setups (especially filters). Since there are a lot of changes I chose to use gerrit for the discussion. A long mail is not able to provide the means to update and review the latest consensus. Please have a look at https://codereview.qt-project.org/#/c/225694/ The patch is not intended to be merged. It merely exists to facilitate the community discussion. However I might document some of the outcomes (especially process outcomes) somewhere later on. Thank you for your feedback. -- Alex _______________________________________________ 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 sergio.martins at kdab.com Mon Aug 20 14:08:36 2018 From: sergio.martins at kdab.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Mon, 20 Aug 2018 13:08:36 +0100 Subject: [Development] override keyword on destructors Message-ID: Hi, Looks like some 'override' keywords crept into a few destructors. This is probably because clang-tidy warns about it (and now QtCreator). IMO we should avoid it, as it's misleading. Dtors are a special case and have completely different semantics. They don't replace their base class dtors. They're chained instead. This is not 100% consensual, some people like to use it. But it's discouraged by the Cpp Core Guidelines [1] ; gcc's -Wsuggest-override doesn't suggest it for dtors and neither does clang's -Winconsistent-missing-override. So clang-tidy is the one odd out. I'll update the coding conventions if nobody opposes. [1] - https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rh-override Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From tobias.hunger at gmail.com Mon Aug 20 14:15:08 2018 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Mon, 20 Aug 2018 14:15:08 +0200 Subject: [Development] About 3D desktop. In-Reply-To: References: Message-ID: Hi Stef, in my misspent youth I played with Berlin (later Fresco), which went into that direction. The website is long gone, but the internet archive has a copy: https://web.archive.org/web/20080223200807/http://issues.fresco.org:80/ The code is still also still around: https://github.com/stefanseefeld/fresco 3DWM is something similar from back then: https://www.researchgate.net/publication/239744067_3Dwm_A_Platform_for_Research_and_Development_of_Three-Dimensional_User_Interfaces Looking Glass from Sun was already mentioned. That's all I can think of. Best Regards, Tobias On Mon, Aug 6, 2018 at 3:36 PM Stef Bon wrote: > > Hi, > > There are various desktop effects which offer 3D effects (kube for example). > > I want to know I anyone knows about any plan to create a 3D desktop, > eg a desktop with not only the coordinates height and width, but also > depth. > > I want to work on this, maybe start it. It would be awesome. > > Stef > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From olli.hirvonen at qt.io Mon Aug 20 15:20:06 2018 From: olli.hirvonen at qt.io (Olli Hirvonen) Date: Mon, 20 Aug 2018 13:20:06 +0000 Subject: [Development] CI Maintainers / creating bug reports for CI Message-ID: <97A2615E-4B3C-4093-A7A4-55A6B4FBFC80@qt.io> Hi all, There has been occasional confusion that who is maintaining Qt CI and Coin especially. CI info page https://wiki.qt.io/CI_Overview has the correct info now. Page update was done in summer. Coin Maintainer: @Aapo Keskimölö HW/Virtualization: @Tony Sarajärvi If you want a bit wider audience, use qt.ci at qt.io address, which includes a bit more guys working in CI area. Reporting CI bugs: https://wiki.qt.io/Reporting_Bugs#Reporting_bugs_for_Coin Hopefully this clarifies and helps. -Olli -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.funk at kdab.com Mon Aug 20 15:58:35 2018 From: kevin.funk at kdab.com (Kevin Funk) Date: Mon, 20 Aug 2018 15:58:35 +0200 Subject: [Development] override keyword on destructors In-Reply-To: References: Message-ID: <7262400.tAYMJZ3HSC@kerberos> On Monday, 20 August 2018 14:08:36 CEST Sérgio Martins via Development wrote: > Hi, > > > Looks like some 'override' keywords crept into a few destructors. This > is probably because clang-tidy warns about it (and now QtCreator). > > IMO we should avoid it, as it's misleading. Dtors are a special case and > have completely different semantics. They don't replace their base class > dtors. They're chained instead. > > This is not 100% consensual, some people like to use it. > > But it's discouraged by the Cpp Core Guidelines [1]; gcc's > -Wsuggest-override doesn't suggest it for dtors and neither does clang's > -Winconsistent-missing-override. Heya, Just as a side note: There's still a warning which will warn for inconsistent overrides on destructors in Clang: https://www.mail-archive.com/cfe-commits at lists.llvm.org/msg50989.html (off by default though, it was noted it's too noisy for existing code bases) To be honest, I find the explanation on the Cpp Core Guidelines wiki pretty poor, if not to say non-existent. If you read through the discussion of amending of rule C.128 [1] it becomes pretty clear there's no consensus at all, but rather one person (gdr-at-ms) trying to push through his preference and shutting down the discussion. I think the destructors-are-chained argument is a bit weak; to me 'override' rather translates to "I expect there to exist a base class version of this function which is declared virtual" (also cf. [2]), which applies very well to destructors. IMO, it would also be nice to get a compiler warning/error if a base class' destructor is changed from virtual to non-virtual which may cause subtle behavioral changes such as memory leaks. [1] https://github.com/isocpp/CppCoreGuidelines/issues/721 [2] https://en.cppreference.com/w/cpp/language/override My 2 cents. Regards, Kevin > So clang-tidy is the one odd out. > > I'll update the coding conventions if nobody opposes. > > > > [1] - > https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md > #Rh-override > > Regards, -- Kevin Funk | kevin.funk at kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5322 bytes Desc: not available URL: From ville.voutilainen at gmail.com Mon Aug 20 16:12:13 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Mon, 20 Aug 2018 17:12:13 +0300 Subject: [Development] override keyword on destructors In-Reply-To: <7262400.tAYMJZ3HSC@kerberos> References: <7262400.tAYMJZ3HSC@kerberos> Message-ID: On 20 August 2018 at 16:58, Kevin Funk via Development wrote: > On Monday, 20 August 2018 14:08:36 CEST Sérgio Martins via Development wrote: >> Hi, >> >> >> Looks like some 'override' keywords crept into a few destructors. This >> is probably because clang-tidy warns about it (and now QtCreator). >> >> IMO we should avoid it, as it's misleading. Dtors are a special case and >> have completely different semantics. They don't replace their base class >> dtors. They're chained instead. >> >> This is not 100% consensual, some people like to use it. >> >> But it's discouraged by the Cpp Core Guidelines [1]; gcc's >> -Wsuggest-override doesn't suggest it for dtors and neither does clang's >> -Winconsistent-missing-override. > > Heya, > > Just as a side note: There's still a warning which will warn for inconsistent > overrides on destructors in Clang: > https://www.mail-archive.com/cfe-commits at lists.llvm.org/msg50989.html > > (off by default though, it was noted it's too noisy for existing code bases) > > > To be honest, I find the explanation on the Cpp Core Guidelines wiki pretty > poor, if not to say non-existent. If you read through the discussion of > amending of rule C.128 [1] it becomes pretty clear there's no consensus at > all, but rather one person (gdr-at-ms) trying to push through his preference > and shutting down the discussion. > > I think the destructors-are-chained argument is a bit weak; to me 'override' > rather translates to "I expect there to exist a base class version of this > function which is declared virtual" (also cf. [2]), which applies very well to > destructors. IMO, it would also be nice to get a compiler warning/error if a > base class' destructor is changed from virtual to non-virtual which may cause > subtle behavioral changes such as memory leaks. Right; that's the rationale from Google for marking destructor overrides. If you have struct B {virtual ~B();}; struct D : B {~D() override;}; changing the destructor of B to be non-virtual will cause a compiler error in D. If 'override' is not present in D, that change would not cause a compiler error, and would very probably cause a silent change in meaning and a run-time error. The question becomes whether such changes are likely; I don't think they are, whereas for functions other than a destructor such changes are somewhat likely. From Eike.Ziller at qt.io Mon Aug 20 16:40:31 2018 From: Eike.Ziller at qt.io (Eike Ziller) Date: Mon, 20 Aug 2018 14:40:31 +0000 Subject: [Development] override keyword on destructors In-Reply-To: References: <7262400.tAYMJZ3HSC@kerberos> Message-ID: > On 20. Aug 2018, at 16:12, Ville Voutilainen wrote: > > On 20 August 2018 at 16:58, Kevin Funk via Development > wrote: >> On Monday, 20 August 2018 14:08:36 CEST Sérgio Martins via Development wrote: >>> Hi, >>> >>> >>> Looks like some 'override' keywords crept into a few destructors. This >>> is probably because clang-tidy warns about it (and now QtCreator). >>> >>> IMO we should avoid it, as it's misleading. Dtors are a special case and >>> have completely different semantics. They don't replace their base class >>> dtors. They're chained instead. >>> >>> This is not 100% consensual, some people like to use it. >>> >>> But it's discouraged by the Cpp Core Guidelines [1]; gcc's >>> -Wsuggest-override doesn't suggest it for dtors and neither does clang's >>> -Winconsistent-missing-override. >> >> Heya, >> >> Just as a side note: There's still a warning which will warn for inconsistent >> overrides on destructors in Clang: >> https://www.mail-archive.com/cfe-commits at lists.llvm.org/msg50989.html >> >> (off by default though, it was noted it's too noisy for existing code bases) >> >> >> To be honest, I find the explanation on the Cpp Core Guidelines wiki pretty >> poor, if not to say non-existent. If you read through the discussion of >> amending of rule C.128 [1] it becomes pretty clear there's no consensus at >> all, but rather one person (gdr-at-ms) trying to push through his preference >> and shutting down the discussion. >> >> I think the destructors-are-chained argument is a bit weak; to me 'override' >> rather translates to "I expect there to exist a base class version of this >> function which is declared virtual" (also cf. [2]), which applies very well to >> destructors. IMO, it would also be nice to get a compiler warning/error if a >> base class' destructor is changed from virtual to non-virtual which may cause >> subtle behavioral changes such as memory leaks. > > Right; that's the rationale from Google for marking destructor > overrides. If you have > > struct B {virtual ~B();}; > > struct D : B {~D() override;}; > > changing the destructor of B to be non-virtual will cause a compiler error in D. > If 'override' is not present in D, that change would not cause a > compiler error, and would > very probably cause a silent change in meaning and a run-time error. > The question > becomes whether such changes are likely; I don't think they are, > whereas for functions > other than a destructor such changes are somewhat likely. For example when removing QObject as a base class in a class hierarchy. We regularly do these kind of changes in Qt Creator, when we find out that we don’t need the baggage of QObject after all for something. Br, Eike -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From giuseppe.dangelo at kdab.com Mon Aug 20 16:46:44 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 20 Aug 2018 16:46:44 +0200 Subject: [Development] override keyword on destructors In-Reply-To: References: <7262400.tAYMJZ3HSC@kerberos> Message-ID: <027eccc8-608e-5dac-29f8-4d576fd295d0@kdab.com> On 20/08/18 16:40, Eike Ziller wrote: > For example when removing QObject as a base class in a class hierarchy. > We regularly do these kind of changes in Qt Creator, when we find out that we don’t need the baggage of QObject after all for something. Do you have an example of such a change, that wouldn't be caught by -Wall / -Weffc++? Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: S/MIME Cryptographic Signature URL: From philwave at gmail.com Mon Aug 20 17:16:00 2018 From: philwave at gmail.com (Philippe) Date: Mon, 20 Aug 2018 17:16:00 +0200 Subject: [Development] override keyword on destructors In-Reply-To: References: Message-ID: <20180820171559.D3C7.6F0322A@gmail.com> I have recently used Resharper C++ to automatically add override to destructor declarations, on a very large application. Conclusion: very instructive with reflexions such as: "ha ha! this base class is virtual!" IOW, override on dtor reveals information which can be useful to understand code. Philippe On Mon, 20 Aug 2018 13:08:36 +0100 Sérgio Martins via Development wrote: > Hi, > > > Looks like some 'override' keywords crept into a few destructors. This > is probably because clang-tidy warns about it (and now QtCreator). > > IMO we should avoid it, as it's misleading. Dtors are a special case and > have completely different semantics. They don't replace their base class > dtors. They're chained instead. > > This is not 100% consensual, some people like to use it. > > But it's discouraged by the Cpp Core Guidelines [1] ; gcc's > -Wsuggest-override doesn't suggest it for dtors and neither does clang's > -Winconsistent-missing-override. > > So clang-tidy is the one odd out. > > I'll update the coding conventions if nobody opposes. > > > > [1] - > https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rh-override > > Regards, > -- > Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - The Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From apoenitz at t-online.de Mon Aug 20 08:47:34 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Mon, 20 Aug 2018 08:47:34 +0200 Subject: [Development] override keyword on destructors In-Reply-To: References: Message-ID: <20180820064734.GA14139@klara.mpi.htwm.de> On Mon, Aug 20, 2018 at 01:08:36PM +0100, Sérgio Martins via Development wrote: > Hi, > > Looks like some 'override' keywords crept into a few destructors. This is > probably because clang-tidy warns about it (and now QtCreator). > > IMO we should avoid it, as it's misleading. Dtors are a special case and > have completely different semantics. They don't replace their base class > dtors. They're chained instead. That's one way look at it. One can also argue that it's "something" for which some base implementation exists and that might need double-checking when the base disappears. It's also a hint when reading code that the base destructor's "virtual" actually has not been forgotten. > This is not 100% consensual, some people like to use it. > > But it's discouraged by the Cpp Core Guidelines [1] ; gcc's > -Wsuggest-override doesn't suggest it for dtors and neither does clang's > -Winconsistent-missing-override. > So clang-tidy is the one odd out. > > I'll update the coding conventions if nobody opposes. Please not. Andre' From stefbon at gmail.com Tue Aug 21 05:36:31 2018 From: stefbon at gmail.com (Stef Bon) Date: Tue, 21 Aug 2018 05:36:31 +0200 Subject: [Development] About 3D desktop. In-Reply-To: References: Message-ID: Yes the 3D window manager looks a lot at the idea I want to work on. Any point in the 3D WM (a good name!) has three components: (x, y, z) these are projected on the visible 2D screen, suggesting 3D like: https://en.wikipedia.org/wiki/3D_projection Very interesting is also: https://en.wikipedia.org/wiki/Viewing_frustum Also important here is what is called in Dutch a "verdwijnpunt". I do not know the translation, but the horizon is something like that, where all parallel lines meet..) Stef Op ma 20 aug. 2018 om 14:15 schreef Tobias Hunger : > > Hi Stef, > > in my misspent youth I played with Berlin (later Fresco), which went > into that direction. The website is long gone, but the internet > archive has a copy: > https://web.archive.org/web/20080223200807/http://issues.fresco.org:80/ > > The code is still also still around: > https://github.com/stefanseefeld/fresco > > > 3DWM is something similar from back then: > https://www.researchgate.net/publication/239744067_3Dwm_A_Platform_for_Research_and_Development_of_Three-Dimensional_User_Interfaces > > Looking Glass from Sun was already mentioned. > > That's all I can think of. > > Best Regards, > Tobias > On Mon, Aug 6, 2018 at 3:36 PM Stef Bon wrote: > > > > Hi, > > > > There are various desktop effects which offer 3D effects (kube for example). > > > > I want to know I anyone knows about any plan to create a 3D desktop, > > eg a desktop with not only the coordinates height and width, but also > > depth. > > > > I want to work on this, maybe start it. It would be awesome. > > > > Stef > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development From kotov.valery at gmail.com Tue Aug 21 07:26:27 2018 From: kotov.valery at gmail.com (Valery Kotov) Date: Tue, 21 Aug 2018 07:26:27 +0200 Subject: [Development] Storing and managing ValueArray inside QV4::Heap objects In-Reply-To: <16CDC633-9E3A-4152-9F13-5D421CE8D0F9@qt.io> References: <16CDC633-9E3A-4152-9F13-5D421CE8D0F9@qt.io> Message-ID: Hello Lars, > Yes, you’re right that will be problematic, as SimpleArrayData is meant to be used together with the Object it belongs to. So either use an ArrayObject, or a QVector then. I decided to give ArrayObject a try and it seems to work fine. Thank you! =) Sincerely yours, Valery Kotov On Mon, 20 Aug 2018 at 09:04, Lars Knoll wrote: > Hi Valery, > > On 16 Aug 2018, at 08:06, Valery Kotov wrote: > > Hello all, > > I'm trying to wrap my head around SimpleArrayData API. And I might > actually need a bit of help here. > > Instead of using ValueArray now I declare myValues to be SimpleArrayData*: > > #define MyObjectMembers(class, Member) \ > Member(class, Pointer, SimpleArrayData*, myValues) > > DECLARE_HEAP_OBJECT(MyObject, Object) { > DECLARE_MARKOBJECTS(MyObject); > > In MyObjects' init function I'm creating and initializing myValues: > > const size_t size = sizeof(Heap::ArrayData) + length*sizeof(Value); // I > still can have 0 length array, right? > Heap::SimpleArrayData *d = > e->memoryManager->allocManaged(size); > d->init(); > d->type = Heap::ArrayData::Simple; > d->offset = 0; > d->values.alloc = length; > d->values.size = length; > myValues.set(e, d); > > Later I'm trying to add a new item to myValues: > > ScopedArrayObject a(scope, > scope.engine->memoryManager->allocate()); > a->d()->arrayData.set(scope.engine, d()->myValues); > Scoped sa(scope, d()->myValues); > sa->push_front(a, newValue, 1); > > Clearly I'm doing something wrong. push_front adds a new item to array > indeed, but not to myValues SimpleArrayData memeber. Internally, from what > I could observe, realloc creates a new SimpleArrayData and new item > actually added to it. > What I have a little bit of trouble to understand, is how to use > SimpleArrayData API. It has to be used in conjunction with ArrayObject > somehow, right? Or shall I store ArrayObject pointer instead of > SimpleArrayData? > > > Yes, you’re right that will be problematic, as SimpleArrayData is meant to > be used together with the Object it belongs to. So either use an > ArrayObject, or a QVector then. > > > >> If you have a fully dynamic array, then the alternative would be to > store a pointer to your QVector in the heap object. > Yes, that is a good point. Thank you. Though, I have a small concern here. > From what I could see, QQmlSequence does not store JS heap objects in > QVector (or did I miss it somehow?). > Whereas I would like my container to: > * be dynamically resizable, since amount of it's items is not known in > advance > * be able to store JS heap objects > > What would you suggest to use in this case? Shall I still go for > SimpleArrayData and make it work? Or shall I use QVector instead? In case > of QVector would it be safe to store JS Object pointers or it should be > QVector of PersistentValues? > > > You can use a QVector, but then you need to reimplement the > markObjects() method manually to loop over the vector and call mark() on > all the values. > > Best regards, > Lars > > > Thank you! > Sincerely yours, > Valery Kotov > > > On Thu, 9 Aug 2018 at 08:20, Valery Kotov wrote: > >> Hi Lars, Simon, >> >> I think I got it. Thanks a lot for your tips! >> >> Sincerely yours, >> Valery Kotov >> >> On 8 August 2018 at 09:32, Simon Hausmann wrote: >> >>> Hi, >>> >>> If you want to use the ValueArray, then you need to make sure that it's >>> the last member of your type. Then encapsulate the creation if the type in >>> a factory function that works a bit like ExecutionContext::newCallContext: >>> >>> (1) Calculate how much memory you're going to need for the type >>> _and_ the value array (minus one Value). >>> (2) Allocate the memory with one call to allocManaged. >>> (3) call init() manually. >>> (4) Set the alloc and size members of the value array to the amount >>> of allocated values. >>> >>> While this approach is clever in the sense that it gives a compact >>> memory representation and allocates object and array data in one shot, it >>> also means that it's not so suitable for frequent dynamic resizing as it >>> will require re-allocating the entire object. >>> >>> If you have a fully dynamic array, then the alternative would be to >>> store a pointer to your QVector in the heap object. Heap::QQmlSequence does >>> that, for example. Just make sure to use V4_NEEDS_DESTROY and provide a >>> destroy() function to delete the vector. >>> >>> I'd probably go for the first approach with perhaps an indirect type >>> (similar to how Object has MemberData) if the array contains references to >>> the JS heap. If your array has only references to the C heap, then you're >>> probably better off using a pointer to a regular vector. >>> >>> >>> Simon >>> >>> ------------------------------ >>> *From:* Development >> qt.io at qt-project.org> on behalf of Valery Kotov >>> *Sent:* Wednesday, August 8, 2018 9:10:43 AM >>> *To:* Qt development mailing list >>> *Subject:* [Development] Storing and managing ValueArray inside >>> QV4::Heap objects >>> >>> Hello all, >>> >>> I have a question about QV4 heap objects and what could be stored in >>> them. >>> I would like to move data structure from c++ heap to GC heap. >>> Unfortunately, my data structure stores a pair of QLists internally. >>> As far as I'm aware, QV4::Heap objects should be "trivially >>> constructible", and thus, cannot store QList(s). >>> One option would be to store QList pointer and manage it's lifecycle >>> manually. But that does not sound like a good idea. >>> I've noticed though, that some of qv4 types are using >>> DECLARE_MARKOBJECTS macro. By using DECLARE_MARKOBJECTS macro and >>> ObjectMember(s) define I can actually store a ValueArray member in my QV4 >>> heap object. >>> >>> #define MyObjectMembers(class, Member) \ >>> Member(class, ValueArray, ValueArray, myValues) >>> >>> DECLARE_HEAP_OBJECT(MyObject, Object) { >>> DECLARE_MARKOBJECTS(MyObject); >>> >>> In this case I can refer to myValues ValueArray type inside of MyObject. >>> Unfortunately, it is a little bit unclear to me how to manage >>> ValueArrays. >>> From what I can see from some examples in the code (qv4generatorobject, >>> qv4arraydata), it seems that I need to manage ValueArray manually. >>> What I'm missing at the moment a little bit is how the actually >>> allocation for ValueArray.values is done. >>> I suspect that it is probably not done via plain "new" call. Otherwise >>> it is a little bit confusing why not just to store the pointer directly. >>> >>> Could you guys please give me a few hints how to go about ValueArray >>> management? >>> >>> Thank you! >>> Sincerely yours, >>> Valery Kotov >>> >> >> _______________________________________________ > 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 samuel.gaist at idiap.ch Tue Aug 21 08:16:11 2018 From: samuel.gaist at idiap.ch (Samuel Gaist) Date: Tue, 21 Aug 2018 08:16:11 +0200 Subject: [Development] Proposing Samuel Gaist for approver status In-Reply-To: References: Message-ID: <94BAAFD3-8A5C-425F-859C-7CE06FCB6637@idiap.ch> Hi, Thank you very much for the vote of confidence ! Samuel > On 20 Aug 2018, at 12:48, Alex Blasche wrote: > > Congratulations to Samuel. OGApprover rights have been set. > > -- > Alex > > ________________________________________ > From: Development on behalf of André > Sent: Saturday, 28 July 2018 10:56:37 AM > To: development at qt-project.org; samuel.gaist at idiap.ch > Subject: [Development] Proposing Samuel Gaist for approver status > > Hello all, > > I'd like to propose Samuel as approver. He has been active in the Qt project for ages. > > He not only provides code changes [0], he is also active reviewing others changes [1]. > > But that's not all: Samuel is *extremly* active in the Qt Forum [2], where he works > as moderator and answers plenty of questions every day. > > Some of his patches arised from forum questions, therefore Samuel perfectly bridges > between the end users and the Qt main developers. > > I think this all qualifies Samuel for the approver status. > > Best regards, > André > > [0] https://codereview.qt-project.org/#/q/owner:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z > [1] https://codereview.qt-project.org/#/q/reviewer:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z > [2] https://forum.qt.io/user/sgaist > _______________________________________________ > 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 > -- Samuel Gaist Research And Development Engineer Idiap Research Institute, Centre du Parc, CP 592, CH-1920 Martigny http://www.idiap.ch/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From jani.heikkinen at qt.io Tue Aug 21 11:04:09 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 21 Aug 2018 09:04:09 +0000 Subject: [Development] HEADS-UP: Branching from 'dev' to '5.12' completed In-Reply-To: References: Message-ID: Hi, Branching from 'dev' to '5.12' is now complete and Qt 5.12 Feature Freeze is in effect. So from now on all changes for Qt 5.12 release must be done in '5.12' and 'dev' is for Qt 5.13. If not already done please update Qt 5.12 new features page: https://wiki.qt.io/New_Features_in_Qt_5.12 Our plan is to publish Qt 5.12 alpha release as soon as possible. Alpha blocker list here: https://bugreports.qt.io/issues/?filter=19449 br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Tuesday, August 14, 2018 2:48 PM To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Development] HEADS-UP: Branching from 'dev' to '5.12' started Hi! We have soft branched '5.12' from 'dev' today. We are planning to have final downmerge and Qt 5.12 Feature Freeze Monday 20.8.2018. So there is still time to finalize ongoing task in 'dev' and start using '5.12' for new changes targeted to Qt 5.12 release. br, Jani Heikkinen Release Manager _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From edward.welbourne at qt.io Tue Aug 21 11:18:45 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 21 Aug 2018 09:18:45 +0000 Subject: [Development] About 3D desktop. In-Reply-To: References: , Message-ID: Stef Bon (21 August 2018 05:36) > Also important here is what is called in Dutch a "verdwijnpunt". I do > not know the translation, but the horizon is something like that, > where all parallel lines meet..) Searching for it on nl.wikipedia.org I get a page [0] whose pictures tell me it's what we call a "panishing point" [1] in English. [0] https://nl.wikipedia.org/wiki/Lijnperspectief [1] https://en.wikipedia.org/wiki/Vanishing_point Eddy. From tobias.hunger at gmail.com Tue Aug 21 11:32:31 2018 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Tue, 21 Aug 2018 11:32:31 +0200 Subject: [Development] About 3D desktop. In-Reply-To: References: Message-ID: On Tue, Aug 21, 2018 at 5:36 AM Stef Bon wrote: > Yes the 3D window manager looks a lot at the idea I want to work on. Projecting "normal" 2D applications into 3D space is pretty useless and full 3D applications do not really make sense for that many use-cases. I have used both 3dwm and fresco in a VR environment at the University of Goteborg once. It was fun to be able to walk around your terminal windows, but they were also pretty hard to use:-) Best regards, Tobias From tuukka.turunen at qt.io Tue Aug 21 13:56:27 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 21 Aug 2018 11:56:27 +0000 Subject: [Development] HEADS-UP: Branching from 'dev' to '5.12' completed Message-ID: <317DB931-DFA0-4562-9700-719C701922EB@qt.io> Hi, There are still quite many modules that have nothing mentioned about them in the new features overview page. It would be great to get these added quickly as we will point to the wiki from the Alpha announcement. Yours, Tuukka On 21/08/2018, 11.04, "Development on behalf of Jani Heikkinen" wrote: Hi, Branching from 'dev' to '5.12' is now complete and Qt 5.12 Feature Freeze is in effect. So from now on all changes for Qt 5.12 release must be done in '5.12' and 'dev' is for Qt 5.13. If not already done please update Qt 5.12 new features page: https://wiki.qt.io/New_Features_in_Qt_5.12 Our plan is to publish Qt 5.12 alpha release as soon as possible. Alpha blocker list here: https://bugreports.qt.io/issues/?filter=19449 br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Tuesday, August 14, 2018 2:48 PM To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Development] HEADS-UP: Branching from 'dev' to '5.12' started Hi! We have soft branched '5.12' from 'dev' today. We are planning to have final downmerge and Qt 5.12 Feature Freeze Monday 20.8.2018. So there is still time to finalize ongoing task in 'dev' and start using '5.12' for new changes targeted to Qt 5.12 release. br, Jani Heikkinen Release Manager _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From lars.knoll at qt.io Tue Aug 21 16:07:14 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 21 Aug 2018 14:07:14 +0000 Subject: [Development] override keyword on destructors In-Reply-To: <20180820064734.GA14139@klara.mpi.htwm.de> References: <20180820064734.GA14139@klara.mpi.htwm.de> Message-ID: I’d agree with most comments. I find the override keyword on destructors useful, and would like to keep it/encourage having it. Cheers, Lars > On 20 Aug 2018, at 08:47, André Pönitz wrote: > > On Mon, Aug 20, 2018 at 01:08:36PM +0100, Sérgio Martins via Development wrote: >> Hi, >> >> Looks like some 'override' keywords crept into a few destructors. This is >> probably because clang-tidy warns about it (and now QtCreator). >> >> IMO we should avoid it, as it's misleading. Dtors are a special case and >> have completely different semantics. They don't replace their base class >> dtors. They're chained instead. > > That's one way look at it. > > One can also argue that it's "something" for which some base implementation > exists and that might need double-checking when the base disappears. > > It's also a hint when reading code that the base destructor's "virtual" > actually has not been forgotten. > >> This is not 100% consensual, some people like to use it. >> >> But it's discouraged by the Cpp Core Guidelines [1] ; gcc's >> -Wsuggest-override doesn't suggest it for dtors and neither does clang's >> -Winconsistent-missing-override. > >> So clang-tidy is the one odd out. >> >> I'll update the coding conventions if nobody opposes. > > Please not. > > Andre' > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From edward.welbourne at qt.io Tue Aug 21 18:50:32 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 21 Aug 2018 16:50:32 +0000 Subject: [Development] HEADS-UP: Branching from 'dev' to '5.12' completed In-Reply-To: <317DB931-DFA0-4562-9700-719C701922EB@qt.io> References: <317DB931-DFA0-4562-9700-719C701922EB@qt.io> Message-ID: Jani Heikkinen (21/08/2018, 11.04) wrote: > Branching from 'dev' to '5.12' is now complete and Qt 5.12 Feature Freeze is in effect. So now it is time for the API review. Find your favourite module on: https://codereview.qt-project.org/#/q/status:open+branch:5.12+topic:api-review,n,z Track the review in: http://bugreports.qt.io/browse/QTBUG-70094 Any issues you raise in review should, per [QUIP 10], be reported as bugs that block both QTBUG-70094 and the release. * [QUIP 10] https://quips-qt-io.herokuapp.com/quip-0010-API-review.html Eddy. From thiago.macieira at intel.com Wed Aug 22 02:15:09 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 21 Aug 2018 17:15:09 -0700 Subject: [Development] Upgrade the XCode running in the CI's macOS 10.11 In-Reply-To: <4494200.OeiRVixnHO@tjmaciei-mobl1> References: <4494200.OeiRVixnHO@tjmaciei-mobl1> Message-ID: <3202488.U1gYQa4Ahj@tjmaciei-mobl1> On Sunday, 8 July 2018 17:15:36 PDT Thiago Macieira wrote: > This is the second time I've run into a compiler bug with that XCode's > ancient Clang. Third strike. Can we PLEASE REMOVE ancient Clang that is running on macOS 10.11 in the CI for 5.12? Yes, I've read the email that it would leave us without 10.11 testing. If that's the result, then do it. And BEFORE the final downmerge? I can't integrate changes that compile on regular Clang (Linux and FreeBSD), modern Apple Clang, GCC, MSVC 2015 and MSVC 2017. If that isn't done, I can't guarantee CBOR will work. I *do not* have time to investigate this problem or find work arounds, so this will impact my ability to provide bug fixes. Unless the consensus is to drop the work I was doing that ran into issues. See https://codereview.qt-project.org/233481 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tony.sarajarvi at qt.io Wed Aug 22 09:11:20 2018 From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=) Date: Wed, 22 Aug 2018 07:11:20 +0000 Subject: [Development] Upgrade the XCode running in the CI's macOS 10.11 In-Reply-To: <3202488.U1gYQa4Ahj@tjmaciei-mobl1> References: <4494200.OeiRVixnHO@tjmaciei-mobl1> <3202488.U1gYQa4Ahj@tjmaciei-mobl1> Message-ID: The timing 😉 https://codereview.qt-project.org/#/c/237412/ -Tony -----Original Message----- From: Development On Behalf Of Thiago Macieira Sent: keskiviikko 22. elokuuta 2018 3.15 To: development at qt-project.org Subject: Re: [Development] Upgrade the XCode running in the CI's macOS 10.11 Importance: High On Sunday, 8 July 2018 17:15:36 PDT Thiago Macieira wrote: > This is the second time I've run into a compiler bug with that XCode's > ancient Clang. Third strike. Can we PLEASE REMOVE ancient Clang that is running on macOS 10.11 in the CI for 5.12? Yes, I've read the email that it would leave us without 10.11 testing. If that's the result, then do it. And BEFORE the final downmerge? I can't integrate changes that compile on regular Clang (Linux and FreeBSD), modern Apple Clang, GCC, MSVC 2015 and MSVC 2017. If that isn't done, I can't guarantee CBOR will work. I *do not* have time to investigate this problem or find work arounds, so this will impact my ability to provide bug fixes. Unless the consensus is to drop the work I was doing that ran into issues. See https://codereview.qt-project.org/233481 -- 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 Liang.Qi at qt.io Wed Aug 22 09:42:03 2018 From: Liang.Qi at qt.io (Liang Qi) Date: Wed, 22 Aug 2018 07:42:03 +0000 Subject: [Development] HEADS-UP: Branching from 'dev' to '5.12' completed In-Reply-To: References: Message-ID: <3489C4DB-8FD9-4CF3-8746-61B4EDD7D518@qt.io> qt5 dev->5.12 is also done last night, https://codereview.qt-project.org/#/c/237349/ . Please remember to retarget your provisioning changes in qt5 if agreed for 5.12. — Liang > On 21 Aug 2018, at 11:04, Jani Heikkinen wrote: > > Branching from 'dev' to '5.12' is now complete and Qt 5.12 Feature Freeze is in effect. So from now on all changes for Qt 5.12 release must be done in '5.12' and 'dev' is for Qt 5.13. > > If not already done please update Qt 5.12 new features page: https://wiki.qt.io/New_Features_in_Qt_5.12 > > Our plan is to publish Qt 5.12 alpha release as soon as possible. Alpha blocker list here: https://bugreports.qt.io/issues/?filter=19449 > > br, > Jani From Morten.Sorvig at qt.io Wed Aug 22 10:52:31 2018 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Wed, 22 Aug 2018 08:52:31 +0000 Subject: [Development] Upgrade the XCode running in the CI's macOS 10.11 In-Reply-To: <4494200.OeiRVixnHO@tjmaciei-mobl1> References: <4494200.OeiRVixnHO@tjmaciei-mobl1> Message-ID: <5A4DF22C-18A5-4A92-BE71-17E7D196B5DD@qt.io> > On 9 Jul 2018, at 02:15, Thiago Macieira wrote: > > This is the second time I've run into a compiler bug with that XCode's ancient > Clang. > > Can we please upgrade the XCode installation there to the latest available for > macOS 10.11? > > If that's the latest, can we declare that building Qt on 10.11 is no longer > supported for Qt 5.12? I'm not asking about deployment, only building. Yes, let’s drop support for the older clang versions. There are some other aspects to take into account as well: - As mentioned above, we want to drop support for outdated compilers for new Qt releases. - We want to deploy to a relativly wide range of macOS platforms. Current - 2. If the minimum deployment target for the LTS releases is fixed, then older macOS versions stay relevant. - We can require that developers stay reasonably up to date: current +/- 1. - We are now seeing that older Qt versions are not going to support newer SDKs, since Apple is using the build SDK version to enable new behaviors (for example dark mode and CA layers on 10.14). This means the max supported SDK version for e.g. Qt 5.9 is the 10.13 SDK. - On the other hand we would like to build the 5.12 binary package with the 10.14 SDK in order to make use of new API. - Can we mix and match compiler and SDK versions? Empiricism shows that it’s the final app link SDK that gates the enabled features, so it might not matter exactly which SDK the Qt binary package is built against for this purpose. - CI system support for building on one platform version and deploying/testing on others is still on the wish list :) Morten From frederik.gladhorn at qt.io Wed Aug 22 10:53:49 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Wed, 22 Aug 2018 10:53:49 +0200 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> Message-ID: <2317435.y4KJu3U8PQ@frederik-thinkcentre-m93p> Quick status update from my side: I have the script running against a test installation of JIRA. It seems to work, there are some small issues to be worked out still. - Qt Creator version numbers are verbose, so I need to be more generous in matching strings, right now I don't detect the version number correctly there. This one I will fix, it's just going to take a few minutes. - Qt 3D Studio seems to be a mess, it has 5.x branches but the JIRA versions are 2.x, I consider this a won't fix. I'd love if people started using "Fixes:", it will work retro-actively. And if you manually close a task in the meantime, no harm is done. Multiple fix versions: There were some doubts about which fix versions would be set, for example during the down-merge. This actually turns out to work quite nicely: If a change ends up in dev, the script will detect that it will end up in 5.13.0 right now and sets that as fix version. If the downmerge happens, the script will see the change again in 5.12.0 and add that fix version. In my opinion there is no major harm. If the change is then cherry-picked to 5.9.7, it will also add that fix version. This also means that changes going into 5.11.4 will be marked as fixed in 5.12.1 or whatever is applicable branch/version wise. So we will actually set fix versions nicely. There are some fixes in JIRA that would be easy to make, assuming there is agreement. Since I have to use some heuristics, I decided to only ever look at full version numbers, including patch level releases. Currently we have version numbers in JIRA which do not make much sense to me, since they will never be released, such as 6.0, 5.12 and a few more. I would propose we always use the full version, so 6.0.0 and 5.12.0. If the script finds 5.13 but not 5.13.0 it will not set any fix version. I'm unsure where the whole thing should live, currently it's internal to The Qt Company, I'd love to publish it somewhere (it's a bunch of python files). Cheers, Frederik From Tor.arne.Vestbo at qt.io Wed Aug 22 16:46:39 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Wed, 22 Aug 2018 14:46:39 +0000 Subject: [Development] unified data model API in QtCore => thin wrapper proposal In-Reply-To: <1764957.X2QKQoLrbe@tjmaciei-mobl1> References: <1983779.PT3qfJPyb1@tjmaciei-mobl1> <1764957.X2QKQoLrbe@tjmaciei-mobl1> Message-ID: <09CDA149-6973-453E-B67A-23E1FD75E0F3@qt.io> On 17 Aug 2018, at 17:08, Thiago Macieira wrote: > > On Friday, 17 August 2018 02:50:32 PDT Tor Arne Vestbø wrote: >>> Unless someone can volunteer to test. I *think* my design is slightly >>> better than QJsonValue, so the following should work: >>> >>> value[1]["hello"][32] = false; >> >> That’s great news. I assume it’s also easy to convert from and to JSON, so >> that one could use QCbor as an intermediate data format if one needs to >> modify JSON In place and write it out again? > > Please note I said that I *think* it should work, not that it does work. Could > you give it a try and see if it makes your life easier? > > Now, looking at the code, I don't think it does work. I thought that > QCborValue::operator[] returned QCborValueRefs, but it doesn't. Adding a set > of non-const overloads returning QCborValueRef might be the trick. And it's a > trick we can add to QJsonValue too. > > Converting from JSON is lossless and converting that content back to JSON is > lossless too. It's just not particularly efficient today. This library looks really nice: https://cocoapods.org/pods/nlohmann_json Tor Arne > > -- > 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 mikhail.svetkin at gmail.com Wed Aug 22 16:53:46 2018 From: mikhail.svetkin at gmail.com (Mikhail Svetkin) Date: Wed, 22 Aug 2018 16:53:46 +0200 Subject: [Development] unified data model API in QtCore => thin wrapper proposal In-Reply-To: <09CDA149-6973-453E-B67A-23E1FD75E0F3@qt.io> References: <1983779.PT3qfJPyb1@tjmaciei-mobl1> <1764957.X2QKQoLrbe@tjmaciei-mobl1> <09CDA149-6973-453E-B67A-23E1FD75E0F3@qt.io> Message-ID: Yes, this library is very cool and requires only c++11. Best regards, Mikhail On Wed, 22 Aug 2018 at 16:47, Tor Arne Vestbø wrote: > On 17 Aug 2018, at 17:08, Thiago Macieira > wrote: > > > > On Friday, 17 August 2018 02:50:32 PDT Tor Arne Vestbø wrote: > >>> Unless someone can volunteer to test. I *think* my design is slightly > >>> better than QJsonValue, so the following should work: > >>> > >>> value[1]["hello"][32] = false; > >> > >> That’s great news. I assume it’s also easy to convert from and to JSON, > so > >> that one could use QCbor as an intermediate data format if one needs to > >> modify JSON In place and write it out again? > > > > Please note I said that I *think* it should work, not that it does work. > Could > > you give it a try and see if it makes your life easier? > > > > Now, looking at the code, I don't think it does work. I thought that > > QCborValue::operator[] returned QCborValueRefs, but it doesn't. Adding a > set > > of non-const overloads returning QCborValueRef might be the trick. And > it's a > > trick we can add to QJsonValue too. > > > > Converting from JSON is lossless and converting that content back to > JSON is > > lossless too. It's just not particularly efficient today. > > This library looks really nice: > > https://cocoapods.org/pods/nlohmann_json > > Tor Arne > > > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel Open Source Technology Center > > > > > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at qt.io Thu Aug 23 09:48:02 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 23 Aug 2018 07:48:02 +0000 Subject: [Development] Qt 5.12 new features In-Reply-To: References: Message-ID: Hi Vlad, While deprecated, Qt Quick Controls 1 is still part of Qt 5.12, so you can continue using it. It’s performance is not adequate for many use cases, and Qt Quick Controls 2 fixed that. Qt Quick Controls 2 is the one we are actively developing and it adds many nice features in Qt 5.12. TreeView would certainly be a natural addition to Controls 2. Yours, Tuukka From: Development on behalf of Vlad Stelmahovsky Date: Thursday, 16 August 2018 at 17.17 To: Jason H Cc: "development at qt-project.org" Subject: Re: [Development] Qt 5.12 new features A bit unclear about deprecating QQC1 Since in QQC2 no TreeView and even no plans for this, isn't it a bit too early to deprecate QQC1? thanks On Thu, Aug 16, 2018 at 4:02 PM Jason H > wrote: 5.11 included WebGL TP2. Is there any change? Why is it staying TP2, or should it be TP3? 5.12 looks like it'll be a pretty great update! I'm not sure what's on the agenda for 5.13... but as I mentioned on interest, one pain point I continually have is the amount of custom platform integrations for mobile. This is one area where Xamrain excels, as they have a simple property on an object you can set to control things like the status bar visibility, the screen brightness, etc. The downside is the Xamarin stuff is all platform-specific so using a iOS property on Android won't work. This is one area where Qt can leapfrog the other platforms including React Native by being cross platform. Anything that doesn't require me to write Obj-C is a very good thing! I figure this would need to be a few Qt Quick/QObject Singletons. Notifications should be supported too, and this could also be used for desktop platform notifications as well. The notifications support would only need to cover being messaged my the platform, and not any display - this would get me out of having to deal with Obj-C almost completely. (My beef wi th ObjC is other than being not good at it, is whatever I'm writing isn't cross-platform. Java I am more comfortable with, so I complain less, but I still cringe on the non-portability!) Looking forward to 5.12! > Sent: Wednesday, August 15, 2018 at 12:50 AM > From: "Jani Heikkinen" > > To: "development at qt-project.org" > > Subject: [Development] Qt 5.12 new features > > Hi, > > Qt 5.12 Feature Freeze will be in effect Mon 20th August and we should have already now pretty good understanding what is new in Qt 5.12. So please update 5.12 new features page here: https://wiki.qt.io/New_Features_in_Qt_5.12 > > 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 -- Best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwoehlke.floss at gmail.com Thu Aug 23 22:38:18 2018 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Thu, 23 Aug 2018 16:38:18 -0400 Subject: [Development] override keyword on destructors In-Reply-To: <7262400.tAYMJZ3HSC@kerberos> References: <7262400.tAYMJZ3HSC@kerberos> Message-ID: <3e9fad92-40de-516f-a162-ebbba90962d2@gmail.com> On 2018-08-20 09:58, Kevin Funk wrote: > IMO, it would also be nice to get a compiler warning/error if a > base class' destructor is changed from virtual to non-virtual which may cause > subtle behavioral changes such as memory leaks. You mean something like -Wnon-virtual-dtor? Granted, it's not *exactly* what I think you're asking for, but how often do you have a base class with a virtual dtor and *no* other virtual members? -- Matthew From thiago.macieira at intel.com Fri Aug 24 08:03:43 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Aug 2018 23:03:43 -0700 Subject: [Development] Windows 7 support future removal Message-ID: <17474900.KWDFbFpmzP@tjmaciei-mobl1> Since we're talking about macOS 10.11 and I came across the Windows support lifetime pages, I'm posting this for future reference. https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet Windows 7 ends its Extended Support lifecycle on January 14, 2020, roughly a year and a half from now. If we keep our current release cycle, the current release at that time will be 5.14. Or, put differently, Windows 7 will be out of support when 5.15 launches. We may want to drop support for it in one of those two releases. We should announce we're doing so one year before the fact. So if we'd like to drop in 5.14, we should include the announcement in the 5.12 changelog. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lars.knoll at qt.io Fri Aug 24 08:11:09 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 24 Aug 2018 06:11:09 +0000 Subject: [Development] Windows 7 support future removal In-Reply-To: <17474900.KWDFbFpmzP@tjmaciei-mobl1> References: <17474900.KWDFbFpmzP@tjmaciei-mobl1> Message-ID: > On 24 Aug 2018, at 08:03, Thiago Macieira wrote: > > Since we're talking about macOS 10.11 and I came across the Windows support > lifetime pages, I'm posting this for future reference. > > https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet > > Windows 7 ends its Extended Support lifecycle on January 14, 2020, roughly a > year and a half from now. If we keep our current release cycle, the current > release at that time will be 5.14. Or, put differently, Windows 7 will be out > of support when 5.15 launches. > > We may want to drop support for it in one of those two releases. We should > announce we're doing so one year before the fact. So if we'd like to drop in > 5.14, we should include the announcement in the 5.12 changelog. We know that quite some users stay on unsupported versions of Windows for quite a while. I wonder whether it wouldn’t be easiest in this case to then drop Windows 7 with Qt 6.0 in Autumn 2020 (ie. in the release after 5.15). Cheers, Lars From thiago.macieira at intel.com Fri Aug 24 08:11:49 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Aug 2018 23:11:49 -0700 Subject: [Development] Windows 7 support future removal In-Reply-To: <17474900.KWDFbFpmzP@tjmaciei-mobl1> References: <17474900.KWDFbFpmzP@tjmaciei-mobl1> Message-ID: <8654796.JcMI9IVypG@tjmaciei-mobl1> On Thursday, 23 August 2018 23:03:43 PDT Thiago Macieira wrote: > Since we're talking about macOS 10.11 and I came across the Windows support > lifetime pages, I'm posting this for future reference. > > https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet > > Windows 7 ends its Extended Support lifecycle on January 14, 2020, roughly a > year and a half from now. If we keep our current release cycle, the current > release at that time will be 5.14. Or, put differently, Windows 7 will be > out of support when 5.15 launches. > > We may want to drop support for it in one of those two releases. We should > announce we're doing so one year before the fact. So if we'd like to drop in > 5.14, we should include the announcement in the 5.12 changelog. And here's some depressing news, "Based on that trend, Computerworld now predicts that Windows 7 will account for 35% of all active Windows editions when support ends in January 2020." - https://www.computerworld.com/article/3199373/windows-pcs/windows-by-the-numbers-windows-10s-growth-continues.html -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Aug 24 08:24:02 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Aug 2018 23:24:02 -0700 Subject: [Development] Windows 7 support future removal In-Reply-To: References: <17474900.KWDFbFpmzP@tjmaciei-mobl1> Message-ID: <5455041.9HkFxZB0Y9@tjmaciei-mobl1> On Thursday, 23 August 2018 23:11:09 PDT Lars Knoll wrote: > We know that quite some users stay on unsupported versions of Windows for > quite a while. I wonder whether it wouldn’t be easiest in this case to then > drop Windows 7 with Qt 6.0 in Autumn 2020 (ie. in the release after 5.15). I don't mind either way. I just wanted to bring the topic up. I don't think we have much that requires Windows 8 or 8.1, which would result in any meaningful clean up of our source code if we were to drop Windows 7. We'd get rid of a few GetProcAddresses, but not a lot. And considering that Windows 10 still has a smaller market share than Windows 7 today, three years after Windows 10 TH1 came out (see CW link in the other email), you're probably right. PS: I don't believe Qt 6.0 will be in the Autumn of 2020. More likely early 2021. PPS: had anyone noticed we had THREE minor releases of Qt in 2017? 5.8 (Jan 20), 5.9 (May 29) and 5.10 (Dec 5). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lars.knoll at qt.io Fri Aug 24 08:52:35 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 24 Aug 2018 06:52:35 +0000 Subject: [Development] Windows 7 support future removal In-Reply-To: <5455041.9HkFxZB0Y9@tjmaciei-mobl1> References: <17474900.KWDFbFpmzP@tjmaciei-mobl1> <5455041.9HkFxZB0Y9@tjmaciei-mobl1> Message-ID: <6629A2D0-F90E-483E-BF94-6F883127D4D2@qt.io> > On 24 Aug 2018, at 08:24, Thiago Macieira wrote: > > On Thursday, 23 August 2018 23:11:09 PDT Lars Knoll wrote: >> We know that quite some users stay on unsupported versions of Windows for >> quite a while. I wonder whether it wouldn’t be easiest in this case to then >> drop Windows 7 with Qt 6.0 in Autumn 2020 (ie. in the release after 5.15). > > I don't mind either way. I just wanted to bring the topic up. > > I don't think we have much that requires Windows 8 or 8.1, which would result > in any meaningful clean up of our source code if we were to drop Windows 7. > We'd get rid of a few GetProcAddresses, but not a lot. > > And considering that Windows 10 still has a smaller market share than > Windows 7 today, three years after Windows 10 TH1 came out (see CW link in the > other email), you're probably right. And see your other mail about estimated market share of Win7. It’s been like that in the past as well. We always had to support older windows versions for quite a long time. > > PS: I don't believe Qt 6.0 will be in the Autumn of 2020. More likely early > 2021. With a major version, we certainly have the risk of delays. But I’d rather like us all to plan for Autumn 2020. If we plan for 2021, it might end up getting out even later :) > > PPS: had anyone noticed we had THREE minor releases of Qt in 2017? 5.8 > (Jan 20), 5.9 (May 29) and 5.10 (Dec 5). Yes, because 5.8 was late :) Cheers, Lars From alexei.fedotov at gmail.com Fri Aug 24 12:38:20 2018 From: alexei.fedotov at gmail.com (Alexei Fedotov) Date: Fri, 24 Aug 2018 13:38:20 +0300 Subject: [Development] configure best practices Message-ID: Hello, folks. I want to learn configure options beyond the limits of Qt documentation. I believe there should be a place where Qt regular builds are built, and there should be plenty of working options there. Could you please suggest a link to the scripts which produce these builds? -- Carry a towel http://dataved.ru/ +7 916 562 8095 [1] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/ [2] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings [3] Start using Apache Openmeetings today, http://openmeetings.apache.org/ From Shawn.Rutledge at qt.io Fri Aug 24 14:01:35 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Fri, 24 Aug 2018 12:01:35 +0000 Subject: [Development] Windows 7 support future removal In-Reply-To: <5455041.9HkFxZB0Y9@tjmaciei-mobl1> References: <17474900.KWDFbFpmzP@tjmaciei-mobl1> <5455041.9HkFxZB0Y9@tjmaciei-mobl1> Message-ID: > On 24 Aug 2018, at 08:24, Thiago Macieira wrote: > > On Thursday, 23 August 2018 23:11:09 PDT Lars Knoll wrote: >> We know that quite some users stay on unsupported versions of Windows for >> quite a while. I wonder whether it wouldn’t be easiest in this case to then >> drop Windows 7 with Qt 6.0 in Autumn 2020 (ie. in the release after 5.15). > > I don't mind either way. I just wanted to bring the topic up. > > I don't think we have much that requires Windows 8 or 8.1, which would result > in any meaningful clean up of our source code if we were to drop Windows 7. > We'd get rid of a few GetProcAddresses, but not a lot. Pointer Input Messages (modern API for touch, touchpad, and tablet/stylus devices, recently added, see QTBUG-60437 and https://codereview.qt-project.org/#/c/230421/ ) are not supported in Windows 7 AFAIK. So maybe there’s some room for simplification there eventually, FWIW. From apoenitz at t-online.de Fri Aug 24 10:58:45 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Fri, 24 Aug 2018 10:58:45 +0200 Subject: [Development] Windows 7 support future removal In-Reply-To: <17474900.KWDFbFpmzP@tjmaciei-mobl1> References: <17474900.KWDFbFpmzP@tjmaciei-mobl1> Message-ID: <20180824085844.GA11626@klara.mpi.htwm.de> On Thu, Aug 23, 2018 at 11:03:43PM -0700, Thiago Macieira wrote: > Since we're talking about macOS 10.11 and I came across the Windows support > lifetime pages, I'm posting this for future reference. > > https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet > > Windows 7 ends its Extended Support lifecycle on January 14, 2020, roughly a > year and a half from now. If we keep our current release cycle, the current > release at that time will be 5.14. Or, put differently, Windows 7 will be out > of support when 5.15 launches. > > We may want to drop support for it in one of those two releases. We should > announce we're doing so one year before the fact. So if we'd like to drop in > 5.14, we should include the announcement in the 5.12 changelog. What exactly does Qt gain by dropping Windows 7 compatibility? "Being out of support by Microsoft" seems to be for quite a few people a rather unimportant line of reasoning in comparison to having to submit to Windows 10-style forced system upgrades and snooping on user activities. Andre' From Ch.Ehrlicher at gmx.de Sat Aug 25 21:03:28 2018 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Sat, 25 Aug 2018 21:03:28 +0200 Subject: [Development] Q_COMPILER_UNIFORM_INIT still needed? Message-ID: <3f16f8db-f7be-6880-7918-5cbc6eeb644b@gmx.de> Hi, will reviewing a patch I found this comment from Marc Mutz in qstringlistmodel.cpp: // once Q_COMPILER_UNIFORM_INIT can be used, change to: // emit dataChanged(index, index, {Qt::DisplayRole, Qt::EditRole}); Now I wonder if this is still needed because we're using this way calling dataChanged in a lot of other places without the guard and even in the documentation. So - is this comment wrong or is the define no longer needed (I would guess the latter) Christian From kevin.kofler at chello.at Mon Aug 27 01:12:51 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 27 Aug 2018 01:12:51 +0200 Subject: [Development] Qt 6 buildsystem support requirements References: <12270285.0g7gfsGHTX@tjmaciei-mobl1> <36508308.LhyNAa6ULx@debian> <1744013.hO7IBvXSqR@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > Also note that QML files are usually cross-platform too and could be > shared. Any non-cross-platform QML file should be selected by the source > via QFileSelector. Plugins, however, are arch-dependent and should live in > an arch-dependent dir. That would mean splitting the "qml" dir in two: > > /lib/qml > /share/qml > > I don't see us spending the effort... That would also help multilib GNU/Linux distributions though, because right now we have to treat all QML-only packages as arch-specific just because of the installation path. Having the QML files themselves in /usr/share would allow us to make those packages noarch. Kevin Kofler From andre.hartmann at iseg-hv.de Mon Aug 27 08:39:03 2018 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Mon, 27 Aug 2018 08:39:03 +0200 Subject: [Development] Windows 7 support future removal In-Reply-To: <20180824085844.GA11626@klara.mpi.htwm.de> References: <17474900.KWDFbFpmzP@tjmaciei-mobl1> <20180824085844.GA11626@klara.mpi.htwm.de> Message-ID: <22f79e41-5003-5822-2d95-74b286b9272b@iseg-hv.de> Am 24.08.2018 um 10:58 schrieb André Pönitz: > "Being out of support by Microsoft" seems to be for quite a few people > a rather unimportant line of reasoning in comparison to having to submit > to Windows 10-style forced system upgrades and snooping on user activities. I couldn't agree you more. André From thiago.macieira at intel.com Mon Aug 27 09:00:17 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Aug 2018 00:00:17 -0700 Subject: [Development] Windows 7 support future removal In-Reply-To: <22f79e41-5003-5822-2d95-74b286b9272b@iseg-hv.de> References: <17474900.KWDFbFpmzP@tjmaciei-mobl1> <20180824085844.GA11626@klara.mpi.htwm.de> <22f79e41-5003-5822-2d95-74b286b9272b@iseg-hv.de> Message-ID: <8086317.rBugRgWIOs@tjmaciei-mobl1> On Sunday, 26 August 2018 23:39:03 PDT André Hartmann wrote: > Am 24.08.2018 um 10:58 schrieb André Pönitz: > > "Being out of support by Microsoft" seems to be for quite a few people > > a rather unimportant line of reasoning in comparison to having to submit > > to Windows 10-style forced system upgrades and snooping on user > > activities. > > I couldn't agree you more. I don't have a problem with that, so long as they never connect those computers to the Internet after January 2020. That would be irresponsible. But if people are using Qt for applications that run on those offline computers, I don't mind keeping support. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From apoenitz at t-online.de Mon Aug 27 10:50:46 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Mon, 27 Aug 2018 10:50:46 +0200 Subject: [Development] Windows 7 support future removal In-Reply-To: <8086317.rBugRgWIOs@tjmaciei-mobl1> References: <17474900.KWDFbFpmzP@tjmaciei-mobl1> <20180824085844.GA11626@klara.mpi.htwm.de> <22f79e41-5003-5822-2d95-74b286b9272b@iseg-hv.de> <8086317.rBugRgWIOs@tjmaciei-mobl1> Message-ID: <20180827085046.GA3834@klara.mpi.htwm.de> On Mon, Aug 27, 2018 at 12:00:17AM -0700, Thiago Macieira wrote: > On Sunday, 26 August 2018 23:39:03 PDT André Hartmann wrote: > > Am 24.08.2018 um 10:58 schrieb André Pönitz: > > > "Being out of support by Microsoft" seems to be for quite a few people > > > a rather unimportant line of reasoning in comparison to having to submit > > > to Windows 10-style forced system upgrades and snooping on user > > > activities. > > > > I couldn't agree you more. > > I don't have a problem with that, so long as they never connect those > computers to the Internet after January 2020. That would be irresponsible. Because of what? Because Microsoft (or any OS vendor that's on the "newer is better" trip for that matter) have scheduled the invention of the magic sauce that makes their systems suddenly safe to use in public networks for December 2019? Because hardware vendors have forsworn security-by-obscurity and suddenly release their OS-and-a-half-on-a-chip-that-may-change-anything-the-user's- -OS-does to public scrutiny? Because there'll be World Peace and all the bad guys are gone? I doubt either of that will happen. "Realistically" (a term I colloquially use for "extrapolating from a number of incidents in the past") we will see trading semi-working systems with a certain number of known and an uncertain number of unknown deficiencies for other systems with another uncertain number of the same of other, newer unknown deficiencies. This might look like an advantage to some, but it isn't in any metrics that I am tempted to take seriously - *especially* when there are ways to mitigate some of known deficiencies in a way that don't boil down to "try to use a newer random version of what we sold you last year as the best thing since sliced bread". Andre' From thiago.macieira at intel.com Mon Aug 27 23:34:50 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Aug 2018 14:34:50 -0700 Subject: [Development] Windows 7 support future removal In-Reply-To: <20180827085046.GA3834@klara.mpi.htwm.de> References: <17474900.KWDFbFpmzP@tjmaciei-mobl1> <8086317.rBugRgWIOs@tjmaciei-mobl1> <20180827085046.GA3834@klara.mpi.htwm.de> Message-ID: <3114410.Jl4yWPMlei@tjmaciei-mobl1> On Monday, 27 August 2018 01:50:46 PDT André Pönitz wrote: > On Mon, Aug 27, 2018 at 12:00:17AM -0700, Thiago Macieira wrote: > > I don't have a problem with that, so long as they never connect those > > computers to the Internet after January 2020. That would be irresponsible. > > Because of what? Because it's not receiving security updates. > Because Microsoft (or any OS vendor that's on the "newer is better" trip > for that matter) have scheduled the invention of the magic sauce that makes > their systems suddenly safe to use in public networks for December 2019? No, that sauce is already known. It's called "security updates" and they have to be applied on a continuous basis. You may not need to apply all fixes, but you need to have the ability to do so when there's a fix that is relevant to you. Starting in January 2020, the only company that could make those fixes will stop making them. It is unlikely that the next day will start with a new vulnerability discovered, but one will be sooner or later. And since no fix will ever be coming, those devices will be forever vulnerable. Sure, there are other ways to mitigate the problem, like having an external firewall. But all it takes is another device also vulnerable on that network to allow access in and now those out-of-date Windows are accessible. > "Realistically" (a term I colloquially use for "extrapolating from a number > of incidents in the past") we will see trading semi-working systems with a > certain number of known and an uncertain number of unknown deficiencies for > other systems with another uncertain number of the same of other, newer > unknown deficiencies. Right. But worse than that, you have an unknown number of devices with *known* deficiencies. > This might look like an advantage to some, but it isn't in any metrics > that I am tempted to take seriously - *especially* when there are ways > to mitigate some of known deficiencies in a way that don't boil down > to "try to use a newer random version of what we sold you last year as > the best thing since sliced bread". Defence in depth. You should deploy those other mitigations, like the firewall. But ignoring or not receiving OS fixes is a critical problem. Then again, those computers would be vulnerable without Internet connection. Have you ever seen what happens if you drop a USB stick in a company's parking lot? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Aug 27 23:34:50 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Aug 2018 14:34:50 -0700 Subject: [Development] Windows 7 support future removal In-Reply-To: <20180827085046.GA3834@klara.mpi.htwm.de> References: <17474900.KWDFbFpmzP@tjmaciei-mobl1> <8086317.rBugRgWIOs@tjmaciei-mobl1> <20180827085046.GA3834@klara.mpi.htwm.de> Message-ID: <3114410.Jl4yWPMlei@tjmaciei-mobl1> On Monday, 27 August 2018 01:50:46 PDT André Pönitz wrote: > On Mon, Aug 27, 2018 at 12:00:17AM -0700, Thiago Macieira wrote: > > I don't have a problem with that, so long as they never connect those > > computers to the Internet after January 2020. That would be irresponsible. > > Because of what? Because it's not receiving security updates. > Because Microsoft (or any OS vendor that's on the "newer is better" trip > for that matter) have scheduled the invention of the magic sauce that makes > their systems suddenly safe to use in public networks for December 2019? No, that sauce is already known. It's called "security updates" and they have to be applied on a continuous basis. You may not need to apply all fixes, but you need to have the ability to do so when there's a fix that is relevant to you. Starting in January 2020, the only company that could make those fixes will stop making them. It is unlikely that the next day will start with a new vulnerability discovered, but one will be sooner or later. And since no fix will ever be coming, those devices will be forever vulnerable. Sure, there are other ways to mitigate the problem, like having an external firewall. But all it takes is another device also vulnerable on that network to allow access in and now those out-of-date Windows are accessible. > "Realistically" (a term I colloquially use for "extrapolating from a number > of incidents in the past") we will see trading semi-working systems with a > certain number of known and an uncertain number of unknown deficiencies for > other systems with another uncertain number of the same of other, newer > unknown deficiencies. Right. But worse than that, you have an unknown number of devices with *known* deficiencies. > This might look like an advantage to some, but it isn't in any metrics > that I am tempted to take seriously - *especially* when there are ways > to mitigate some of known deficiencies in a way that don't boil down > to "try to use a newer random version of what we sold you last year as > the best thing since sliced bread". Defence in depth. You should deploy those other mitigations, like the firewall. But ignoring or not receiving OS fixes is a critical problem. Then again, those computers would be vulnerable without Internet connection. Have you ever seen what happens if you drop a USB stick in a company's parking lot? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Aug 27 23:34:50 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Aug 2018 14:34:50 -0700 Subject: [Development] Windows 7 support future removal In-Reply-To: <20180827085046.GA3834@klara.mpi.htwm.de> References: <17474900.KWDFbFpmzP@tjmaciei-mobl1> <8086317.rBugRgWIOs@tjmaciei-mobl1> <20180827085046.GA3834@klara.mpi.htwm.de> Message-ID: <3114410.Jl4yWPMlei@tjmaciei-mobl1> On Monday, 27 August 2018 01:50:46 PDT André Pönitz wrote: > On Mon, Aug 27, 2018 at 12:00:17AM -0700, Thiago Macieira wrote: > > I don't have a problem with that, so long as they never connect those > > computers to the Internet after January 2020. That would be irresponsible. > > Because of what? Because it's not receiving security updates. > Because Microsoft (or any OS vendor that's on the "newer is better" trip > for that matter) have scheduled the invention of the magic sauce that makes > their systems suddenly safe to use in public networks for December 2019? No, that sauce is already known. It's called "security updates" and they have to be applied on a continuous basis. You may not need to apply all fixes, but you need to have the ability to do so when there's a fix that is relevant to you. Starting in January 2020, the only company that could make those fixes will stop making them. It is unlikely that the next day will start with a new vulnerability discovered, but one will be sooner or later. And since no fix will ever be coming, those devices will be forever vulnerable. Sure, there are other ways to mitigate the problem, like having an external firewall. But all it takes is another device also vulnerable on that network to allow access in and now those out-of-date Windows are accessible. > "Realistically" (a term I colloquially use for "extrapolating from a number > of incidents in the past") we will see trading semi-working systems with a > certain number of known and an uncertain number of unknown deficiencies for > other systems with another uncertain number of the same of other, newer > unknown deficiencies. Right. But worse than that, you have an unknown number of devices with *known* deficiencies. > This might look like an advantage to some, but it isn't in any metrics > that I am tempted to take seriously - *especially* when there are ways > to mitigate some of known deficiencies in a way that don't boil down > to "try to use a newer random version of what we sold you last year as > the best thing since sliced bread". Defence in depth. You should deploy those other mitigations, like the firewall. But ignoring or not receiving OS fixes is a critical problem. Then again, those computers would be vulnerable without Internet connection. Have you ever seen what happens if you drop a USB stick in a company's parking lot? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Aug 27 23:34:50 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Aug 2018 14:34:50 -0700 Subject: [Development] Windows 7 support future removal In-Reply-To: <20180827085046.GA3834@klara.mpi.htwm.de> References: <17474900.KWDFbFpmzP@tjmaciei-mobl1> <8086317.rBugRgWIOs@tjmaciei-mobl1> <20180827085046.GA3834@klara.mpi.htwm.de> Message-ID: <3114410.Jl4yWPMlei@tjmaciei-mobl1> On Monday, 27 August 2018 01:50:46 PDT André Pönitz wrote: > On Mon, Aug 27, 2018 at 12:00:17AM -0700, Thiago Macieira wrote: > > I don't have a problem with that, so long as they never connect those > > computers to the Internet after January 2020. That would be irresponsible. > > Because of what? Because it's not receiving security updates. > Because Microsoft (or any OS vendor that's on the "newer is better" trip > for that matter) have scheduled the invention of the magic sauce that makes > their systems suddenly safe to use in public networks for December 2019? No, that sauce is already known. It's called "security updates" and they have to be applied on a continuous basis. You may not need to apply all fixes, but you need to have the ability to do so when there's a fix that is relevant to you. Starting in January 2020, the only company that could make those fixes will stop making them. It is unlikely that the next day will start with a new vulnerability discovered, but one will be sooner or later. And since no fix will ever be coming, those devices will be forever vulnerable. Sure, there are other ways to mitigate the problem, like having an external firewall. But all it takes is another device also vulnerable on that network to allow access in and now those out-of-date Windows are accessible. > "Realistically" (a term I colloquially use for "extrapolating from a number > of incidents in the past") we will see trading semi-working systems with a > certain number of known and an uncertain number of unknown deficiencies for > other systems with another uncertain number of the same of other, newer > unknown deficiencies. Right. But worse than that, you have an unknown number of devices with *known* deficiencies. > This might look like an advantage to some, but it isn't in any metrics > that I am tempted to take seriously - *especially* when there are ways > to mitigate some of known deficiencies in a way that don't boil down > to "try to use a newer random version of what we sold you last year as > the best thing since sliced bread". Defence in depth. You should deploy those other mitigations, like the firewall. But ignoring or not receiving OS fixes is a critical problem. Then again, those computers would be vulnerable without Internet connection. Have you ever seen what happens if you drop a USB stick in a company's parking lot? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Aug 27 23:34:50 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Aug 2018 14:34:50 -0700 Subject: [Development] Windows 7 support future removal In-Reply-To: <20180827085046.GA3834@klara.mpi.htwm.de> References: <17474900.KWDFbFpmzP@tjmaciei-mobl1> <8086317.rBugRgWIOs@tjmaciei-mobl1> <20180827085046.GA3834@klara.mpi.htwm.de> Message-ID: <3114410.Jl4yWPMlei@tjmaciei-mobl1> On Monday, 27 August 2018 01:50:46 PDT André Pönitz wrote: > On Mon, Aug 27, 2018 at 12:00:17AM -0700, Thiago Macieira wrote: > > I don't have a problem with that, so long as they never connect those > > computers to the Internet after January 2020. That would be irresponsible. > > Because of what? Because it's not receiving security updates. > Because Microsoft (or any OS vendor that's on the "newer is better" trip > for that matter) have scheduled the invention of the magic sauce that makes > their systems suddenly safe to use in public networks for December 2019? No, that sauce is already known. It's called "security updates" and they have to be applied on a continuous basis. You may not need to apply all fixes, but you need to have the ability to do so when there's a fix that is relevant to you. Starting in January 2020, the only company that could make those fixes will stop making them. It is unlikely that the next day will start with a new vulnerability discovered, but one will be sooner or later. And since no fix will ever be coming, those devices will be forever vulnerable. Sure, there are other ways to mitigate the problem, like having an external firewall. But all it takes is another device also vulnerable on that network to allow access in and now those out-of-date Windows are accessible. > "Realistically" (a term I colloquially use for "extrapolating from a number > of incidents in the past") we will see trading semi-working systems with a > certain number of known and an uncertain number of unknown deficiencies for > other systems with another uncertain number of the same of other, newer > unknown deficiencies. Right. But worse than that, you have an unknown number of devices with *known* deficiencies. > This might look like an advantage to some, but it isn't in any metrics > that I am tempted to take seriously - *especially* when there are ways > to mitigate some of known deficiencies in a way that don't boil down > to "try to use a newer random version of what we sold you last year as > the best thing since sliced bread". Defence in depth. You should deploy those other mitigations, like the firewall. But ignoring or not receiving OS fixes is a critical problem. Then again, those computers would be vulnerable without Internet connection. Have you ever seen what happens if you drop a USB stick in a company's parking lot? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Tue Aug 28 01:50:43 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Mon, 27 Aug 2018 20:50:43 -0300 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: References: <1744013.hO7IBvXSqR@tjmaciei-mobl1> Message-ID: <3221739.PSJ9CCBiuE@tonks> El domingo, 26 de agosto de 2018 20:12:51 -03 Kevin Kofler escribió: > Thiago Macieira wrote: > > Also note that QML files are usually cross-platform too and could be > > shared. Any non-cross-platform QML file should be selected by the source > > via QFileSelector. Plugins, however, are arch-dependent and should live in > > an arch-dependent dir. That would mean splitting the "qml" dir in two: > > > > /lib/qml > > /share/qml > > > > I don't see us spending the effort... > > That would also help multilib GNU/Linux distributions though, because right > now we have to treat all QML-only packages as arch-specific just because of > the installation path. Having the QML files themselves in /usr/share would > allow us to make those packages noarch. That's right, it will allow less disk usage for sure. But I don't know up to which point is a "nice to have" feature or something that would really decrease disk usage. It is not strange to have more than one arch headers installed if cross compiling, but QML packages are, and please correct me if I'm wrong, only needed at run/develop time, but not while building. But again, it would be nice to have it for sure. -- I must confess, I was born at a very early age. -- Groucho Marx Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Tue Aug 28 04:59:22 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Aug 2018 19:59:22 -0700 Subject: [Development] Qt 6 buildsystem support requirements In-Reply-To: <3221739.PSJ9CCBiuE@tonks> References: <3221739.PSJ9CCBiuE@tonks> Message-ID: <2862328.DLPtTz4sUM@tjmaciei-mobl1> On Monday, 27 August 2018 16:50:43 PDT Lisandro Damián Nicanor Pérez Meyer wrote: > That's right, it will allow less disk usage for sure. But I don't know up to > which point is a "nice to have" feature or something that would really > decrease disk usage. Strictly speaking, it would be no worse. In the worst case scenario (single architecture), it would occupy exactly as much space as it does now. The question is whether it's worth to implement it. QML plugins usually aren't big. I expect the savings to be minimal. So we should implement this only if it isn't too difficult to do so. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From coroberti at gmail.com Tue Aug 28 07:59:23 2018 From: coroberti at gmail.com (coroberti .) Date: Tue, 28 Aug 2018 08:59:23 +0300 Subject: [Development] Windows 7 support future removal In-Reply-To: <3114410.Jl4yWPMlei@tjmaciei-mobl1> References: <17474900.KWDFbFpmzP@tjmaciei-mobl1> <8086317.rBugRgWIOs@tjmaciei-mobl1> <20180827085046.GA3834@klara.mpi.htwm.de> <3114410.Jl4yWPMlei@tjmaciei-mobl1> Message-ID: On Tue, Aug 28, 2018 at 12:34 AM, Thiago Macieira wrote: > On Monday, 27 August 2018 01:50:46 PDT André Pönitz wrote: >> On Mon, Aug 27, 2018 at 12:00:17AM -0700, Thiago Macieira wrote: >> > I don't have a problem with that, so long as they never connect those >> > computers to the Internet after January 2020. That would be irresponsible. >> >> Because of what? > > Because it's not receiving security updates. > >> Because Microsoft (or any OS vendor that's on the "newer is better" trip >> for that matter) have scheduled the invention of the magic sauce that makes >> their systems suddenly safe to use in public networks for December 2019? > > No, that sauce is already known. It's called "security updates" and they have > to be applied on a continuous basis. You may not need to apply all fixes, but > you need to have the ability to do so when there's a fix that is relevant to > you. > > Starting in January 2020, the only company that could make those fixes will > stop making them. It is unlikely that the next day will start with a new > vulnerability discovered, but one will be sooner or later. And since no fix > will ever be coming, those devices will be forever vulnerable. > > Sure, there are other ways to mitigate the problem, like having an external > firewall. But all it takes is another device also vulnerable on that network > to allow access in and now those out-of-date Windows are accessible. > >> "Realistically" (a term I colloquially use for "extrapolating from a number >> of incidents in the past") we will see trading semi-working systems with a >> certain number of known and an uncertain number of unknown deficiencies for >> other systems with another uncertain number of the same of other, newer >> unknown deficiencies. > > Right. But worse than that, you have an unknown number of devices with *known* > deficiencies. > >> This might look like an advantage to some, but it isn't in any metrics >> that I am tempted to take seriously - *especially* when there are ways >> to mitigate some of known deficiencies in a way that don't boil down >> to "try to use a newer random version of what we sold you last year as >> the best thing since sliced bread". > > Defence in depth. You should deploy those other mitigations, like the > firewall. But ignoring or not receiving OS fixes is a critical problem. > > Then again, those computers would be vulnerable without Internet connection. > Have you ever seen what happens if you drop a USB stick in a company's parking > lot? This is not the case with many enterprises, finance, medical, military, banking and even local governments etc. where mounting of an external storage, CD/DVD or downloading is not an option or should pass IT people with a detailed examination of each file or package. In such well controlled and managed environments, you can find enough computers which are still using old systems like Win2000 and XP. Due to the mentioned issues with Win-10, which was not the case with Win-7, my bet is that Win-7 will have a lifetime of about 10 years with a good share still remaining but may be obscured from statistics since not seen over open Internet. jm4c to add. Kind regards, Robert From jani.heikkinen at qt.io Tue Aug 28 09:33:44 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 28 Aug 2018 07:33:44 +0000 Subject: [Development] HEADS UP: Branching from '5.11' to '5.11.2' ready Message-ID: Hi all, Branching from '5.11' to '5.11.2' is now done and all changes for Qt 5.11.2 must be done in '5.11.2' from now on. And as usual in release branches: No any nice-to-haves in anymore! br, Jani > -----Original Message----- > From: Development project.org> On Behalf Of Jani Heikkinen > Sent: perjantai 17. elokuuta 2018 18.19 > To: development at qt-project.org > Subject: [Development] HEADS UP: Branching from '5.11' to '5.11.2' started > > Hi, > > We have soft branched '5.11.2' from '5.11' today. Target is to finalize > branching Fri 24th August 2018. So please finalize ongoing changes in '5.11' > and start using '5.11.2' for new changes targeted to Qt 5.11.2 release > > br, > Jani > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Tue Aug 28 13:53:21 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 28 Aug 2018 11:53:21 +0000 Subject: [Development] Qt 5.11.2 changes files: Maintainers, Your action needed Message-ID: Hi, Initial ones here: https://codereview.qt-project.org/#/q/branch:5.11.2+message:%22Add+changes+file+for+Qt+5.11.2%22,n,z Please take over and finalize those as soon as possible (during this week latest) br, Jani From jc.fernandez.navarro.lists at gmail.com Tue Aug 28 15:09:08 2018 From: jc.fernandez.navarro.lists at gmail.com (Jose Fernandez Navarro) Date: Tue, 28 Aug 2018 15:09:08 +0200 Subject: [Development] Scatter plots (individual colours) Message-ID: <4E52093F-3705-4E87-A8E4-25B745A01B4B@gmail.com> Hello Qt developers, I am wondering if there are plans to make QtDataVisualization and QtCharts support individual colours/values for the data items. I am very grateful to Qt and its developers but with all my respect providing a data visualisation library that does not support assignation of individual colours/values for the data points and conversely having colour scales makes the library very limited for real scenarios. One could create multiple series as a hack but this becomes unfeasible when the number of colours is high. Of course, one can use QOpenGLWidget or Qt3D to build customise visualisations but I believe these features are pretty much a must for visualisation libraries (specially scatter plots). Thanks to the community for an excellent work maintaining and improving Qt. ps: hope I am not using the wrong mail list :) Best, Jose From tony.sarajarvi at qt.io Wed Aug 29 10:41:13 2018 From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=) Date: Wed, 29 Aug 2018 08:41:13 +0000 Subject: [Development] Coin momentarily down Message-ID: Hi We have a small glitch in the CI currently. We keep spawning VMs like crazy. The CI is down for a while as we figure out why and clean up the mess. Shouldn’t take more than say 30 minutes…. shouldn’t 😉 -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Wed Aug 29 11:39:24 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Wed, 29 Aug 2018 12:39:24 +0300 Subject: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration Message-ID: Hi all. I have an Apalis iMX6 board with the Yocto's image with the working 'eglfs' and 'linuxfb' backends (without of X11 support). I need to create a 'pure' QtWidgets application, where I need to use a real-time plotting with the Qwt library (using the Qt Quick is not an option, as there the QtCharts is not ready for usage) . But, I'm sadly surprised that a 2D painting takes ~100% CPU loading as with the 'eglfs' and as with 'linuxfb' backends. It is not an acceptable, because, e.g. on Desktop Linux/Windows it takes ~4-5% CPU loading. Is any workarounds for this? Maybe I need to re-build the Yocto's image to enable the X11 'xcb' support? BR, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at qt.io Wed Aug 29 12:06:57 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Wed, 29 Aug 2018 10:06:57 +0000 Subject: [Development] HEADS-UP: Branching from 'dev' to '5.12' completed In-Reply-To: References: <317DB931-DFA0-4562-9700-719C701922EB@qt.io> Message-ID: <046C68F7-48C5-4346-ACDA-83A7CF87A857@qt.io> Hi, I would like to remind about the API review. Some modules are already nicely progressing (or even completed), but there are also some that are not yet even started. Despite Alpha being slightly delayed due to the needed fixes, we hopefully can catch up and release Beta 1 around the originally planned schedule. Yours, Tuukka On 21/08/2018, 19.50, "Edward Welbourne" wrote: Jani Heikkinen (21/08/2018, 11.04) wrote: > Branching from 'dev' to '5.12' is now complete and Qt 5.12 Feature Freeze is in effect. So now it is time for the API review. Find your favourite module on: https://codereview.qt-project.org/#/q/status:open+branch:5.12+topic:api-review,n,z Track the review in: http://bugreports.qt.io/browse/QTBUG-70094 Any issues you raise in review should, per [QUIP 10], be reported as bugs that block both QTBUG-70094 and the release. * [QUIP 10] https://quips-qt-io.herokuapp.com/quip-0010-API-review.html Eddy. From denis.shienkov at gmail.com Wed Aug 29 12:21:18 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Wed, 29 Aug 2018 13:21:18 +0300 Subject: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration In-Reply-To: References: Message-ID: I even have created a simple test app, which re-fill the 1280x800 rect every 50 msec with the 'red' and 'green' colors. [code] #include #include #include #include class Widget final : public QWidget { public: explicit Widget(QWidget *parent = nullptr); private: void paintEvent(QPaintEvent *event) final; void timerEvent(QTimerEvent *event) final; }; Widget::Widget(QWidget *parent) : QWidget(parent) { startTimer(50); } void Widget::paintEvent(QPaintEvent *event) { QPainter p(this); static bool toggled = false; const auto color = (toggled) ? QColor(Qt::red) : QColor(Qt::green); const auto rect = event->rect(); p.fillRect(rect, color); toggled = !toggled; } void Widget::timerEvent(QTimerEvent *event) { Q_UNUSED(event); update(); } int main(int argc, char *argv[]) { QApplication app(argc, argv); Widget w; w.setMinimumSize(1280, 800); w.show(); return app.exec(); } [/code] And then I see that the Desktop PC has the ~0% CPU load, but the iMX6 has ~50% CPU load. WTF? BR, Denis ср, 29 авг. 2018 г. в 12:39, Denis Shienkov : > Hi all. > > I have an Apalis iMX6 board with the Yocto's image with the working > 'eglfs' and 'linuxfb' backends (without of X11 support). > > I need to create a 'pure' QtWidgets application, where I need to use a > real-time plotting with the Qwt library (using the Qt Quick is not an > option, as there the QtCharts is not ready for usage) . > > But, I'm sadly surprised that a 2D painting takes ~100% CPU loading as > with the 'eglfs' and as with 'linuxfb' backends. It is not an acceptable, > because, e.g. on Desktop Linux/Windows it takes ~4-5% CPU loading. > > Is any workarounds for this? Maybe I need to re-build the Yocto's image to > enable the X11 'xcb' support? > > BR, > Denis > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Wed Aug 29 14:30:33 2018 From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=) Date: Wed, 29 Aug 2018 12:30:33 +0000 Subject: [Development] QT infra weekly report In-Reply-To: <5CB4A22F97CED74D94F954BE9601E77C6F306E@office-exbe-02.office.nbl.fi> References: <5CB4A22F97CED74D94F954BE9601E77C6F306E@office-exbe-02.office.nbl.fi> Message-ID: Hi We’ve decided to start sharing a bit more information about the state of our infra and what we’re up to. This will be a brief e-mail that will cover the main topics. State of the CI - We've been running 2 weeks now with a stable kernel. The hosts have actually been up without reboots now for 2 weeks, which must be a record for us. This means, we won't be touching them now as they work. Update of OpenNebula - 5.6 has been installed. Scripting it will require still some work, as the same deployment procedure doesn’t work right of the bat. Will be tested in the dev environment. Update of CI hosts to Ubuntu 18.04 and upgrade MAAS - Current MAAS version doesn't support Ubuntu 18.04, so we need to update MAAS. - A newer version of MAAS requires it to run on Ubuntu 18.04. So we need to update the host of MAAS as well (no chicken and the egg problem here). - This all lead us to need a dev/sandbox environment with all new VLAN tags. That's done now and we can now test everything before breaking production (again). - One host has been allocated into the dev environment (So CI is down one from 33 we have in total) Mac hardware in the CI - Currently OpenNebula doesn’t have Mac hardware attached to it. A Mac Pro could be attached to it for testing, but we don’t have a PDU (power distribution unit) for it yet. This needs some further planning what we really want to do with these. Our packet loss situation - We’ve had problems with odd packet loss. We suspected that our firewall was to blame, and surely it hit high peaks in load. - QoS was disabled, as manufacturer told us it will increase load on the firewall by 20-50% - Packet loss was reduced from 5-8% down to 0.5%. - If we can pin point the culprit of the remaining 0.5% to be the firewall, we might get a budget to replace those firewalls ASAP (work ongoing). Our Blade infrastructure is going to have a backup Blade allocated to the pool currently running our infra. It needed more RAM however, and the order has been placed. Coin’s server will be allocated terabytes of disk space from the Compellent to cope with vast amount of builds produced by product repo development. This became an issue as the Compellent is getting quite full, so we’re currently dumping old pre Qt 5.6 images into USB drives for disposal (read: storage). You might have seen issues with Licenses in the INTEGRITY builds. These have now been resolved, but if you see more of these or have any license related questions, contact mailto:it.helpdesk at qt.io and CC andrey.leman at qt.io who takes care of them and mailto:qt.ci at qt.io (that’s us) as well. Naturally we keep an eye on builds as well, but quite often is the case such that people staging the commits see the problem right after the failure and not the next time we glance Coin's front page. This first e-mail had some longer back stories attached to the points above. In the future I'll try to be more brief, as you all will know the back stories from this e-mail 😊 -Tony ---- Click _here_ if you wish to unsubscribe. From tony.sarajarvi at qt.io Wed Aug 29 14:48:14 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Wed, 29 Aug 2018 12:48:14 +0000 Subject: [Development] Recall: QT infra weekly report Message-ID: Tony Sarajärvi would like to recall the message, "QT infra weekly report". From drwho at infidigm.net Wed Aug 29 14:51:36 2018 From: drwho at infidigm.net (drwho) Date: Wed, 29 Aug 2018 08:51:36 -0400 Subject: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration In-Reply-To: References: Message-ID: <31796296-c20a-a5b5-a2de-a03850a32310@infidigm.net> Hi Denis, Most Qt widgets are not drawn using opengl but instead are rasterized.  I was surprised when I first learned this as well. "QPainter provides API for drawing vector graphics, text and images onto different surfaces, or QPaintDevice instances, such as QImage , QOpenGLPaintDevice , QWidget , and QPrinter . The actual drawing happens in the QPaintDevice 's QPaintEngine . The software rasterizer and the OpenGL (ES) 2.0 back-ends are the two most important QPaintEngine implementations. *The raster paint engine is Qt’s software rasterizer, and is used when drawing on a QImage or QWidget .* Its strength over the OpenGL paint engine is its high quality when antialiasing is enabled, and a complete feature set.” On 29/08/18 06:21 AM, Denis Shienkov wrote: > I even have created a simple test app, which re-fill the 1280x800 rect > every 50 msec with the 'red' and 'green' colors. > > [code] > #include > #include > #include > #include > classWidgetfinal:publicQWidget > { > public: > explicitWidget(QWidget*parent=nullptr); > private: > voidpaintEvent(QPaintEvent*event)final; > voidtimerEvent(QTimerEvent*event)final; > }; > Widget::Widget(QWidget*parent) > :QWidget(parent) > { > startTimer(50); > } > voidWidget::paintEvent(QPaintEvent*event) > { > QPainterp(this); > staticbooltoggled=false; > constautocolor=(toggled)?QColor(Qt::red):QColor(Qt::green); > constautorect=event->rect(); > p.fillRect(rect,color); > toggled=!toggled; > } > voidWidget::timerEvent(QTimerEvent*event) > { > Q_UNUSED(event); > update(); > } > intmain(intargc,char*argv[]) > { > QApplicationapp(argc,argv); > Widgetw; > w.setMinimumSize(1280,800); > w.show(); > returnapp.exec(); > } > [/code] > > And then I see that the Desktop PC has the ~0% CPU load, but the iMX6 > has ~50% CPU load. WTF? > > BR, > Denis > > > > ср, 29 авг. 2018 г. в 12:39, Denis Shienkov >: > > Hi all. > > I have an Apalis iMX6 board with the Yocto's image with the > working 'eglfs' and 'linuxfb'  backends (without of X11 support). > > I need to create a 'pure' QtWidgets application, where I need to > use a real-time plotting with the Qwt library (using the Qt Quick > is not an option, as there the QtCharts is not ready for usage) . > > But, I'm sadly surprised that a 2D painting takes ~100% CPU > loading as with the 'eglfs' and as with 'linuxfb' backends. It is > not an acceptable, because, e.g. on Desktop Linux/Windows it takes > ~4-5% CPU loading. > > Is any workarounds for this? Maybe I need to re-build the Yocto's > image to enable the X11 'xcb' support? > > BR, > Denis > > > > > _______________________________________________ > 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 denis.shienkov at gmail.com Wed Aug 29 15:43:40 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Wed, 29 Aug 2018 16:43:40 +0300 Subject: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration In-Reply-To: <31796296-c20a-a5b5-a2de-a03850a32310@infidigm.net> References: <31796296-c20a-a5b5-a2de-a03850a32310@infidigm.net> Message-ID: > Most Qt widgets are not drawn using opengl but instead are rasterized. I was surprised when I first learned this as well. So, there are no way to improve an acceleration and to minimize the CPU loading? PS: I tried to mix the OpenGL widgets with usual widgets, but the 'eglfs' says that it is impossible to mix it. This is some sort of hopeless situation. ((( BR, Denis ср, 29 авг. 2018 г. в 15:51, drwho : > Hi Denis, > > Most Qt widgets are not drawn using opengl but instead are rasterized. I > was surprised when I first learned this as well. > "QPainter > provides API for drawing vector > graphics, text and images onto different surfaces, or QPaintDevice > > instances, such as QImage > , > QOpenGLPaintDevice > > , QWidget > , > and QPrinter > . The actual drawing happens in the > QPaintDevice > 's QPaintEngine > > . The software rasterizer and > the OpenGL (ES) 2.0 back-ends are the two most important QPaintEngine > > implementations. *The raster > paint engine is Qt’s software rasterizer, and is used when drawing on a > QImage > or QWidget > .* > Its strength over the OpenGL paint engine is its high quality when > antialiasing is enabled, and a complete feature set.” > > > On 29/08/18 06:21 AM, Denis Shienkov wrote: > > I even have created a simple test app, which re-fill the 1280x800 rect > every 50 msec with the 'red' and 'green' colors. > > [code] > > #include > > #include > > #include > > #include > > class Widget final : public QWidget > > { > > public: > > explicit Widget(QWidget *parent = nullptr); > > private: > > void paintEvent(QPaintEvent *event) final; > > void timerEvent(QTimerEvent *event) final; > > }; > > Widget::Widget(QWidget *parent) > > : QWidget(parent) > > { > > startTimer(50); > > } > > void Widget::paintEvent(QPaintEvent *event) > > { > > QPainter p(this); > > static bool toggled = false; > > const auto color = (toggled) ? QColor(Qt::red) : QColor(Qt::green); > > const auto rect = event->rect(); > > p.fillRect(rect, color); > > toggled = !toggled; > > } > > void Widget::timerEvent(QTimerEvent *event) > > { > > Q_UNUSED(event); > > update(); > > } > > int main(int argc, char *argv[]) > > { > > QApplication app(argc, argv); > > Widget w; > > w.setMinimumSize(1280, 800); > > w.show(); > > return app.exec(); > > } > > [/code] > > And then I see that the Desktop PC has the ~0% CPU load, but the iMX6 has > ~50% CPU load. WTF? > > BR, > Denis > > > > ср, 29 авг. 2018 г. в 12:39, Denis Shienkov : > >> Hi all. >> >> I have an Apalis iMX6 board with the Yocto's image with the working >> 'eglfs' and 'linuxfb' backends (without of X11 support). >> >> I need to create a 'pure' QtWidgets application, where I need to use a >> real-time plotting with the Qwt library (using the Qt Quick is not an >> option, as there the QtCharts is not ready for usage) . >> >> But, I'm sadly surprised that a 2D painting takes ~100% CPU loading as >> with the 'eglfs' and as with 'linuxfb' backends. It is not an acceptable, >> because, e.g. on Desktop Linux/Windows it takes ~4-5% CPU loading. >> >> Is any workarounds for this? Maybe I need to re-build the Yocto's image >> to enable the X11 'xcb' support? >> >> BR, >> Denis >> >> >> > > _______________________________________________ > Development mailing listDevelopment at qt-project.orghttp://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 thiago.macieira at intel.com Wed Aug 29 17:18:15 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 29 Aug 2018 08:18:15 -0700 Subject: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration In-Reply-To: References: <31796296-c20a-a5b5-a2de-a03850a32310@infidigm.net> Message-ID: <3195532.vKb54qRvdY@tjmaciei-mobl1> On Wednesday, 29 August 2018 06:43:40 PDT Denis Shienkov wrote: > > Most Qt widgets are not drawn using opengl but instead are rasterized. I > > was surprised when I first learned this as well. > > So, there are no way to improve an acceleration and to minimize the CPU > loading? Rewrite using techniques and classes that are accelerated using OpenGL. Like QtQuick. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From vladstelmahovsky at gmail.com Wed Aug 29 17:56:08 2018 From: vladstelmahovsky at gmail.com (Vlad Stelmahovsky) Date: Wed, 29 Aug 2018 17:56:08 +0200 Subject: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration In-Reply-To: References: Message-ID: <7ec68df1-6807-33fb-edc6-854c6e01ae5f@gmail.com> have you tried QOpenGlWidget ? otherwise you dont have other options: plain QWidget's does not HW accelerated or, you can extend QtCharts to be more QtQuicker and more featured. everyone will be happy :) On 8/29/18 11:39 AM, Denis Shienkov wrote: > Hi all. > > I have an Apalis iMX6 board with the Yocto's image with the working > 'eglfs' and 'linuxfb'  backends (without of X11 support). > > I need to create a 'pure' QtWidgets application, where I need to use a > real-time plotting with the Qwt library (using the Qt Quick is not an > option, as there the QtCharts is not ready for usage) . > > But, I'm sadly surprised that a 2D painting takes ~100% CPU loading as > with the 'eglfs' and as with 'linuxfb' backends. It is not an > acceptable, because, e.g. on Desktop Linux/Windows it takes ~4-5% CPU > loading. > > Is any workarounds for this? Maybe I need to re-build the Yocto's > image to enable the X11 'xcb' support? > > BR, > Denis > > > > _______________________________________________ > 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 denis.shienkov at gmail.com Wed Aug 29 19:49:20 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Wed, 29 Aug 2018 20:49:20 +0300 Subject: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration In-Reply-To: <7ec68df1-6807-33fb-edc6-854c6e01ae5f@gmail.com> References: <7ec68df1-6807-33fb-edc6-854c6e01ae5f@gmail.com> Message-ID: <111faef3-94e4-fb09-5da3-a65aaf496e39@gmail.com> Hi, > have you tried QOpenGlWidget ? It does not work together (can't be mixed) with an usual QtWidgets using the 'eglfs' backend. > QtCharts to be more QtQuicker and more featured As I see from the QtCharts sources, it also renders via QGraphicsScene && QGraphicsWidget even in QtQuick. 29.08.2018 18:56, Vlad Stelmahovsky пишет: > > have you tried QOpenGlWidget ? > > otherwise you dont have other options: plain QWidget's does not HW > accelerated > > or, you can extend QtCharts to be more QtQuicker and more featured. > everyone will be happy :) > > On 8/29/18 11:39 AM, Denis Shienkov wrote: >> Hi all. >> >> I have an Apalis iMX6 board with the Yocto's image with the working >> 'eglfs' and 'linuxfb'  backends (without of X11 support). >> >> I need to create a 'pure' QtWidgets application, where I need to use >> a real-time plotting with the Qwt library (using the Qt Quick is not >> an option, as there the QtCharts is not ready for usage) . >> >> But, I'm sadly surprised that a 2D painting takes ~100% CPU loading >> as with the 'eglfs' and as with 'linuxfb' backends. It is not an >> acceptable, because, e.g. on Desktop Linux/Windows it takes ~4-5% CPU >> loading. >> >> Is any workarounds for this? Maybe I need to re-build the Yocto's >> image to enable the X11 'xcb' support? >> >> BR, >> Denis >> >> >> >> _______________________________________________ >> 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 robert.loehning at qt.io Wed Aug 29 20:17:52 2018 From: robert.loehning at qt.io (=?UTF-8?Q?Robert_L=c3=b6hning?=) Date: Wed, 29 Aug 2018 20:17:52 +0200 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <2317435.y4KJu3U8PQ@frederik-thinkcentre-m93p> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> <2317435.y4KJu3U8PQ@frederik-thinkcentre-m93p> Message-ID: Am 22.08.2018 um 10:53 schrieb Frederik Gladhorn: > Quick status update from my side: > I have the script running against a test installation of JIRA. It seems to > work, there are some small issues to be worked out still. > > - Qt Creator version numbers are verbose, so I need to be more generous in > matching strings, right now I don't detect the version number correctly there. > This one I will fix, it's just going to take a few minutes. > > - Qt 3D Studio seems to be a mess, it has 5.x branches but the JIRA versions > are 2.x, I consider this a won't fix. > > I'd love if people started using "Fixes:", it will work retro-actively. And if > you manually close a task in the meantime, no harm is done. Looks like somebody should tell the sanity bot: https://codereview.qt-project.org/#/c/238280/1//COMMIT_MSG Cheers, Robert > > Multiple fix versions: > There were some doubts about which fix versions would be set, for example > during the down-merge. This actually turns out to work quite nicely: > If a change ends up in dev, the script will detect that it will end up in > 5.13.0 right now and sets that as fix version. If the downmerge happens, the > script will see the change again in 5.12.0 and add that fix version. In my > opinion there is no major harm. > If the change is then cherry-picked to 5.9.7, it will also add that fix > version. > > This also means that changes going into 5.11.4 will be marked as fixed in > 5.12.1 or whatever is applicable branch/version wise. So we will actually set > fix versions nicely. > > There are some fixes in JIRA that would be easy to make, assuming there is > agreement. Since I have to use some heuristics, I decided to only ever look at > full version numbers, including patch level releases. > Currently we have version numbers in JIRA which do not make much sense to me, > since they will never be released, such as 6.0, 5.12 and a few more. I would > propose we always use the full version, so 6.0.0 and 5.12.0. > If the script finds 5.13 but not 5.13.0 it will not set any fix version. > > I'm unsure where the whole thing should live, currently it's internal to The > Qt Company, I'd love to publish it somewhere (it's a bunch of python files). > > Cheers, > Frederik > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From Uwe.Rathmann at tigertal.de Thu Aug 30 09:44:21 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Thu, 30 Aug 2018 07:44:21 +0000 (UTC) Subject: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration References: <31796296-c20a-a5b5-a2de-a03850a32310@infidigm.net> Message-ID: On Wed, 29 Aug 2018 16:43:40 +0300, Denis Shienkov wrote: > So, there are no way to improve an acceleration and to minimize the CPU > loading? It depends on the requirements of your application, but when it comes to oscilloscope alike widgets your best choice is Qt4/X11. The X11 paint engine is hardware accelerated, it even allows painting outside of paint events - what is important for incremental painting. ( The fact, that Qt 4.8 prefers using raster with the argument of performance it is totally nonsense, when it comes to any sort of vector graphics. ) Furthermore the X11 paint engine simply has a better quality. The sort of bugs coming and going with the various Qt versions is a nightmare for any sort of graphics framework. Actually my job for today is to find a work around for this one: https://bugreports.qt.io/browse/QTBUG-70101 -- If you need to go with Qt5 I would recommend to use a platform that allows for using QOpenGlWidget - X11 again is IMHO not a bad choice. Actually one of our terminals is a iMX6, where we do this ( because we needed VNC support ). Next I recommend Qwt from SVN trunk, where you can simply assign a QwtPlotOpenGLCanvas to achieve hardware acceleration. The quality of the OpenGL paint engine is not as good as X11 or Raster, but for a oscilloscope things usually do not need to be pixel perfect. -- Finally you should not ignore algorithmic options to reduce what has to be painted. How to optimize the rendering process is often quite individual, but often QwtPlotCurve::FilterPointsAggressive ( since Qwt 6.2 ) has a significant effect in oscilloscope alike applications. In fact I have been contacted quite often with oscilloscope applications struggling with performance issues and often it could be solved on a algorithmic level. As an inspiration you could also try to run the oscilloscope demo of Qwt on your board. You will notice, that it runs with almost no CPU usage because it mostly paints incrementally. Of course this only works because the design of the user interface is made for this, but maybe you can do something similar. Uwe From Shawn.Rutledge at qt.io Thu Aug 30 13:03:15 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Thu, 30 Aug 2018 11:03:15 +0000 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> <2317435.y4KJu3U8PQ@frederik-thinkcentre-m93p> Message-ID: <50B23DD5-D665-4BD1-AA3B-351A3ACDC6DA@qt.io> > On 29 Aug 2018, at 20:17, Robert Löhning wrote: > > Am 22.08.2018 um 10:53 schrieb Frederik Gladhorn: >> Quick status update from my side: >> I have the script running against a test installation of JIRA. It seems to >> work, there are some small issues to be worked out still. >> >> - Qt Creator version numbers are verbose, so I need to be more generous in >> matching strings, right now I don't detect the version number correctly there. >> This one I will fix, it's just going to take a few minutes. >> >> - Qt 3D Studio seems to be a mess, it has 5.x branches but the JIRA versions >> are 2.x, I consider this a won't fix. >> >> I'd love if people started using "Fixes:", it will work retro-actively. And if >> you manually close a task in the meantime, no harm is done. > > Looks like somebody should tell the sanity bot: > https://codereview.qt-project.org/#/c/238280/1//COMMIT_MSG > > Cheers, > Robert Yes. Also Jira should ideally start showing the patch alongside the bug, as in https://bugreports.qt.io/browse/QTCREATORBUG-20991 From denis.shienkov at gmail.com Thu Aug 30 13:26:34 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Thu, 30 Aug 2018 14:26:34 +0300 Subject: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration In-Reply-To: References: <31796296-c20a-a5b5-a2de-a03850a32310@infidigm.net> Message-ID: Hi Uwe, many thanks for your help! :) Yeah, seems that Qt5 && X11 && 'xcb' backend with the Qwt 6.2 and QwtPlotOpenGLCanvas does help a bit. The iMX6 CPU usage now is ~50% (instead of previous 100%). PS: But compilation for latest Qwt version from trunk r2921 fails, please look on this my post: https://www.qtcentre.org/threads/69743-Qwt-6-3-0-(from-qwt-code-r2921-trunk)-compilation-fails-on-Ubuntu-18-04?p=303603#post303603 BR, Denis чт, 30 авг. 2018 г. в 10:46, Uwe Rathmann : > On Wed, 29 Aug 2018 16:43:40 +0300, Denis Shienkov wrote: > > > So, there are no way to improve an acceleration and to minimize the CPU > > loading? > > It depends on the requirements of your application, but when it comes to > oscilloscope alike widgets your best choice is Qt4/X11. > > The X11 paint engine is hardware accelerated, it even allows painting > outside of paint events - what is important for incremental painting. > > ( The fact, that Qt 4.8 prefers using raster with the argument of > performance it is totally nonsense, when it comes to any sort of vector > graphics. ) > > Furthermore the X11 paint engine simply has a better quality. The sort of > bugs coming and going with the various Qt versions is a nightmare for any > sort of graphics framework. Actually my job for today is to find a work > around for this one: https://bugreports.qt.io/browse/QTBUG-70101 > > -- > > If you need to go with Qt5 I would recommend to use a platform that > allows for using QOpenGlWidget - X11 again is IMHO not a bad choice. > Actually one of our terminals is a iMX6, where we do this ( because we > needed VNC support ). > > Next I recommend Qwt from SVN trunk, where you can simply assign a > QwtPlotOpenGLCanvas to achieve hardware acceleration. The quality of the > OpenGL paint engine is not as good as X11 or Raster, but for a > oscilloscope things usually do not need to be pixel perfect. > > -- > > Finally you should not ignore algorithmic options to reduce what has to > be painted. How to optimize the rendering process is often quite > individual, but often QwtPlotCurve::FilterPointsAggressive ( since Qwt > 6.2 ) has a significant effect in oscilloscope alike applications. > > In fact I have been contacted quite often with oscilloscope applications > struggling with performance issues and often it could be solved on a > algorithmic level. > > As an inspiration you could also try to run the oscilloscope demo of Qwt > on your board. You will notice, that it runs with almost no CPU usage > because it mostly paints incrementally. Of course this only works because > the design of the user interface is made for this, but maybe you can do > something similar. > > Uwe > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Uwe.Rathmann at tigertal.de Thu Aug 30 15:09:22 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Thu, 30 Aug 2018 13:09:22 +0000 (UTC) Subject: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration References: <31796296-c20a-a5b5-a2de-a03850a32310@infidigm.net> Message-ID: On Thu, 30 Aug 2018 14:26:34 +0300, Denis Shienkov wrote: > Yeah, seems that Qt5 && X11 && 'xcb' backend with the Qwt 6.2 and > QwtPlotOpenGLCanvas does help a bit. The iMX6 CPU usage now is ~50% > (instead of previous 100%). I have been attending one of the Qt roadshows last year in Munich. One of the speakers asked the audience which Qt versions they are using: I didn't have time to count them manually, but my rough estimation was that about 30% were still on Qt4. Assuming that almost all of them were Qt/Widgets users and there are others in the Qt5 groups I would guess that the majority was interested in Qt/Widget applications. Considering, that Qt/Quick Controls 1 has been given up it is fair to say that today the only reasonable option, Qt has to offer for desktop applications, is: Qt/Widgets. So to me there is an obvious mismatch between where the users are and what Qt development is working on. Concerning the future of Qt/Widgets I guess almost everyone wants to have hardware accelerated options - like what we had with Qt4/X11 or what could be done with OpenGL. The most recent related feature I'm aware of was introducing QOpenGLWidget with Qt 5.4. But combining QOpenGLWidget with standard QWidgets is unstable - see https://bugreports.qt.io/browse/QTBUG-50916 ). Furthermore nobody seems to be interested in working on the OpenGL paint engine. At least I have no explanation, why bugs like this one https:// bugreports.qt.io/browse/QTBUG-52672 are not being handled over years. ( actually this one is assigned to Gunnar, who is not even active anymore ). >From my experience with the QSkinny project I'm tempted to say that it would even be possible to implement the Qt/Widgets API on top of Qt/Quick core. Of course it wouldn't be exactly the same, but for standard desktop applications it should be possible to offer a migration path, that is not harder than what we had with Qt3 -> Qt4. Uwe From edward.welbourne at qt.io Thu Aug 30 15:27:40 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 30 Aug 2018 13:27:40 +0000 Subject: [Development] Orphan modules Message-ID: I notice, as part of seeking folk to look at API reviews, that we have several modules with no Maintainer: qtandroidextras, qtgraphicaleffects, qtmacextras, qtquick1, qtquickcontrols, qtsvg, qtwinextras and (the one that brought this to my attention) qtxmlpatterns, according to [0]. * [0] https://wiki.qt.io/Maintainers (There's also qtdoc, with no person as maintainer, but with "Norway" in the Country column, which I interpret as the doc-team here in Oslo; and there's qtfeedback, which is unsupported; two other unsupported modules do in fact have Maintainers.) If anyone out there feels an urge to volunteer to adopt one of these orphans, it'd be worth speaking up, Eddy. From Uwe.Rathmann at tigertal.de Thu Aug 30 15:52:15 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Thu, 30 Aug 2018 13:52:15 +0000 (UTC) Subject: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration References: <31796296-c20a-a5b5-a2de-a03850a32310@infidigm.net> Message-ID: On Thu, 30 Aug 2018 14:26:34 +0300, Denis Shienkov wrote: > Yeah, seems that Qt5 && X11 && 'xcb' backend with the Qwt 6.2 and > QwtPlotOpenGLCanvas does help a bit. The iMX6 CPU usage now is ~50% > (instead of previous 100%). A small correction for others reading this: trunk is Qwt 6.3. The main difference to the code you find in the 6.2 branch is exactly about the OpenGL canvases, where I need more time to find workarounds for the incompatibilities of the OpenGL paint engines. I also forgot to mention that Qwt from trunk also has the option QwtPlotCanvas::OpenGLBuffer. In this mode rendering is also done hardware accelerated - using the OpenGL paint engine to an offscreen FBO. Then the FBO gets copied to a QImage being rendered to a normal QWidget. This combination should also work with EGLFS. But of course copying from GPU to CPU and back for each frame might kill your performance requirements. Please let me know what you can achieve with this combination ? Uwe From thiago.macieira at intel.com Thu Aug 30 16:50:41 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 30 Aug 2018 07:50:41 -0700 Subject: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration In-Reply-To: References: Message-ID: <1732018.exvlWEssA7@tjmaciei-mobl1> On Thursday, 30 August 2018 06:09:22 PDT Uwe Rathmann wrote: > Furthermore nobody seems to be interested in working on the OpenGL paint > engine That paint engine was always experimental and the experiment concluded. There were two important conclusions: a) retrofitting paint events on top of OpenGL is hard and not efficient, plus it was not pixel-perfect b) proper OpenGL integration requires a stack designed with OpenGL in mind The result of (b) is a retained-mode scene graph. It's in the QtQuick library. > From my experience with the QSkinny project I'm tempted to say that it > would even be possible to implement the Qt/Widgets API on top of Qt/Quick > core. So long as you ditch the paint event for most of the classes, leaving the QQuickPaintedItem (or whatever it's called) only for the cases where it's truly needed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From frederik.gladhorn at qt.io Thu Aug 30 17:42:45 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Thu, 30 Aug 2018 17:42:45 +0200 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> <2317435.y4KJu3U8PQ@frederik-thinkcentre-m93p> Message-ID: <1999169.SP9bsu3tMU@frederik-thinkcentre-m93p> On onsdag 29. august 2018 20.17.52 CEST Robert Löhning wrote: > Am 22.08.2018 um 10:53 schrieb Frederik Gladhorn: > > Quick status update from my side: > > I have the script running against a test installation of JIRA. It seems to > > work, there are some small issues to be worked out still. > > > > - Qt Creator version numbers are verbose, so I need to be more generous in > > matching strings, right now I don't detect the version number correctly > > there. This one I will fix, it's just going to take a few minutes. > > > > - Qt 3D Studio seems to be a mess, it has 5.x branches but the JIRA > > versions are 2.x, I consider this a won't fix. > > > > I'd love if people started using "Fixes:", it will work retro-actively. > > And if you manually close a task in the meantime, no harm is done. > > Looks like somebody should tell the sanity bot: > https://codereview.qt-project.org/#/c/238280/1//COMMIT_MSG Seems like nobody volunteered (surprise :P). Sanity bot: https://codereview.qt-project.org/#/c/238437/1 Commit template: https://codereview.qt-project.org/#/c/238435/ I now consider the code done, no idea if/where it should live in the future, currently it's some internal repo inside TQtC. It's running in a VM and just needs the integration to be enabled in the real JIRA instance, so hopefully it goes live in the next few days :) Cheers, Frederik > > Cheers, > Robert > > > Multiple fix versions: > > There were some doubts about which fix versions would be set, for example > > during the down-merge. This actually turns out to work quite nicely: > > If a change ends up in dev, the script will detect that it will end up in > > 5.13.0 right now and sets that as fix version. If the downmerge happens, > > the script will see the change again in 5.12.0 and add that fix version. > > In my opinion there is no major harm. > > If the change is then cherry-picked to 5.9.7, it will also add that fix > > version. > > > > This also means that changes going into 5.11.4 will be marked as fixed in > > 5.12.1 or whatever is applicable branch/version wise. So we will actually > > set fix versions nicely. > > > > There are some fixes in JIRA that would be easy to make, assuming there is > > agreement. Since I have to use some heuristics, I decided to only ever > > look at full version numbers, including patch level releases. > > Currently we have version numbers in JIRA which do not make much sense to > > me, since they will never be released, such as 6.0, 5.12 and a few more. > > I would propose we always use the full version, so 6.0.0 and 5.12.0. > > If the script finds 5.13 but not 5.13.0 it will not set any fix version. > > > > I'm unsure where the whole thing should live, currently it's internal to > > The Qt Company, I'd love to publish it somewhere (it's a bunch of python > > files). > > > > Cheers, > > Frederik > > > > > > > > _______________________________________________ > > 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 Uwe.Rathmann at tigertal.de Thu Aug 30 17:46:32 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Thu, 30 Aug 2018 15:46:32 +0000 (UTC) Subject: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration References: <1732018.exvlWEssA7@tjmaciei-mobl1> Message-ID: On Thu, 30 Aug 2018 07:50:41 -0700, Thiago Macieira wrote: > The result of (b) is a retained-mode scene graph. It's in the QtQuick > library. I know, but now we have Qt 5.11 and it is fair to review this result: the API of the scene graph - as it is today - is so far from offering a comparable feature set like the one you have with QPainter. Actually it does not even offer the most fundamental primitives like: - non rectangular boxes - text - ... Have a look at all classes in the public API being derived from QSGNode: it boils down to QSGImageNode, QSGRectangleNode, QSGSimpleRectNode and QSGSimpleTextureNode. Do you really recommend starting with only this ? All sort of code that implements the minimal set of primitives almost everyone needs is hidden somewhere in private code of Qt/Quick core. But even if this code would make it into the scene graph it would be far from what you get with QPainter. But QPainter is more: it is an API, that allows you to implement render engines that works with different backends - f.e PDF is often simply mandatory. So implementing a plot package on top of scene graph does not mean, that you can drop the QPainter code you have to do the work twice. Having the common API running on various backends is such a huge asset of Qt - maybe one of the most important ones Qt has to offer. I really don't get why so many Qt developers do not realize what you actually have in your hands. Uwe From albert.astals.cid at kdab.com Thu Aug 30 20:42:11 2018 From: albert.astals.cid at kdab.com (Albert Astals Cid) Date: Thu, 30 Aug 2018 20:42:11 +0200 Subject: [Development] Submitting Qt to oss-fuzz Message-ID: <5019602.XjDd8nfdAG@xps15> oss-fuzz is an online fuzzing service run by Google. They test daily the code base and run fuzzying over it, maintaining a list of open and closed bugs. As example you can see one of the poppler issues i fixed at https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9382 Everything is done automatically by a bot, except my "This is fixed by" comment, but that's just there for historical reasons, it's not really needed. Found bugs are sent to a list of trusted address and kept private for 90 days, then if not fixed then they become public. Fixed bugs become public 30 days after being fixed. I have made a qimage fuzzer that uses libpng test files as seed corpus. You can find it at https://github.com/albert-astals-cid-kdab/oss-fuzz Adding support for Qt is "relatively simple" see https://github.com/albert-astals-cid-kdab/oss-fuzz/commit/2df60c7af6619b8a6a44b1cd679bf356e6e6ed3f I made a local test run of the undefined sanitizer and it found https://paste.kde.org/prkox41mx in a few seconds, so "it works" If you want to test it locally you can do python infra/helper.py build_fuzzers --sanitizer undefined qt python infra/helper.py run_fuzzer qt qimage_fuzzer for the undefined sanitizer and python infra/helper.py build_fuzzers --sanitizer address qt python infra/helper.py run_fuzzer qt qimage_fuzzer Unfortunately I have not been able to compile with the memory sanitizer enabled yet. The most important thing before submitting this upstream is changing the list of trusted addresses the private bugs get sent to. To have something written i've used my email address but i guess at least i should add eirik.aavitsland at qt.io (listed as QImage maintainer) there too? Anyone else? I am not sure how the email address thing works, but i think they need to be "google account" activated, whatever that means, so we can't use security at qt-project.org. On poppler i'm using my @gmail.com address and not my @kde.org address since it was just easier. Comments? Cheers, Albert -- Albert Astals Cid | albert.astals.cid at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From apoenitz at t-online.de Thu Aug 30 08:59:40 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 30 Aug 2018 08:59:40 +0200 Subject: [Development] Submitting Qt to oss-fuzz In-Reply-To: <5019602.XjDd8nfdAG@xps15> References: <5019602.XjDd8nfdAG@xps15> Message-ID: <20180830065940.GA9161@klara.mpi.htwm.de> On Thu, Aug 30, 2018 at 08:42:11PM +0200, Albert Astals Cid via Development wrote: > I made a local test run of the undefined sanitizer and it found > https://paste.kde.org/prkox41mx in a few seconds, so "it works" > > If you want to test it locally you can do python infra/helper.py > build_fuzzers --sanitizer undefined qt python infra/helper.py > run_fuzzer qt qimage_fuzzer for the undefined sanitizer and > python infra/helper.py build_fuzzers --sanitizer address qt > python infra/helper.py run_fuzzer qt qimage_fuzzer > > Unfortunately I have not been able to compile with the memory > sanitizer enabled yet. > > The most important thing before submitting this upstream is > changing the list of trusted addresses the private bugs get sent > to. > > To have something written i've used my email address but i guess > at least i should add eirik.aavitsland at qt.io (listed as QImage > maintainer) there too? Anyone else? I am not sure how the email > address thing works, but i think they need to be "google account" > activated, whatever that means, so we can't use > security at qt-project.org. That would be the natural choice. > On poppler i'm using my @gmail.com address and not my @kde.org address since it was > just easier. > > Comments? We are not taking about an innovative approach to coerce people into using Google services, right? Andre' From lars.knoll at qt.io Thu Aug 30 21:27:42 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 30 Aug 2018 19:27:42 +0000 Subject: [Development] Submitting Qt to oss-fuzz In-Reply-To: <5019602.XjDd8nfdAG@xps15> References: <5019602.XjDd8nfdAG@xps15> Message-ID: Hi Albert, Nice! Robert has been working on exactly the same thing lately. I think it would be good if you guys coordinated the effort :) It would be ideal, if we could somehow get those mails forwarded to the security mailing list. I wonder whether we could do that with a special mail account that forwards to the security mailing list. Cheers, Lars > On 30 Aug 2018, at 20:42, Albert Astals Cid via Development wrote: > > oss-fuzz is an online fuzzing service run by Google. > > They test daily the code base and run fuzzying over it, maintaining a list of open and closed bugs. > > As example you can see one of the poppler issues i fixed at > https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9382 > > Everything is done automatically by a bot, except my "This is fixed by" comment, but that's just there for historical reasons, it's not really needed. > > Found bugs are sent to a list of trusted address and kept private for 90 days, then if not fixed then they become public. > > Fixed bugs become public 30 days after being fixed. > > I have made a qimage fuzzer that uses libpng test files as seed corpus. > > You can find it at https://github.com/albert-astals-cid-kdab/oss-fuzz > > Adding support for Qt is "relatively simple" see > https://github.com/albert-astals-cid-kdab/oss-fuzz/commit/2df60c7af6619b8a6a44b1cd679bf356e6e6ed3f > > I made a local test run of the undefined sanitizer and it found > https://paste.kde.org/prkox41mx > in a few seconds, so "it works" > > If you want to test it locally you can do > python infra/helper.py build_fuzzers --sanitizer undefined qt > python infra/helper.py run_fuzzer qt qimage_fuzzer > for the undefined sanitizer and > python infra/helper.py build_fuzzers --sanitizer address qt > python infra/helper.py run_fuzzer qt qimage_fuzzer > > Unfortunately I have not been able to compile with the memory sanitizer enabled yet. > > The most important thing before submitting this upstream is changing the list of trusted addresses the private bugs get sent to. > > To have something written i've used my email address but i guess at least i should add eirik.aavitsland at qt.io (listed as QImage maintainer) there too? Anyone else? > > I am not sure how the email address thing works, but i think they need to be "google account" activated, whatever that means, so we can't use security at qt-project.org. On poppler i'm using my @gmail.com address and not my @kde.org address since it was just easier. > > Comments? > > Cheers, > Albert > > -- > Albert Astals Cid | albert.astals.cid at kdab.com | Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - The Qt, C++ and OpenGL Experts > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From albert.astals.cid at kdab.com Thu Aug 30 21:30:12 2018 From: albert.astals.cid at kdab.com (Albert Astals Cid) Date: Thu, 30 Aug 2018 21:30:12 +0200 Subject: [Development] Submitting Qt to oss-fuzz In-Reply-To: <20180830065940.GA9161@klara.mpi.htwm.de> References: <5019602.XjDd8nfdAG@xps15> <20180830065940.GA9161@klara.mpi.htwm.de> Message-ID: <1631333.tplpRLKiD1@xps15> El dijous, 30 d’agost de 2018, a les 8:59:40 CEST, André Pönitz va escriure: > On Thu, Aug 30, 2018 at 08:42:11PM +0200, Albert Astals Cid via > > Development wrote: > > I made a local test run of the undefined sanitizer and it found > > https://paste.kde.org/prkox41mx in a few seconds, so "it works" > > > > If you want to test it locally you can do python infra/helper.py > > build_fuzzers --sanitizer undefined qt python infra/helper.py > > run_fuzzer qt qimage_fuzzer for the undefined sanitizer and > > python infra/helper.py build_fuzzers --sanitizer address qt > > python infra/helper.py run_fuzzer qt qimage_fuzzer > > > > Unfortunately I have not been able to compile with the memory > > sanitizer enabled yet. > > > > The most important thing before submitting this upstream is > > changing the list of trusted addresses the private bugs get sent > > to. > > > > To have something written i've used my email address but i guess > > at least i should add eirik.aavitsland at qt.io (listed as QImage > > maintainer) there too? Anyone else? I am not sure how the email > > address thing works, but i think they need to be "google account" > > activated, whatever that means, so we can't use > > security at qt-project.org. > > That would be the natural choice. > > > On poppler i'm using my @gmail.com address and not my @kde.org address > > since it was just easier. > > > > Comments? > > We are not taking about an innovative approach to coerce people > into using Google services, right? Maybe :D Not really sure how it works, we can try submitting it with security at qt- project.org and see what happens, but first i'd like confirmation from them that they'll look at the errors and confirmation from "the project" that it's a good idea to do this. Cheers, Albert > > Andre' -- Albert Astals Cid | albert.astals.cid at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From albert.astals.cid at kdab.com Thu Aug 30 21:32:56 2018 From: albert.astals.cid at kdab.com (Albert Astals Cid) Date: Thu, 30 Aug 2018 21:32:56 +0200 Subject: [Development] Submitting Qt to oss-fuzz In-Reply-To: <5019602.XjDd8nfdAG@xps15> References: <5019602.XjDd8nfdAG@xps15> Message-ID: <3531371.OWjeJk9eaF@xps15> El dijous, 30 d’agost de 2018, a les 20:42:11 CEST, Albert Astals Cid via Development va escriure: > Unfortunately I have not been able to compile with the memory sanitizer > enabled yet. Done :) https://github.com/albert-astals-cid-kdab/oss-fuzz/commit/b4f28e7dc5e4b936166cda1be36c3bde6b62c53d Found https://paste.kde.org/ptyi8utax in under a minute. Cheers, Albert > > Cheers, > Albert -- Albert Astals Cid | albert.astals.cid at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Fri Aug 31 00:47:34 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 30 Aug 2018 15:47:34 -0700 Subject: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration In-Reply-To: References: <1732018.exvlWEssA7@tjmaciei-mobl1> Message-ID: <14770708.mNuPGObmTa@tjmaciei-mobl1> On Thursday, 30 August 2018 08:46:32 PDT Uwe Rathmann wrote: > On Thu, 30 Aug 2018 07:50:41 -0700, Thiago Macieira wrote: > > The result of (b) is a retained-mode scene graph. It's in the QtQuick > > library. > > I know, but now we have Qt 5.11 and it is fair to review this result: > > the API of the scene graph - as it is today - is so far from offering a > comparable feature set like the one you have with QPainter. Actually it > does not even offer the most fundamental primitives like: > > - non rectangular boxes Draw it with OpenGL. > - text Implemented in QML. Just layer your text over whatever you were painting as a background. > - ... Use the onion solution: layers! > But QPainter is more: it is an API, that allows you to implement render > engines that works with different backends - f.e PDF is often simply > mandatory. So implementing a plot package on top of scene graph does not > mean, that you can drop the QPainter code you have to do the work twice. PDF is not OpenGL. Trying to solve for both makes it a good solution for neither. > Having the common API running on various backends is such a huge asset of > Qt - maybe one of the most important ones Qt has to offer. I really don't > get why so many Qt developers do not realize what you actually have in > your hands. I understand it's a huge asset. But it's also a performance bottleneck. You can always just use QPainter on a QPixmap and paint that pixmap on your QSGPaintedItem. It won't be particularly fast, but it will work and do what you asked. If you want faster, redesign with OpenGL in mind. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From chris.adams at qinetic.com.au Fri Aug 31 02:06:05 2018 From: chris.adams at qinetic.com.au (Chris Adams) Date: Fri, 31 Aug 2018 10:06:05 +1000 Subject: [Development] Orphan modules In-Reply-To: References: Message-ID: Hi Eddy, I'm willing to be listed as the maintainer of QtFeedback for now. If it ever gets more development attention and released as a supported module then someone with more time to give should probably take over, but until then I'm more than happy to review any changes people might contribute for that module. Cheers, Chris. On Thu, Aug 30, 2018 at 11:27 PM, Edward Welbourne wrote: > I notice, as part of seeking folk to look at API reviews, that we have > several modules with no Maintainer: qtandroidextras, qtgraphicaleffects, > qtmacextras, qtquick1, qtquickcontrols, qtsvg, qtwinextras and (the one > that brought this to my attention) qtxmlpatterns, according to [0]. > > * [0] https://wiki.qt.io/Maintainers > > (There's also qtdoc, with no person as maintainer, but with "Norway" in > the Country column, which I interpret as the doc-team here in Oslo; and > there's qtfeedback, which is unsupported; two other unsupported modules > do in fact have Maintainers.) > > If anyone out there feels an urge to volunteer to adopt one of these > orphans, it'd be worth speaking up, > > Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From lars.knoll at qt.io Fri Aug 31 08:18:44 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 31 Aug 2018 06:18:44 +0000 Subject: [Development] Orphan modules In-Reply-To: References: Message-ID: <7E79E63F-EBF6-47D9-86CE-D46E83C3E61C@qt.io> On 31 Aug 2018, at 02:06, Chris Adams > wrote: Hi Eddy, I'm willing to be listed as the maintainer of QtFeedback for now. If it ever gets more development attention and released as a supported module then someone with more time to give should probably take over, but until then I'm more than happy to review any changes people might contribute for that module. Thanks Chris! Let’s add you for Qt Feedback then :) Cheers, Chris. On Thu, Aug 30, 2018 at 11:27 PM, Edward Welbourne > wrote: I notice, as part of seeking folk to look at API reviews, that we have several modules with no Maintainer: qtandroidextras, qtgraphicaleffects, qtmacextras, qtquick1, qtquickcontrols, qtsvg, qtwinextras and (the one that brought this to my attention) qtxmlpatterns, according to [0]. * [0] https://wiki.qt.io/Maintainers The supported modules where we have no maintainer listed go to me for the API reviews. Cheers, Lars (There's also qtdoc, with no person as maintainer, but with "Norway" in the Country column, which I interpret as the doc-team here in Oslo; and there's qtfeedback, which is unsupported; two other unsupported modules do in fact have Maintainers.) If anyone out there feels an urge to volunteer to adopt one of these orphans, it'd be worth speaking up, Eddy. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Fri Aug 31 10:27:08 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 31 Aug 2018 08:27:08 +0000 Subject: [Development] Submitting Qt to oss-fuzz In-Reply-To: <5019602.XjDd8nfdAG@xps15> References: <5019602.XjDd8nfdAG@xps15> Message-ID: Albert Astals Cid (30 August 2018 20:42) wrote: > oss-fuzz is an online fuzzing service run by Google. Sounds useful. > They test daily the code base and run fuzzying over it, maintaining a > list of open and closed bugs. > > Found bugs are sent to a list of trusted address and kept private for > 90 days, then if not fixed then they become public. > > Fixed bugs become public 30 days after being fixed. By "fixed" do they mean "we have told them we've fixed it" or "we've released all currently releasing branches of Qt with fixes" ? I'm guessing it's closer to the former than the latter. So we have a month from fixing it, or perhaps from releasing *one* branch with a fix, within which to also release all our other live branches. That sounds like it may stress our release processes. So we have a quarter year in which to find a fix, then we need to orchestrate releases across all branches within a month; and this happens for each and every issue found. That schedule is fine for Chromium, which doesn't support old versions or care about backwards-compatibility, but may be a poor fit for our more conservative processes. So it would be better to run this *ourselves*, if we can, so that the Qt community has more control over how and when the results get to be published. > If you want to test it locally you can do > python infra/helper.py build_fuzzers --sanitizer undefined qt > python infra/helper.py run_fuzzer qt qimage_fuzzer > for the undefined sanitizer and > python infra/helper.py build_fuzzers --sanitizer address qt > python infra/helper.py run_fuzzer qt qimage_fuzzer So it *can* be used locally, without giving Google yet more power ... Good to know. Eddy. From albert.astals.cid at kdab.com Fri Aug 31 10:52:32 2018 From: albert.astals.cid at kdab.com (Albert Astals Cid) Date: Fri, 31 Aug 2018 10:52:32 +0200 Subject: [Development] Submitting Qt to oss-fuzz In-Reply-To: References: <5019602.XjDd8nfdAG@xps15> Message-ID: <1668556.nD2G9sjF0x@xps15> El divendres, 31 d’agost de 2018, a les 10:27:08 CEST, Edward Welbourne va escriure: > Albert Astals Cid (30 August 2018 20:42) wrote: > > oss-fuzz is an online fuzzing service run by Google. > > Sounds useful. > > > They test daily the code base and run fuzzying over it, maintaining a > > list of open and closed bugs. > > > > Found bugs are sent to a list of trusted address and kept private for > > 90 days, then if not fixed then they become public. > > > > Fixed bugs become public 30 days after being fixed. > > By "fixed" do they mean "we have told them we've fixed it" or "we've > released all currently releasing branches of Qt with fixes" ? Fixed means "the daily bot has run again and it has found that what was wrong before is now fine" > I'm > guessing it's closer to the former than the latter. So we have a month > from fixing it, or perhaps from releasing *one* branch with a fix, > within which to also release all our other live branches. That sounds > like it may stress our release processes. So we have a quarter year in > which to find a fix, then we need to orchestrate releases across all > branches within a month; and this happens for each and every issue > found. That schedule is fine for Chromium, which doesn't support old > versions or care about backwards-compatibility, but may be a poor fit > for our more conservative processes. > > So it would be better to run this *ourselves*, if we can, so that the Qt > community has more control over how and when the results get to be > published. This is scarily close to the security by obscurity argument ;) "what if we have an horrible bug, we fix it, it becomes public in 30 days and we've not been able yet to put out a release?" My answer to that is, you had an horrible bug, it's fixed, that is a great thing, so just put and advisory out with the patch if we can't get a release out. > > > If you want to test it locally you can do > > > > python infra/helper.py build_fuzzers --sanitizer undefined qt > > python infra/helper.py run_fuzzer qt qimage_fuzzer > > > > for the undefined sanitizer and > > > > python infra/helper.py build_fuzzers --sanitizer address qt > > python infra/helper.py run_fuzzer qt qimage_fuzzer > > So it *can* be used locally, without giving Google yet more power ... > Good to know. But you lose the daily bot runs and the free hardware. I am not sure, but i think the bot part is not actually free software, though i may be wrong. Also when i run it, it stops at the first found issue, i guess there may be a parameter to have it continue since the bot will find N issues in a given day. Cheers, Albert > > Eddy. -- Albert Astals Cid | albert.astals.cid at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From simon.hausmann at qt.io Fri Aug 31 11:01:23 2018 From: simon.hausmann at qt.io (Simon Hausmann) Date: Fri, 31 Aug 2018 11:01:23 +0200 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> <738A8F0F-5F4C-4D31-8AF9-1A719699D69C@qt.io> Message-ID: On 8/15/18 9:32 AM, Alex Blasche wrote: > >> -----Original Message----- >> From: Tor Arne Vestbø >> 1. Scoped enums (enum class) for the sake of avoiding name clashes is useful for >> global enums, but when the enum lives inside a class, the chance that we’ll see a >> naming clash is minor, and using scoped enums in that case arguably has >> negative effects on code writability/readability. As a result, we should update >> the policy to not mandate scoped enums when the enum lives inside a class. > I don't think we have ever not permitted exceptions to official policy. Therefore, take it for granted that the policy can be ignored such as in the case presented by Allan. Having said that the default should be the use of scoped enums even inside of classes. > > I don't consider the longer names detrimental for writability and usability. Writability is easily solved with code completion and readability is actually better because the type adds additional context info. To cite an example from Shawn's patch: > > QQuickPointerDevice::Finger > QQuickPointerDevice::Mouse > > is far less descriptive than (and not compliant to current naming convention) > > QQuickPointerDevice::PointerType::Finger > QQuickPointerDevice::DeviceType::Mouse. > > The uninitiated reader of the code cannot see the additional type context when reading code and therefore someone might interpret Finger as a device type too. That's exactly what the existing unscoped enum policy tries to fix. Scoped enums provide this feature out of the box. Another example of a good naming policy (IMO) is QAbstractSocket (never mind the technical limitations). Here we could shorten the enum names using scoped enums: > > QAbstractSocket::SocketError::ConnectionRefusedError -> QAbstractSocket::SocketError::ConnectionRefused (or even QAbstractSocket::Error::ConnectionRefused) > > Name clash prevention was only ever secondary to readability. > We don't need scoped enums to improve readability though, that doesn't seem like an argument. To take the finger/mouse example, we would use     QQuickPointerDevice::FingerPointer or     QQuickPointerDevice::PointerType_Finger and you get exactly the same benefit, no? Meanwhile, QQuickPointerDevice::DeviceType::Mouse is not improving readability IMO but adding noise. The name "PointerDevice" gives the exactly the context required to get an idea about the meaning of "Mouse". API is like documentation, there is a balance to be struck between conciseness and verbosity. If text is too verbose, it's hard to read. If text is too concise, then it may fail to convey crucial information. So we have three arguments for scoped enums:     1. Avoids clashes     2. Improves readability     3. Adds type safety After some of enum class use myself and seeing their use in code reviews, I feel that to avoid (1) and achieve (2) we don't need enum classes. After all we've solved this before with prefixing. I do buy a little into the type safety argument, but I feel that affects more the internal use (where we sometimes do things on a low-level and need it) in contrast to our API where we can make sure that the enums are used in good context. The risk I start to see with enum classes is that they present an opportunity where we can spend less time thinking about good names in the API. They present a tool that allow us to just use any name we like and not worry so much about the big picture of the class(es) they appear in. If we decide to allow deciding on a case-by-case basis, then I encourage everyone to carefully look at newly introduced enums, their values and their context in the upcoming "API review season". Simon >> 2. Scoped enums for the sake of type safety is a valid use case, but can be solved >> by promoting a warning to an error, and as such shouldn’t block us moving >> forward with #1. > I don't see how a policy of elevating warnings to errors is better that using a language inbuilt error due to strong type safety. > -- > Alex > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From edward.welbourne at qt.io Fri Aug 31 11:12:59 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 31 Aug 2018 09:12:59 +0000 Subject: [Development] Submitting Qt to oss-fuzz In-Reply-To: <1668556.nD2G9sjF0x@xps15> References: <5019602.XjDd8nfdAG@xps15> , <1668556.nD2G9sjF0x@xps15> Message-ID: El divendres, 31 d’agost de 2018, a les 10:27:08 CEST, Edward Welbourne va escriure: >> By "fixed" do they mean "we have told them we've fixed it" or "we've >> released all currently releasing branches of Qt with fixes" ? Albert Astals Cid (31 August 2018 10:52) > Fixed means "the daily bot has run again and it has found that what > was wrong before is now fine" OK, so that'll be shortly after we release an update to whatever branch they're testing. I suppose we have some say in which version they test, so we could start with LTS and work our way closer to the bleeding edge as we get all our old horrors out of the way - and maybe one day get to test live on dev. >> So it would be better to run this *ourselves*, if we can, so that the >> Qt community has more control over how and when the results get to be >> published. > This is scarily close to the security by obscurity argument ;) > > "what if we have an horrible bug, we fix it, it becomes public in 30 > days and we've not been able yet to put out a release?" > > My answer to that is, you had an horrible bug, it's fixed, that is a > great thing, so just put and advisory out with the patch if we can't > get a release out. Yet we have a security group, whose business is to manage the timing of advisories and co-ordinate those with releases. I'm not saying we should try to hide our dirty laundry; just that we should let our security team actually have a chance to have some control over the things they're there to control. >> So it *can* be used locally, without giving Google yet more power ... >> Good to know. > But you lose the daily bot runs and the free hardware. I am not sure, > but i think the bot part is not actually free software, though i may > be wrong. Also when i run it, it stops at the first found issue, i > guess there may be a parameter to have it continue since the bot will > find N issues in a given day. Indeed, running it ourselves would be One More Thing that the poor infrastructure team would have to take care of, and One More System to maintain; all the more so if we have to implement our own replacement for some non-free parts. So the question is whether the impedance mismatch - between Google's disclosure time-line (optimised for Chromium-style software that doesn't care about old versions or backwards-compatibility) and our security team's processes - is a big enough issue that it's worth going to all that effort ourselves ... I'm not saying "let's not do this" only "let's just think about this for a moment, first" - in particular, about how it'll interact with our existing security and release processes, Eddy. From robert.loehning at qt.io Fri Aug 31 11:24:58 2018 From: robert.loehning at qt.io (=?UTF-8?Q?Robert_L=c3=b6hning?=) Date: Fri, 31 Aug 2018 11:24:58 +0200 Subject: [Development] Submitting Qt to oss-fuzz In-Reply-To: References: <5019602.XjDd8nfdAG@xps15> Message-ID: <06f84c5f-52b5-5ec2-6062-9a29e0f2db69@qt.io> Hi everybody, yes I did. So far I have been working on getting Qt into a better shape for fuzzing at all, resulting in [1]. This prepares a Qt build for being fuzz tested with clang's libFuzzer, the tool that Google also uses in oss-fuzz. The fuzzer I used for testing my setup already found a crash. What I have so far: - fuzzing Qt with libFuzzer locally, using [1] - AFAICS collected all the needed "OK"s to enter Qt [2] What I don't have so far: - create the pull request for [2], wanted to do this now-ish - Everything that comes after registering the project like: - setting up build/run on Google's servers - finding out what kind of dashboard I'll get there I would appreciate if I might use the scripts you posted, Albert, or if we could work on this together. Cheers, Robert [1] https://codereview.qt-project.org/236937/ [2] https://github.com/google/oss-fuzz/compare/master...rlohning:master Am 30.08.2018 um 21:27 schrieb Lars Knoll: > Hi Albert, > > Nice! Robert has been working on exactly the same thing lately. I think it would be good if you guys coordinated the effort :) > > It would be ideal, if we could somehow get those mails forwarded to the security mailing list. I wonder whether we could do that with a special mail account that forwards to the security mailing list. > > Cheers, > Lars > >> On 30 Aug 2018, at 20:42, Albert Astals Cid via Development wrote: >> >> oss-fuzz is an online fuzzing service run by Google. >> >> They test daily the code base and run fuzzying over it, maintaining a list of open and closed bugs. >> >> As example you can see one of the poppler issues i fixed at >> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9382 >> >> Everything is done automatically by a bot, except my "This is fixed by" comment, but that's just there for historical reasons, it's not really needed. >> >> Found bugs are sent to a list of trusted address and kept private for 90 days, then if not fixed then they become public. >> >> Fixed bugs become public 30 days after being fixed. >> >> I have made a qimage fuzzer that uses libpng test files as seed corpus. >> >> You can find it at https://github.com/albert-astals-cid-kdab/oss-fuzz >> >> Adding support for Qt is "relatively simple" see >> https://github.com/albert-astals-cid-kdab/oss-fuzz/commit/2df60c7af6619b8a6a44b1cd679bf356e6e6ed3f >> >> I made a local test run of the undefined sanitizer and it found >> https://paste.kde.org/prkox41mx >> in a few seconds, so "it works" >> >> If you want to test it locally you can do >> python infra/helper.py build_fuzzers --sanitizer undefined qt >> python infra/helper.py run_fuzzer qt qimage_fuzzer >> for the undefined sanitizer and >> python infra/helper.py build_fuzzers --sanitizer address qt >> python infra/helper.py run_fuzzer qt qimage_fuzzer >> >> Unfortunately I have not been able to compile with the memory sanitizer enabled yet. >> >> The most important thing before submitting this upstream is changing the list of trusted addresses the private bugs get sent to. >> >> To have something written i've used my email address but i guess at least i should add eirik.aavitsland at qt.io (listed as QImage maintainer) there too? Anyone else? >> >> I am not sure how the email address thing works, but i think they need to be "google account" activated, whatever that means, so we can't use security at qt-project.org. On poppler i'm using my @gmail.com address and not my @kde.org address since it was just easier. >> >> Comments? >> >> Cheers, >> Albert >> >> -- >> Albert Astals Cid | albert.astals.cid at kdab.com | Software Engineer >> Klarälvdalens Datakonsult AB, a KDAB Group company >> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) >> KDAB - The Qt, C++ and OpenGL Experts >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > From edward.welbourne at qt.io Fri Aug 31 11:25:29 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 31 Aug 2018 09:25:29 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> <738A8F0F-5F4C-4D31-8AF9-1A719699D69C@qt.io> , Message-ID: Simon Hausmann (31 August 2018 11:01) > If we decide to allow deciding on a case-by-case basis, then I encourage > everyone to carefully look at newly introduced enums, their values and > their context in the upcoming "API review season". or, indeed, s/upcoming/ongoing/ ;-) Eddy. From robert.loehning at qt.io Fri Aug 31 11:31:16 2018 From: robert.loehning at qt.io (=?UTF-8?Q?Robert_L=c3=b6hning?=) Date: Fri, 31 Aug 2018 11:31:16 +0200 Subject: [Development] Submitting Qt to oss-fuzz In-Reply-To: <1631333.tplpRLKiD1@xps15> References: <5019602.XjDd8nfdAG@xps15> <20180830065940.GA9161@klara.mpi.htwm.de> <1631333.tplpRLKiD1@xps15> Message-ID: Am 30.08.2018 um 21:30 schrieb Albert Astals Cid via Development: > El dijous, 30 d’agost de 2018, a les 8:59:40 CEST, André Pönitz va escriure: >> On Thu, Aug 30, 2018 at 08:42:11PM +0200, Albert Astals Cid via >> >> Development wrote: >>> I made a local test run of the undefined sanitizer and it found >>> https://paste.kde.org/prkox41mx in a few seconds, so "it works" >>> >>> If you want to test it locally you can do python infra/helper.py >>> build_fuzzers --sanitizer undefined qt python infra/helper.py >>> run_fuzzer qt qimage_fuzzer for the undefined sanitizer and >>> python infra/helper.py build_fuzzers --sanitizer address qt >>> python infra/helper.py run_fuzzer qt qimage_fuzzer >>> >>> Unfortunately I have not been able to compile with the memory >>> sanitizer enabled yet. >>> >>> The most important thing before submitting this upstream is >>> changing the list of trusted addresses the private bugs get sent >>> to. >>> >>> To have something written i've used my email address but i guess >>> at least i should add eirik.aavitsland at qt.io (listed as QImage >>> maintainer) there too? Anyone else? I am not sure how the email >>> address thing works, but i think they need to be "google account" >>> activated, whatever that means, so we can't use >>> security at qt-project.org. >> >> That would be the natural choice. >> >>> On poppler i'm using my @gmail.com address and not my @kde.org address >>> since it was just easier. >>> >>> Comments? >> >> We are not taking about an innovative approach to coerce people >> into using Google services, right? > > Maybe :D > > Not really sure how it works, we can try submitting it with security at qt- > project.org and see what happens, but first i'd like confirmation from them > that they'll look at the errors and confirmation from "the project" that it's > a good idea to do this. Hi, I was planning to do it the other way round: I registered a GMail address for this sole purpose and will manually forward what comes in there to the security list whenever needed. Of course I'd then try to automate this as far as possible. Cheers, Robert > > Cheers, > Albert > >> >> Andre' > > From alexander.blasche at qt.io Fri Aug 31 11:41:57 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Fri, 31 Aug 2018 09:41:57 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> <738A8F0F-5F4C-4D31-8AF9-1A719699D69C@qt.io> Message-ID: > -----Original Message----- > From: Development project.org> On Behalf Of Simon Hausmann > > I don't consider the longer names detrimental for writability and usability. > Writability is easily solved with code completion and readability is actually better > because the type adds additional context info. To cite an example from Shawn's > patch: > > > > QQuickPointerDevice::Finger > > QQuickPointerDevice::Mouse > > > > is far less descriptive than (and not compliant to current naming convention) > > > > QQuickPointerDevice::PointerType::Finger > > QQuickPointerDevice::DeviceType::Mouse. > > > > The uninitiated reader of the code cannot see the additional type context > when reading code and therefore someone might interpret Finger as a device > type too. That's exactly what the existing unscoped enum policy tries to fix. > Scoped enums provide this feature out of the box. Another example of a good > naming policy (IMO) is QAbstractSocket (never mind the technical limitations). > Here we could shorten the enum names using scoped enums: > > > > QAbstractSocket::SocketError::ConnectionRefusedError -> > QAbstractSocket::SocketError::ConnectionRefused (or even > QAbstractSocket::Error::ConnectionRefused) > > > > Name clash prevention was only ever secondary to readability. > > > We don't need scoped enums to improve readability though, that doesn't > seem like an argument. To take the finger/mouse example, we would use > >     QQuickPointerDevice::FingerPointer > > or > >     QQuickPointerDevice::PointerType_Finger > > and you get exactly the same benefit, no? I don't see how your two options above are any different(better?) readability wise than QQuickPointerDevice::PointerType::Finger. I believe I mentioned earlier that in light of Qt 6 it might actually make sense to rename some enum type names too which means QQuickPointerDevice::Pointer::Finger is possible and we can remove some of the redundancy between enum type name and enum value name. Sure, we can get away with the old style of naming but when you consider that the length of the string is extremely close to being the same and gain type safety, why would we not use them? Of course, if you purposely don't want to type safety traditional enums are still the way to go. My five cents.. -- Alex From albert.astals.cid at kdab.com Fri Aug 31 11:53:12 2018 From: albert.astals.cid at kdab.com (Albert Astals Cid) Date: Fri, 31 Aug 2018 11:53:12 +0200 Subject: [Development] Submitting Qt to oss-fuzz In-Reply-To: References: <5019602.XjDd8nfdAG@xps15> <1631333.tplpRLKiD1@xps15> Message-ID: <3339622.hR5jyeNRUN@xps15> El divendres, 31 d’agost de 2018, a les 11:31:16 CEST, Robert Löhning va escriure: > Am 30.08.2018 um 21:30 schrieb Albert Astals Cid via Development: > > El dijous, 30 d’agost de 2018, a les 8:59:40 CEST, André Pönitz va escriure: > >> On Thu, Aug 30, 2018 at 08:42:11PM +0200, Albert Astals Cid via > >> > >> Development wrote: > >>> I made a local test run of the undefined sanitizer and it found > >>> https://paste.kde.org/prkox41mx in a few seconds, so "it works" > >>> > >>> If you want to test it locally you can do python infra/helper.py > >>> build_fuzzers --sanitizer undefined qt python infra/helper.py > >>> run_fuzzer qt qimage_fuzzer for the undefined sanitizer and > >>> python infra/helper.py build_fuzzers --sanitizer address qt > >>> python infra/helper.py run_fuzzer qt qimage_fuzzer > >>> > >>> Unfortunately I have not been able to compile with the memory > >>> sanitizer enabled yet. > >>> > >>> The most important thing before submitting this upstream is > >>> changing the list of trusted addresses the private bugs get sent > >>> to. > >>> > >>> To have something written i've used my email address but i guess > >>> at least i should add eirik.aavitsland at qt.io (listed as QImage > >>> maintainer) there too? Anyone else? I am not sure how the email > >>> address thing works, but i think they need to be "google account" > >>> activated, whatever that means, so we can't use > >>> security at qt-project.org. > >> > >> That would be the natural choice. > >> > >>> On poppler i'm using my @gmail.com address and not my @kde.org address > >>> since it was just easier. > >>> > >>> Comments? > >> > >> We are not taking about an innovative approach to coerce people > >> into using Google services, right? > > > > Maybe :D > > > > Not really sure how it works, we can try submitting it with security at qt- > > project.org and see what happens, but first i'd like confirmation from > > them > > that they'll look at the errors and confirmation from "the project" that > > it's a good idea to do this. > > Hi, > > I was planning to do it the other way round: I registered a GMail > address for this sole purpose and will manually forward what comes in > there to the security list whenever needed. Of course I'd then try to > automate this as far as possible. That works for me if it works for the project :) Cheers, Albert > > Cheers, > Robert > > > Cheers, > > > > Albert > >> > >> Andre' > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Albert Astals Cid | albert.astals.cid at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From albert.astals.cid at kdab.com Fri Aug 31 11:53:52 2018 From: albert.astals.cid at kdab.com (Albert Astals Cid) Date: Fri, 31 Aug 2018 11:53:52 +0200 Subject: [Development] Submitting Qt to oss-fuzz In-Reply-To: <06f84c5f-52b5-5ec2-6062-9a29e0f2db69@qt.io> References: <5019602.XjDd8nfdAG@xps15> <06f84c5f-52b5-5ec2-6062-9a29e0f2db69@qt.io> Message-ID: <2700085.RmqWHZbtQ5@xps15> El divendres, 31 d’agost de 2018, a les 11:24:58 CEST, Robert Löhning va escriure: > Hi everybody, > > yes I did. So far I have been working on getting Qt into a better shape > for fuzzing at all, resulting in [1]. > > This prepares a Qt build for being fuzz tested with clang's libFuzzer, > the tool that Google also uses in oss-fuzz. The fuzzer I used for > testing my setup already found a crash. > > What I have so far: > - fuzzing Qt with libFuzzer locally, using [1] > - AFAICS collected all the needed "OK"s to enter Qt [2] > > What I don't have so far: > - create the pull request for [2], wanted to do this now-ish > - Everything that comes after registering the project like: > - setting up build/run on Google's servers > - finding out what kind of dashboard I'll get there > > I would appreciate if I might use the scripts you posted, Albert, or if > we could work on this together. Feel free to merge my github branch into your github branch :) Cheers, Albert > > Cheers, > Robert > > [1] https://codereview.qt-project.org/236937/ > [2] https://github.com/google/oss-fuzz/compare/master...rlohning:master > > Am 30.08.2018 um 21:27 schrieb Lars Knoll: > > Hi Albert, > > > > Nice! Robert has been working on exactly the same thing lately. I think it > > would be good if you guys coordinated the effort :) > > > > It would be ideal, if we could somehow get those mails forwarded to the > > security mailing list. I wonder whether we could do that with a special > > mail account that forwards to the security mailing list. > > > > Cheers, > > Lars > > > >> On 30 Aug 2018, at 20:42, Albert Astals Cid via Development > >> wrote: > >> > >> oss-fuzz is an online fuzzing service run by Google. > >> > >> They test daily the code base and run fuzzying over it, maintaining a > >> list of open and closed bugs. > >> > >> As example you can see one of the poppler issues i fixed at > >> > >> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9382 > >> > >> Everything is done automatically by a bot, except my "This is fixed by" > >> comment, but that's just there for historical reasons, it's not really > >> needed. > >> > >> Found bugs are sent to a list of trusted address and kept private for 90 > >> days, then if not fixed then they become public. > >> > >> Fixed bugs become public 30 days after being fixed. > >> > >> I have made a qimage fuzzer that uses libpng test files as seed corpus. > >> > >> You can find it at https://github.com/albert-astals-cid-kdab/oss-fuzz > >> > >> Adding support for Qt is "relatively simple" see > >> https://github.com/albert-astals-cid-kdab/oss-fuzz/commit/2df60c7af6619b8 > >> a6a44b1cd679bf356e6e6ed3f > >> > >> I made a local test run of the undefined sanitizer and it found > >> https://paste.kde.org/prkox41mx > >> in a few seconds, so "it works" > >> > >> If you want to test it locally you can do > >> > >> python infra/helper.py build_fuzzers --sanitizer undefined qt > >> python infra/helper.py run_fuzzer qt qimage_fuzzer > >> > >> for the undefined sanitizer and > >> > >> python infra/helper.py build_fuzzers --sanitizer address qt > >> python infra/helper.py run_fuzzer qt qimage_fuzzer > >> > >> Unfortunately I have not been able to compile with the memory sanitizer > >> enabled yet. > >> > >> The most important thing before submitting this upstream is changing the > >> list of trusted addresses the private bugs get sent to. > >> > >> To have something written i've used my email address but i guess at least > >> i should add eirik.aavitsland at qt.io (listed as QImage maintainer) there > >> too? Anyone else? > >> > >> I am not sure how the email address thing works, but i think they need to > >> be "google account" activated, whatever that means, so we can't use > >> security at qt-project.org. On poppler i'm using my @gmail.com address and > >> not my @kde.org address since it was just easier. > >> > >> Comments? > >> > >> Cheers, > >> > >> Albert > >> > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development -- Albert Astals Cid | albert.astals.cid at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From Tor.arne.Vestbo at qt.io Fri Aug 31 11:56:15 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Fri, 31 Aug 2018 09:56:15 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> <738A8F0F-5F4C-4D31-8AF9-1A719699D69C@qt.io> Message-ID: <5E684AFF-023C-4933-9F1C-BF03532FD633@qt.io> I think Simon’s reasoning in the review that spurred this discussion summarises it nicely: > On 31 Aug 2018, at 10:24, Simon Hausmann (Code Review) wrote: > > Simon Hausmann has posted comments on this change. > > Change subject: Convert QQEventPoint and QQPointerDevice enums to enum classes > ...................................................................... > > > Patch Set 7: > > As excited I was initially with enum classes, I also start to dislike them when looking at their use. > > The counter example, QQuickPointerDevice::Mouse, is awesome. QQuickPointerDevice::DeviceType::Mouse looks worse. > > Always scoping leads to redundancy and never scoping leads to clashes. Enum classes don't allow us to choose, they force us into the longer names. The previous policy of prefixing _when needed_ gave us the flexibility to have lean names when we could and longer names when required. For example QuickItem::ItemHasContents. > > So in terms of naming I find enum classes not truly winning. Perhaps they make us more lazy in finding the best names, because just putting whatever we have in an enum class "takes care of it". > > The remaining argument in favor of enum classes is the type safety they add. But at least inside Qt I've often seen it become an anti-pattern because we do things in a more low-level fashion and need to cast to an int sometimes, for example. > > Given the names in this very API, I also disagree with commit message statement that the existing scoping is insufficient. (See QQuickPointerDevice::GrabState::GrabExclusive) Based on the disagreement on how and when to use scoped enums, I think we should change the style policy to: - always recommend using scoped enums for global enums - describe the pro’s and con’s of scoped enums inside classes - ask the developer to consider each case individually - and use good judgement in choosing one or the other Tor Arne From pasi.keranen at qt.io Fri Aug 31 12:23:41 2018 From: pasi.keranen at qt.io (=?utf-8?B?UGFzaSBLZXLDpG5lbg==?=) Date: Fri, 31 Aug 2018 10:23:41 +0000 Subject: [Development] Deprecation of Qt Canvas3D in 5.12 Message-ID: We’ve maintained the Canvas3D (a WebGL like API for Qt Quick JavaScript) module with very minimal effort, but when we look at our future it seems clear we need to start supporting multiple low level APIs in Qt’s graphics stack and make our graphics stack less OpenGL centric. This was discussed in the Qt Contributor’s Summit 2018 and has been “in the air” for some time now among developers of Qt 3D, Qt 3D Studio and Qt Quick. Qt will of course still support OpenGL, but it’s not going to be the only API we need to support. To this end Canvas3D with it’s WebGL API that maps nearly 1:1 to OpenGL is no longer a simple API to maintain going in to the future. It would require a major rewrite and a lot more involved design work to map it to new APIs (e.g. Vulcan, DX 12 or Metal). Also there hasn’t been a big uptake in the customers or in the community to use this QML API or the ported three.js javascript 3D engine versions. All in all I think Qt’s graphics stack development effort would be better spent in improving Qt 3D, Qt 3D Studio and Qt Quick, adding enablers in these modules for supporting new graphics APIs etc. So as creator and maintainer of Canvas3D I’d like to propose the deprecation of the module in Qt 5.12 and removal of the module and it’s APIs in a future Qt version. Instead of Qt Canvas3D I’d strongly recommend any existing developers on top of Canvas3D to move on top of Qt 3D or Qt 3D Studio APIs as those are being developed actively, offer much improved performance (especially on resource limited devices) and enable more modern GPU acceleration than is possible with Canvas3D. Regards, Pasi -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eike.Ziller at qt.io Fri Aug 31 12:52:37 2018 From: Eike.Ziller at qt.io (Eike Ziller) Date: Fri, 31 Aug 2018 10:52:37 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: <5E684AFF-023C-4933-9F1C-BF03532FD633@qt.io> References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> <738A8F0F-5F4C-4D31-8AF9-1A719699D69C@qt.io> <5E684AFF-023C-4933-9F1C-BF03532FD633@qt.io> Message-ID: <964E901E-AF3A-4A61-9B44-57D16233F361@qt.io> > On 31. Aug 2018, at 11:56, Tor Arne Vestbø wrote: > > I think Simon’s reasoning in the review that spurred this discussion summarises it nicely: > >> On 31 Aug 2018, at 10:24, Simon Hausmann (Code Review) wrote: >> >> Simon Hausmann has posted comments on this change. >> >> Change subject: Convert QQEventPoint and QQPointerDevice enums to enum classes >> ...................................................................... >> >> >> Patch Set 7: >> >> As excited I was initially with enum classes, I also start to dislike them when looking at their use. >> >> The counter example, QQuickPointerDevice::Mouse, is awesome. QQuickPointerDevice::DeviceType::Mouse looks worse. That could be probably be QQuickPointerDevice::Type::Mouse to kill the redundancy in the name. (I wonder a bit what a device with type Mouse and pointer type Pen would look like btw.) >> >> Always scoping leads to redundancy and never scoping leads to clashes. Enum classes don't allow us to choose, they force us into the longer names. Which at least reduces future surprises. >> The previous policy of prefixing _when needed_ gave us the flexibility to have lean names when we could and longer names when required. For example QuickItem::ItemHasContents. >> >> So in terms of naming I find enum classes not truly winning. Perhaps they make us more lazy in finding the best names, because just putting whatever we have in an enum class "takes care of it”. And maybe not. If you use unscoped enums without prefix, then this can lead to bad names in the future when items must be added to some enum. And also maybe not. >> The remaining argument in favor of enum classes is the type safety they add. But at least inside Qt I've often seen it become an anti-pattern because we do things in a more low-level fashion and need to cast to an int sometimes, for example. IMO especially if you need to pass an enum to API that uses integers once in a while, it is a good thing if you need to make this conversion explicit. >> >> Given the names in this very API, I also disagree with commit message statement that the existing scoping is insufficient. (See QQuickPointerDevice::GrabState::GrabExclusive) > > Based on the disagreement on how and when to use scoped enums, I think we should change the style policy to: > > - always recommend using scoped enums for global enums > - describe the pro’s and con’s of scoped enums inside classes > - ask the developer to consider each case individually > - and use good judgement in choosing one or the other Obviously we have a disagreement on what the “good judgement” is supposed to be though ;) -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Kai.Koehne at qt.io Fri Aug 31 13:39:34 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Fri, 31 Aug 2018 11:39:34 +0000 Subject: [Development] QML API Review Message-ID: Hi, In addition to the C++ API review that Edward has been pushing, we also need to review new/changed QML API. Most of our QML API is actually defined in C++, so one way to review them is diffing the corresponding .h files; however, because they are private (in the C++ sense), every module is free to place these files in different locations. It also misses the information on how exactly the type is registered in the end (think of qmlRegisterXXX). Fortunately, we have another way to inspect QML API: The plugins.qmltypes files that every plugin is supposed to ship alongside. The prime use of these files is to make syntax highlighting and code completion in Qt Creator possible. However, it turns out it's also a very concise way of reviewing new API, so let's use it for that 😊. The .qmltypes files need to be updated manually. I've now run the update for all the .qmltypes files I could find and upload the change for review (see also https://bugreports.qt.io/browse/QTBUG-70264 and linked patches). I suggest to use these patches as the basis for reviewing the QML API. Different from C++, I suggest that if you're happy with the API, please +2 it - The patch will actually be merged in the end. Note that some the plugins.qmltypes files got updated in between, and therefore the patches do not show the full diff to version 5.11. Other plugins.qmltypes files didn't see an update in 5.11, something we should really avoid in the future ☹ In these cases a separate review might be necessary. Anyhow, it turns out that most developers don't update the plugins.qmltypes files, so I suggest to establish this as the new norm, and update them only before the release, as part of the API review process. An alternative would be to make sure that the .qmltypes files are up to date directly before the API review, and include them as part of the C++ diff. Anyhow, this would require us to _not_ instantly fix things in the .qmltypes file when it gets updated, but first check in the plugins.qmltypes file as is - something that can be difficult to accept. So maybe it's just easier to have this as separate diffs. Regards Kai PS: I intend to codify this http://quips-qt-io.herokuapp.com/quip-0010-API-review.html , but first wanted to establish a consensus. -- Kai Koehne, Senior Manager R&D | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B The Future is Written with Qt www.qtworldsummit.com From Shawn.Rutledge at qt.io Fri Aug 31 14:45:56 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Fri, 31 Aug 2018 12:45:56 +0000 Subject: [Development] QML API Review In-Reply-To: References: Message-ID: > On 31 Aug 2018, at 13:39, Kai Koehne wrote: > > Hi, > > In addition to the C++ API review that Edward has been pushing, we also need to review new/changed QML API. > > Most of our QML API is actually defined in C++, so one way to review them is diffing the corresponding .h files; however, because they are private (in the C++ sense), every module is free to place these files in different locations. It also misses the information on how exactly the type is registered in the end (think of qmlRegisterXXX). > > Fortunately, we have another way to inspect QML API: The plugins.qmltypes files that every plugin is supposed to ship alongside. The prime use of these files is to make syntax highlighting and code completion in Qt Creator possible. However, it turns out it's also a very concise way of reviewing new API, so let's use it for that 😊. Yep we got started with that already (at least I found a few things I want to change). > The .qmltypes files need to be updated manually. I've now run the update for all the .qmltypes files I could find and upload the change for review (see also https://bugreports.qt.io/browse/QTBUG-70264 and linked patches). I suggest to use these patches as the basis for reviewing the QML API. Different from C++, I suggest that if you're happy with the API, please +2 it - The patch will actually be merged in the end. But after the changes do you want to rebase and update that same patch, or just have another patch? I was thinking that after API review, changes are likely. So if you want to combine all the changes, your patch will end up dangling for a few weeks or months. I was thinking we could do it twice, once before API review and once before release. On the other hand, if we keep it atomic, then running “gitk plugins.qmltypes” will make it easy to re-review in the future what exactly changed between releases. Maybe that’s a nice feature to have, if it’s worth the trouble? > Note that some the plugins.qmltypes files got updated in between, and therefore the patches do not show the full diff to version 5.11. Other plugins.qmltypes files didn't see an update in 5.11, something we should really avoid in the future ☹ In these cases a separate review might be necessary. > > Anyhow, it turns out that most developers don't update the plugins.qmltypes files, so I suggest to establish this as the new norm, and update them only before the release, as part of the API review process. > > An alternative would be to make sure that the .qmltypes files are up to date directly before the API review, and include them as part of the C++ diff. Anyhow, this would require us to _not_ instantly fix things in the .qmltypes file when it gets updated, but first check in the plugins.qmltypes file as is - something that can be difficult to accept. So maybe it's just easier to have this as separate diffs. You could let git diff do the work: it can compare the latest qmltypes files against the latest on 5.11 branch regardless how many patches modified them. And that could be added to the tool that generates the header diffs. From Jan-Arve.Saether at qt.io Fri Aug 31 14:50:27 2018 From: Jan-Arve.Saether at qt.io (=?Windows-1252?Q?Jan-Arve_S=E6ther?=) Date: Fri, 31 Aug 2018 12:50:27 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: <5E684AFF-023C-4933-9F1C-BF03532FD633@qt.io> References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> <738A8F0F-5F4C-4D31-8AF9-1A719699D69C@qt.io> , <5E684AFF-023C-4933-9F1C-BF03532FD633@qt.io> Message-ID: For me it seems that enum classes can help us create a more structured API, because they also gives more semantic information, e.g: QQuickPointerDevice::PointerType::Finger gives more information than QQuickPointerDevice::Finger For example, when doing code completion if I type "QQuickPointerDevice::" it will give me _all_ members of QQuickPointerDevice (which I always have found a bit annoying), but with an enum class I can type "QQuickPointerDevice::PointerType::" and I will get listed only the valid values (finally). With the extra semantic I can even assume that the associated property for the value QQuickPointerDevice::PointerType::Finger is called pointerType (which it is). (I admit this is not always the case, but maybe it should be a goal). And having it up for discussion for each review whether an enum should be class enums or not just sounds like were planning for lots of bike-shedding ahead. Last, maybe enum classes will lead to more ugly static_cast inside Qt, but that's a cheap price to pay if it gives our users a better API (my point is that a few awkward internal static_cast should not influence how our public API is). my 5 øre --- Jan Arve Sæther Senior Software Engineer ________________________________ Fra: Development på vegne av Tor Arne Vestbø Sendt: fredag 31. august 2018 11.56.15 Til: Alex Blasche Kopi: development at qt-project.org Emne: Re: [Development] Naming convention for (scoped) enums I think Simon’s reasoning in the review that spurred this discussion summarises it nicely: > On 31 Aug 2018, at 10:24, Simon Hausmann (Code Review) wrote: > > Simon Hausmann has posted comments on this change. > > Change subject: Convert QQEventPoint and QQPointerDevice enums to enum classes > ...................................................................... > > > Patch Set 7: > > As excited I was initially with enum classes, I also start to dislike them when looking at their use. > > The counter example, QQuickPointerDevice::Mouse, is awesome. QQuickPointerDevice::DeviceType::Mouse looks worse. > > Always scoping leads to redundancy and never scoping leads to clashes. Enum classes don't allow us to choose, they force us into the longer names. The previous policy of prefixing _when needed_ gave us the flexibility to have lean names when we could and longer names when required. For example QuickItem::ItemHasContents. > > So in terms of naming I find enum classes not truly winning. Perhaps they make us more lazy in finding the best names, because just putting whatever we have in an enum class "takes care of it". > > The remaining argument in favor of enum classes is the type safety they add. But at least inside Qt I've often seen it become an anti-pattern because we do things in a more low-level fashion and need to cast to an int sometimes, for example. > > Given the names in this very API, I also disagree with commit message statement that the existing scoping is insufficient. (See QQuickPointerDevice::GrabState::GrabExclusive) Based on the disagreement on how and when to use scoped enums, I think we should change the style policy to: - always recommend using scoped enums for global enums - describe the pro’s and con’s of scoped enums inside classes - ask the developer to consider each case individually - and use good judgement in choosing one or the other Tor Arne _______________________________________________ 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 Tor.arne.Vestbo at qt.io Fri Aug 31 15:09:40 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Fri, 31 Aug 2018 13:09:40 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> <738A8F0F-5F4C-4D31-8AF9-1A719699D69C@qt.io> <5E684AFF-023C-4933-9F1C-BF03532FD633@qt.io> Message-ID: <8FFD2C1B-9E0C-431E-9C43-0AF33D82B89F@qt.io> Hey, > On 31 Aug 2018, at 14:50, Jan-Arve Sæther wrote: > > For me it seems that enum classes can help us create a more structured API, because they also gives more semantic information, e.g: > QQuickPointerDevice::PointerType::Finger > gives more information than > QQuickPointerDevice::Finger Again, showing the enum like this leaves out context that is usually there in real code: if (ev->pointerType() == QQuickPointerDevice::Finger) At which point the “more semantic information”, becomes “redundant semantic information”: if (ev->pointerType() == QQuickPointerDevice::PointerType::Finger) > For example, when doing code completion if I type "QQuickPointerDevice::" it will give me _all_ members of QQuickPointerDevice (which I always have found a bit annoying), but with an enum class I can type "QQuickPointerDevice::PointerType::" and I will get listed only the valid values (finally). Code completion should be able to look at the type you are comparing with (as above), and list the relevant enum values first (or only). We do that for function arguments don’t we, when suggesting variables to pass e.g.? > With the extra semantic I can even assume that the associated property for the value QQuickPointerDevice::PointerType::Finger is called pointerType (which it is). (I admit this is not always the case, but maybe it should be a goal). Do you often go from enum value to property name? (Related but orthogonal, I notice our docs do not point back from an enum to functions that reference it. Perhaps there should be some automatic resolving there based on properties e.g. so that one doesn’t have to do \sa manually?) > And having it up for discussion for each review whether an enum should be class enums or not just sounds like were planning for lots of bike-shedding ahead. Is it better to forcefully enforce a coding style that is contended, and that might hurt code readability and our APIs, just to not “have to think”? > Last, maybe enum classes will lead to more ugly static_cast inside Qt, but that's a cheap price to pay if it gives our users a better API (my point is that a few awkward internal static_cast should not influence how our public API is). What if it gives our users a _worse_ API? How does that balance look? Should we pay for that too? My -5 øre 😊 Tor Arne From jhihn at gmx.com Fri Aug 31 15:26:06 2018 From: jhihn at gmx.com (Jason H) Date: Fri, 31 Aug 2018 15:26:06 +0200 Subject: [Development] QML API Review In-Reply-To: References: Message-ID: Is this why in Qt Creator some very basic things and non basic things are underlined/don't autocomplete on various platforms? Ex: (on iOS) import QtQuick 2.11 import QtQuick.Window 2.11 // QML module not found(...) import QtWebView 1.1 // QML module not found(...) import QtMultimedia 5.9 // QML module not found(...) import QtSensors 5.11 // QML module not found(...) I'd have thought by now that these modules would be found. In addition, QtSensors will auto-complete, but Creator only offers up to version 5.9. It's a similar situation on Android. Would this fall under the API review? > Sent: Friday, August 31, 2018 at 7:39 AM > From: "Kai Koehne" > To: "development at qt-project.org" > Subject: [Development] QML API Review > > Hi, > > In addition to the C++ API review that Edward has been pushing, we also need to review new/changed QML API. > > Most of our QML API is actually defined in C++, so one way to review them is diffing the corresponding .h files; however, because they are private (in the C++ sense), every module is free to place these files in different locations. It also misses the information on how exactly the type is registered in the end (think of qmlRegisterXXX). > > Fortunately, we have another way to inspect QML API: The plugins.qmltypes files that every plugin is supposed to ship alongside. The prime use of these files is to make syntax highlighting and code completion in Qt Creator possible. However, it turns out it's also a very concise way of reviewing new API, so let's use it for that 😊. > > The .qmltypes files need to be updated manually. I've now run the update for all the .qmltypes files I could find and upload the change for review (see also https://bugreports.qt.io/browse/QTBUG-70264 and linked patches). I suggest to use these patches as the basis for reviewing the QML API. Different from C++, I suggest that if you're happy with the API, please +2 it - The patch will actually be merged in the end. > > Note that some the plugins.qmltypes files got updated in between, and therefore the patches do not show the full diff to version 5.11. Other plugins.qmltypes files didn't see an update in 5.11, something we should really avoid in the future ☹ In these cases a separate review might be necessary. > > Anyhow, it turns out that most developers don't update the plugins.qmltypes files, so I suggest to establish this as the new norm, and update them only before the release, as part of the API review process. > > An alternative would be to make sure that the .qmltypes files are up to date directly before the API review, and include them as part of the C++ diff. Anyhow, this would require us to _not_ instantly fix things in the .qmltypes file when it gets updated, but first check in the plugins.qmltypes file as is - something that can be difficult to accept. So maybe it's just easier to have this as separate diffs. > > Regards > > Kai > > PS: I intend to codify this http://quips-qt-io.herokuapp.com/quip-0010-API-review.html , but first wanted to establish a consensus. > > -- > Kai Koehne, Senior Manager R&D | The Qt Company > > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, > HRB 144331 B > > The Future is Written with Qt > www.qtworldsummit.com > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From Marco.Bubke at qt.io Fri Aug 31 20:47:42 2018 From: Marco.Bubke at qt.io (Marco Bubke) Date: Fri, 31 Aug 2018 18:47:42 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: <8FFD2C1B-9E0C-431E-9C43-0AF33D82B89F@qt.io> References: <20180517103538.221f0e85@ckandeler-archlinux> <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> <27E5CA21-5411-4B8B-A92C-BEA1C97944A7@qt.io> <580CA5C8-559E-4604-93ED-8C05C4D5EE91@qt.io> <738A8F0F-5F4C-4D31-8AF9-1A719699D69C@qt.io> <5E684AFF-023C-4933-9F1C-BF03532FD633@qt.io> <8FFD2C1B-9E0C-431E-9C43-0AF33D82B89F@qt.io> Message-ID: Enumerations inside of classes makes dependency breaking harder. We don't use that in Qt but users of our interface may do. It's still possible but much more complex because you generally get much more dependencies. A simple header file for enumerations instead can simply be included without any additional dependencies.