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 whic
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 qt-cm
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 h
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 th
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 impo
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 ship
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 could
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 to
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. qmleasi
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 k
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 if
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 u
13 matches
Mail list logo
