<AWT Dev> Some Window OverrideRedirect patches for Metacity

Artem Ananiev Artem.Ananiev at Sun.COM
Mon May 26 03:49:33 PDT 2008


Hi, Mark,

see my comments below.

Mark Wielaard wrote:
> Hi,
> 
> There are a couple of bug reports because the Metacity window manager
> doesn't obey the polite requests of the xawt peers to override the
> default window placement and ordering. There is actually already code to
> handle this in the xawt peers. The following patches activate that code
> in some circumstances.
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6695441
> This bug report is about jpopupmenus not being placed exactly where
> requested if something (like the gnome panel) is in the way. The way to
> resolve this is to set OverrideRedirect on Windows that request it in
> the name. java.swing.Popup already sets the name hint. And if we were
> using motif this would be enough (see MWindowPeer_pCreate in
> awt_TopLevel.c). For the awt X peers one little change is necessary to
> pick up the hint and set the OverrideRedirect parameter. Patch attached.

This 'hint' has never been supported by XAWT, and we need to find if it 
is really required by swing popups. I feel it is, however let me first 
get a confirmation from the Swing team.

> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6669302
> Windows (not Frames or Dialogs) should be handled somewhat specially
> (they don't have decorations). There is an issue when trying toBack() or
> toFront() on a Window when another window has the Focus. Metacity won't
> do this. There is actually code to override the window manager similar
> to the above popup menu solution. In XWindowPeer there is special code
> to handle toFront() and toBack() when OverrideRedirect is set. For olwm
> this is explicitly enabled, so we do the same for metacity. This is a
> bit of a sledgehammer. But is does seem to work if we want to force this
> behavior for bare Windows. And it is relatively safe since
> isOverrideRedirect() is overridden in the XDecoratedPeer (which is used
> for normal Frames) to always return false. Patch attached.

As far as I remember, this is not a problem in JDK, but in Metacity. We 
filed a bug against this window manager and got a confirmation. Let's 
not try to fix their problems in our code...

> I added the combined patch (also attached) to IcedTea to give it some
> wider exposure. Since both the above behaviors are somewhat
> controversial, but apparently what ClosedJDK6 does, or at least what
> people seem to expect it to do, I have attached them separately for
> comments. I think the JPopupMenu one is the right thing to do since you
> always want popup menus to show up on top and where the application
> expects them to popup. The explicit Window OverrideRedirect for Metacity
> is a bit more controversial. It seems to implement the behavior of what
> might be expected from an top-level awt/swing Window without decoration
> (as used for splash-screens, etc). But it is fairly user hostile because
> it overrides the default behavior of the window manager and users might
> not like the "sticky" nature of such Windows.
> 
> Comments much appreciated.

Roughly, your patch consists of two parts (please, correct me, if I'm 
wrong): support for ###overrideRedirect### hint (or hack?), and making 
all the Windows (not Frames or Dialogs) be OverrideRedirect if running 
under Metacity. The first part is something we need to think about, and 
the second is exactly what we have recently fixed in JDK7, so we 
definitely don't want it back.

Thanks,

Artem

> Cheers,
> 
> Mark



More information about the distro-pkg-dev mailing list