Learning QT (with C++), I have been defining my own classes, which are not QObjects derivates. Even if QT tutorial teach you to extend their widgets in order to make your own I don’t because I was thinking that my code would be more “portable” and less QT inherent (if that makes sense) in case I switched to another graphical toolkit.
So my classes are something like this.-
class mainWindow
{
QVBoxLayout *winLayout;
public:
QWidget *winWidget;
mainWindow();
}
…so, having the main widget as a public member and everything being operated from within the classes, adding methods to manipulate my widgets.
In case I need Signals and Slots, I make a class extending QObject and use the Q_OBJECT macro.
But now I wonder, is my notion (explained in the beginning) even vaguely right? Do you think that I can face any issues in the future by doing this my way and not extending QT own widgets? What method should I stick to?
Your clas is not a proper QWidget, but I don’t think it would be a problem to Qt. Unless you need to gain acces to some protected elements of wigets (eg. interact with events) you could go without ever inheriting qt widgets – the choice of design is yours.
The only reason for inheriting might be to save some memory taken by additional QObject, but if your class is not extensivly used in application, this should not be an issue.
About being less “Qt inherent” i can only say that moving application from one framework to another usually needs lots of changes, independently on your design, so this aregument doesn’t really convince me.
On tth other hand this is generally bad idea to keep public field in a class like this – accidental modifications will cause difficult to track errors – think about making winWidget private and adding some accesor method perhaps?
When i was beggining to learn qt, I also had aversion to subclassing QWidgets, but soon i realised that it is simply more comfortable to inherit, mostly because you don’t need heavy changes to your class if one day you need event-interaction.