Whats the bext programming style (methadology) for Qt (compared to MFC)?

[mike_the_tv]

All
I am very new to Qt but so far think it looks really good. I have previously created several very complex MFC applications for Windows only, but now we need to start developing applications for a range of platforms including Linux, etc.

As such therefore I am quite accustomed to the MFC style of programming, however I don't want to just blindly use this programming style for Qt if it is not appropriate.

Now by style I really mean the programming paradigm. MFC tries to be object orientated but does not manage it entirely. Qt at first sight seems to be structured from the off to be an OO framework and therefore I want to take advantage of this from the off. It is all too easy to use something in the spirit of the language/API but fail to actually embrace the methodology. Too many C++ programs are written which are basically C programs written in C++.

I have previously used both dialog and SDI based interfaces in MFC. Both these seem possible under Qt, but so far I have not seen the same document/view framework that MFC presents for SDIs compared to Qt. I did look into document/view stuff under Qt but only found references to MVC concepts with regard to a selection of widgets (tables, lists and trees). It did not look like this concept extended to the application level which it does in MFC with the CDocument class behind the GUI. Now maybe this is just a usage issue and the concept is there, I am just not sure as MFC and VC++ creates at least the bare templates to these classes. If Qt does not implement this mechanism then I guess it can be created by a simple C++ class which uses the Qt slots and signals in the QUI classes.

Also in MFC you are quite often forced to create separate classes as a result of certain GUI designs. For example tab panes are not designed in place with the GUI editor, but as separate form views. As such they get created as separate classes. Qt seems to allow the contents of a tab pane to be visually constructed, which is just excellent. However this would then seem to imply that this tab control is just another child class of a single main window class. Is this the case? Is there any benefit in splitting the GUI controls into separate classes? I assume that is you create popup dialogs then these will be separate classes from a Qt view?

One final question. How does Qt compare to MFC in terms of an application framework? MFC encompasses not just the GUI but also the application in its framework, see SDIs, etc. Some old Googling results for Qt compared to MFC seemed to suggest that Qt used to be just a GUI framework rather than an application framework, but this was quite old.

Any hints, tips, etc. on how to structure a Qt application, SDI style, would be much appreciated. The examples are good but quite small and hence do not necessarily show you concepts and methodologies that you may adopt in a larger application.

I really want to start off on the right lines with this rather than start trying to make the Qt program work how I have been used to MFC programs working.

Cheers

[axeljaeger]

Hello,
you are right, Qt does not have an equivalent to a document class. You usually subclass QObject and create your own one. You could use signals & slots for communication between your view then but I suggest to use classic getter and setter there.

Signals & Slots are for loose coupled connection and a model and a view are usually very tightly connected together and not really replaceable.

Regarding seperate classes for views: I tend to create more and more classes for example for the different pages of a tab pane. Just in case I want to show those pages in a different context, it is easier to change the fact that they are embedded in a tab.

Also when I create for example a settings dialog for a certain class, I can ship settings pane and class to be configured to a customer and he decides how to embed the config pane in his UI.

Regarding the application framework: Qt does not have something like the mentioned document and I'm in the process of creating my own little application framework for doing syncing toolbars when a different document is selected and so on.

Regarding tips:
Create your application as a set of components. Create a lot of objects that inherit QObject or QAbstractItemModel and friends and put little code in your subclasses of QWidget. I've seen many applications that put a lot of code in their "MainWindow" and MainWindow becomes the god class. This is bad if you see a widget or window as a view that should not do any data processing.

Another tip is: Realy use the Qt Itemview framework. Do not use the convinience classes that have their own embedded model and where you can just "add items". This looks nice at the beginning but does not scale: You get your data from somewhere and when you add every single data item to some list widget, you have the first copy of your data in the application. You have now two independent copies of your data. Better implement for example a QAbstractListModel that is really just an adapter to your native data structure.

[mike_the_tv]

Thanks for the suggestions axeljaeger. That pretty much summed up what I had thought, just wanted to check I was not missing something really clever.