[Solved] Restriction when making modal mdi windows
-
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.
-
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.