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