RE: Mouse offset when using java swing based gui applications
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. Richard -Original Message- From: Jon TURNEY [mailto:jon.tur...@dronecode.org.uk] Sent: 21 July 2010 20:08 To: cygwin-xfree@cygwin.com; 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 as 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 wrong 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 XDecoratedPeer.java between 1.6u21 and a fixed version is: --- /opt/wip/jdk-1_6_0/j2se/src/solaris/classes/sun/awt/X11/XDecoratedPeer.j ava 2010-07-21 15:46:33.28125 +0100 +++ /opt/wip/openjdk/jdk/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java 2010-06-21 22:15:43.0 +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() - currentInsets.left, xe.get_y() - currentInsets.top); } else { // CDE/MWM/Metacity/Sawfish bug: if shell is resized using // 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 Glass) 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}, new Object[]{String.valueOf(xlocation)}); } if (xlocation != null) { newLocation = xlocation; } break; } default: break; } } Location updates from ConfigureNotify are not processed in the NO_WM case, presumably causing the menus behave as if the window was still located where 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 knows about, like LG3D. This one of the workarounds suggested in the manpage for 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 doesn't really (although it should), so I'm not too keen on this approach. (ii) Alternatively, it's a straightforward workaround to add to the internal WM to cause it to send synthetic ConfigureNotify for these windows when a non-synthetic ConfigureNotify occurs. From a quick test, this approach seems to work ok. But the Java window still appears with the frame off the top-left, rather than getting nudged away from 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 you could try it out and see if it works for you? [1] ftp://cygwin.com/pub/cygwinx/XWin.20100721-git-2704058015f198ce.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
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 as 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 wrong 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 XDecoratedPeer.java between 1.6u21 and a fixed version is: --- /opt/wip/jdk-1_6_0/j2se/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java 2010-07-21 15:46:33.28125 +0100 +++ /opt/wip/openjdk/jdk/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java 2010-06-21 22:15:43.0 +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() - currentInsets.left, xe.get_y() - currentInsets.top); } else { // CDE/MWM/Metacity/Sawfish bug: if shell is resized using // 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 Glass) 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}, new Object[]{String.valueOf(xlocation)}); } if (xlocation != null) { newLocation = xlocation; } break; } default: break; } } Location updates from ConfigureNotify are not processed in the NO_WM case, presumably causing the menus behave as if the window was still located where 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 knows about, like LG3D. This one of the workarounds suggested in the manpage for 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 doesn't really (although it should), so I'm not too keen on this approach. (ii) Alternatively, it's a straightforward workaround to add to the internal WM to cause it to send synthetic ConfigureNotify for these windows when a non-synthetic ConfigureNotify occurs. From a quick test, this approach seems to work ok. But the Java window still appears with the frame off the top-left, rather than getting nudged away from 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 you could try it out and see if it works for you? [1] ftp://cygwin.com/pub/cygwinx/XWin.20100721-git-2704058015f198ce.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Mouse offset when using java swing based gui applications
On 15/07/2010 15:38, Richard Evans wrote: There's a bug reported against Java relating to this, with some more details. It claims to be fixed, but it still occurs. There's a small test case in the bug report. It makes many Java UI applications unusable with Cygwin/X. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6434227 Thanks very much for the link. That bug report and related ones makes interesting reading: I can see now that Swing/AWT problems are probably behind a few problem reports of this kind we've had. I tried out the test case in that particular bug, and it does seem to be fixed in the JRE is claims to be fixed in. But looking at the horror-show that is XWM.java [1], I can believe there are other problems, and the behaviour will be different with different JRE versions. There's certainly scope for adding fixes/workarounds to the multiwindow mode internal window manager so that AWT does the correct thing, but I guess what I need to progress this is a test case I can easily run, and 'java -version' for the platform the test case should be run on [1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/d58354a69011/src/solaris/classes/sun/awt/X11/XWM.java -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: Mouse offset when using java swing based gui applications
I've attached a small test case which shows the menu problems. Compile and run with: javac menus.java java menus My server configuration is Windows 7 x64, Cygwin/X X server version 1.7.3, with dual 1920x1200 monitors. I ran the test case on Fedora 12 x86, using the latest released JRE 1.6u21. The frame appears in one of two ways: 1. With the window frame off the screen top left - ie (0, 0) in the content area is at (0, 0) on the display Or 2. With the window frame showing, but as soon as I try to select a menu, the windows shifts to the position in 1. When the frame as off screen, (as in 1. above), the menus work fine; If I move the window elsewhere on the screen, the menus can be opened but you can't select any item. This menu behaviour has been seen for all versions of JDK 1.6 as far as I remember; it certainly happens with 1.6u3 and 1.6u4. Hope this helps Richard -Original Message- From: Jon TURNEY [mailto:jon.tur...@dronecode.org.uk] Sent: 19 July 2010 16:52 To: cygwin-xfree@cygwin.com; jonas_wink...@gmx.de; Richard Evans Subject: Re: Mouse offset when using java swing based gui applications On 15/07/2010 15:38, Richard Evans wrote: There's a bug reported against Java relating to this, with some more details. It claims to be fixed, but it still occurs. There's a small test case in the bug report. It makes many Java UI applications unusable with Cygwin/X. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6434227 Thanks very much for the link. That bug report and related ones makes interesting reading: I can see now that Swing/AWT problems are probably behind a few problem reports of this kind we've had. I tried out the test case in that particular bug, and it does seem to be fixed in the JRE is claims to be fixed in. But looking at the horror-show that is XWM.java [1], I can believe there are other problems, and the behaviour will be different with different JRE versions. There's certainly scope for adding fixes/workarounds to the multiwindow mode internal window manager so that AWT does the correct thing, but I guess what I need to progress this is a test case I can easily run, and 'java -version' for the platform the test case should be run on [1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/d58354a69011/src/solaris/c lasses/sun/awt/X11/XWM.java -- Jon TURNEY Volunteer Cygwin/X X Server maintainer menus.java Description: menus.java -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: Mouse offset when using java swing based gui applications
There's a bug reported against Java relating to this, with some more details. It claims to be fixed, but it still occurs. There's a small test case in the bug report. It makes many Java UI applications unusable with Cygwin/X. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6434227 Richard -Original Message- From: Jon TURNEY [mailto:jon.tur...@dronecode.org.uk] Sent: 15 July 2010 14:38 To: cygwin-xfree@cygwin.com Cc: jonas_wink...@gmx.de Subject: Re: Mouse offset when using java swing based gui applications On 13/07/2010 22:56, Jonas Winkler wrote: I just noticed a very strange behaviour of my Cygwin/X-setup. I have a laptop running Debian 5.0 and openssh-server 1.5.1. My windows7 x64 machine is running cygwin 1.7.5 and cygwin/x 1.8.0 (fresh installation). I'm using ssh and x forwarding to use gui applications - especially Netbeans 6.9 - on my windows machine. So far, all X applications run fine on windows. Using Netbeans is somewhat weird. After startup, i can use the menues, edit code, etc. But as soon as I change the window position (moving, maximizing) of Netbeans, it seems as if the position of the window actually does not change. Clicking works, but selecting a menu item not. I need to click and hold on the menu item, drag the mouse to the position where the menu would be before moving the window and then release it. Same goes for code completition windows - they pop up where they should be before moving the window. I investigated a bit more and build a very basic Java gui application using swing (same library used by netbeans to display gui elemets) and the problem persists. As said before other applications (tested: gnome-terminal, gedit and nautilus) just work fine. So this is a swing-related rather than a netbeans-related problem. I attached the cygcheck.out. I dont know what other kind of information I should provide, so if there's anything you need, please let me know. Thanks very much for the clear problem report. We've had some similar reports before of problems with the mouse position reporting with Java applications, for e.g. [1], but I've never had a simple test case that has allowed me to reproduce it and investigate. So, I'd be very interested to see your simple Java application which demonstrates the problem. If you could also start the Xserver with the '-logverbose 3' option and attach your /var/log/XWin.0.log, that would be most helpful. [1] http://sourceware.org/ml/cygwin-xfree/2009-08/msg00060.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/