Re: [Development] Qt 6 co-installability with Qt 5
On Wednesday, 28 October 2020 01:15:33 PDT Lars Knoll wrote: > > On 28 Oct 2020, at 08:37, Allan Sandfeld Jensen wrote: > > > > On Dienstag, 27. Oktober 2020 17:34:44 CET Thiago Macieira wrote: > >> Have we fixed it? > >> > >> I do not plan on updating qtchooser for Qt 6. Qt 6 should not install any > >> binary with the same name as Qt 5 did. > > > > Do we need to change the default name of moc and uic then? > > The solution we have with qtchooser works also for Qt 6 for those > applications. Is there a reason to change this? qtchooser is EOL and should not be used for Qt 6. The solution for Qt 6 must not use it. See the problem statement as I outlined in the email to Shawn. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6 co-installability with Qt 5
On Wednesday, 28 October 2020 04:05:25 PDT Shawn Rutledge wrote: > I meant the symlinks pointing to qtchooser, for people who use it. > > Otherwise I’m not sure what you meant about “not updating” qtchooser. qtchooser manages the symlinks. I don't want to update qtchooser, which means I don't want to add the new set of symlinks. > > Either all Qt binaries get installed into the libdir > > and are not accessible via $PATH, or they all get a "-qt6" suffix. > > I get the impression qtchooser is not popular among distro maintainers; in Correct, it isn't. We must move away from it. The solution for Qt 6 must not depend on it. So here's the problem statement: assuming all Qt 5 binaries are already installed in CMAKE_INSTALL_BINDIR (/usr/bin), install Qt 6 without replacing any file that is already there. The same applies to any libraries, plugins, and CMake files, but those already have a different name. > practice it’s mainly been up to people who want to be able to switch > quickly and often between qt versions to install it themselves. (There was > a period when Arch had it; then they took it away again.) Consequently I > have to install the symlinks pointing to qtchooser into some place that > comes earlier in the path than /usr/bin, and it’s easier if that is a > location where I don’t need sudo to make the links either. Usually I have > /usr/local/bin and ~/bin both coming earlier in my PATH, so installing > qtchooser in either of those is OK for me. But I’m open to better ideas. Which tools do you often run manually? I find that I only run: * qdbus * qmake * qplugininfo * qtdiag I don't run these but I suspect other people do: * assistant * designer * linguist * qtpaths * qml & qmlscene And of those, qmake is by far the most common, by at least 10x compared to the second place. All of the rest are development tools only. I've run moc manually in the past, but that's when I was checking what output it produced. > On Debian there’s /etc/alternatives, so what’s wrong if Qt binaries get > installed into some location that’s not in the PATH, the /usr/bin symlinks > point to Qt 6 binaries by default (via /etc/alternatives on distros that > have it), and then you switch Qt versions with the standard distro > mechanism? (Is there a user-specific alternative?) Meanwhile, > applications that need Qt 5 link against Qt 5 libs (different mechanisms > might apply), and don’t necessarily need any Qt-installed binaries from > PATH, right? And those who want to install qtchooser just need to set up > its config files if the distro doesn’t provide them; it works with any lib > path and any binary path, but can’t deal with binaries being renamed > AFAIK. Because Debian Alternatives are a system-wide configuration and requires one to be the superuser to apply. This is what qtchooser attempted to fix, by making it entirely under the control of a user and modifiable with just the environment. So Alternatives is not a solution. We need an answer to the problem statement as posed above. > In any case I don’t particularly want to need to type “qml6” on the command > line to run the qml interpreter, if it can be avoided. When I think about > how often I have had to switch the python symlink to point to either > python2 or python3 because of some script that made an assumption or was > written before python3 existed: that’s an anti-pattern IMO. And I hope our > transition is not going to take as long as that one has, either. ;-) Unfortunately, you will have to because the plugins are different. QML is not a scripting language, you cannot assume that the plugins that exist for QML on Qt 6 are present in the plugins that exist on QML for Qt 5. This is also the reason why Qt Designer needs a different name too. For the sake of muscle memory, Qt installation may add unsuffixed binaries elsewhere in the system, allowing you to modify $PATH. But to CMAKE_INSTALL_BINDIR you cannot install any binaries that Qt 5 already has. The only tools that are truly version-independent are qdbus and Linguist. All the rest are tied to the specific Qt version. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposing Alex Trotsenko as approver
Congratulations to Alex. Approver rights have been granted. -- Alex > -Original Message- > From: Development On Behalf Of > André Hartmann > Sent: Thursday, 17 September 2020 11:37 > To: development@qt-project.org; alex197...@gmail.com > Subject: [Development] Proposing Alex Trotsenko as approver > > Hi all, > > I like to propose Alex Trotsenko as approver. > > Alex has been contributing to Qt since 2014, and has done *a lot* of low level > optimization and fixes. He has a deep knowledge of QIODevice, Q*Socket, > QProcess, and related classes. > > Furthermore, he is also an active and helpful reviewer. His constructive > feedback > makes changes better and improves the overall Qt quality. > > All this makes me believe he will be a good approver. > > Now the interesting part: > > His patches: > https://codereview.qt-project.org/q/owner:alex1973tr%2540gmail.com > > And his reviews: > https://codereview.qt-project.org/q/reviewer:alex1973tr%2540gmail.com > > Best regards, > André > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Inho Lee as an approver
+1 > On 28 Oct 2020, at 13:53, Andy Nichols wrote: > > +1 from Me. > > Inho has been a great contributor to Qt Quick 3D module over the last year. > He’s done a wonderful job working on the animation support and making sure > that features from GLTF2 work correctly. > He also does a great job in his reviews, so I have no hesitation recommending > him as an approver. > > Regards, > Andy Nichols > > From: Development On Behalf Of Paul Tvete > Sent: Wednesday, October 28, 2020 1:43 PM > To: Qt development mailing list > Subject: [Development] Nominating Inho Lee as an approver > > Hi all, > > I would like to nominate Inho Lee as an approver for the Qt Project. > > Inho has been working for the Qt Company for over a year now, and he has > contributed extensively to Qt Quick 3D during this time. > > Here is the list of his commits on Gerrit: > https://codereview.qt-project.org/q/owner:inho.lee%2540qt.io > > Disclaimer: I share an office with Inho, or at least did back when offices > were a thing. > > Best regards, > > - Paul > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Inho Lee as an approver
+1 from Me. Inho has been a great contributor to Qt Quick 3D module over the last year. He's done a wonderful job working on the animation support and making sure that features from GLTF2 work correctly. He also does a great job in his reviews, so I have no hesitation recommending him as an approver. Regards, Andy Nichols From: Development On Behalf Of Paul Tvete Sent: Wednesday, October 28, 2020 1:43 PM To: Qt development mailing list Subject: [Development] Nominating Inho Lee as an approver Hi all, I would like to nominate Inho Lee as an approver for the Qt Project. Inho has been working for the Qt Company for over a year now, and he has contributed extensively to Qt Quick 3D during this time. Here is the list of his commits on Gerrit: https://codereview.qt-project.org/q/owner:inho.lee%2540qt.io Disclaimer: I share an office with Inho, or at least did back when offices were a thing. Best regards, - Paul ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Nominating Inho Lee as an approver
Hi all, I would like to nominate Inho Lee as an approver for the Qt Project. Inho has been working for the Qt Company for over a year now, and he has contributed extensively to Qt Quick 3D during this time. Here is the list of his commits on Gerrit: https://codereview.qt-project.org/q/owner:inho.lee%2540qt.io Disclaimer: I share an office with Inho, or at least did back when offices were a thing. Best regards, - Paul ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6 co-installability with Qt 5
> On 27 Oct 2020, at 20:33, Thiago Macieira wrote: > > On Tuesday, 27 October 2020 10:06:32 PDT Shawn Rutledge wrote: >>> On 27 Oct 2020, at 17:34, Thiago Macieira >>> wrote: > >>> Have we fixed it? >>> >>> I do not plan on updating qtchooser for Qt 6. Qt 6 should not install any >>> >>> binary with the same name as Qt 5 did. >> >> >> Well I still use it for Qt 6. It works fine, but I suppose we’ve added some >> new binaries that need symlinks. > > No symlinks necessary. I meant the symlinks pointing to qtchooser, for people who use it. Otherwise I’m not sure what you meant about “not updating” qtchooser. > Either all Qt binaries get installed into the libdir > and are not accessible via $PATH, or they all get a "-qt6" suffix. I get the impression qtchooser is not popular among distro maintainers; in practice it’s mainly been up to people who want to be able to switch quickly and often between qt versions to install it themselves. (There was a period when Arch had it; then they took it away again.) Consequently I have to install the symlinks pointing to qtchooser into some place that comes earlier in the path than /usr/bin, and it’s easier if that is a location where I don’t need sudo to make the links either. Usually I have /usr/local/bin and ~/bin both coming earlier in my PATH, so installing qtchooser in either of those is OK for me. But I’m open to better ideas. On Debian there’s /etc/alternatives, so what’s wrong if Qt binaries get installed into some location that’s not in the PATH, the /usr/bin symlinks point to Qt 6 binaries by default (via /etc/alternatives on distros that have it), and then you switch Qt versions with the standard distro mechanism? (Is there a user-specific alternative?) Meanwhile, applications that need Qt 5 link against Qt 5 libs (different mechanisms might apply), and don’t necessarily need any Qt-installed binaries from PATH, right? And those who want to install qtchooser just need to set up its config files if the distro doesn’t provide them; it works with any lib path and any binary path, but can’t deal with binaries being renamed AFAIK. In any case I don’t particularly want to need to type “qml6” on the command line to run the qml interpreter, if it can be avoided. When I think about how often I have had to switch the python symlink to point to either python2 or python3 because of some script that made an assumption or was written before python3 existed: that’s an anti-pattern IMO. And I hope our transition is not going to take as long as that one has, either. ;-) ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Codereview maintenance break on Monday 2-Nov 7:00 am CET
Hi, As the Qt CI will have its monthly maintenance break on Monday 2-Nov, we take the opportunity and upgrade the Gerrit to the latest patch version 3.1.8 at the same time. The maintenance break starts Monday 2-Nov 7:00 am CET and the tool is expected to be back online 8:00 am CET --Jukka, Gerrit Admin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] HEADS UP : Qt 6.0 soft string freeze
Hi all, First beta releases from Qt 6.0 are already out so it is time to start keeping translatable strings as it is. Official string freeze will be in effect Wed 4th November 2020. br, Jani Heikkinen Release Manager ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6 co-installability with Qt 5
On Mittwoch, 28. Oktober 2020 09:15:33 CET Lars Knoll wrote: > > On 28 Oct 2020, at 08:37, Allan Sandfeld Jensen wrote: > > > > On Dienstag, 27. Oktober 2020 17:34:44 CET Thiago Macieira wrote: > >> Have we fixed it? > >> > >> I do not plan on updating qtchooser for Qt 6. Qt 6 should not install any > >> binary with the same name as Qt 5 did. > > > > Do we need to change the default name of moc and uic then? > > The solution we have with qtchooser works also for Qt 6 for those > applications. Is there a reason to change this? > Just seems better if the development packages could be installed in parallel by linux distros, without them having to do the renaming themselves. Though then we should also consider where we install headers. I guess we can leave up it to distros to fix themselves once more. 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6 co-installability with Qt 5
> On 28 Oct 2020, at 08:37, Allan Sandfeld Jensen wrote: > > On Dienstag, 27. Oktober 2020 17:34:44 CET Thiago Macieira wrote: >> Have we fixed it? >> >> I do not plan on updating qtchooser for Qt 6. Qt 6 should not install any >> binary with the same name as Qt 5 did. > > Do we need to change the default name of moc and uic then? The solution we have with qtchooser works also for Qt 6 for those applications. Is there a reason to change this? Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6 co-installability with Qt 5
On Dienstag, 27. Oktober 2020 17:34:44 CET Thiago Macieira wrote: > Have we fixed it? > > I do not plan on updating qtchooser for Qt 6. Qt 6 should not install any > binary with the same name as Qt 5 did. Do we need to change the default name of moc and uic then? Best regards Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
