Google

The K Desktop Environment
Next PreviousTable of Contents

4. Basic ideas

With the approach from above you can understand the usage of QextMDI.
As you may already suppose, two types of objects are important. You need a mainframe and views. Both ones must have additional functionality which makes them more than just a common QWidget. The mainframe has got the knowledge about managing the MDI views and the MDI view has got to know how to integrate itself in the MDI system.

At first I want to describe the whole mechanism in a quite easy way:

  1. Create a special mainframe class that inherits QextMdiMainFrm (which is a special QMainWindow).
  2. Create several view classes that inherit QextMdiChildView (which is a special QWidget).
  3. Add the views to the MDI system (take them under mainframe control) by calling addWindow(..) of the mainframe class.
  4. You can call methods of the mainframe class to generally control from the application's point of view.
  5. You can call methods of the view class to control that certain view window.
The way QextMDI handles those added views depends on the set MDI mode. At present, you can switch your mainframe class to Childframe Mode or Toplevel Mode or TabPage Mode (see above) by calling QextMdiMainFrm::switchToToplevelMode() or QextMdiMainFrm::switchToChildframeMode or QextMdiMainFrm::switchToTabPageMode. You can also switch the mode at runtime by choosing the appropriate menu items in the "Windows" menu.
The two methods switch all view windows, globally. A change to Childframe mode docks (attach) all undocked MDI views and a switch to Toplevel mode undocks (detach) all views from within the mainframe.

The method QextMdiMainFrm::addWindow(..) is probably the most important function in QextMDI. Here you take the view under MDI control and set an initial state set as flags for the method call. You can add a view as Attached, Detached (toplevel), Minimized, Maximized, hidden and pre-positioned or pre-resized.
 
Question: Why do you use addWindow(..)? Why not setting the mainframe window as MDI parent in the view contructor?
Answer:  addWindow(..) is used because of a possible plugin library system in your application. Once the QextMdiChildView is created in a dynamically loaded library, it is still not noticed by the QextMdiMainFrm which is located in the executable. And the MDI view still doesn't know the mainframe. It is created with parent 0L first. If the plugin component GUI gets active, it calls addWindow wich is an internal reparent to the mainframe. Only then it gets under MDI control. To summarize, the GUI plugin doesn't know anything about the mainframe.

In a bigger application often the mainframe is not accessable. You just want to deal with your current view. If a view is detached (in Toplevel mode), it still should be possible to call an attach(..), a minimize(), maximize() or to ask about the current state with for instance isAttached() or isDetached().
QextMdiChildView cares about all such stuff involved in the MDI system. For example, if you call QextMdiChildView::minimize(), it will minimize the view on desktop when it's detached or it will switch to a mini window (just the caption bar remains) when the MDI view is attached. That's why an extra class for MDI views.
 

Next PreviousTable of Contents