GNOME Bugzilla – Bug 96140
Stacking of transient children of transient with a group-induced layer promotion
Last modified: 2004-12-22 21:47:04 UTC
See the FIXME in stack.c:compute_layer about this. If we move a dialog into the dock layer because it's in the same group as the dock, then we don't move its transients into the dock layer. (In metacity-window-demo, create parentless dialog and bottom dock, then from the parentless dialog create some children of the parentless dialog, note that those children are underneath the dock.)
Batch adding GNOME2 keyword to Metacity bugs. Sorry for the spam.
Still broken, maybe the same fix as bug #100343
*** Bug 126427 has been marked as a duplicate of this bug. ***
*** Bug 128801 has been marked as a duplicate of this bug. ***
*** Bug 129038 has been marked as a duplicate of this bug. ***
not sure I understand the implications of this bug. But just to note, GOK wants its preference dialog (for instance) to be in a non-DOCK layer even when GOK's main window is a DOCK. Will this still be possible?
*** Bug 129403 has been marked as a duplicate of this bug. ***
*** Bug 130268 has been marked as a duplicate of this bug. ***
*** Bug 130851 has been marked as a duplicate of this bug. ***
*** Bug 130915 has been marked as a duplicate of this bug. ***
*** Bug 131326 has been marked as a duplicate of this bug. ***
marking high because of the large number of dupes.
*** Bug 133363 has been marked as a duplicate of this bug. ***
*** Bug 133608 has been marked as a duplicate of this bug. ***
Created attachment 24432 [details] [review] promotion of transients of group-promoted windows.
attached patch solves this problem. For explanation, see the long comment in meta_stack_ensure_sorted.
*** Bug 134122 has been marked as a duplicate of this bug. ***
*** Bug 134459 has been marked as a duplicate of this bug. ***
This is very important, as you see it all the time with dialogs in gnome-panel. E.g.: 1. Open the panel's "Run Program" dialog. 2. Click on "Append files" 3. The file selector appears under the dialog, and there is no way to raise it.
I'm removing the old, extra GNOMEVER keywords and adding a TARGET2.6.0 based on Federico's comments (which I have to agree with). I don't know if this helps, but I've downloaded the patch and tested it for the bugs I could reproduce and the patch seemed to fix the problems for me. (Well... except for one evolution bug; but I'm pretty sure the transient hint wasn't being set in that case).
*** Bug 135459 has been marked as a duplicate of this bug. ***
*** Bug 135483 has been marked as a duplicate of this bug. ***
/me hopes this will be applied before 2.6.0, else we'll see tons of duplicates.
I will stop the release for this bug, period.
Havoc, unless you say something I'm just gonna go ahead and commit the patch, since it needs testing.
committed to HEAD
*** Bug 135665 has been marked as a duplicate of this bug. ***
Sorry to say nothing earlier, I'm simply not able to keep up with bug spam right now. I'll get back to being able to in future, at least for metacity. Rob did mail me on this one but I didn't realize it was a release stopper. Reopening so these comments aren't lost... Nitpicks: - s/gint/gboolean/ for layers_dirty - I would rather just always g_list_sort the stack than store tmp_layer per-window I believe; the cpu savings aren't worth the memory hit and ugliness A larger point, unless I'm confused, note that the issue is not only transients: - /* FIXME when promoting a window here, - * it's necessary to promote its transient children - * (or other windows constrained to be above it) - * as well, the patch only fixes transients, not the case where we raise a window due to constraints. So at least a FIXME and a bug needs to remain. But how about reverting this patch and trying a much smaller patch, which you may already have considered: in ensure_above() when applying constraints, set window->layer such that the window above is always in at least as high a layer as the one below. That fix would be a) a smaller patch b) handle _all_ constraints not just transients and c) not require a yucky iterative algorithm... If you do this ideally revert, commit, repatch, commit so it's possible to see what happened in cvs history... Thanks as always
It would be good to attach any new patches to the bug of course, to save everyone grubbing around in cvs ;-)
OK this patch essentially implements the algorithm that I described in my long comment in the previous patch. Slightly simpler to implement.
Created attachment 24914 [details] [review] alternate implementation
Does that work then? Nice that you get to delete the "promote to maximum layer of ancestor" code since it's magically handled by the constraints, good catch, I wouldn't have seen that. If get_maximum_layer_of_ancestor is now unused presumably it's causing a compiler warning and should get nuked. The only other nitpick I can come up with is that this list of types is duplicated twice: above->type == META_WINDOW_DIALOG || + above->type == META_WINDOW_MODAL_DIALOG || + above->type == META_WINDOW_UTILITY || + above->type == META_WINDOW_MENU || + above->type == META_WINDOW_TOOLBAR If this approach works it feels like the Right Thing to me, but I'd definitely test it.
Created attachment 25016 [details] [review] final version of patch
attached final version of the patch implements a couple of cleanups, but is otherwise identical. I'd meant to nuke that function originally but it slipped my mind somehow. Interestingly enough, we already had a macro defined for that transient type stuff, so I just used that in both places (although I had to move the macro definition)
Kick ass, looks great.
Was this patch commited successully? I am still seeing the same behaviour.
yea it was committed. Please describe reproduction instructions that work for the latest unstable release.
*** Bug 137712 has been marked as a duplicate of this bug. ***
David, please give reproduction instructions for latest unstable release.
I've checked on this problem. This bug is fixed, it should be closed.
This bug is not fixed. Windows like 'Create Launcher', 'Panel Properties', 'Pick a Colour' _still_ stay on top of other windows, obscuring their view/functionality. From an accessibility point of view where a simple drag of the mouse might not be an option, this is a serious problem. Please re-open bug.
That's the expected behavior. A solution for gok is a separate issue.
Why is this expected behaviour? Accessibility aside it it still not pleasant to have a window obscuring all others. I don't understand this.
The point is to ensure that dialog boxes are kept stacked in order one on top of each other. So if you pull up a modal dialog in the panel properties dialog, that dialog should be above the panel properties dialog. In older versions of metacity, this wasn't true and the panel properties dialog was actually kept above its modal transient child (not good). Similarly, a panel dialog shouldn't be obscured by the panel itself.
I can understand that transient children should stack in order, but if I were to leave these windows open and focus a web-browser for example, I would expect the web-browser to come to the foreground on top of the previously opened 'stack' of windows. This is the behaviour I'm not agreeing with. e.g. - launch a terminal - launch gedit - access it's 'Open File' window . the stacking of it's child window behaves as you describe, and remains on top of gedit. - now focus the terminal . the terminal is brought to the foreround on top of gedit and it's child window. My point is, why that when when 'panel properties' or other 'panel-spawned' windows are open they do _not_ behave in the same manner. Focusing the same terminal in this case will result in the terminal being masked.
I agree that would be nice, but unfortunately we have a fundamental problem: 1) We want to keep dialog boxes stacked above their parents. 2) We want to keep panels in the dock layer above other windows. 3) "is above" is a transitive relation. 4) Therefore, in order to have (1) and (2), dialogs of panels must be in the dock layer above other windows. gnome-panel could change this, by the way, by making the panel dialogs be separate toplevel windows and not transient children of the panel.
Rob: It seems to me that the panel change/fix makes sense, at least for free-standing panel dialogs. Since these would be full-fledged toplevels then, metacity would be responsible for not posting them on top of the panels (via observing STRUTS).
The panel fix will break because you want dialog type decorations on those dialogs, and even if you don't set TRANSIENT_FOR the dialogs will be in the panel group and thus kept on top of panel. We could make this dependent on whether the transient is focused or something. it may be clearer to make a new bug for this topic instead of recycling this one.
This bug is still present in JDS3-release_09
hp, why don't these dialogs respect struts? (I think this is what Frances is indicating). Frances, by 'bug is still present', do you mean that dialogs which are small enough to fit in the non-panel area of the screen nonetheless post on top of the panel? What's the accessibility impact? Note that there was a problem with GOK's top DOCK struts, so use gnome-panel as a test case until we get a new GOK tarball (fixed strut behavior).
If I bring up the panel properties window, I can move it over the panel itself and obsecure the panel. Also, with the panel properties window active, it obsecures all other windows open
Frances: the behaviors you just described are "normal" and correct. They are in fact the very behaviors which this bugfix was intended to provide.