<AWT Dev> Add mutter as a window manager.

Anthony Petrov anthony.petrov at oracle.com
Wed Apr 11 05:11:45 PDT 2012

Hi Mario,

On 4/11/2012 3:39 PM, Mario Torre wrote:
> I also agree with Omair.
> To be honest, I'm not that happy with the fix, but not because of
> Omair's patch, which is very fine given the current state of things,
> but because we keep adding this to each and every new WM we find,
> although fixing AWT in this regard will be probably more work than
> adding another exception to the list and an issue for perennial
> backward compatibility...

That would be fine, indeed. However, this would require a lot of testing 
with all the WMs AWT knows about to make sure no regressions are introduced.

> Btw, this patch brings in another small issue:
>     static boolean isNonReparentingWM() {
>          return (XWM.getWMID() == XWM.COMPIZ_WM || XWM.getWMID() ==
> XWM.LG3D_WM || XWM.getWMID() == XWM.CWM_WM);
>      }
> I don't remember at this moment why this was needed at all, but if my
> memory is correct, Compiz is a reparenting WM now. I'm not sure if
> mutter is or not.

I believe there would be a bug filed already about this, since in 
XDecoratedPeer.handleConfigureNotify() this would cause the newLocation 
to be assigned with the relative position of the frame, not absolute 
position. As long as there's no bug filed, I assume it's OK to report 
Compiz as a non-reparenting WM for AWT.

best regards,

> Anyway, I just wanted to give Omair my +1 to this patch.
> Cheers,
> Mario
> 2012/4/11 Anthony Petrov <anthony.petrov at oracle.com>:
>> Hi Omair,
>> The analysis below sounds reasonable to me, and as I've already mentioned
>> I'm OK with your fix.
>> Let's hear what Artem says though.
>> PS. Perhaps it also makes sense to rewrite that comment in the
>> XDecoratedPeer to replace the word "bug" with something saying that this is
>> implemented according to the ICCCM specification with a reference to the
>> paragraph 4.1.5 of it?
>> --
>> best regards,
>> Anthony
>> On 4/11/2012 8:50 AM, Omair Majid wrote:
>>> 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
>>> required.
>>> 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?
>>> Thanks,
>>> Omair
>>> [1] http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.5

More information about the awt-dev mailing list