<AWT Dev> Some Window OverrideRedirect patches for Metacity

[Mark Wielaard]

Hi Artem,

On Mon, 2008-05-26 at 14:49 +0400, Artem Ananiev wrote:
> > 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.

There is a testcase in the bug report but that doesn't seem visible. I
got a copy of it to create and test my proposed fix. I'll ask the
reporter if I may publish that. It shows a case where a popup doesn't
show correctly/at the requested location (it should show over the
standard panel, but doesn't). I think it is ok for popups to always show
above any other window since the whole point is that the user selects an
item in it.

> > 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...

In general I agree. But there is more code in XWindowPeer that depends
on (mis)features of specific window managers (the reason I solved this
issue this way was precisely because the line above does the same for
another window manager). There is also lots of window manager specific
code in XWM itself to work around various bugs. But I see the bug
actually got closed as "not a bug". The upstream Metacity bug is still
open though: http://bugzilla.gnome.org/show_bug.cgi?id=405269
Also this change makes bare Windows, as used in for example splash
screens always show in front of all other windows, which apparently is
what people expect and what older jdk versions seemed to do.

> 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.

Yes, that is the summary. I do see why you might not want the second
part. I do agree it is obnoxious, but apparently it is what (some) users
would expect.

Cheers,

Mark