<AWT Dev> Some Window OverrideRedirect patches for Metacity

[Artem Ananiev]

Hi, Mark,

Mark Wielaard wrote:
> 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.

Agree. This is right what OverrideRedirect is used for: popups, 
tooltips, etc. - all the short-living helper windows.

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

We would like to simplify the code with all that WM-specific workarounds 
(hacks?) instead of adding more and more stuff there. As for all the 
windows like splash screens - there is AlwaysOnTop feature for this 
purpose available @since 1.5, and it is implemented in more WM-friendly 
way (i. e. we just set a hint which can or cannot be respected by WM). 
And we have a completely native SplashScreen in JDK6 :)

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

Users expect their popups and comboboxes to work, right? And they don't 
expect all that Window/JWindow bugs existed in JDK6 because of their 
OverrideRedirect nature, regardless of what WM is running...

Thanks,

Artem

> Cheers,
> 
> Mark