Re: [Development] Q_FOREACH, again

[Ahmad Samir]

On 14/8/23 21:46, Thiago Macieira wrote:

On Monday, 14 August 2023 10:32:36 PDT Marc Mutz via Development wrote:

It does _not_ have any influence on user code.


Except where accidentally the QT_NO_FOREACH gets copied to the library's CMake
INTERFACE. Then it does. This happened for QT_NO_CONTEXTLESS_CONNECT when it
was applied to Qt6UiPlugin.

We don't understand why it happened there (didn't bother to investigate), so
be aware that your claim may be incorrect and that user code may be affected
regardless of your intention.

See 93de403391b59acf90fbe7319a059382dfe458a6 in the qt-creator repository.




Thanks to Giuseppe for poking the issue, Alexandru figured it out a while ago: 
https://codereview.qt-project.org/c/qt/qttools/+/491477/2/src/uiplugin/CMakeLists.txt#16


The issue seen in Qt Creator 93de403391b59acf90fbe7319a059382dfe458a6 (the 
QT_NO_CONTEXTLESS_CONNECT leaking to user code) was "fixed" by 
https://codereview.qt-project.org/c/qt/qttools/+/492556


The "gist" of it is, don't use qt_internal_add_module + HEADER_MODULE + DEFINES, 
because those DEFINES could be leaked into user code that links to the plugin in 
question.


HEADER_MODULE isn't used that many times in Qt code, and typically where it's used 
there is no SOURCES arg passed to qt_internal_add_module, however it's a corner 
case to look out for when adding DEFINES to qt_internal_add_module.


Regards,
Ahmad Samir



OpenPGP_signature
Description: OpenPGP digital signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Using DMA instead of SHM in non OpenGL apps (Linux/Wayland)

[Eduardo Hopperdietzel]

Hello Kai,

Thank you for your reply. After following the links you provided, I believe
that implementing the DMA feature should take place within the following
file:

https://code.qt.io/cgit/qt/qtwayland.git/tree/src/client/qwaylandshmbackingstore.cpp

Here's my proposed plan for this implementation:

1. Start by checking whether the compositor supports the wl_drm and
linux-DMA-buff protocols.
2. Manually implement both protocols, without relying on the wayland-egl
implementation.
3. Authenticate a DRM device fd through the wl_drm protocol.
4. Verify if the compositor supports the DRM_FORMAT_MOD_LINEAR modifier
using the linux-dma-buff protocol.
5. Create a LINEAR DMA buffer using the GBM library. I propose making this
buffer relatively large to prevent the need for frequent destruction and
recreation of a new buffer when the window is resized.
6. Perform mmap on the DMA buffer.
7. Wrap the mapped buffer with a QImage(), following a similar approach as
it's done with shared memory.

If any of these steps fail, fallback to shared memory.

Do you foresee any potential issues with this approach? Please feel free to
share your thoughts.

Best regards,
Eduardo Hopperdietzel
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Q_FOREACH, again

[Thiago Macieira]

On Monday, 14 August 2023 10:32:36 PDT Marc Mutz via Development wrote:
> It does _not_ have any influence on user code.

Except where accidentally the QT_NO_FOREACH gets copied to the library's CMake 
INTERFACE. Then it does. This happened for QT_NO_CONTEXTLESS_CONNECT when it 
was applied to Qt6UiPlugin.

We don't understand why it happened there (didn't bother to investigate), so 
be aware that your claim may be incorrect and that user code may be affected 
regardless of your intention.

See 93de403391b59acf90fbe7319a059382dfe458a6 in the qt-creator repository.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


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

Re: [Development] Q_FOREACH, again

[Marc Mutz via Development]

Forgot to add sample commits for each of the cases. Added inline below.

Also, please use topic:Q_FOREACH in Gerrit.

Module maintainers: if your module's .cmake.conf doesn't already contain the 
QT_NO_FOREACH=1, and no Gerrit change is up that adds it, either add it 
yourself to check locally or wait for the default to switch. You can use 
https://codereview.qt-project.org/c/qt/qtwebengine/+/494757 as a template for 
whitelisting, should that be necessary. Prefer whitelisting over fixing for now 
(see bottom of my thread starter email). The use of NO_PCH_SOURCES in tests 
requires 
https://codereview.qt-project.org/q/I8ead238a8d9e55da632b2929638b67724a42d73c 
(the absense of which in qt5.git  is why most module top-level changes aren't 
merged, yet). If you don't have it, you can use NO_UNITY_BUILD_SOURCES instead.

On 14.08.23 19:32, Marc Mutz via Development wrote:
> There's _one_ situation which I call "trivial": When the loop is over a
> _const_ local container (local _value_, const-references or data members
> do _not_ count). For me, it's ok to say in the commit message that these
> are of the trivial kind (but _say_ it in the commit message), it's
> trivially(!) verified by a reviewer that it's correct.

https://codereview.qt-project.org/c/qt/qtbase/+/495076

> There's also what I call a "simple" case: where you iterate over a local
> container that's _not_ const, but where the loop body _clearly_ doesn't
> modify the container. That must be _clearly_ visible. If it calls an
> out-of-line function, that should already spark an explanation in the
> commit message (unless it's something every Qt developer should know,
> like QString::toUtf8() doesn't call unknown code).

https://codereview.qt-project.org/c/qt/qtbase/+/495113

> If it's not one the two, you should do two things:
> 
> - port only one loop (or at most a group of loops over the same
> variable) per commit. This allows us to quickly revert such a change
> if it goes south, or even find it, with git-bisect, in the first
> place.
> - _proove_ that the loop body cannot modify the container. Write the
> proof in the _commit message_. Watch out for signal emissions,
> callbacks, events being sent, etc under the hood that can cause
> unknown code to be called. If you find something like this, you _must_
> take a copy and iterate over that, or use an indexed loop. Unless the
> modification is obvious, add a _code comment_ that explains why we
> take a copy/use an indexed loop.

https://codereview.qt-project.org/c/qt/qtbase/+/495111

> If you can't proove it, don't do the change, or take a copy and say "//
> ### needed?". Just don't do that _everywhere_.

https://codereview.qt-project.org/c/qt/qtbase/+/495080

-- 
Marc Mutz 
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B

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

[Development] Q_FOREACH, again

[Marc Mutz via Development]

Hi,

I've uploaded a patch series that makes QT_NO_FOREACH the default and 
whitelists any existing uses of Q_FOREACH/foreach as can be seen in the 
culminating patch of the series: 
https://codereview.qt-project.org/c/qt/qtbase/+/495115

The intention of this patch series is not to fix all uses, the intention 
is to change the default from allowing Q_FOREACH to disallowing 
Q_FOREACH in new Qt (library|plugin|tool|test) code.

It does _not_ have any influence on user code.

It has, however, sparked a flurry of commits that attempt to fix 
remaining uses, and I'd like to give everyone that tries a heads up:

For your own sanity, and those of your reviewers, remember that the port 
is _not easy_. Details are in https://www.kdab.com/goodbye-q_foreach/, 
but here's the TL;DR: in current terminology.

There's _one_ situation which I call "trivial": When the loop is over a 
_const_ local container (local _value_, const-references or data members 
do _not_ count). For me, it's ok to say in the commit message that these 
are of the trivial kind (but _say_ it in the commit message), it's 
trivially(!) verified by a reviewer that it's correct.

There's also what I call a "simple" case: where you iterate over a local 
container that's _not_ const, but where the loop body _clearly_ doesn't 
modify the container. That must be _clearly_ visible. If it calls an 
out-of-line function, that should already spark an explanation in the 
commit message (unless it's something every Qt developer should know, 
like QString::toUtf8() doesn't call unknown code).

If it's not one the two, you should do two things:

- port only one loop (or at most a group of loops over the same
   variable) per commit. This allows us to quickly revert such a change
   if it goes south, or even find it, with git-bisect, in the first
   place.
- _proove_ that the loop body cannot modify the container. Write the
   proof in the _commit message_. Watch out for signal emissions,
   callbacks, events being sent, etc under the hood that can cause
   unknown code to be called. If you find something like this, you _must_
   take a copy and iterate over that, or use an indexed loop. Unless the
   modification is obvious, add a _code comment_ that explains why we
   take a copy/use an indexed loop.

If you can't proove it, don't do the change, or take a copy and say "// 
### needed?". Just don't do that _everywhere_.

My patch series takes the pressure of porting away from Q_FOREACH away. 
We don't need to do it now, and when we can depend on C++20, any 
Q_FOREACH use can be trivially ported to ranged-for-with-initializer:

#define Q_FOREACH(x, y) for (const auto _c = y; x : _c)

So we can remove all remaining ones in an automated fashion then.

You will, of course, find reviewers who will approve such ports even 
though the proof is missing. Given that we no longer need to port away, 
that would be foolish, but I fully expect it to happen. Just make sure _you_
are not that fool.

Thanks,
Marc

-- 
Marc Mutz 
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] RFC: CMake's automoc option to warn about missing moc includes; or not have mocs_compilation.cpp

[Friedrich W. H. Kossebau]

Hi,

Am Donnerstag, 13. Juli 2023, 23:16:07 CEST schrieb Friedrich W. H. Kossebau:
> I would like to propose some new features to CMake's automoc, around
> enforcing explicit moc includes, and to do this with support of the
> respective Qt developers, so first hear their comments or, best, get them
> also involved :)
> 
> A)
> Have automoc emit warnings if no explicit moc include has been found and
> instead one is to be added to mocs_compilation.cpp (silently currently).
> Perhaps controlled by some target property AUTOMOC_MISSING_INCLUDE_WARNINGS,
> default OFF
> --- 8< ---
> AutoMoc warning:  SRC:/foo.h contains a Q_OBJECT macro, but no file includes
> the moc file "moc_foo.cpp". Added to the target's mocs_compilation.cpp
> instead.
> --- 8< ---
> 
> B)
> Have an option for no mocs_compilation.cpp at all being used in the build,
> saving the related build resources and failing hard in case of missing
> includes. Perhaps by a target property named AUTOMOC_USE_MOCS_COMPILATION,
> default ON.

Thanks once more those you who replied on- & off-list, seems the ideas have 
been not that wild.

So finally got around and filed the ideas as requests on the CMake issue 
tracker:

* Request: option to have automoc warn about non-explicit moc includes
  https://gitlab.kitware.com/cmake/cmake/-/issues/25185

* Request: option to have automoc not add a mocs_compilation.cpp file
  https://gitlab.kitware.com/cmake/cmake/-/issues/25186

Be invited to please add further input there and perhaps collaborate with the 
CMake developers on this if you are an active stake holder on the matter.

Myself for now have no further spare resources here, just could plant the idea 
seed :)

Cheers
Friedrich


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

Re: [Development] Failed to run configure.bat in qt/qt5 repository on Windows?

[Edward Welbourne via Development]

Haowei Hsu (14 August 2023 13:27) wrote:
> The reason why I run vcvarsall.bat is to let CMake find MSVC compilers.

Understandable, just not given by README.md

> As for init-repository, I didn't see its instructions in README.md [...] 
> Where is it?

https://github.com/qt/qt5/blob/dev/README.git
Lines 17 to 21.

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

Re: [Development] QAbstractItemModel's meta-object got changed in QtQuick

[Axel Spoerl via Development]

Hi,

The meta object doesn’t change during execution. The messages probably mean, 
that upon app close, the custom class (inheriting from QObject) is already 
deleted. Only a QObject is left, which is what className() correctly reports.

Maybe throw a qDebug() in the custom class destructor, to check if it is 
reached too early. I personally haven’t seen error logs of that kind. It 
doesn’t seem right that the custom class gets deleted, with its connections 
still being reported as active. Unless there is a bug in the custom class 
implementation, I suggest to file a bug report with a minimal reproducer.

Cheers
Axel

On 14 Aug 2023, at 15:06, Ziming Song  wrote:

Hi,

I’m playing with QtQuick TreeView with custom QAbstractItemModel in C++. The 
program runs fine, except some error logs when program exits:

qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::rowsAboutToBeRemoved(QModelIndex,int,int)
qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::columnsAboutToBeRemoved(QModelIndex,int,int)
qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::rowsAboutToBeInserted(QModelIndex,int,int)
qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::columnsAboutToBeInserted(QModelIndex,int,int)
qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::rowsAboutToBeMoved(QModelIndex,int,int,QModelIndex,int)
qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::columnsAboutToBeMoved(QModelIndex,int,int,QModelIndex,int)
qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::rowsMoved(QModelIndex,int,int,QModelIndex,int)
qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::columnsMoved(QModelIndex,int,int,QModelIndex,int)
qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::layoutAboutToBeChanged(QList,QAbstractItemModel::LayoutChangeHint)
qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::layoutChanged(QList,QAbstractItemModel::LayoutChangeHint)
qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::modelReset()

This is what I found.

Error messages come from QItemSelectionModelPrivate::initModel, which is called 
(at least) twice, one during app start to set the model and connect some 
signals, one during app close to disconnect signals and set model to NULL.

At app starting, m->metaObject()->className() is correct (my custom model class 
name).

At app closing, m->metaObject() value changes, and m->metaObject()->className() 
is “QObject”, which doesn’t have those signals, thus the error message.

Can metaobject be modified during execution? If so, why?

Thanks in advance
songziming
--
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

[Development] QAbstractItemModel's meta-object got changed in QtQuick

[Ziming Song]

Hi,

I’m playing with QtQuick TreeView with custom QAbstractItemModel in C++. The 
program runs fine, except some error logs when program exits:


qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::rowsAboutToBeRemoved(QModelIndex,int,int)

qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::columnsAboutToBeRemoved(QModelIndex,int,int)

qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::rowsAboutToBeInserted(QModelIndex,int,int)

qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::columnsAboutToBeInserted(QModelIndex,int,int)

qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::rowsAboutToBeMoved(QModelIndex,int,int,QModelIndex,int)

qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::columnsAboutToBeMoved(QModelIndex,int,int,QModelIndex,int)

qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::rowsMoved(QModelIndex,int,int,QModelIndex,int)

qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::columnsMoved(QModelIndex,int,int,QModelIndex,int)

qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::layoutAboutToBeChanged(QList,QAbstractItemModel::LayoutChangeHint)

qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::layoutChanged(QList,QAbstractItemModel::LayoutChangeHint)

qt.core.qobject.connect: QObject::disconnect: No such signal 
QObject::modelReset()

This is what I found.

Error messages come from QItemSelectionModelPrivate::initModel, which is called 
(at least) twice, one during app start to set the model and connect some 
signals, one during app close to disconnect signals and set model to NULL.

At app starting, m->metaObject()->className() is correct (my custom model class 
name).

At app closing, m->metaObject() value changes, and m->metaObject()->className() 
is “QObject”, which doesn’t have those signals, thus the error message.

Can metaobject be modified during execution? If so, why?

Thanks in advance
songziming
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Failed to run configure.bat in qt/qt5 repository on Windows?

[Haowei Hsu]

Hello, Edward.

These instructions do not appear in README.md; it contains, for example,
> no mention of vcvarsall.bat and its instructions for updating quite
> explicitly mention running init-repository.  See README.git for the
> details of how to clone and set up an initial checkout of Qt.  Note that
> it does not use --recursive to git clone; init-repository takes care of
> the recursing into submodules.


The reason why I run *vcvarsall.bat* is to let CMake find MSVC compilers.

As for *init-repository*, I didn't see its instructions in README.md
. Where is it?

---
Haowei Hsu

Edward Welbourne  於 2023年8月14日 週一 下午5:50寫道：

> Haowei Hsu (13 August 2023 14:08) wrote:
> > Recently, I tried to configure the qt/qt5
> > repository. The following commands are what I use to configure the
> > project according to its README.md:
> >
> >   1.  git clone --recursive https://github.com/qt/qt5.git
> >   2.  chdir qt5
> >   3.  git status
> >   4.  git checkout v6.5.2
> >   5.  git submodule update --recursive
> >   6.  vcvarsall.bat x64
> >   7.  configure.bat
>
> These instructions do not appear in README.md; it contains, for example,
> no mention of vcvarsall.bat and its instructions for updating quite
> explicitly mention running init-repository.  See README.git for the
> details of how to clone and set up an initial checkout of Qt.  Note that
> it does not use --recursive to git clone; init-repository takes care of
> the recursing into submodules.
>
> > However, it turns out that there are some errors occurred.
> > What do I miss? How to fix these errors?
>
> Follow the actual instructions in README.git and README.md5 - and please
> report any problems you have then, as those would imply we need to
> update these files.
>
> > NOTE: Currently, I just want to build Qt's Documentation instead of the
> > whole Qt's artifacts.
>
> That will involve building at least QDoc, hence at least QtCore, so
> you'll get some artifacts, but indeed you won't need all.  After you run
> configure, ninja -t targets will list all possible targets; search that
> for ones containig "doc" and you should find one suitable.
>
> Eddy.
>
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] [Announce] Qt Creator 11.0.2 released

[List for announcements regarding Qt releases and development via Announce via Development]

We are happy to announce the release of Qt Creator 11.0.2!

https://www.qt.io/blog/qt-creator-11.0.2-released


David Schulz
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
david.sch...@qt.io
+49 30 63 92 32 56
http://qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png]
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png]
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png]
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png]
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png]
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png]

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

Re: [Development] Unity Build on CI for Qt Base for 3 Platforms

[Friedrich W. H. Kossebau]

Hi,

Am Freitag, 11. August 2023, 22:14:13 CEST schrieb Marc Mutz via Development:
> All my -unity-build-batch-size 100'000 patches except for one are now
> merged: https://codereview.qt-project.org/q/topic:unity-build
> 
> I'm currently testing without the unmerged one, because it won't apply
> to 6.5, anyway, and the goal is to have unity-builds from 6.5 onwards.
> Maybe a few more TUs will have to be excluded, but you should be able to
> see the pattern. So far it looks like it's not needed.
> 
> Compile with -unity-build -unity-build-batch-size 10 and add all TUs
> that create problems with a small comment as to what's breaking to
> NO_UNITY_BUILD_SOURCES.

Just a quick note/question given 10 seems to be used to denote "all the 
sources!":

CMake actually supports "0" as value for that purpose of "all!", had that been 
considered in the design, to be consistent with CMake's approach?

>From https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD_BATCH_SIZE.html
--- 8< ---
Although strongly discouraged, the batch size may be set to a value of 0 to 
combine all the sources for the target into a single unity file, regardless of 
how many sources are involved. This runs the risk of creating an excessively 
large unity source file and negatively impacting the build performance, so a 
value of 0 is not generally recommended.
--- 8< ---

Curiousity:

While at it, I am curious what purpose unity builds of Qt are supposed to 
serve, i.e. in which cases would exclusive use of unity builds be recommended 
to be used? Are there some docs/notes somewhere, when to use and when not?
Personally had been very impressed by the speed up when I first learned about 
the concept decades ago (KDE's --enable-final flag with unsermake IIRC) and 
the compiler at that time having more options to optimize the generated code. 
But with LTO these days, by what I understood, that advantage/purpose is gone.
And while I made some own project recently work with cmake unity builds for 
curiousity (thus knew about that special value "0" for batch sizes :) ) I am 
still wondering when actually unity builds make sense to be used, especially 
in parallel with supporting non-unity builds.
So, for which use cases are Qt's unity builds done? Whom will the docs 
recommend to use that build option?

Cheers
Friedrich


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

Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

[Ivan Solovev via Development]

I'm now re-reading the discussion, and I think that I missed one thing
previously, so let me comment on that.

> What I meant is that the product API of using the macros are the set of
> operators. The methods that those operators called are not API and users are
> not expected to use them in their code. In fact, if conflicting names are a
> problem, then we should uglify the names we're asking for in the macros by
> inserting a "q_" or "qt_" prefix.
>
> This means C++17 users are able to use all operators to produce a boolean
> result, but can't get a QXxxOrdering result with homogeneous API from the
> macros.

The new macros are supposed to be publicly available. This means that the
users will be able to use them in their custom classes to implement the
unified comparison behavior between C++17 and C++20.

This means that the users will need to provide their implementations of
the helper methods. The idea is to explicitly mention it in the docs,
so the methods cannot be considered "Qt internal" anymore.
Can we use the "q_" or "qt_" prefix for these helper functions in this case?

Or do you suggest making the macros Qt-private? Not that we *really* can
do it, because the macros are exposed in public headers, but we can at least
hide the documentation, and do not advertise the macros...
But IMO such decision would significantly decrease the value of the new
feature.

> We still need *some* level of public API to produce ordering results because
> users will need those methods to produce their own comparison functions, such
> as composing on top of our string or date/time classes. If they want to also
> be compatible with C++17, then they can't use the spaceship, and instead they
> will need to call a named function of some sorts. If we are going to expose
> API, then said API must have proper names and thus must be "equals" and
> "compare".

The initial idea was that the helper functions could also become the public
API for producing ordering results. IIUC, that's also why Marc suggested to
make them hidden friends. Using private 2-arg static function would work for
the comparison operators but wouldn't work as a public API. Hidden friends
will work for both cases.

If we advertise only the public API which is not supported by the macros,
then the users will still need to implement all six (or 12 in case of
mixed-type comparison) relational operators instead of just calling one macro
and implementing two helper functions.

--

Ivan Solovev
Senior Software Engineer

The Qt Company GmbH
Erich-Thilo-Str. 10
12489 Berlin, Germany
ivan.solo...@qt.io
www.qt.io

Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B

From: Development  on behalf of Thiago 
Macieira 
Sent: Tuesday, August 1, 2023 5:11 PM
To: development@qt-project.org 
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

On Tuesday, 1 August 2023 01:55:05 PDT Ivan Solovev via Development wrote:
> > BTW, this needs to integrate with QEqualityOperatorForType and
> > QLessThanOperatorForType in qmetatype.h. I don't think there's any work
> > for
> > you other than verifying.
>
> I was not even aware of them, thanks! A brief look at the code shows that
> they shouldn't be affected, but I'll update the Jira ticket to keep them
> in mind.

I wasn't either. I went looking for qLess, which existed for Qt 3, 4 and 5 for
Q(Value)Map, and found them.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Failed to run configure.bat in qt/qt5 repository on Windows?

[Edward Welbourne via Development]

Haowei Hsu (13 August 2023 14:08) wrote:
> Recently, I tried to configure the qt/qt5
> repository. The following commands are what I use to configure the
> project according to its README.md:
>
>   1.  git clone --recursive https://github.com/qt/qt5.git
>   2.  chdir qt5
>   3.  git status
>   4.  git checkout v6.5.2
>   5.  git submodule update --recursive
>   6.  vcvarsall.bat x64
>   7.  configure.bat

These instructions do not appear in README.md; it contains, for example,
no mention of vcvarsall.bat and its instructions for updating quite
explicitly mention running init-repository.  See README.git for the
details of how to clone and set up an initial checkout of Qt.  Note that
it does not use --recursive to git clone; init-repository takes care of
the recursing into submodules.

> However, it turns out that there are some errors occurred.
> What do I miss? How to fix these errors?

Follow the actual instructions in README.git and README.md5 - and please
report any problems you have then, as those would imply we need to
update these files.

> NOTE: Currently, I just want to build Qt's Documentation instead of the
> whole Qt's artifacts.

That will involve building at least QDoc, hence at least QtCore, so
you'll get some artifacts, but indeed you won't need all.  After you run
configure, ninja -t targets will list all possible targets; search that
for ones containig "doc" and you should find one suitable.

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

[Development] Nominating Kwanghyo Park as approver

[Tomi Korpipää via Development]

Hi,

I'd like to nominate Kwanghyo Park for approver status. He is the main 
developer for Surface3D graphs for the QtGraphs module, and has been 
contributing to QtDataVisualization, QtQuick3D, and QtLottie as well.

https://codereview.qt-project.org/q/owner:kwanghyo.park%2540qt.io
https://codereview.qt-project.org/q/reviewer:kwanghyo.park%2540qt.io

He has been and continues being a productive member of the Oulu Graphics team.


Tomi Korpipää

Senior Manager, R

The Qt Company Oy
Tutkijantie 4C
90590 Oulu
Finland

tomi.korpi...@qt.io

+358445312522

www.qt.io

[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/Qt-Group-logo-black.png]
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/facebook-x2-right_2023-03-01-095511_zhlr.png]
 
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/twitter-x2.png] 
 
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/linkedin-x2.png]
 
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/youtube-x2.png] 


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