Qt Creator - ui as private member instead of inheriting from it.
-
I came across the book "C++ GUI Programming with Qt 4" "(1st Edition is available online":http://www.qtrac.eu/C++-GUI-Programming-with-Qt-4-1st-ed.zip) and found very interesting that on their examples the "ui" class is used as base for the widget (window, dialog) and not like Qt creator does as a "private member".
I have never bothered creating it by hand so have always used the code generated by qt creator. Now after reading the example, I actually like the "multi inheritance" approach better - no more "ui->...." business...
I am looking at the first edition, does anybody know any good reason for the shift in "recommended" methods?
-
Good question. As I rarely develop stuff using ui / qt designer (most of my projects uses QGW or QML), when I need to use it I always ask myself what's the best approach. I like the inheritance way, but is not based on any good reason.
-
I like the private member approach, because the code is better encapsulated this way and the generated code is separated from my own (written by me) code.
And as a disadvantage i can mention the fact that you might need to code more signals and slots just to keep the ui pointer (or member) private.
-
The decision should be made based on how the class will be used. A private ui pointer has the advantage of keeping the UI private. Doing so restricts the interface of the class, which is a good thing because it cuts down on potential coupling between classes. However, if the class needs to be used as the widget defined by the UI, then inheritance is necessary.
-
[quote author="Volker" date="1292189521"]In the "Qt Tips and Tricks" track on DevDays 2010 they recommended to use the private pointer method. Unfortunately I cannot remember the reason why, so we'll have to wait for the videos :-)[/quote]
Because of binary compatibility. It's used extensively on Qt and on KDE libs. It's called "d-pointer" very frequently:
"http://en.wikipedia.org/wiki/Opaque_pointer":http://en.wikipedia.org/wiki/Opaque_pointer
"http://techbase.kde.org/Policies/Library_Code_Policy#D-Pointers":http://techbase.kde.org/Policies/Library_Code_Policy#D-Pointers -
With regard to BC that's the only choice, true. But that's mainly an issue with libs. In applications it's not that important, IMHO. But you're right - in general it's the easiest approach and does not cause any troubles. Multiple inheritance can be confusing too :-)
