Opened 14 years ago
Closed 13 years ago
#198 closed defect (fixed)
modal child widgets go to background
Reported by: | rudi | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | Qt 4.7 |
Component: | QtGui | Version: | 4.6.3 |
Severity: | low | Keywords: | |
Cc: |
Description
Certain modal 3rd-level child widgets go to the background (i.e. behind the main window) when they should not. An example for this is in Arora browser:
1. Select "Tools/Options" from main menu 2. On the "Autofill" tab, click "Edit" 3.) Click on the Arora main window
What happens is, that the modal dialog "Form Passwords" will disappear behind the main window. Something similar can be observed with KDIFF3.
Change History (6)
comment:1 by , 14 years ago
comment:3 by , 13 years ago
I guess I see a similar problem with Qt Creator. Try to open the Session Manager dialog and then click the What is a Session? link below. You will notice that the main application goes on top while still remaining inactive (blocked by the Session Manager dialog).
comment:4 by , 13 years ago
Found the reason. We not always disable the blocked windows right. This is especially true when there is a bunch of modal windows created (and not necessarily visible). What happens is that the window to be disabled is first disabled and then gets accidentally re-enabled under some circumstances.
BTW, I had to do quite a lot of testing to see how this should behave. I found some inconsistencies, at least on Linux, where they block all the application when a window with WindowModal windowModality() and NO parent is shown. While WindowModal only means blocking parents and their siblings (as opposed to Application modal which is to block all regardless of whether it has a parent). I will not go this way on OS/2. (Windows seems to behave correctly).
comment:5 by , 13 years ago
I fixed the original issue in r936. The blocked windows are really blocked now, it should be impossible to put them in front of the modal windows they are blocked by, neither with the mouse, nor programmatically (e.g. from the Window List).
Note that there is one difference from the standard (expected) behavior: bringing the modal window in front does not pull the the window it blocks to the surface -- i.e. if both are obscured, attempting to activate either of them will reveal the modal window, but the blocked one will remain obscured. It's not easy to do it right since PM doesn't support window blocking in the way needed by Qt and Qt does not maintain its own global Z-Order list. I will try to solve that later.
comment:6 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I implemented proper Z-order changes in r938. It was a bit tricky (it's always tricky to be smarter than PM wants you to be). But now it works quite well, in some aspects better than on Windows (e.g. activating the parent-less ApplicationModal widget on Windows will not bring the widgets it blocks right behind it, if they are hidden, they will remain such -- on OS/2 this is not the case).
Also, under no circumstance there should be the case when the blocked (i.e. completely disabled) widget goes above the modal one -- this is what sometimes happens on Linux and which really annoys because you find yourself typing into a wrong window.
Enough for this defect. Feel free to create a new one if you find any problem with the new implementation.
Rudi did you test with Qt 4.6.3? I added the 4.6.3 version now, so it can be selected.