<AWT Dev> Some Window OverrideRedirect patches for Metacity

[Artem Ananiev]

Hi, Mark,

I have filed a change request 6708392 to address OverrideRedirect 
support in XToolkit for Swing helper windows. The fix will be based on 
your patch (the first part) with some additional refactoring.

As for toFront/toBack issue, I'd first try to make Metacity team fix 
their bug. Will contact them the next week.

Thanks,

Artem

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