I was wondering about the design pattern behind the signals and slots mechanism in Qt?
I am hesitating between the mediator and observer one?
Thank you...
QT's signals and slots is an implementation of the Observer pattern. If you want to know more about it, I recommend reading A Deeper Look at Signals and Slots which motivates it and compares it to Boost signals. Otherwise, there's always the QT docs.
If you want to use the Mediator pattern instead of the Observer pattern, it would be fairly trivial to do this using QT. You'd have to add a mediator class into the mix, and make it your observer of the events of interest; i.e. move the slots and most of your update logic from your regular observers to your mediator.
Related
I have a fairly complex MVC structured application and I want a convenient way to update a QStatusBar from almost any part of it. My understanding is that I would have to pass around a lot of references to my QStatusBar or set up a bunch of signals in my controllers. It would get messy.
I also understand that QApplication is essentially a singleton. Would it be an acceptable idea to add a slot to it so that I could get the instance of QApplication from anywhere and emit to it?
Alternatively, what is a reasonable way to communicate global-ish things in my application without littering the controllers and views with references to widgets parented elsewhere?
How about implement singleton, that allow communication between components and gui, something like:
#include <statuscontroller.h>
StatusController::instance()->setStatus("Status string");
In this case only StatusController contain pointer to QStatusBar and available globally in gui thread.
With QObject as base class for StatusController you could use signals and slots.
This question is not directly about programming, but I hope that it still fits here: When programming with Qt I have the problem that after some times my subclasses are getting extremely large which leads to a lot of signals and slots in each class I have to connect later. Therefore I was wondering if there is a simple possibility to keep track of all the signals and slots, for example to tell me if I forgot to connect a signal, or to show me all connections of one signal if it is connected more than once. Is there a tool or a function in Qt for that, or should I rather stay with pen & paper for keeping track of them?
Conan is a C++ library that provides run-time introspection of object
hierarchies, object inheritance, signal/slot connections, and signal
emissions.
GammaRay is another advanced analyser which can show signals/slots.
A typical line I often need is
connect(thread, SIGNAL(started()), this->actExecute, SLOT(setDisabled(>>bool<<)));
But afaik you can't connect signals/slots with different signatures.
It's often recommended to use a helper method to trigger/emit a custom signal which passes true/false, but I have a lot of actions which needs to get disabled/enabled on thread start/stop/other, so I want to avoid writing dozens of helper functions/signals.
Is there a better way (maybe a single-line solution)?
There is a way to do this but it depends on Qt 5 and C++11. You can use a lambda expression to call the slot with the appropriate parameters. There was recently a question asking how to do this specifically with QTimers, here is a link to the answer I gave earlier.
Basically though, the code will look something like this-
connect(thread, &QThread::started, this->actExecute, [=]() {
setDisabled(true);
} );
Make your own Action class by deriving it from QAction and add simple disable() and enable() slots to it.
If Qt 5 and C++11 can't be used, there are 2 possible solutions for this problem:
1) Derive QAction
Derive QAction and add 2 simple slots(disabled/enabled) to it as #Roku said.
2) Derive QThread
Derive QThread and add an additional signal started(bool) which will be emitted with a true parameter when started() signal is emitted and with a false parameter when finished() or terminated() signals are emitted although I must note that being notified by a started(false) signal that the thread has finished is not that intuitive especially if you're developing an API that will be used by other people.
If both approaches make you change a lot of code, then I would recommend using helper methods instead. Beside these, I don't think you have a better alternative.
I have learned the basics of Qt and now interested in the depths of that pretty library. Please help me to understand:
Are the all classes derived from QObject?
Why is it possible to paint on a QWidget (and derived classes)?
What does the line return app.exec(); mean? What does exec() method do?
Are there virtual slots? And virtual signals?
Thanks.
All classes that need Qt's object model (e.g. by using signals and slots) must derive from QObject.
So that you can implement your own widgets, with a customised look. Any sensible GUI library would let you do that.
As documented, it enters the Qt event loop.
Slots can be virtual. Since signals do not have implementation (or rather, moc generates their implementation), they cannot be made virtual.
Qt has really good and extensive documentation, if you have more questions then they are probably already answered there. Start with Programming with Qt section.
I always try to apply the S.O.L.I.D principles and I really like the Qt toolkit but I find myself stuggeling all the time with the single inheritance rule.
If you are using multiple inheritance,
moc assumes that the first inherited
class is a subclass of QObject.
Also, be sure that only the first inherited class is a QObject.
How do you combine the single inheritance from a QObject rule and the Interface Segregation Principle.
I want to define the interfaces with signals and slots, but I'm not allowed to do this.
How do you get around this shortcomming?
Keep in mind that signals and slots are nothing more than functions that have special behaviors. Thus, you can use them to create interfaces.
For a full description of the process and a complete workaround for complex cases, see Qt Quarterly #15.
I don't think you can easily get around that with Qt's signal/slot mechanisms. You could try looking at either boost::signals or the sigc library, which are both more flexible in where you can place signals and slots. Be aware of possible namespace collisions with either library and Qt's signals and slots macros.