Re: [Development] Nominating Inho Lee as an approver

[Alex Blasche]

Congratulations to Inho Lee. Approver rights have been set.

--
Alex


From: Development  on behalf of Paul Tvete 

Sent: Wednesday, 28 October 2020 13:43
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

Re: [Development] Qt 6 co-installability with Qt 5

[Joerg Bornemann]

On 11/18/20 12:49 AM, Lisandro Damián Nicanor Pérez Meyer wrote:


You need to have a host Qt installed, including qmake.
The cross-built Qt's qmake is a wrapper script that calls the host Qt's
qmake and passes a qt.conf file, adjusting qmake's properties.
This wrapper script in the cross-built Qt is currently named "qmake" and
currently lives in $prefix/bin.


Sounds like $prefix/bin/qmake6 is feasible, even maybe *always* a
script that calls the host's qmake installed in $bindir except when
passed the right qt.conf file. Would that work? That would also mean
avoiding installing the real qmake in $prefix/bin and it's prefix.


$prefix/bin/qmake6 can also be a wrapper script, sure.
What would be the advantage of not installing the actual qmake binary there?


Cheers,

Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Joerg Bornemann]

On 11/18/20 12:41 AM, Lisandro Damián Nicanor Pérez Meyer wrote:


Tools I don't know if they should or shouldn't be in this list:

- pixeltool: it's a screen magnifier, never used it before, but
clearly not something used at build time. Sounds like a user-facing
app for me.


That's not a tool for the user of Qt.
This is used for squinting at UI elements when debugging visual issues.


Cheers,

Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Development Digest, Vol 110, Issue 43

[Arnaud Clère]

Le mer. 18 nov. 2020 à 08:36,  a écrit :

> -- Forwarded message --
> From: Thiago Macieira 
> On Tuesday, 17 November 2020 15:41:10 PST Lisandro Damián Nicanor Pérez
> Meyer wrote:
> > - qtplugininfo: I sincerely don't know how it's being used.
>
> I was going to suggest it, but I ended up thinking it was obscure enough
> that
> for anyone who really needs it, they can use
>
> `qtpaths6 --binaries-dir`/qtplugininfo
>
> > - qtwaylandscanner: same as above.
> > - tracegen: same as above
>
> Ditto and even less likely to be used.
>

Just for information tracegen is used for high-performance tracing as
described here:
https://www.kdab.com/wp-content/uploads/stories/QtWS2019-Milian-Wolff-Full-Stack-Tracing-With-LTTng.pdf
And used in conjunction with Q_TRACE:
https://code.woboq.org/qt5/qtbase/src/corelib/global/qtrace_p.h.html
As in QObject

::QObject

(QObject

*parent) :
https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qobject.cpp.html#870
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lars Knoll]

On 18 Nov 2020, at 00:41, Lisandro Damián Nicanor Pérez Meyer 
mailto:perezme...@gmail.com>> wrote:

On Tue, 17 Nov 2020 at 14:09, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

On Tuesday, 27 October 2020 09:34:44 PST 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.

Lars and I just had a quick discussion on IRC about this and here's what we
propose. Ground rules and caveats:

1) MOST tools do not need to be in $PATH for most users. We developers are not
most users. For us, setting PATH is acceptable. We're also likely the only
audience to have more than one 5.x or 6.x Qt version installed.

2) This recommendation need not be supported by the buildsystem in time for
6.0.0, but needs to be as early as possible and by 6.1 at the latest. This
recommendation allows Linux distributions to apply workarounds meanwhile,
other buildsystems to adjust (read: Meson), and for us to write docs and QUIP.

3) there's a question of cross-compilation relating to qmake and host tools,
which I have not followed and do not understand the current state of. Need
input here.

With that in mind, our recommendation is as follows:

a) ALL tools be installed to a binary directory that is not $prefix/bin
b) SOME tools be symlinked/hardlinked/stubbed into $prefix/bin, with a suffix
 (we recommend a simple "6" instead of "-qt6")
c) ADDITIONALLY, some further tools can be present unsuffixed

Thinking a bit more about this, I wonder how many applications _really_ need a 
version.

To start with, I think it’s important to recognise a difference between 
developer oriented tools and tools targeting end users.

Most of our developer oriented tools are (or can be) dependent on the exact 
version of Qt installed. Thus the problem is larger than just a Qt 5 vs Qt 6 
thing.

Those tools should just stay in a version specific directory and should IMO not 
be exposed in the generic path for end users (moc should for example never end 
up in /usr/bin). Instead the correct version is found by the build system and 
called from there. And developers needing direct access to them should adjust 
their path to include those tools.

For most end user facing tools, I wonder whether we actually need to support 
co-installation. The examples listed just below (linguist etc.) are backwards 
compatible, and it should be ok to simply install the latest version, similar 
to what is done with qtcreator.

Once we have that, the question is what is left that actually has to have a 
versioned name?


The question is what tools are those in lists (b) and (c). Starting with the
easiest (c):
- linguist
- qdbus
- qdbusviewer

Those are user-facing tools that definitely do not depend on Qt version. It's
up to the implementer to decide which Qt version they want these tools to be
and any choice is fine. My guess is that for two of the three, it will depend
mostly on Look-and-Feel with the desktop. But since these are an implementer's
choice, Qt installation never installs those tools with the unsuffixed names
by default.

Agreed to all above.

Then there's the question of which tools we recommend be in $PATH with a
suffix (list (b)). Please expand on this list if necessary, with a reason.
Here's the minimum list:

qmake6 entry point for building qmake-based applications, situation
   similar to /usr/bin/python (see [1])

I am not yet 100% convinced it is. This is a build tool after all, and even 
changes with minor versions of Qt. I know Linux distributions do only ship one 
minor version, but many of our users have to manage multiple minor versions of 
Qt as well. And renaming qmake with every minor version is a no-go.

qml6   I don't understand why, but I'm told it's necessary

It’s a runtime for running qml files without a C++ entry point. But we can 
actually decide that this is a developer oriented tool and not have it linked 
into /usr/bin.

qtdiag6entry point for debugging problems with Qt 6
qtpaths6   because knowing the path in order to run the tool to get
   paths sounds weird. Having this in $PATH allows us to
   help users get to the other, debugging tools (qtplugininfo,
   qmlplugindump, etc.)

Possibly also:

assistant6 for reading Qt 6 help files when not using Qt Creator
designer6  for those not using Qt Creator and needing to use Qt 6 plugins

Offtopic, but I wonder how much those standalone apps are still being used 
today.

Also agreed. I would consider assistant6 and designer6 to be included
in list (b) due to past experience.

Tools I don't know if they should or shouldn't be in this list:

- pixeltool: it's a screen magnifier, never used it before, but
clearly not something used at build time. Sounds like a user-facing
app for me.

- qtplugininfo: I sincerely don't know how it's being used.

- qtwaylandscanner: same as above.

- tracegen: same as a

Re: [Development] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

Morning,

IMHO, suffixing our binaries is a kludge. It “solves” the major version 
transition, but not any of the other use cases such as minor version upgrades, 
different builds of the same Qt version, etc.

Qt Creator already provides a way to manage and switch Qt versions: 
https://doc.qt.io/qtcreator/creator-project-qmake.html

What we need is a command line tool for doing the same. That’s how other 
project solve things too (nvm, rvm, pyenv, etc). And we already have a tool for 
that, qtchooser. If maintenance of that is an issue, then let’s solve that.

Why is that not an acceptable solution for distros?

Tor Arne

On 27 Oct 2020, at 17:34, Thiago Macieira 
mailto:thiago.macie...@intel.com>> 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.

--
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

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

On 18 Nov 2020, at 12:11, Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:

What we need is a command line tool for doing the same. That’s how other 
project solve things too (nvm, rvm, pyenv, etc)

For some context:

  *   https://github.com/nvm-sh/nvm
  *   https://rvm.io/
  *   https://github.com/rbenv/rbenv/
  *   https://github.com/pyenv/pyenv
  *   
https://doc.rust-lang.org/edition-guide/rust-2018/rustup-for-managing-rust-versions.html
  *   https://github.com/kylef/swiftenv

Some of these tools modify PATH on behalf of the user, while others add a 
custom directory to the PATH where they then swap symlinks around (which is how 
qtchooser works as far as I know?).

They also allow per project (local) version pinning, which can be useful.

Tor Arne






___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Wed, 18 Nov 2020 at 06:02, Joerg Bornemann  wrote:
>
> On 11/18/20 12:49 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
>
> >> You need to have a host Qt installed, including qmake.
> >> The cross-built Qt's qmake is a wrapper script that calls the host Qt's
> >> qmake and passes a qt.conf file, adjusting qmake's properties.
> >> This wrapper script in the cross-built Qt is currently named "qmake" and
> >> currently lives in $prefix/bin.
> >
> > Sounds like $prefix/bin/qmake6 is feasible, even maybe *always* a
> > script that calls the host's qmake installed in $bindir except when
> > passed the right qt.conf file. Would that work? That would also mean
> > avoiding installing the real qmake in $prefix/bin and it's prefix.
>
> $prefix/bin/qmake6 can also be a wrapper script, sure.
> What would be the advantage of not installing the actual qmake binary there?

None, I've realized it after sending the mail.



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Giuseppe D'Angelo via Development]

Il 18/11/20 12:03, Lars Knoll ha scritto:


- tracegen: same as above


Is tracegen of any usage outside Qt itself?

Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@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



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi Lars!

On Wed, 18 Nov 2020 at 08:03, Lars Knoll  wrote:
[snip]
> Thinking a bit more about this, I wonder how many applications _really_ need 
> a version.
>
> To start with, I think it’s important to recognise a difference between 
> developer oriented tools and tools targeting end users.
>
> Most of our developer oriented tools are (or can be) dependent on the exact 
> version of Qt installed. Thus the problem is larger than just a Qt 5 vs Qt 6 
> thing.
>
> Those tools should just stay in a version specific directory and should IMO 
> not be exposed in the generic path for end users (moc should for example 
> never end up in /usr/bin). Instead the correct version is found by the build 
> system and called from there. And developers needing direct access to them 
> should adjust their path to include those tools.

Well, that's a huge change from what was discussed before, specially
when I brought this topic in Qt 5.0 (which I had forgotten, Thiago
made me remember). Yes, of course, if we can decide that most of the
tools are for developers only and can live outside $prefix/bin then
it's definitely another way to solve this issue. And in fact it might
be a much better solution.

So basically:

- Move out of $prefix/bin (and thus out of $PATH) every developer-oriented tool.
- Ensure that user-facing applications will be backwards compatible
with Qt 5 for all the Qt 6 timeline.

> For most end user facing tools, I wonder whether we actually need to support 
> co-installation. The examples listed just below (linguist etc.) are backwards 
> compatible, and it should be ok to simply install the latest version, similar 
> to what is done with qtcreator.

Yes if backwards compatibility is assured. Last time we discussed this
(for 5.0 if my memory does not fails me) designer was considered a
tool that needed to be on $PATH. When Qt5's designer arrived it
supported Qt4's plugins... for some time.

But then I wonder if designer shouldn't stay on $PATH or not. Because
even if it's a developer tool it's one expected to be on $PATH much
like Qt Creator. The developer tools that can stay out of $PATH are
the ones that can be easily callable from within toolchains (qmake,
cmake, etc). But then again we distros could simply make a
$prefix/bin/designer6 symlink. Telling our users "just use designer6"
it's really not a big deal, even if the docs just say "designer".

[snip]
> Then there's the question of which tools we recommend be in $PATH with a
> suffix (list (b)). Please expand on this list if necessary, with a reason.
> Here's the minimum list:
>
> qmake6 entry point for building qmake-based applications, situation
>similar to /usr/bin/python (see [1])
>
>
> I am not yet 100% convinced it is. This is a build tool after all, and even 
> changes with minor versions of Qt. I know Linux distributions do only ship 
> one minor version, but many of our users have to manage multiple minor 
> versions of Qt as well. And renaming qmake with every minor version is a 
> no-go.

Well, that's the exact opposite reply I've got (from Ossi?) on Qt 5.0
times. qmake needed to be on path in order to be able to query it for
some paths. But if that's no longer the case then yes, it can stay
away.

> qml6   I don't understand why, but I'm told it's necessary
>
>
> It’s a runtime for running qml files without a C++ entry point. But we can 
> actually decide that this is a developer oriented tool and not have it linked 
> into /usr/bin.

Still a tool that is expected to be called by humans though. And then
again we could easily keep a $prefix/bin/qml6 link.

> qtdiag6entry point for debugging problems with Qt 6
> qtpaths6   because knowing the path in order to run the tool to get
>paths sounds weird. Having this in $PATH allows us to
>help users get to the other, debugging tools (qtplugininfo,
>qmlplugindump, etc.)
>
> Possibly also:
>
> assistant6 for reading Qt 6 help files when not using Qt Creator
> designer6  for those not using Qt Creator and needing to use Qt 6 plugins
>
>
> Offtopic, but I wonder how much those standalone apps are still being used 
> today.

designer: a lot, specially if your screen does not has enough
resolution to use it embedded within Qt Creator. That's exactly my
case (yes, I sadly still have an old machine, the same I used in Qt
5.0 times ;-) )

> Also agreed. I would consider assistant6 and designer6 to be included
> in list (b) due to past experience.
>
> Tools I don't know if they should or shouldn't be in this list:
>
> - pixeltool: it's a screen magnifier, never used it before, but
> clearly not something used at build time. Sounds like a user-facing
> app for me.
>
> - qtplugininfo: I sincerely don't know how it's being used.
>
> - qtwaylandscanner: same as above.
>
> - tracegen: same as above
>
> - sdpscanner: "Performs an SDP scan on remote device, using the SDP server
> represented by the local Blueto

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi Tor!

On Wed, 18 Nov 2020 at 08:13, Tor Arne Vestbø  wrote:
>
> Morning,
>
> IMHO, suffixing our binaries is a kludge. It “solves” the major version 
> transition, but not any of the other use cases such as minor version 
> upgrades, different builds of the same Qt version, etc.

It's only about solving the major version, ie, the end-users version
provided by distributions. The cases you mention are mostly
developer-oriented.

> Qt Creator already provides a way to manage and switch Qt versions: 
> https://doc.qt.io/qtcreator/creator-project-qmake.html

Not everyone uses Creator.

> What we need is a command line tool for doing the same. That’s how other 
> project solve things too (nvm, rvm, pyenv, etc). And we already have a tool 
> for that, qtchooser. If maintenance of that is an issue, then let’s solve 
> that.
>
> Why is that not an acceptable solution for distros?

Because it breaks things:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=qtchooser and form
that list specially
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712264 which is a
per-design bug, ie, it can't be solved.

That doesn't means developers can still use it though.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Wed, 18 Nov 2020 at 08:58, Tor Arne Vestbø  wrote:
>
>
> On 18 Nov 2020, at 12:11, Tor Arne Vestbø  wrote:
>
> What we need is a command line tool for doing the same. That’s how other 
> project solve things too (nvm, rvm, pyenv, etc)
>
>
> For some context:
>
> https://github.com/nvm-sh/nvm
> https://rvm.io/
> https://github.com/rbenv/rbenv/
> https://github.com/pyenv/pyenv
> https://doc.rust-lang.org/edition-guide/rust-2018/rustup-for-managing-rust-versions.html
> https://github.com/kylef/swiftenv
>
> Some of these tools modify PATH on behalf of the user, while others add a 
> custom directory to the PATH where they then swap symlinks around (which is 
> how qtchooser works as far as I know?).
>
> They also allow per project (local) version pinning, which can be useful.

Right, and this are all developer's tools. End users shouldn't care
nor even know about them. Remember, we are talking about
distribution-provided binaries.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 18 Nov 2020 at 09:34, Lisandro Damián Nicanor Pérez Meyer
 wrote:
[snip]
> > Then there's the question of which tools we recommend be in $PATH with a
> > suffix (list (b)). Please expand on this list if necessary, with a reason.
> > Here's the minimum list:
> >
> > qmake6 entry point for building qmake-based applications, situation
> >similar to /usr/bin/python (see [1])
> >
> >
> > I am not yet 100% convinced it is. This is a build tool after all, and even 
> > changes with minor versions of Qt. I know Linux distributions do only ship 
> > one minor version, but many of our users have to manage multiple minor 
> > versions of Qt as well. And renaming qmake with every minor version is a 
> > no-go.
>
> Well, that's the exact opposite reply I've got (from Ossi?) on Qt 5.0
> times. qmake needed to be on path in order to be able to query it for
> some paths. But if that's no longer the case then yes, it can stay
> away.

...but using the same rationale that would also mean that tools like
cmake shouldn't be on path, which is not true. And yes, we could
simply symlink qmake6 but I think that, for this very specific tool,
the name should be qmake6 in docs too, at least on Linux.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

On 18 Nov 2020, at 13:39, Lisandro Damián Nicanor Pérez Meyer 
mailto:perezme...@gmail.com>> wrote:

Right, and this are all developer's tools. End users shouldn't care
nor even know about them. Remember, we are talking about
distribution-provided binaries.

Let’s clarify this, so we’re talking about the same thing:

 1. Application end-users
 2. Application developers using Qt
 3. Qt developers

#3 develops Qt for use by #2 to produce applications for #1

When you are talking about end users, which one of these do you refer to?

Cheers,
Tor Arne
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 18 Nov 2020 at 09:58, Tor Arne Vestbø  wrote:
[snip]
> Let’s clarify this, so we’re talking about the same thing:
>
>  1. Application end-users
>  2. Application developers using Qt
>  3. Qt developers

Let me expand it:

1. Application end-users
2.1. Application developers using Qt as provided by distro.
2.2. Application developers using more than one Qt major/minor version.
3. Qt developers.

> #3 develops Qt for use by #2 to produce applications for #1
>
> When you are talking about end users, which one of these do you refer to?

1 and 2.1.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 18 Nov 2020 at 10:01, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> On Wed, 18 Nov 2020 at 09:58, Tor Arne Vestbø  wrote:
> [snip]
> > Let’s clarify this, so we’re talking about the same thing:
> >
> >  1. Application end-users
> >  2. Application developers using Qt
> >  3. Qt developers
>
> Let me expand it:
>
> 1. Application end-users
> 2.1. Application developers using Qt as provided by distro.
> 2.2. Application developers using more than one Qt major/minor version.
> 3. Qt developers.

Maybe worth mentioning: 2.2 should probably be "more than one minor
version", I am assuming that 2.1 covers both Qt 5 and 6.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

> On 18 Nov 2020, at 14:01, Lisandro Damián Nicanor Pérez Meyer 
>  wrote:
> 
> On Wed, 18 Nov 2020 at 09:58, Tor Arne Vestbø  wrote:
> [snip]
>> Let’s clarify this, so we’re talking about the same thing:
>> 
>> 1. Application end-users
>> 2. Application developers using Qt
>> 3. Qt developers
> 
> Let me expand it:
> 
> 1. Application end-users
> 2.1. Application developers using Qt as provided by distro.
> 2.2. Application developers using more than one Qt major/minor version.
> 3. Qt developers.
> 
>> #3 develops Qt for use by #2 to produce applications for #1
>> 
>> When you are talking about end users, which one of these do you refer to?
> 
> 1 and 2.1.

The application end user (#1) shouldn’t need access to any of Qt’s binaries 
AFAIK. What’s there for us to fix for them? 

Cheers,
Tor Arne 

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 18 Nov 2020 at 10:16, Tor Arne Vestbø  wrote:
>
>
>
> > On 18 Nov 2020, at 14:01, Lisandro Damián Nicanor Pérez Meyer 
> >  wrote:
> >
> > On Wed, 18 Nov 2020 at 09:58, Tor Arne Vestbø  wrote:
> > [snip]
> >> Let’s clarify this, so we’re talking about the same thing:
> >>
> >> 1. Application end-users
> >> 2. Application developers using Qt
> >> 3. Qt developers
> >
> > Let me expand it:
> >
> > 1. Application end-users
> > 2.1. Application developers using Qt as provided by distro.
> > 2.2. Application developers using more than one Qt major/minor version.
> > 3. Qt developers.
> >
> >> #3 develops Qt for use by #2 to produce applications for #1
> >>
> >> When you are talking about end users, which one of these do you refer to?
> >
> > 1 and 2.1.
>
> The application end user (#1) shouldn’t need access to any of Qt’s binaries 
> AFAIK. What’s there for us to fix for them?

qdbus can be called by an app ran by an end-user. Yes, it's a
backwards-compatible tool so nothing to worry with that specific tool
(in fact this thread helped to clear down the tools that need to be
backwards compatible).

So (#1) is mostly (fully?) cleared, then we still have (#2.1).


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

On 18 Nov 2020, at 14:21, Lisandro Damián Nicanor Pérez Meyer 
mailto:perezme...@gmail.com>> wrote:

On Wed, 18 Nov 2020 at 10:16, Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:



On 18 Nov 2020, at 14:01, Lisandro Damián Nicanor Pérez Meyer 
mailto:perezme...@gmail.com>> wrote:

On Wed, 18 Nov 2020 at 09:58, Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:
[snip]
Let’s clarify this, so we’re talking about the same thing:

1. Application end-users
2. Application developers using Qt
3. Qt developers

Let me expand it:

1. Application end-users
2.1. Application developers using Qt as provided by distro.
2.2. Application developers using more than one Qt major/minor version.
3. Qt developers.

#3 develops Qt for use by #2 to produce applications for #1

When you are talking about end users, which one of these do you refer to?

1 and 2.1.

The application end user (#1) shouldn’t need access to any of Qt’s binaries 
AFAIK. What’s there for us to fix for them?

qdbus can be called by an app ran by an end-user.

That sounds like a deployment issue. If the app needs qdbus, it needs to bundle 
it, or make sure it knows the full path to it (but that sounds like a fragile 
thing to rely on). Besides, shouldn’t an app using dbus use 
https://doc.qt.io/qt-5/qtdbus-index.html and not an external binary?

So (#1) is mostly (fully?) cleared, then we still have (#2.1).

Okey, good to get #1 out of the way first. Thanks!

Tor Arne
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 18 Nov 2020 at 11:04, Tor Arne Vestbø  wrote:
[snip]
>> qdbus can be called by an app ran by an end-user.
> That sounds like a deployment issue. If the app needs qdbus, it needs to 
> bundle it, or make sure it knows the full path to it (but that sounds like a 
> fragile thing to rely on).

Embedding is something that distributions avoid. Getting the full path
is possible if exposed somehow (like a CMake variable that holds the
path), but it also means the developer must do "the right thing".

> Besides, shouldn’t an app using dbus use 
> https://doc.qt.io/qt-5/qtdbus-index.html and not an external binary?

Maybe, but there seems to be use cases:

https://sources.debian.org/src/plasma-workspace/4:5.19.5-5/wallpapers/image/wallpaper.knsrc.cmake/?hl=49#L49

just to name one.

> So (#1) is mostly (fully?) cleared, then we still have (#2.1).
>
>
> Okey, good to get #1 out of the way first. Thanks!

Thanks to you! This really helps everyone discuss the issue!


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QThread::create mandatory in Qt 6?

[Thiago Macieira]

On Tuesday, 17 November 2020 23:34:59 PST Oliver Wolff wrote:
> > clang-MSVC on the other hand is useful as it means a better compiler
> > frontend (clang) using a better standard library on Windows (msvc).
> 
> As far as I know, people *do* want an open alternative that does not
> involve Microsoft software. That's where mingw comes into play. As we
> cannot support an unlimited amount of configurations, it looks like we
> will go the clang-mingw route instead of clang-msvc.

Clang-MSVC is not an open alternative without MS software. It's still using MS 
software. It's just a better compiler than MS's.

Clang-mingw and GCC-mingw are open alternatives. Both have very good 
compilers. I don't know whether either has already solved the thread_local 
problem -- if any of them have, I'd strongly recommend we switch to that and 
ban the other (note: the issue is libgcc and libcompiler-rt, not the compilers 
themselves).

-- 
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

[Thiago Macieira]

On Wednesday, 18 November 2020 06:50:12 PST Kai Köhne wrote:
> FYI, we've been taking assistant out of Qt 6.0.
> https://bugreports.qt.io/browse/QTBUG-86746 . It's not depending on any
> particular Qt version, so my suggestion is to resurrect it (if there's
> enough demand) outside of qt5.git.

Agreed, provided it can load both Qt5 and Qt6 documents.

-- 
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

[Thiago Macieira]

On Wednesday, 18 November 2020 04:34:40 PST Lisandro Damián Nicanor Pérez > 
> So basically:
> 
> - Move out of $prefix/bin (and thus out of $PATH) every developer-oriented
> tool. 
> - Ensure that user-facing applications will be backwards compatible
> with Qt 5 for all the Qt 6 timeline.

I don't think that will work for qmake6 (see below). I am willing to accept 
this for all other (developer) tools. 

As for user-facing, here's the litmus test: the application can be moved out 
of the Qt repositories into one of its own. And then we do exactly that. 
Preferably also removing the use of private API in the process.

We've long had the question about translators wanting to install Linguist, but 
the only installation we have of it is the full Qt, which requires a compiler 
to also be present. Instead, we should provide translators with an installable 
Linguist using the Installer Framework for Windows, a macdeployqt bundle in a 
.dmg for Macs and, if we're feeling adventurous, a FlatPak for Linux.

> But then I wonder if designer shouldn't stay on $PATH or not. Because
> even if it's a developer tool it's one expected to be on $PATH much
> like Qt Creator. The developer tools that can stay out of $PATH are
> the ones that can be easily callable from within toolchains (qmake,
> cmake, etc). But then again we distros could simply make a
> $prefix/bin/designer6 symlink. Telling our users "just use designer6"
> it's really not a big deal, even if the docs just say "designer".

That's not an option. The docs must say either:
a) "run designer6"
or 
b) "run /bin/designer"

> > qmake6 entry point for building qmake-based applications,
> > situation
> > 
> >similar to /usr/bin/python (see [1])
> > 
> > I am not yet 100% convinced it is. This is a build tool after all, and
> > even changes with minor versions of Qt. I know Linux distributions do
> > only ship one minor version, but many of our users have to manage
> > multiple minor versions of Qt as well. And renaming qmake with every
> > minor version is a no-go.
> Well, that's the exact opposite reply I've got (from Ossi?) on Qt 5.0
> times. qmake needed to be on path in order to be able to query it for
> some paths. But if that's no longer the case then yes, it can stay
> away.

qmake6 needs to be on PATH because that's how we will tell people how to build 
their applications. Telling users to go discover where their Linux 
distributions installed Qt6 is not acceptable, in my point of view.

In any case, since we *need* qtdiag6 and qtpaths6, I don't see what's the harm 
in having qmake6 too.

> > qml6   I don't understand why, but I'm told it's necessary
> > 
> > 
> > It’s a runtime for running qml files without a C++ entry point. But we can
> > actually decide that this is a developer oriented tool and not have it
> > linked into /usr/bin.
> Still a tool that is expected to be called by humans though. And then
> again we could easily keep a $prefix/bin/qml6 link.

I don't care enough. I'm sure I haven't run this tool in 3 years. I even 
thought "qmlscene" was the one we were supposed to run since 5.0...

I'm just following what has been said in this thread that some people do run 
it.

> > All of those are developer facing tools and shouldn’t be in /usr/bin at
> > all IMO.
> And again, they could be easily symlinked with a prefix if needed.

I'd like to come to a consensus so that every installation follows procedure 
and is supported by docs. I'd rather Linux distributions didn't feel the need 
to start adding more symlinks.

-- 
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

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 18 Nov 2020 at 13:45, Thiago Macieira  wrote:
>
> On Wednesday, 18 November 2020 04:34:40 PST Lisandro Damián Nicanor Pérez >
> > So basically:
> >
> > - Move out of $prefix/bin (and thus out of $PATH) every developer-oriented
> > tool.
> > - Ensure that user-facing applications will be backwards compatible
> > with Qt 5 for all the Qt 6 timeline.
>
> I don't think that will work for qmake6 (see below). I am willing to accept
> this for all other (developer) tools.
>
> As for user-facing, here's the litmus test: the application can be moved out
> of the Qt repositories into one of its own. And then we do exactly that.
> Preferably also removing the use of private API in the process.

That would be simply awesome.

> We've long had the question about translators wanting to install Linguist, but
> the only installation we have of it is the full Qt, which requires a compiler
> to also be present. Instead, we should provide translators with an installable
> Linguist using the Installer Framework for Windows, a macdeployqt bundle in a
> .dmg for Macs and, if we're feeling adventurous, a FlatPak for Linux.
>
> > But then I wonder if designer shouldn't stay on $PATH or not. Because
> > even if it's a developer tool it's one expected to be on $PATH much
> > like Qt Creator. The developer tools that can stay out of $PATH are
> > the ones that can be easily callable from within toolchains (qmake,
> > cmake, etc). But then again we distros could simply make a
> > $prefix/bin/designer6 symlink. Telling our users "just use designer6"
> > it's really not a big deal, even if the docs just say "designer".
>
> That's not an option. The docs must say either:
> a) "run designer6"
> or
> b) "run /bin/designer"

In that case I would prefer (a) because it's situation is almost the
same as the qmake one you describe below.

> > > qmake6 entry point for building qmake-based applications,
> > > situation
> > >
> > >similar to /usr/bin/python (see [1])
> > >
> > > I am not yet 100% convinced it is. This is a build tool after all, and
> > > even changes with minor versions of Qt. I know Linux distributions do
> > > only ship one minor version, but many of our users have to manage
> > > multiple minor versions of Qt as well. And renaming qmake with every
> > > minor version is a no-go.
> > Well, that's the exact opposite reply I've got (from Ossi?) on Qt 5.0
> > times. qmake needed to be on path in order to be able to query it for
> > some paths. But if that's no longer the case then yes, it can stay
> > away.
>
> qmake6 needs to be on PATH because that's how we will tell people how to build
> their applications. Telling users to go discover where their Linux
> distributions installed Qt6 is not acceptable, in my point of view.

Agreed, that's why I followed my initial mail comparing it to CMake,
I've just realized it later.

And I think a tool like designer should follow the same path.

> In any case, since we *need* qtdiag6 and qtpaths6, I don't see what's the harm
> in having qmake6 too.
>
> > > qml6   I don't understand why, but I'm told it's necessary
> > >
> > >
> > > It’s a runtime for running qml files without a C++ entry point. But we can
> > > actually decide that this is a developer oriented tool and not have it
> > > linked into /usr/bin.
> > Still a tool that is expected to be called by humans though. And then
> > again we could easily keep a $prefix/bin/qml6 link.
>
> I don't care enough. I'm sure I haven't run this tool in 3 years. I even
> thought "qmlscene" was the one we were supposed to run since 5.0...
>
> I'm just following what has been said in this thread that some people do run
> it.
>
> > > All of those are developer facing tools and shouldn’t be in /usr/bin at
> > > all IMO.
> > And again, they could be easily symlinked with a prefix if needed.
>
> I'd like to come to a consensus so that every installation follows procedure
> and is supported by docs. I'd rather Linux distributions didn't feel the need
> to start adding more symlinks.

Right.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Ulf Hermann]

qml6   I don't understand why, but I'm told it's necessary
[...]


If we consider QML to be a general purpose scripting or UI prototyping 
language, then we should keep this easily accessible to end users. You 
can write QML-only applications or scripts and then use the qml(6) tool 
to run them.


qml(6) should be preferred over qmlscene(6). We've been trying to get 
rid of qmlscene for a while now.


best regards,
Ulf

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QThread::create mandatory in Qt 6?

[Sérgio Martins via Development]

On 2020-11-18 07:34, Oliver Wolff wrote:

Hi

On 16/11/2020 23:29, Sérgio Martins via Development wrote:

On 2020-11-16 21:57, Thiago Macieira wrote:

On Monday, 16 November 2020 13:38:06 PST Cristian Adam wrote:
LLVM.org clang.exe binary reports the x86_64-pc-windows-msvc target, 
which
is Clang/MSVC. clang-cl is just a different command line options 
parser,

which always sets the *-msvc target.

Clang/MinGW is something that ends up in *-gnu as target. That's the 
case

for winlibs and llvm-mingw.


I see, thanks.

So, what's wrong with llvm-mingw?


Probably the prebuilt toolchain Tony is using (WinLibs) has an old 
standard library.

The problem is not specific to Clang perse.


But why do we want clang-MinGW to begin with ? MinGW is niche as it 
is. I don't see anyone wanting this combo.


clang-MSVC on the other hand is useful as it means a better compiler 
frontend (clang) using a better standard library on Windows (msvc).


As far as I know, people *do* want an open alternative that does not
involve Microsoft software. That's where mingw comes into play.


I agree we want MinGW, but we already have it in the CI (gcc-mingw).
clang-mingw won't add much value, as it overlaps a lot with the existing 
gcc-mingw.


clang-cl.exe however has a bigger delta over cl.exe.






As we
cannot support an unlimited amount of configurations, it looks like we
will go the clang-mingw route instead of clang-msvc.






Regards,
--
Sérgio Martins | sergio.mart...@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@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Kai Pastor, DG0YT via Development]

Am 18.11.20 um 15:50 schrieb Kai Köhne:
FYI, we've been taking assistant out of Qt 6.0. 
https://bugreports.qt.io/browse/QTBUG-86746 . It's not depending on 
any particular Qt version, so my suggestion is to resurrect it (if 
there's enough demand) outside of qt5.git. 


Could you please clarify: Can building Qt Asistant be enabled by a 
configuration option? Is it still build as part of CI?


Now with all Qt help links changed to the online version, how is Qt 
Assistant/QTextBrowser limiting Qt's documentation at all, justifying 
its removal from the build (so late in the Qt 6 release process)?


Regards,
Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of Kai
> Pastor, DG0YT via Development
> Sent: Thursday, November 19, 2020 7:03 AM
> To: development@qt-project.org
> Subject: Re: [Development] Qt 6 co-installability with Qt 5
> 
> Am 18.11.20 um 15:50 schrieb Kai Köhne:
> > FYI, we've been taking assistant out of Qt 6.0.
> > https://bugreports.qt.io/browse/QTBUG-86746 . It's not depending on
> > any particular Qt version, so my suggestion is to resurrect it (if
> > there's enough demand) outside of qt5.git.
> 
> Could you please clarify: Can building Qt Asistant be enabled by a
> configuration option? Is it still build as part of CI?

Currently not. I think it should be completely removed from qttools - disabling 
the build was just the quickest way for the 6.0 release.

> Now with all Qt help links changed to the online version, how is Qt
> Assistant/QTextBrowser limiting Qt's documentation at all, justifying its
> removal from the build (so late in the Qt 6 release process)?

The reason why we removed Qt Assistant in the beta phase is that I don't think 
it should be part of Qt 6.

Regards

Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Kai Pastor, DG0YT via Development]

Am 19.11.20 um 08:20 schrieb Kai Köhne:

Am 18.11.20 um 15:50 schrieb Kai Köhne:

FYI, we've been taking assistant out of Qt 6.0.
https://bugreports.qt.io/browse/QTBUG-86746 . It's not depending on
any particular Qt version, so my suggestion is to resurrect it (if
there's enough demand) outside of qt5.git.

Could you please clarify: Can building Qt Asistant be enabled by a
configuration option? Is it still build as part of CI?

Currently not. I think it should be completely removed from qttools - disabling 
the build was just the quickest way for the 6.0 release.


I wouldn't mind if Assistant would actually be moved to a different 
repository. But so far, it is only a suggestion.



Now with all Qt help links changed to the online version, how is Qt
Assistant/QTextBrowser limiting Qt's documentation at all, justifying its
removal from the build (so late in the Qt 6 release process)?

The reason why we removed Qt Assistant in the beta phase is that I don't think 
it should be part of Qt 6.


Do you want to remove it from "Qt 6", from "Qt 6.0", or from "Qt 6.0.0"? 
There has been no deprecation of this Qt feature AFAIK.


If you want to remove it from "Qt 6", then there is no need for CI.

Regards,
Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development