Best practice to access gui elements from other classes ?
-
What's the best practice to access gui elements from classes other than the main class ? (e.g. a QTcpSocket derived class that needs setting some ui elements).
-
My guess is it would be the "signals and slots":http://qt-project.org/doc/qt-4.8/signalsandslots.html mechanism.
-
That's possible indeed. But, depending on the number of elements you want to control, you may end up with lots of signals/slots, probably making the code less clear/readable... And one will still have an issue if a class needs e.g. to read information from a gui element, no ?
-
If you follow proper coding and naming conventions your code will stay clear. Signals and slots can also transfer information, you can pass parameters just like with regular functions. Besides, the only other possibility is to use function pointers or a third party library for call-backs, which will only INCREASE complexity and decrease readability. Signals and slots is by far the easiest and most readable solution you can hope for, and 99% of the work is done for you by the MOC.
Naturally, you can also go for a vanilla c++ implementation and bypass signals and slots and sort of build all your classes and their methods for usage in your particular scenario from the ground up but you will lose flexibility and will actually go against code reusability, which is an OOP core concept.
You obliviously haven't used signals and slots, that is the only reason they seem complex and alien to you, so just go ahead and use them, and as you get more familiar you will realize what a time and effort saver they are, compared to the "other way around". And last but not least, Qt is designed with the concept of signals and slots embedded in it and this concept is used extensively throughout the entire library. There is no avoiding them, there is no point in avoiding them, if you don't want to use signals and slots (which makes almost zero sense) you are using the wrong SDK framework. The entire GUI framework revolves around signals and slots, in case you haven't noticed!
You asked for best practice, you got the best practice.
-
Thanks for your reply.
I do already use signals and slots and they work fine. But in some cases, I was not convinced it was the best way to do. But that's obviously rather a problem of how my code is build up...
Now I am sure signals/slots is the way to go ! -
At first I was cautious embracing signals and slots, coming from some basic procedural programing skills I assumed the code that executes when a button is pressed must be tightly packed with the button, which is different than the signal and slot paradigm, where the code just sits there and is only connected to the signal of the button, making it easy to use the same code from other places without duplicating it. I also had performance concerns but signals and slots are very fast, hundreds of thousands of calls per second on an average contemporary machine. I still dislike the fact the actual code is written by the MOC, because I like to know what's happening even if it is swiped under the carpet, and after I discovered the messy ways to implement callbacks myself I am glad to leave it all to the MOC and just live with it.