After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 96140 - Stacking of transient children of transient with a group-induced layer promotion
Stacking of transient children of transient with a group-induced layer promotion
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: general
unspecified
Other other
: High normal
: METACITY2.8.x
Assigned To: Metacity maintainers list
Metacity maintainers list
AP2
: 126427 128801 129038 129403 130268 130851 130915 131326 133363 133608 134122 134459 135459 135483 135665 137712 (view as bug list)
Depends on:
Blocks: 93022 129750
 
 
Reported: 2002-10-18 06:01 UTC by Havoc Pennington
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: 2.6.next
GNOME version: ---


Attachments
promotion of transients of group-promoted windows. (7.39 KB, patch)
2004-02-16 00:40 UTC, Rob Adams
none Details | Review
alternate implementation (3.53 KB, patch)
2004-02-29 00:07 UTC, Rob Adams
none Details | Review
final version of patch (7.90 KB, patch)
2004-03-02 02:28 UTC, Rob Adams
none Details | Review

Description Havoc Pennington 2002-10-18 06:01:30 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.)
Comment 1 Heath Harrelson 2002-10-30 15:45:36 UTC
Batch adding GNOME2 keyword to Metacity bugs.  Sorry for the spam.
Comment 2 Havoc Pennington 2003-09-25 02:01:17 UTC
Still broken, maybe the same fix as bug #100343
Comment 3 Havoc Pennington 2003-12-07 20:43:29 UTC
*** Bug 126427 has been marked as a duplicate of this bug. ***
Comment 4 padraig.obriain 2003-12-08 17:48:42 UTC
*** Bug 128801 has been marked as a duplicate of this bug. ***
Comment 5 Vincent Untz 2003-12-11 12:32:16 UTC
*** Bug 129038 has been marked as a duplicate of this bug. ***
Comment 6 bill.haneman 2003-12-11 12:53:01 UTC
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?
Comment 7 Vincent Untz 2003-12-18 15:48:18 UTC
*** Bug 129403 has been marked as a duplicate of this bug. ***
Comment 8 Arvind S N 2003-12-31 08:42:31 UTC
*** Bug 130268 has been marked as a duplicate of this bug. ***
Comment 9 Arvind S N 2004-01-08 03:18:27 UTC
*** Bug 130851 has been marked as a duplicate of this bug. ***
Comment 10 Vincent Untz 2004-01-08 17:44:01 UTC
*** Bug 130915 has been marked as a duplicate of this bug. ***
Comment 11 Vincent Untz 2004-01-13 11:40:49 UTC
*** Bug 131326 has been marked as a duplicate of this bug. ***
Comment 12 Rob Adams 2004-01-13 16:33:18 UTC
marking high because of the large number of dupes.
Comment 13 Vincent Untz 2004-02-04 16:06:29 UTC
*** Bug 133363 has been marked as a duplicate of this bug. ***
Comment 14 Arvind S N 2004-02-06 10:30:06 UTC
*** Bug 133608 has been marked as a duplicate of this bug. ***
Comment 15 Rob Adams 2004-02-16 00:40:39 UTC
Created attachment 24432 [details] [review]
promotion of transients of group-promoted windows.
Comment 16 Rob Adams 2004-02-16 00:41:42 UTC
attached patch solves this problem.  For explanation, see the long
comment in meta_stack_ensure_sorted.
Comment 17 Mark McLoughlin 2004-02-16 13:00:00 UTC
*** Bug 134122 has been marked as a duplicate of this bug. ***
Comment 18 Mark McLoughlin 2004-02-16 13:00:13 UTC
*** Bug 134459 has been marked as a duplicate of this bug. ***
Comment 19 Federico Mena Quintero 2004-02-24 21:04:11 UTC
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.
Comment 20 Elijah Newren 2004-02-25 00:16:33 UTC
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).
Comment 21 Mark McLoughlin 2004-02-26 08:43:32 UTC
*** Bug 135459 has been marked as a duplicate of this bug. ***
Comment 22 Vincent Untz 2004-02-26 12:04:56 UTC
*** Bug 135483 has been marked as a duplicate of this bug. ***
Comment 23 Vincent Untz 2004-02-26 12:09:10 UTC
/me hopes this will be applied before 2.6.0, else we'll see tons of
duplicates.
Comment 24 Luis Villa 2004-02-26 14:54:56 UTC
I will stop the release for this bug, period.
Comment 25 Rob Adams 2004-02-26 18:14:06 UTC
Havoc, unless you say something I'm just gonna go ahead and commit the
patch, since it needs testing.
Comment 26 Rob Adams 2004-02-28 01:50:32 UTC
committed to HEAD
Comment 27 Mark McLoughlin 2004-02-28 09:42:44 UTC
*** Bug 135665 has been marked as a duplicate of this bug. ***
Comment 28 Havoc Pennington 2004-02-28 21:50:04 UTC
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
Comment 29 Havoc Pennington 2004-02-28 21:58:02 UTC
It would be good to attach any new patches to the bug of course, to
save everyone grubbing around in cvs ;-)
Comment 30 Rob Adams 2004-02-29 00:07:11 UTC
OK this patch essentially implements the algorithm that I described in
my long comment in the previous patch.  Slightly simpler to implement.
Comment 31 Rob Adams 2004-02-29 00:07:57 UTC
Created attachment 24914 [details] [review]
alternate implementation
Comment 32 Havoc Pennington 2004-03-01 01:35:17 UTC
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.
Comment 33 Rob Adams 2004-03-02 02:28:05 UTC
Created attachment 25016 [details] [review]
final version of patch
Comment 34 Rob Adams 2004-03-02 02:29:14 UTC
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)
Comment 35 Havoc Pennington 2004-03-02 03:41:52 UTC
Kick ass, looks great.
Comment 36 david.hawthorne 2004-03-19 10:24:38 UTC
Was this patch commited successully? I am still seeing the same behaviour.
Comment 37 Rob Adams 2004-03-19 16:38:30 UTC
yea it was committed.  Please describe reproduction instructions that
work for the latest unstable release.
Comment 38 Vincent Untz 2004-03-19 17:48:48 UTC
*** Bug 137712 has been marked as a duplicate of this bug. ***
Comment 39 Rob Adams 2004-03-19 18:04:56 UTC
David, please give reproduction instructions for latest unstable release.
Comment 40 Patrick Wade 2004-03-25 13:38:40 UTC
I've checked on this problem. This bug is fixed, it should be closed.


Comment 41 david.hawthorne 2004-03-31 13:53:44 UTC
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.
Comment 42 Rob Adams 2004-03-31 16:43:41 UTC
That's the expected behavior.  A solution for gok is a separate issue.
Comment 43 david.hawthorne 2004-03-31 16:47:31 UTC
Why is this expected behaviour? Accessibility aside it it still not pleasant to
have a window obscuring all others. I don't understand this.
Comment 44 Rob Adams 2004-03-31 17:07:08 UTC
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.
Comment 45 david.hawthorne 2004-04-01 09:39:01 UTC
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.
Comment 46 Rob Adams 2004-04-01 16:45:24 UTC
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.
Comment 47 bill.haneman 2004-04-01 17:40:37 UTC
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).
Comment 48 Havoc Pennington 2004-04-01 19:37:42 UTC
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.
Comment 49 Frances Keenan 2004-05-13 13:08:53 UTC
This bug is still present in JDS3-release_09

Comment 50 bill.haneman 2004-05-13 13:33:41 UTC
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).
Comment 51 Frances Keenan 2004-05-13 14:06:16 UTC
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
Comment 52 bill.haneman 2004-05-13 15:01:34 UTC
Frances:  the behaviors you just described are "normal" and correct.  They are
in fact the very behaviors which this bugfix was intended to provide.