> On 1 Nov 2020, at 01:19, Kevin Kofler via Development > <[email protected]> wrote: > > Really, it is this whole concept of the user choosing a version of Qt that > is flawed. The right place to make this choice is the build system of the > software using Qt.
Sorry for snipping so much, but it seems like all your arguments are about tools that are used to build software (qmake, moc etc.). And you have a point there. But I don’t see the point of renaming user-facing tools like assistant, qml, qtdiag and pixeltool. So I hope at least those will be spared. When it comes to the actual suffix to add, why use -qt6 instead of just 6? BTW java still works without having to add some clumsy suffix. /usr/bin/javac -> /usr/lib/jfm/default/bin/javac for example. I can see which version it is with the -version argument. I guess there aren't enough compatibility breaks to justify suffixing? But we are also trying to avoid it. > If any changes are needed to make qtchooser work with Qt 6, then I suggest > that those like you who want to keep using it fork it and make those > required changes. It is Free Software. I might have to do that if there’s no other choice. > The anti-pattern there is really that you as the user have to pick the > version of Python at all. The Python scripts ought to have the correct > #!/usr/bin/env python2 or #!/usr/bin/env python3 shebang. (There too, the > script *knows* which version of Python it needs and ought to just work.) Yes, I agree. They are somewhat incompatible after all. At least they only added one digit to the interpreter’s name. > Can you also use shebangs for QML? (If not, then the interpreter ought to be > fixed to allow them, it just needs to ignore the shebang line if it is not > already treated as a comment.) You can, but there is resistance against this idea, even though it’s basically the Unix standard for how to run a script. The reason it works is that the qml tool handles the arguments and strips that line off before it goes to the QML parser. The parser itself doesn’t treat # as a comment-beginning character, so you can’t let it see that. (And thus if your main.qml starts with a shebang, you can’t package it into resources as-is.) I have argued that all we need is for the parser to ignore any lines that begin with # at the beginning of the qml file, but so far this request has fallen on deaf ears. It would really be as simple as that; I don’t think we need to support hash-comments after the actual qml code begins. It’s probably only the lack of a couple of lines of code that stand in the way. Also, this mantra “QML is not a scripting language”… that’s just a matter of perspective really. IMO since you can run it with an interpreter, which includes JS, it’s a scripting language. Many features are missing, there are many things you can’t do without some ad-hoc C++ modules (ordinary file I/O and such) but perhaps that’s just a matter of time, and demand from the users, until those things get added. My favorite languages are the ones that can run either way: interpreted or compiled. And preferably without writing boilerplate like main.cpp. But we seem to have a lack of faith holding us back for some reason. OTOH maybe we are just afraid of embarrassment when somebody gets the idea of emailing a qml virus and tempting users to double-click it. So let’s hope shebang keeps working at least to the extent that it already does; then there’s the matter of module versions. You can write a qml program that will be portable between Qt 5 and 6 (especially 5.15 and 6, because some newer syntax is already available, to make the migration smoother), as long as you stick to modules that are still being maintained and have compatible API (i.e. Controls 2 is OK, but qtlocation qtmultimedia qtcharts etc. are uncertain until they have maintainers again). The imports don’t even need version numbers anymore. This isn’t like going from python 2 to 3, unless you use strict mode, or you want new API from some module. But every language has some sort of modules which can introduce new features sometimes. _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
