Widget signal chaining

mpergand

@Pl45m4
Hi,
If I understand you well, from your description,
each widged needs to maintain a list of all their parents and another list of all their children.

You can create a abstract base class with a pure virtual method like:
void done(parent)=0;

When all parents have done for a widget, starts himself and when finished, calls done() for all the children.

Pl45m4

@mpergand said in Widget signal chaining:

each widged needs to maintain a list of all their parents and another list of all their children.

From my side there is no need to do that, but this might be one solution.
Was looking for the "cleanest" way, if there is any.
I'm not sure about putting a list of pointers to all other widgets in every widget. Deleting a widget will become more difficult then.

All I'm planing to do is to notify (via signal or something else) the next widget in the chain to start its task.
Currently I'm not even sure if it's better to work with widget x and let it notify widget x+1 or the other way round ("previous" vs. "next" approach, or both)

mpergand

@Pl45m4 said in Widget signal chaining:

I'm not sure about putting a list of pointers to all other widgets in every widget. Deleting a widget will become more difficult then.

You can use QObject::destroyed signal.
Or inform any children when a parent is deleted yourself.
Since you use subclasses of widgets, signals/slots are superflous.
You can create any methods you want to manage the states of your widgets.

jeremy_k

@mpergand said in Widget signal chaining:

Since you use subclasses of widgets, signals/slots are superflous.

Can you clarify this statement?

mpergand

@jeremy_k
Signals and Slots are made to interact to the outside, for ex a button with the mainWindow.
If you look at QWidget, it doesn't use signals when an internal state has changed, ex: focus, close, show etc, it use events.
Here, there is no benefice to us signals, it's heavy and complicated.

jeremy_k

@mpergand said in Widget signal chaining:

@jeremy_k
Signals and Slots are made to interact to the outside, for ex a button with the mainWindow.
If you look at QWidget, it doesn't use signals when an internal state has changed, ex: focus, close, show etc, it use events.
Here, there is no benefice to us signals, it's heavy and complicated.

devhost:qtbase/$ git grep connect src/widgets/
[...]

A quick glance will show that there are lots of signal and slot uses within complex widgets.

mpergand

@jeremy_k
If you're talking about compound widgets, yes of course they use signals.

Pl45m4

First of all, thanks to all of you for your comments and suggestions :)

Coming back to this, I decided to make something like QButtonGroup containing my widgets, to manage the chaining and notifications. I want to keep this private, so that it will be not a part of my widget's "API". Therefore I created a class similar to QButtonGroup's code and added signals and functions.

Since I have some experience in Qt in general but almost none in developing Qt plugins (QtDesigner plugins / widget "libraries") I'm wondering if it can/should be done like this?
Would it be better to subclass QButtonGroup (my widgets are QAbstractButton subclasses)?

Pl45m4

Solved.
Made some kind of manager class to organize the widget chain / hierarchy. So not the widgets know about the next or prev actions, but only the managing class knows. The widgets just have to know when it's their turn (notification comes via call or signal from controlling obj).
The tree / structure is also built in the controlling obj

Christian Ehrlicher

Not read the whole thread but maybe this is of interest: https://wiki.qt.io/TaskTree