Qt/OO best practices: connecting signals and slots

1
votes

I'm relatively light on Qt experience, though I definitely like it. One thing I'm uncertain of is where the best place is to connect signals to slots. Here's an example from my small device with a touchscreen:

I have a class called RadioModel that is owned by my QApplication. My QApplication also owns what I call a ViewController. The ViewController owns the view - i.e. all of the widgets that make up the user interface. There is some hierarchy to the UI widgets, of course. The top-level widget is a QHBoxLayout, which has indicator labels at the top, and a QTabWidget at the bottom. The QTabWidget has 3 screens, each with things like QLabels, QGroupBoxes, QComboBoxes, etc.

The model needs to be signaled when values in the QGroupBoxes and QComboBoxes change. My initial thought was to have a chain like this:

QRadioButton (part of QGroupBox) signals clicked(), this goes to SLOT of the current tab of the QTabWidget, which looks at the sender to determine the value (which radio button) that was clicked, then emits its own signal like RadioChanged. This RadioChanged signal would get connected to the ViewController's RadioChanged signal, which would in turn be connected to the Model's UpdateRadio slot.

Generally speaking, when a widget that is fairly isolated from the model emits a signal of interest, is it fair to have this long chain of signals and slots to get that value change back to the model? Would it be better to pass the model into the ViewController and possibly some of its objects so that the signals can be connected with a shorter path?

Thanks - hope that was understandable and hopefully not too subjective..

1
c++qtsignals-slots
signal mapper helps to convert clicked to changed. It's true that relaying signals out is sometime a pain, but from an OO point of view, outside of ViewController, no one knows about or cares about what a pain it is to route signal out within ViewController, hence has no reason to break OO rules to make ViewController's life easier. I actually consider it a good sacrifice if top-level signal/slot is kept clean at the price of ugly implementation-level signal/slot. – user3528438
Thanks for the heads-up on signal mapper. I will vow not break OO rules. – Rich von Lehe
stackoverflow.com/a/54577124/3096593 – francek

1 Answers

2
votes

I implement mine as 'the controller controls the flow of data'. It gets signals from the view. It then updates the model as needed. The view knows nothing about the model and vice versa.

I notice you said you're signaling each user input change. This can be very inefficient and makes it difficult to cancel half made changes. I usually let the user change all the fields and only update the model when the OK button is pressed.