Mouse offset when using java swing based gui applications

Richard Evans
Thu Jul 22 08:39:00 GMT 2010

Yes, my experience is the same as yours.  The menus test starts with the
frame hidden off the top left, as before, but when I move the window,
the menus _do_ work OK.

Apps which set an initial location (add jframe.setLocation(400, 400);
after the pack() call) appear correctly and the menus still work.
Interestingly with the 1.7.3 XWin, the app would appear in the right
place but would tend to snap back to the top left if you tried to resize
the window.  This does not seem to happen with the patched server.


-----Original Message-----
From: Jon TURNEY [] 
Sent: 21 July 2010 20:08
To:; Richard Evans
Subject: Re: Mouse offset when using java swing based gui applications

On 19/07/2010 17:27, Richard Evans wrote:
> I've attached a small test case which shows the menu problems.

Thanks very much, that was very helpful in investigating this problem.

> This menu behaviour has been seen for all versions of JDK 1.6 as far
> I remember; it certainly happens with 1.6u3 and 1.6u4.

Yes, I wasn't testing what I thought I was testing, and was completely
when I said sun bug #6434227 was fixed in the JRE that it claims it's
fixed in.

It's fixed in JDK1.7 and OpenJDK, but that bug lies when it says the fix
is in 
1.6 as well.

However, it does identify what's going wrong.  The significant
difference in between 1.6u21 and a fixed version is:

2010-07-21 15:46:33.281250000 +0100

  2010-06-21 22:15:43.000000000 +0100
@@ -752,79 +748,69 @@
              Point newLocation = targetBounds.getLocation();
-            if (xe.get_send_event()) {
+        if (xe.get_send_event() || runningWM == XWM.NO_WM || 
XWM.isNonReparentingWM()) {
                  // Location, Client size + insets
                  newLocation = new Point(xe.get_x() -
xe.get_y() -;
              } else {
                  // CDE/MWM/Metacity/Sawfish bug: if shell is resized
                  // top or left border, we don't receive synthetic
                  // ConfigureNotify, only the one from X with zero
                  // coordinates.  This is the workaround to get real
                  // location, 6261336
-                // Do the same for non-reparenting WMs (Compiz, Looking
                  switch (XWM.getWMID()) {
                    case XWM.CDE_WM:
                    case XWM.MOTIF_WM:
                    case XWM.METACITY_WM:
                    case XWM.SAWFISH_WM:
-                  case XWM.COMPIZ_WM:
-                  case XWM.LG3D_WM:
                        Point xlocation = queryXLocation();
                        if (log.isLoggable(Level.FINE)) {
                            log.log(Level.FINE, "New X location: {0}",
                        if (xlocation != null) {
                            newLocation = xlocation;

Location updates from ConfigureNotify are not processed in the NO_WM
presumably causing the menus behave as if the window was still located
it was created.

There are 2 possible workarounds which occur to me:

(i) Lie and pretend we are a non-reparenting WM on the list that AWT
about, like LG3D.  This one of the workarounds suggested in the manpage
dwm (a non-reparenting, tiling WM)

Unfortunately, we have to tell a more lies to get AWT to accept this
lie, and 
in particular, we have to claim to support EWMH, which the internal WM
really (although it should), so I'm not too keen on this approach.

(ii) Alternatively, it's a straightforward workaround to add to the
WM to cause it to send synthetic ConfigureNotify for these windows when
non-synthetic ConfigureNotify occurs.

 From a quick test, this approach seems to work ok.  But the Java window
appears with the frame off the top-left, rather than getting nudged away
the origin so the frame is visible, which is rather mysterious.

I've uploaded a build with this change at [1], patch to follow.  Perhaps
could try it out and see if it works for you?


Volunteer Cygwin/X X Server maintainer

Unsubscribe info:
Problem reports:

More information about the Cygwin-xfree mailing list