PDA

View Full Version : Reponsabilities of QApplication and QMainWindow classes



yellowmat
4th September 2006, 10:10
Hi everybody,

What are the main differences of responsability of QApplication and QMainWindow classes ? To give you more details, I wonder what kind of code can be implemented in QApplication and what kind must not be.

I ask thoses questions because I am working on an application, not developped by me, and many functions are coded in a class inherited from QApplication (slots, signals, timers). The application runs but I wonder if it is well architectured and if that kind of way of coding can be problematic.

Thanks in advance for your answers.

munna
4th September 2006, 10:49
From the docs


The QApplication class manages the GUI application's control flow and main settings.
It contains the main event loop, where all events from the window system and other sources are processed and dispatched. It also handles the application's initialization and finalization, and provides session management. It also handles most system-wide and application-wide settings.
For any GUI application that uses Qt, there is precisely one QApplication object, no matter whether the application has 0, 1, 2 or more windows at any time.


The QMainWindow class provides a main application window, with a menu bar, dock windows (e.g. for toolbars), and a status bar.
Main windows are most often used to provide menus, toolbars and a status bar around a large central widget, such as a text edit, drawing canvas or QWorkspace (for MDI applications). QMainWindow is usually subclassed since this makes it easier to encapsulate the central widget, menus and toolbars as well as the window's state. Subclassing makes it possible to create the slots that are called when the user clicks menu items or toolbar buttons.

Hope this cleared your doubt

wysota
4th September 2006, 11:15
To explain a bit more. QApplication object is always available in your application through the static QCoreApplication::instance() call (or qApp macro), making it a good placeholder for objects, which otherwise would need to be global. This gives an additional benefit, because sometimes when you construct some global objects (for example timers), you get a message, that you can't construct such an object without a QApplication object. This is a way to bypass such messages.

The main window object should only hold data related to the main window itself, whereas the application object can hold data related to different components of the application. To go a little further, the application object can wrap the main window object too, which could make the resulting code clearer and simpler, look at an example of a main() function with the main window (be it QMainWindow or any other widget) wrapped into the application:

#include "myapplication.h"
int main(int argc, char **argv){
MyApplication app;
return app.exec();
}

You can also implement your application object to return various objects used by different components as static pointers, for example a pointer to the main window. This makes access to the widgets you need simpler and less error prone. Consider this snippet:

MyWidget *wid = qobject_cast<MyWidget*>(parent()->parent()->parent()->parent());
This could be substituted by:

MyWidget *wid = MyApplication::myWidget();

or even as a regular function call - without static pointers (some people don't like them):

MyWidget *wid = qApp->myWidget();

To summarise, in my opinion you can put in the application object everything you consider "application wide" and in the main window only those things, which are actually used by the main window or its direct subclasses. A different approach comes when ypu are lazy -- you put everything in the main window and use QApplication without subclassing, as it is a little more time consuming to make a good design out of it.

yellowmat
4th September 2006, 12:31
Thanks Wysota,

Your answer contains all details I need.

jacek
4th September 2006, 17:21
One more thing: QMainWindow is just a widget and you can create many different instances, as for QApplication --- there can be only one ;)