[Solved] Restriction when making modal mdi windows



  • I'm having some problems when trying to create modal MDI windows and don't seem to find the appropriate information regarding any restrictions in doing so. I'm aware that this is not a very common UI design but for my specific use case I need to use an MDI UI but still need some modal dialogs.

    In general:

    • a modal window needs a parent and the the appropriate window flags to be created.
    • a MDI subwindow needs to be first created as a window and then added to the MDI area

    @
    ...
    QDialog* aDialog = new QDialog(aParent)
    aDialog->setWindowFlags(Qt::Sheet);
    aDialog->setAttribute(Qt::WA_DeleteOnClose);
    aDialog->setWindowTitle("Modal dialog");
    aDialog->setWindowModality(Qt::WindowModal);
    aDialog->setModal(true);
    ...
    QMdiSubWindow* aMdiSubWindow = aMdiArea->addSubWindow(aDialog);
    aMdiSubWindow->show();
    ...
    @

    Unfortunately combining modal windows with mdi windows does not seem to work as expected and all my attempts ended with proper MDI but non modal windows.

    Any help, examples or hints to the documentation I did not yet find would be appreciated.



  • Hi,

    first, what is a modal MDI window?
    MDI means multi document interface, which means (normally) an application with multiple documents open at the same time.

    Model windows are normally popups, which spin an own event loop (like QDialog) when you call exec (which in fact creates the modal event loop). If you set the widget the state modal and the call show, it will not be modal.

    That means, an MDI sub window is never a modal window, especially as the QMdiSubWindow would then need to be modal, not the dialog.

    If you look at the documentation, you find the following:

    • "Indicates that the window is a Macintosh sheet. Since using a sheet implies window modality, the recommended way is to use QWidget::setWindowModality(), or QDialog::open(), instead.":http://doc.qt.nokia.com/4.7/qt.html#WindowType-enum

    • "This property holds which windows are blocked by the modal widget. This property only makes sense for windows. A modal widget prevents widgets in other windows from getting input. The value of this property controls which windows are blocked when the widget is visible. Changing this property while the window is visible has no effect; you must hide() the widget first, then show() it again.":http://doc.qt.nokia.com/4.7/qwidget.html#windowModality-prop



  • Gerolf is right. MDI subwindows are not modal by definition. If you want to create modal dialog, your QDialog based class must not be put into the MDI area with addSubWindow(). Instead it must be shown with exec() or open() - depending if you want it to be application modal or window modal.



  • Thank you for all your help!

    I'm not so sure why an MDI window should never be modal by definition (quote from Wikipedia: Graphical computer applications with a multiple document interface (MDI) are those whose windows reside under a single parent window (usually except for modal windows), as opposed to all windows being separate from each other (single document interface)) but I know that this would lead to a discussion about MDI in general and I'm just trying to get a problem solved.

    I just take it as granted that Qt does not allow to create a modal MDI window but understand that I can create a modal window/dialog as long as it is not part of the MDI area.

    I'm not fixated on using an MDI UI but what alternative design/implementation would you suggest to get the following:

    • I need a "task window" acting as an enclosure for all my application windows
    • It would be nice to keep all (actually most) application windows organized inside the "task window"
    • I need a single menu bar for my application and a open windows menu showing the open windows
    • I need to create nested hierarchies of the application windows
    • I (sometimes) need to create window modal dialogs for specific MDI windows that have a nested hierarchy
    • On the windows platform typically only the "task window" should appear in the task bar


  • [quote author="d.oberkofler" date="1294043636"]I'm not so sure why an MDI window should never be modal by definition [/quote]Whether by definition or not, it doesn't make sense at all to choose an MDI setup (where you can switch between windows without restriction) while blocking interaction with all other windows...



  • Hmmm... So I guess you want to make modal dialogs that are specific to a certain MDI subwindow? I guess there may be usecases for such a thing, but it is AFAIK not supported by Qt directly. However, I think it would not be that hard to create something that would work.

    One way that might work is to create a QMdiSubWindow subclass that supports putting an overlay over the whole window (for instance a partly opaque black rectangle so your window looks unavailable) and keeps another QMdiSubWindow above itself. So, when you activate the window that has an open model dialog on top of it, it would immediately activate that window so it is put on top of it. You then make sure your MDI windows are subclasses of this new class instead of inheriting QMdiSubWindow directly.



  • [quote author="Franzk" date="1294046110"]
    [quote author="d.oberkofler" date="1294043636"]I'm not so sure why an MDI window should never be modal by definition [/quote]Whether by definition or not, it doesn't make sense at all to choose an MDI setup (where you can switch between windows without restriction) while blocking interaction with all other windows...
    [/quote]
    I beg to differ!
    I do have very valid use cases where windows in an MDI application have a nested hierarchy and need to block the interaction with the parent windows.



  • [quote author="Andre" date="1294047672"]Hmmm... So I guess you want to make modal dialogs that are specific to a certain MDI subwindow? I guess there may be usecases for such a thing, but it is AFAIK not supported by Qt directly. However, I think it would not be that hard to create something that would work.
    One way that might work is to create a QMdiSubWindow subclass that supports putting an overlay over the whole window (for instance a partly opaque black rectangle so your window looks unavailable) and keeps another QMdiSubWindow above itself. So, when you activate the window that has an open model dialog on top of it, it would immediately activate that window so it is put on top of it. You then make sure your MDI windows are subclasses of this new class instead of inheriting QMdiSubWindow directly. [/quote]

    We are currently emulating in Qt the needed behavior by disabling the parent windows. This does work but is not a very elegant solution. I wanted to explore the options Qt offers but it seems as if the restriction Qt imposes would not allow us to use modality to satisfy our requirements.



  • [quote author="d.oberkofler" date="1294050480"]
    We are currently emulating in Qt the needed behavior by disabling the parent windows. This does work but is not a very elegant solution. I wanted to explore the options Qt offers but it seems as if the restriction Qt imposes would not allow us to use modality to satisfy our requirements.
    [/quote]
    I don't think it is a restriction from Qt per se, but more a restriction in the standard way this document model works. I have not seen the behaviour you're after on other platforms either, as far as I can remember. I think it makes sense that it is not provided by default, but I think it is still posible to provide it in a reasonable way. For me, that is a sensible choice: make easy what is common, and make possible what is not.



  • [quote author="Andre" date="1294051003"]For me, that is a sensible choice: make easy what is common, and make possible what is not.[/quote]
    I agree



  • MDI windows per se do not have a "hierarchy" on themselves. Each QMdiSubWindow is treated equally in Qt. You can have window modal dialogs on a single MDI subwindow by calling "open() ":http://doc.trolltech.com/stable/qdialog.html#open on the dialog. The other subwindows are fully functional then. "Qt Quarterly":http://doc.trolltech.com/qq/ Issue 30 has a nice article about Dialogs and Modalities.

    If you have a kind of hierarchy on your subwindows, and if you want to block all the windows in the hierarchy if some modal dialog is opened from one of its members, you must both set up that relationship manually and disable user interaction the windows.

    Qt does not provide a direct way to achieve this, as this is not a common use case for MDI applications.



  • [quote author="Volker" date="1294061799"]MDI windows per se do not have a "hierarchy" on themselves. Each QMdiSubWindow is treated equally in Qt. You can have window modal dialogs on a single MDI subwindow by calling "open() ":http://doc.trolltech.com/stable/qdialog.html#open on the dialog. The other subwindows are fully functional then. "Qt Quarterly":http://doc.trolltech.com/qq/ Issue 30 has a nice article about Dialogs and Modalities.
    If you have a kind of hierarchy on your subwindows, and if you want to block all the windows in the hierarchy if some modal dialog is opened from one of its members, you must both set up that relationship manually and disable user interaction the windows.
    Qt does not provide a direct way to achieve this, as this is not a common use case for MDI applications.[/quote]

    Thank you for the additional information!
    Now I'm again unsure if Qt might be able to solve our my use case out of the box.

    Please let me explain in more detail what I need:

    • There can be several open subwindows in the MDI area and interact with each other (enabling and disabling the user interaction clearly must be done manually)
    • Sometimes one of the subwindows needs to be blocked from any user interaction because the user needs to complete a (modal) dialog before resuming to interact with the subwindow (this is where is would need a window modal dialog)

    Can (and how) can this be done in Qt?



  • If it is a Dialog ( and is displayed as dialog), just create the dialog and call dlg.exec();

    @
    {
    CMyDialog dlg();
    if(QDialog::Accepted == dlg.exec())
    {
    // handle ok
    }
    else
    {
    // handle cancel
    }
    }
    @

    But this opens a new dialog window (not inside the MDI area) which is application modal. No other application windows can be handled, expect they are created from this dialog (as sub dialogs etc.).



  • Gerolf, did you actually read the thread before replying? Displaying an application modal dialog box was not the issue at all.



    1. I do understand the availability of a stand-alone application modal dialog in an MDI application but according to [quote author="Volker" date="1294061799"]You can have window modal dialogs on a single MDI subwindow by calling "open()[/quote] it should also be possible to create a window modal dialog on a single MDI subwindow and this is where I'm still a little confused.

    2. What's also still unclear is how to create a modal dialog with sheet style on the OSX platform for a MDI subwindow.



  • To 1) window modal means modal to the top level window, which is the mainWindow.
    To 2)
    bq. What’s also still unclear is how to create a modal dialog with sheet style on the OSX platform for a MDI subwindow.

    do you want a dialog?



  • [quote author="Andre" date="1294134904"]Gerolf, did you actually read the thread before replying? Displaying an application modal dialog box was not the issue at all.[/quote]

    Yes, I have. But if you read it, there is sometimes talked about modal dialogs, sometime about MDI subwindows which should be model. The second one does not work without doing it by hand --> disabling all other windows.



  • [quote author="Gerolf" date="1294139711"]To 1) window modal means modal to the top level window, which is the mainWindow.[/quote]In my understanding this is only the case in an MDI application.
    Does this imply that in an MDI application there is no difference between application and window modal?
    Would it therefore also be impossible to create a (window) modal "Sheet" for a MDI subwindow?

    [quote author="Gerolf" date="1294139711"]To 2)
    do you want a dialog?[/quote]Typically a QDialog (Sheet on OSX) but does it make any difference if it would "only" be a QWidget?



  • I guess the point is, that a QMdiSubWindow - in my understanding - really isn't a window at all. It is a widget that can be moved around an a working area (another widget) and that has some decorations drawn around it to make it look like a window. That would imply that the only window that have available, is your main (task) window: the window that is visible on the systems task bar.



  • [quote author="d.oberkofler" date="1294139506"]2) What's also still unclear is how to create a modal dialog with sheet style on the OSX platform for a MDI subwindow.
    [/quote]

    You can create a Mac sheet this way:

    @
    SheetDialog *sd = new SheetDialog((QWidget *)this->parent());
    sd->open();
    @

    Important is the call to open instead of exec. Qt Quarterly Issue 18 has an Introduction to "Qt/Mac Special Features":http://doc.trolltech.org/qq/qq18-macfeatures.html, including the sheets.

    Unfortunately you cannot have a dialog which is modal to a single MDI subwindow only, it's always modal to the hierarchy of widgets and windows, which ends with the toplevel widgets (i.e. that without a parent widget; mostly QMainWindows or QDialogs). That means, if you set up a window modal dialog the complete MDI area and all of its subwindows are blocked.



  • [quote author="Andre" date="1294144204"]I guess the point is, that a QMdiSubWindow - in my understanding - really isn't a window at all. It is a widget that can be moved around an a working area (another widget) and that has some decorations drawn around it to make it look like a window. That would imply that the only window that have available, is your main (task) window: the window that is visible on the systems task bar. [/quote]

    That's right. At least it is not a toplevel window. This is the widget hierarchy of a widget that's placed in a QMdiSubWindow:

    @
    SubWindow(0x1b00060, name = "SubWindow")
    QMdiSubWindow(0x1b04830)
    QWidget(0x15a1ca40)
    QMdiArea(0x15a08820, name = "mdiArea")
    QWidget(0x15a168a0, name = "centralWidget")
    MainWindow(0xbffff980, name = "MainWindow")
    @

    With SubWindow being my widget, thats placed in the MDI area with mdiArea->addSubWindow(widget) and MainWindow beeing my QMainWindow subclass.



  • bq. d.oberkofer wrote
    Typically a QDialog (Sheet on OSX) but does it make any difference if it would “only” be a QWidget?

    If you need a dialog, there should not be a problem.

    Regarding window / application modal:

    modalness always is regarding the top level window. If you have several top level windows, you can also have application modal stuff (thats an addition in multi window applications).



  • I think the Qt's "Window's Modalness" features are bad implemented. I mean, why restricting modal windows only to the top level parents? I know, it's probably the 99.99% of the cases. But you must always implement the most flexible solution. In this case it would be to make a Window/Dialog modal only to its parent! (And maybe, if no parent is provided, to the whole application).



  • I don't think it is badly implemented at all, and it is nonsense that you have to stay flexible enough to cater for 0,01% (your numbers) of the users. You can't. They can rely on their own solutions for such rare use cases.

    The reason is very simple though, IMHO. It has to do with what window managers provide and how they work. Also, it is very hard to make a UI that is still intuitive for the general case. How are you going to indicate that a dialog is modal only for a certain button? Or for a group of buttons? Or a scroll bar? Since you have to be able to interact with the rest of the widgets, the dialog can not stay above the (top level) window, making it even harder for the user to make sense of why that button-with-a-modal-dialog can not be accessed.

    In the case of QMdiSubWindows, sub-window-modal dialogs can sort-of make sense, but only because these widgets mimick top-level windows in many respects. For the general case, I don't see a use case at all.



  • What is nonsense is to restrict a functionality just because you think it won't be used in any other way. I'm not talking about making a function more complex, it would probably be simpler without this restriction.

    Why would you make a QDialog's parent a QPushButton? That's illogical, but still is possible. And that's OK! Let's stay on illogical, let's say you create a QDialog(QPushButton) and make it modal. Then yes, it should be modal only to that particular QPushButton! Of course it isn't usefull at all! But then again, why would you make a QDialog's parent a QPushButton?!



  • I've not read any docs on this, but I'm pretty sure "modality" is defined in some Human Interface Guidelines and implementation is based on that. These guidelines surely do not know about any kind of parent-child relationship. The latter is the way Qt detects what should be blocked by the dialog.

    I agree that QMdiSubWindow behavior does not fit correctly into that.

    What the user want's is expectable user interface behavior. Modality on a push button does not fit into this category, IMHO.



  • [quote author="ivan.todorovich" date="1294151515"]What is nonsense is to restrict a functionality just because you think it won't be used in any other way. I'm not talking about making a function more complex, it would probably be simpler without this restriction.[/quote]

    A component is designed in a way that is behaves according to expectations of the users. As Volker said, that is probably a HIG. In Qt's case, I guess it is several HIGS, for all the platforms Qt runs on. The concept of a modal window applies to top level windows or even complete applications, not to widgets. That is also how window managers work with them. It would be insane IMHO if Qt decided to do it completely different.

    [quote]Why would you make a QDialog's parent a QPushButton? That's illogical, but still is possible. And that's OK! Let's stay on illogical, let's say you create a QDialog(QPushButton) and make it modal. Then yes, it should be modal only to that particular QPushButton! Of course it isn't usefull at all! But then again, why would you make a QDialog's parent a QPushButton?![/quote]

    Why? Very simple. A component that pops up a modal dialog for more detailed interaction. I wrote and use such a thing frequently! This particular component is to select a file. It is basically a combo box (with recently used files) with a button next to it that pops up a modal file dialog so you can select another file easily. And yes, I do expect that dialog to be modal to the whole window, not to just the small button that triggers it or even the whole file selector widget. In this case, the parent is the file selector widget, as that widget knows nothing of the context is is used in, and nor should it.

    If you yourself claim that it is not useful at all, why should Qt jump through all the hoops to make it possible anyway, and then bother all users of Qt with API that just gets in the way of programming, because a feature behaves in a weird way that may benefit 0,01% of the users at some point. I'm glad you're not the one designing APIs at Nokia...



  • [quote author="ivan.todorovich" date="1294151515"]What is nonsense is to restrict a functionality just because you think it won't be used in any other way. I'm not talking about making a function more complex, it would probably be simpler without this restriction. [/quote]

    It's not more complex, this way it's easier. They just spin a local event loop that filters out the events for this dialog, that's it. And (e.g. on Windows) it's normal behavior to have it that way. In old windows (win 3.1) modal means system modal. sin win95/winnt it means application modal. Nowerday you also have top level window modal. This is e.g. used in MS Word (where each document has a top level window).

    Afaik Linux (KDE) has a similar meaning of modal. Other types of modalness could be usefull in some special cases, but why should this 0.01% solution drive the main implementation? You can do it on your own if you need it. so it's not impossible.



  • HIG, you mean like Apple's Human Interface Guidelines? Let's take a look at Sheets (Document-Modal Dialogs)

    bq. A sheet is a modal dialog attached to a particular document or window, ensuring that the user never loses track of which window the dialog applies to. Because a sheet is attached to the window from which it emerges, a sheet does not have its own title. Figure 14-46 shows an example of a sheet.

    http://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGWindows/XHIGWindows.html#//apple_ref/doc/uid/20000961-TPXREF11



  • It works exactly that way with QDialog::open(), except for QMdiArea's QMdiSubWindows (which we all agree upon that it's a misbehavior).



  • This post now contains so much information that I would like to recap what I have understood and please correct me if I (still) got something wrong:

    • Qt does fully supports application and top level window modality (including Mac sheets)
    • In an MDI application a modal window can only be based on the QMainWindow
    • Qt does not treat QMdiSubWindows as top level windows and therefore restrict the use of modal windows to the QMainWindow (IMHO this is the only thing that I see as a restriction and do not yet understand why it is needed)

    To get back to my use case, I would still be most interested to hear how you would solve or make compromises to get the following functionality:

    • I would like to have a “task window” (this would be the QMainWindow) acting as an enclosure for all my application windows to nicely keep all application (sub)windows organized inside this “task window”.
    • I need a single menu bar for my application and a open windows menu showing the open windows.
    • I need to create modal dialogs for specific MDI subwindows that have a nested hierarchy.
    • On the windows platform only the “task window” should appear in the task bar.


  • Good recap, though your second statement is untrue. Any widget can contain a QMdiArea, in which sub windows can be displayed. A QMainWindow would often be suitable however as the kind of "task window" you're after, if you set a QMdiArea as the central widget of the QMainWindow.

    I think we agree that perhaps dialogs should be able to be modal for a QMdiSubWindow (but not for a widget in general). You could create an issue for that in Jira, but to be honest, I doubt it would be accepted without a ready made patch. There doesn't seem to be that much interest in further developing the QWidget based part of Qt at the moment.

    I am not quite sure what you mean exactly by MDI subwindows that have a "nested hierarchy". What is nested in what, exactly? Do your MDI subwindows act as new QMdiArea's with their own subwindows again? I hope not...

    I think I already suggested a path to a solution before: create a QMdiSubWindow subclass that allows disabling itself, and that will activate another QMdiSubWindow when activated itself. That way, you can mimick the way your window manager handles modal windows now. I think that would be doable, and could yield a behaviour similar to that of normal modal windows and their parent windows. I did not try it myself, however.



  • [quote author="Andre" date="1294219924"]Good recap, though your second statement is untrue. Any widget can contain a QMdiArea, in which sub windows can be displayed. A QMainWindow would often be suitable however as the kind of "task window" you're after, if you set a QMdiArea as the central widget of the QMainWindow.[/quote]Thank you for clarifying this.

    [quote author="Andre" date="1294219924"]I think we agree that perhaps dialogs should be able to be modal for a QMdiSubWindow (but not for a widget in general). You could create an issue for that in Jira, but to be honest, I doubt it would be accepted without a ready made patch. There doesn't seem to be that much interest in further developing the QWidget based part of Qt at the moment.[/quote]I might still try to have this record (at least) on record.

    [quote author="Andre" date="1294219924"]I am not quite sure what you mean exactly by MDI subwindows that have a "nested hierarchy". What is nested in what, exactly? Do your MDI subwindows act as new QMdiArea's with their own subwindows again? I hope not...[/quote]No! I just wanted to say that a subwindow might open a modal dialog and this dialog might again open a new modal dialog.

    [quote author="Andre" date="1294219924"]I think I already suggested a path to a solution before: create a QMdiSubWindow subclass that allows disabling itself, and that will activate another QMdiSubWindow when activated itself. That way, you can mimick the way your window manager handles modal windows now. I think that would be doable, and could yield a behaviour similar to that of normal modal windows and their parent windows. I did not try it myself, however.[/quote]Thank you again for the suggestion.

    Does everyone agree that creating an MDI UI (and mimic modal windows) is the correct architectural choice or should I rather not use the Qt MDI functionality and mimic the MDI features?



  • Dieter, from what you wrote, I would go further with the MDI approach.

    You can open a second modal dialog on top of an already modal dialog. As long as these are "genuine" windows (MDI or toplevel) it is not of any concern for the user in general (in our application we do that in some places and it works without problems). If you have OS X sheets on the Mac you would definitely have to open another "real" window - I'm not aware of sheets on sheets working (despite the user getting confused by that :-) ).

    If you have to deal with disabling other MDI subwindows you can setup some specialized signal/slot mechanism to pass the state around. Your main window could be a good place to organize these kind of things.



  • I agree: it seems that in principle MDI is suitable for what you want, just just need to get some modal behaviour to them for your purposes.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.