On Thursday, 13 October 2022 02:31:49 PDT Jörg Bornemann via Development
wrote:
> qt-cmake is to be called by users to configure their projects.
Yup, but then it needs the suffix so that two builds of Qt 6 (or later one of
Qt 7) can be installed in parallel and the user/developer can select
On 10/7/22 19:19, Thiago Macieira wrote:
qt-cmake
qt-cmake-standalone-test
qt-configure-module
Then they need to be built with INSTALL_VERSIONED_LINK to the CMake command
qt_internal_add_app().
Does it make sense to have those in a non-developer build? I could see someone
using either
My question was for the developer's own plugins. Are these tools meant for
the developer to test their QML importing their plugins? It might be
surprising that it cannot find the plugins they've just installed to
QML_PLUGIN_PATH, or worse, finds an older version of them.
Indeed if you actually
Thiago Macieira wrote:
> My question was for the developer's own plugins. Are these tools meant for
> the developer to test their QML importing their plugins? It might be
> surprising that it cannot find the plugins they've just installed to
> QML_PLUGIN_PATH, or worse, finds an older version of
On Friday, 7 October 2022 10:57:52 PDT Ulf Hermann via Development wrote:
> In a parallel install the Qt5 and Qt6 QML import paths should be
> separate. If you ship your own QML modules you can in principle build
> them against both Qt5 and Qt6, separately, and install them in the
> respective
I would consider qml, qmlscene, qmlpreview, qmlprofiler, and qmltime to
be equivalent to their Qt 5 versions, and indeed user-facing.
And would replacing the Qt 5 versions with Qt 6 be an imperceptible change to
the user? What happens if their own QML content has plugins? I assume Qt
itself
On Friday, 7 October 2022 09:52:16 PDT Thiago Macieira wrote:
> > qt-cmake
> > qt-cmake-standalone-test
> > qt-configure-module
> Then they need to be built with INSTALL_VERSIONED_LINK to the CMake command
> qt_internal_add_app().
Does it make sense to have those in a non-developer build? I
On Friday, 7 October 2022 02:34:06 PDT Ulf Hermann via Development wrote:
> Hi,
>
> I would consider qml, qmlscene, qmlpreview, qmlprofiler, and qmltime to
> be equivalent to their Qt 5 versions, and indeed user-facing.
And would replacing the Qt 5 versions with Qt 6 be an imperceptible change
On Friday, 7 October 2022 02:11:53 PDT Jörg Bornemann via Development wrote:
> These are user-facing, equivalent as defined by you to their Qt 5 version:
> lconvert
> lrelease
> lupdate
> qdoc (I assume that its output is usable by Qt 5)
> qmleasing
Agreed.
I would consider qml, qmlscene, qmlpreview, qmlprofiler, and qmltime to
be equivalent to their Qt 5 versions, and indeed user-facing.
Well, qml and qmlscene are only equivalent to Qt5 insofar as we consider
the QML language and our QML modules in Qt6 to be equivalent to the ones
in Qt5. There
Hi,
I would consider qml, qmlscene, qmlpreview, qmlprofiler, and qmltime to
be equivalent to their Qt 5 versions, and indeed user-facing.
qmltc is not user-facing. It's a compiler and should live in the same
place as qmlcachegen.
qmljs is a general-purpose JavaScript interpreter. So, it's
On 10/6/22 21:00, Thiago Macieira wrote:
For the tools below, please answer:
1) are they meant to be run by the user or developer, from a command-line?
2) are they equivalent to their Qt 5 version, if it exists? That is, can the
Qt 6 tool be used where the Qt 5 one was, with Qt 5 input files
For the tools below, please answer:
1) are they meant to be run by the user or developer, from a command-line?
2) are they equivalent to their Qt 5 version, if it exists? That is, can the
Qt 6 tool be used where the Qt 5 one was, with Qt 5 input files if any, and
produce output that Qt 5 will
13 matches
Mail list logo
