Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Exposing signal of the embedded QWidget
Jendker last edited by
Is there any nice way of exposing the signal of the embedded private member (in my case the MyWidget, which stays private, I am adding it with Qt Designer), so that it will be possible to connect to its signal from the outside (e.g. MainWindow)? I guess that would brake the encapsulation, but maybe there is a nicer way, than exposing it like this:
QObject::connect(my_widget, &MyWidget::my_signal, this, &MyDialog::my_signal);
Here MyWidget is embedded into MyDialog and its signal has to be accessed from the outside (from MainWindow) to connect.
With this solution it will be possible to connect to 'my_signal' of MyDialog instead of directly connecting to the signal of the private 'my_widget' as the walkaround. The obvious issue is the additional code while exposing all the necessary signals every signal time I am embedding this MyWidget in any form.
Thank you for any hints!
That's the correct way of doing it.
If you have that many signals to forward that it becomes cumbersome then you might want to rethink the design of your widget.
JonB last edited by
Writing a public accessor which returns the private MyWidget to the outside world lets them call anything they like on it with barely any effort....
Of course, as @SGaist says you're supposed to expose each signal or property on a case-by-case basis :)
Jendker last edited by
@JonB Thank you, of course you are right, I will keep it in mind :) I have no idea why didn't I think about it. I guess this is the reason why you should avoid programming late in the night...
JonB last edited by JonB
Well careful! I never advised this, I only mentioned it :)
It will let you get lots of things done quickly, but dirtily.
Providing proper wrappers like @SGaist said is the proper way.
We don't know whether you're part of company or a one-man band!
It's up to you :)
Jendker last edited by Jendker
@JonB Thanks for the advice! In this case I wanted restrain myself to the solution from my first post which @SGaist has recommended, I don't have that much signals to expose. I was just considering how to act in the future if the Widget would get more complex and will be careful with the design.
Thanks guys one more time for the help! I appreciate it.
I don't have that much signals to expose. I was just considering how to act in the future if the Widget would get more complex and will be careful with the design.
When your widget grows in complexity, take the time to figure out how to logically split it into a multiple smaller, independent widgets. The benefits are:
- You can unit-test each widget independently
- Each widget doesn't have that many signals to expose