[26644] in Athena Bugs
Re: sun4 9.4.18: metacity and zephyr
daemon@ATHENA.MIT.EDU (Robert A Basch)
Thu Sep 29 16:23:45 2005
From: Robert A Basch <rbasch@mit.edu>
To: Laura Baldwin <boojum@mit.edu>
In-Reply-To: <200509281421.j8SELCEg002866@geskekelud.mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Thu, 29 Sep 2005 16:23:02 -0400
Message-Id: <1128025382.26460.41.camel@anhedonia.mit.edu>
Mime-Version: 1.0
X-Spam-Score: 1.042
X-Spam-Level: * (1.042)
X-Spam-Flag: NO
cc: bugs@mit.edu
Errors-To: bugs-bounces@mit.edu
I did some investigation on the zwgc/metacity stacking problems
(also see testers [7295] et al) and found a couple of issues:
1) For a window that does not take focus on mapping, metacity
will stack it below the window which currently has focus, per the
following code in meta_window_show() (in src/window.c):
if ( (!takes_focus_on_map) && (window->display->focus_window != NULL) )
{
meta_window_stack_just_below (window, window->display->focus_window);
ensure_mru_position_after (window, window->display->focus_window);
}
(zephyrgrams do not take focus on mapping here, because zwgc sets
the window manager input hint to False). Unfortunately, this tends
not to work well when focus follows the mouse (without automatic
window raising), since the window with focus might be well down
in the stacking order. This explains why new zephyrgrams will
be stacked below existing windows.
2) metacity ignores sibling window settings in XConfigureWindow()
requests, which essentially breaks zwgc's reverse stacking option.
The following comment in meta_window_configure_request() explains:
/* Handle stacking. We only handle raises/lowers, mostly because
* stack.c really can't deal with anything else. I guess we'll fix
* that if a client turns up that really requires it. Only a very
* few clients even require the raise/lower (and in fact all client
* attempts to deal with stacking order are essentially broken,
* since they have no idea what other clients are involved or how
* the stack looks).
*
* I'm pretty sure no interesting client uses TopIf, BottomIf, or
* Opposite anyway, so the only possible missing thing is
* Above/Below with a sibling set. For now we just pretend there's
* never a sibling set and always do the full raise/lower instead of
* the raise-just-above/below-sibling.
*/
Thus a "below-sibling" request is treated simply as a "lower", so
the new zephyrgram will be stacked below any other initially.
But the order will change when stacking is recalculated, as seems
to occur when switching workspaces.
>From a quick glance at the latest metacity version (2.12.0), I
don't believe it would offer any improvement on these issues
(testing that is non-trivial, though, since 2.12.0 requires a
newer version of glib, etc.).
Bob
