Problems Connecting to QMainWindow::repaint()

Christian Ehrlicher

@Pl45m4 update() always had those overloads so it should never work.

Pl45m4

Mh, strange.

There are so many topics here in the forum, on StackOverflow and everywhere else...
Nobody complained that the posted solutions is wrong or does not work

Like here

Maybe they also converted the String syntax to PMF/Functor-based style and never tested or reported back the issues that they are having... :)

JonB

@Pl45m4
FWIW, I'm surprised you say you have never had to use qOverload/QOverload::of (introduced around Qt 5.7, and before then you had to use a static_cast<> thing) where there are indeed multiple overload signatures. I have never used SIGNAL/SLOT(), always PMF, and have had to use qOverload from the start whenever there was ambiguity, including e.g. update(). Qt docs have some examples for connect(), e.g. https://doc.qt.io/qt-5/qspinbox.html#valueChanged. Even PySide/PyQt have a funny syntax for achieving the same as qOverload. Go find an example in your old code where you have really gotten away without it! ;-)

Pl45m4

@JonB said in Problems Connecting to QMainWindow::repaint():

FWIW, I'm surprised you say you have never had to use qOverload/QOverload::of (introduced around Qt 5.7) where there are indeed multiple overload signatures.

I didn't say "never", I said

@Pl45m4 said in Problems Connecting to QMainWindow::repaint():

I've never used qOverload<>::(&QWidget::update) or something before

I've used overload for overloaded signals (for example for QSpinBox::valueChanged, as you also mention)...
but never for overloaded functions/slots like update() or repaint() :)

I could still swear this worked to some point.... well... I don't know. Apparently it does not and never did (unless you are using the string style)

@JonB said in Problems Connecting to QMainWindow::repaint():

Go find an example in your old code where you have really gotten away without it! ;-)

Don't have code of mine at hand right now, but just google...
Dozens of examples and code snippets here in the forum and on StackOverflow...
and nobody claimed that it's not working... even in "accepted" solutions/answers.

@Pl45m4 said in Problems Connecting to QMainWindow::repaint():

@Christian-Ehrlicher

Mh, strange.

There are so many topics here in the forum, on StackOverflow and everywhere else...
Nobody complained that the posted solutions is wrong or does not work

Like here

Maybe they also converted the String syntax to PMF/Functor-based style and never tested or reported back the issues that they are having... :)

JonB

@Pl45m4 said in Problems Connecting to QMainWindow::repaint():

I've used overload for overloaded signals (for example for QSpinBox::valueChanged, as you also mention)...
but never for overloaded functions/slots like update() or repaint() :)

Ah, I had not appreciated you were commenting on need for overload on slots rather than signals. I had a search of all my old code (amazing what grep -r --include=... can achieve!) and although using it on signals is more frequent I did find myself using it on slots too, though they were my own rather than Qt inbuilt ones.

Pl45m4

@JonB

Fortunately the trend is moving away from ambiguous signals/functions with different parameters...
They've changed it in some of the public API already...
Also, IIRC, clang/clazy recommends not to do it, when you try to overload your own, custom Qt signal.
It advises to slightly change the naming and include the "signature" in the name of the signal, like Qt did in Qt6 (don't know in what release it started) for QButtonGroup (and probably many more):

https://doc.qt.io/qt-6/qbuttongroup.html#signals (Qt6)
vs.
https://dreamswork.github.io/qt4/classQButtonGroup.html (Qt4.8)

So instead of one generic signal with multiple overloads for various use cases

void buttonClicked (QAbstractButton *)
void buttonClicked (int)

they changed to:

void buttonClicked (QAbstractButton *)
void idClicked(int id)

I like it and this makes totally sense ;-)
A signal called <type>changed/clicked/whatever(<type> t) transmits parameters with type <type>.
Better in every aspect than widgetChanged/clicked/whatever(<some_type> t) and then you have to figure out through a list of overloads what overload/type you need or want to address :)

AFAIK the overloads were tolerated in whole Qt5 and became deprecated with Qt6.

JonB

@Pl45m4 said in Problems Connecting to QMainWindow::repaint():

Also not working anymore, which definitely used to work.

I rolled out my decommissioned Ubuntu 22.04, Qt 5.1.5, gcc 11.4 and copy-pasted your connect(timer, &QTimer::timeout, this, &MainWindow::update);. It does fail with same "unresolved overloaded function type" error as under Qt 6, so dunno when it used to work for you... :)

Pl45m4

@JonB said in Problems Connecting to QMainWindow::repaint():

It does fail with same "unresolved overloaded function type" error as under Qt 6, so dunno when it used to work for you... :)

Ok, ok you won :D

but that doesn't change the fact that overload sucks :D

JonB

@Pl45m4
I didn't mean to point-score, I was just interested, honest!

It advises to slightly change the naming and include the "signature" in the name of the signal

Well I don't see much difference between signals, slots and any other method. So if we're going to give up on same-name-methods-with-parameter-overloading and go for different-name-with-indicator-of-which-one-it-is-for we can give up on C++ and go back to C where this used to be a thing, and not a bad idea that would be ;-)

Pl45m4

@JonB said in Problems Connecting to QMainWindow::repaint():

I didn't mean to point-score

I didn't felt like you did :) All good.

Well I don't see much difference between signals, slots and any other method. So if we're going to give up on same-name-methods-with-parameter-overloading and go for different-name-with-indicator-of-which-one-it-is-for we can give up on C++ and go back to C where this used to be a thing, and not a bad idea that would be ;-)

In my eyes, there is nothing wrong with that. Re-using C-related things in C++ is not always a bad idea ;-)
(C-casts might be :P )

You don't have to overshoot and change the way you name things in general, but anything is better than this clunky overload connection syntax...
When you already know that your signal/slot/function needs to take like three, four different arguments, which probably would have different effects (passing an int might be very different from passing a struct or string somewhere, even when it's for the same reason = same "function"), I think you should write separate functions anyway.

Also anyone can see right away what's going on

sendText(output)
is more meaningful than
send(output)
where you have to figure it out first, because output could be an int, a string, some struct... anything...

Imagine using overloads of the signal AND slot... your connection becomes twice as long and harder to read.

When multiple Foo::fooSignal and Bar::barSlot exist:

connect(foo, qOverload<FooType>::(&Foo::fooSignal), bar, qOverload<FooType>::(&Bar::barSlot));
connect(foo, QOverload<FooType>::of(&Foo::fooSignal), bar, QOverload<FooType>::of(&Bar::barSlot));

Urgh. :D

So I would prefer

void idClicked(int id)

over an overload of

void buttonClicked (QAbstractButton *)
void buttonClicked (int)

any time.

JonB

@Pl45m4
Well we're entitled to our own opinions, but I rather like the ability to overload same method name instead of invent different names for each one. What are you going to name e.g. each of the QObject::connect() methods? And overloading applies to constructor calls too, right, else there are a lot to write for QVariant(...) :)

Pl45m4

@JonB said in Problems Connecting to QMainWindow::repaint():

What are you going to name e.g. each of the QObject::connect() methods?

@Pl45m4 said in Problems Connecting to QMainWindow::repaint():

You don't have to overshoot

;-)

I mainly thought about the case when designing your public API in your application with Qt (with public signals/slot/functions etc.) and not to re-write every overloaded function which is existing ;-)
QObject::connect(...) ifself is not used in connections :)

And for regular C++ overloaded functions you don't have to specific anything. What is picked is decided by parameters and name.

@Pl45m4 said in Problems Connecting to QMainWindow::repaint():

void buttonClicked (QAbstractButton *)
void buttonClicked (int)

This just makes life harder as it should be :)

JonB

@Pl45m4 said in Problems Connecting to QMainWindow::repaint():

And for regular C++ overloaded functions you don't have to specific anything.

But signals and slots are just as much "regular C++ overloaded functions" as any other C++ function. It's just that you don't so often need to specify C++ functions as parameters to another function, like connect(), so you don't happen to notice the need to specify which overload so much. But you would if you did. Unless you say there is something really special about connect()/signal/slot, which I don't think there is. And compared to the rest of C++ I don't think there is that much extra typing you have to do... :)

Pl45m4

@JonB said in Problems Connecting to QMainWindow::repaint():

But signals and slots are just as much "regular C++ overloaded functions" as any other C++ function

I know, because there is nothing such as "signals" in C++. Technically they are all functions interpreted together with the Qt macros by MOC/compiler.

Unless you say there is something really special about connect()/signal/slot, which I don't think there is. And compared to the rest of C++ I don't think there is that much extra typing you have to do... :)

I started this, mainly speaking of public Qt API (i.e. public Qt signals).

Therefore I thought of changing ambiguous signals (or "functions" which are used in signal/slot connections) in the first place...
Other functions you would never put in a situation like this, where this topic is all about.

Connecting to functions, not declared as public slots became possible with the PMF/Functor syntax.
The old, string based style excluded most "critical" overloads.
(see, only the parameterless update() and repaint() functions are declared slots)
The string connection style requires to specify the signal's and slot's params, but since back then there was only one available for you (the empty call ()) you had no choice anyway :)

I got your point, hope you got mine ;-)

Edit:
At least you can get rid of every "signal" function overload without worrying about something else, as they have one purpose only: To be used in Qt's signal-slot connections.
That's what Qt did e.g. with QButtonGroup already

JonB

@Pl45m4
Yeah, we're all good :)

C++ '56 will prolly change all this...

I only just realised you are not the OP of this thread, I thought you were, hope we haven't hijacked it from OP!

Christian Ehrlicher

@Pl45m4 said in Problems Connecting to QMainWindow::repaint():

That's what Qt did e.g. with QButtonGroup already

Not only there, take a look at the deprecated stuff in 5.15 :)

SimonSchroeder

I'd like to jump with some remarks to the OP's problems.

First of all, the connect should be properly written as

QObject::connect( pDoc, &MyDoc::RequestRedraw, this, &MainWindow::repaint );

The only way I have learned the new connect syntax is to 1) take the address of the member function (hence the &) and 2) use the fully qualified name with the class name in front of it. At least in the description you have written, QWidget::redraw is not the same as repaint. Those are two different words with the same meaning.

As already mentioned, if you are connecting to an overloaded function (doesn't matter if its a slot or not), you need to use the qOverload function with the specific type. On older compilers you had to use the long form QOverload::of instead.

Also, don't call repaint directly unless you really have to. update is a lot more efficient because it will first collect several update calls and then issues a single repaint.

One final comment: The string based connect syntax always compiles. It does not matter what you write inside the SLOT(...) and SIGNAL(...) macros. Those will expand to strings and are not checked at compile time. This means even though it compiles it might not work. You need to watch out for debug messages when running your program that tell you that a signal or slot could not be found. Using the new syntax is more along the lines of "when it compiles it works", whereas the string based syntax is just a gamble.

Pl45m4

@Christian-Ehrlicher said in Problems Connecting to QMainWindow::repaint():

Not only there, take a look at the deprecated stuff in 5.15 :)

Yeah, that's what my posts above were all about :))
I like the trend to move away from overloads, at least for public API signals... because as we can learn from the topic here, dealing with overloaded signals is a pain ;-)

JonB

@Pl45m4
My last personal observation. Overloads are so easily coded, I always:

Stick in without qOverload() and see if compiler/code model tells you overload needed. 99% not, 1%...
...Look up desired overload in docs and put into qOverload<>(). If compiler did not complain it would be harder, but it does....

#2 takes a few seconds. So I don't get the problem.