[Solved] Restriction when making modal mdi windows
-
[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.).
-
-
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.
-
What's also still unclear is how to create a modal dialog with sheet style on the OSX platform for a MDI subwindow.
-
-
[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.