<AWT Dev> Some Window OverrideRedirect patches for Metacity
Artem.Ananiev at Sun.COM
Tue May 27 01:36:14 PDT 2008
Mark Wielaard wrote:
> Hi Artem,
> On Mon, 2008-05-26 at 14:49 +0400, Artem Ananiev wrote:
>>> 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.
>>> 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...
More information about the distro-pkg-dev