<AWT Dev> Add mutter as a window manager.

Omair Majid omajid at redhat.com
Tue Apr 10 21:50:14 PDT 2012

Hi Artem,

On 04/09/2012 07:10 AM, Artem Ananiev wrote:
> I really hope we can drop most of the ancient WMs listed in the XWM
> class (MOTIF, OPENLOOK, CDE, SAWFISH, etc) in JDK8. We know AWT/Swing
> works fine on the modern WMs that conform to ICCCM and NET standards,
> and I don't see any reasons to have (and add more!) workarounds for
> non-conformant window managers.

I spent a little bit of time reading up on ICCCM (and X11), and here's a
summary of my findings. I am not familiar with this, so it could be that
I am making a mistake. Please correct me if I am wrong.

The problematic case (that the reproducer shows) is that when we
maximize a window by double clicking on the title bar under mutter, java
does not detect that the window has moved/changed size.

ICCCM 4.1.5 [1] states:
If the window manager decides to respond to a ConfigureRequest request by:

... snip ...

- Resizing the window or changing its border width (regardless of
whether the window was also moved or restacked).

    A client that has selected for StructureNotify events will receive a
real ConfigureNotify event. Note that the coordinates in this event are
relative to the parent, which may not be the root if the window has been
reparented. The coordinates will reflect the actual border width of the
window (which the window manager may have changed). The
TranslateCoordinates request can be used to convert the coordinates if

The general rule is that coordinates in real ConfigureNotify events are
in the parent's space; in synthetic events, they are in the root space.

Advice to Implementors

    Clients cannot distinguish between the case where a top-level window
is resized and moved from the case where the window is resized but not
moved, since a real ConfigureNotify event will be received in both
cases. Clients that are concerned with keeping track of the absolute
position of a top-level window should keep a piece of state indicating
whether they are certain of its position. Upon receipt of a real
ConfigureNotify event on the top-level window, the client should note
that the position is unknown. Upon receipt of a synthetic
ConfigureNotify event, the client should note the position as known,
using the position in this event. If the client receives a KeyPress ,
KeyRelease , ButtonPress , ButtonRelease , MotionNotify , EnterNotify ,
or LeaveNotify event on the window (or on any descendant), the client
can deduce the top-level window's position from the difference between
the (event-x, event-y) and (root-x, root-y) coordinates in these events.
Only when the position is unknown does the client need to use the
TranslateCoordinates request to find the position of a top-level window.

To me, this says that when a window has been resized (by, say, double
clicking on the title bar), a real ConfigureNotify event will be sent.
The implementation (awt, in this case) should query for the coordinates
relative to the root and use them.

This is pretty much exactly what the "CDE/MWM/Metacity/Sawfish bug"
currently does. It seems like this should be the correct default
behaviour (for all window managers, including mutter).

What do you think?


[1] http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.5

More information about the awt-dev mailing list