mouse shift with java

[GoogleCodeExporter]

> What steps will reproduce the problem?
1. launch greenfoot (http://www.greenfoot.org/download/)
2. try out the drop-down and the contextual menus

for the dropdown menus, the mouse influence is heavily shifted from the
actual mouse position.

for the contextual menus, the whole menu is shifted away from where it
should appear, in concordance with mouse influence.

I tried to run the program in fluxbox to give it a try, and everything
seems to be in place. It looks like this vertical shift is linked to the
height of the (non-existing) status-bar of the window.

I'm really outside of my area here, but I'm wondering if Java/SWING is
making a call to the WM to gather informations that will allow it to
calculate the mouse coordinates relative to the window's space. 

> What version of the product are you using? On what operating system?

xmonad-0.7 + xmonad-contrib-0.7 on archlinux

Original issue reported on code.google.com by gir...@gmail.com on 4 Sep 2008 at 9:18

[GoogleCodeExporter]

This sounds to me like a badly-coded Java app that is using absolute 
coordinates and 
just leaving space for where it assumes a title bar to be.

Original comment by Braden.S...@gmail.com on 5 Sep 2008 at 2:38

[GoogleCodeExporter]

I found the culprit. It is not the Java app, it is Java itself, which does not 
play
fair and square with the WM sometimes.

There is a solution, however : you just have to use an alternative AWT toolkit :
> export AWT_TOOLKIT=MToolkit
in .bashrc does the trick.

repeat after me : this is not a XMonad bug. XMonad is clean and pure. :)

Original comment by gir...@gmail.com on 9 Sep 2008 at 9:26

[GoogleCodeExporter]

Original comment by SpencerJ...@gmail.com on 9 Sep 2008 at 12:33

• Changed state: Invalid

[GoogleCodeExporter]

I have seen this bug with many, many (all?) java apps.  I don't know if I agree 
with the above assessment that it's not an xmonad bug.  That may be true, but 
it is certainly breaking compatibility with many programs.

Original comment by rm.rf.do...@gmail.com on 20 Aug 2010 at 3:59

[GoogleCodeExporter]

It really isn't xmonad's fault.

The JRE doesn't deal well with non-reparenting window managers.  It has a small 
compiled-in list of non-reparenting window managers for which it will work 
around its own brokenness --- but any non-reparenting WM they didn't put into 
that list will have problems with graphics.

The "official" solution is to use the SetWMName module in contrib to make 
xmonad advertise itself as a WM on that short list.  MToolkit is a hack with 
its own bugs and no guarantee of continued support (the environment it was 
created for is these days quite dead).

Original comment by allber...@gmail.com on 20 Aug 2010 at 4:18

[GoogleCodeExporter]

See also 
http://www.haskell.org/haskellwiki/Xmonad/Frequently_asked_questions#Problems_wi
th_Java_applications.2C_Applet_java_console which discusses all the known 
solutions and orders them by desirability.

Original comment by daniel.w...@gmail.com on 20 Aug 2010 at 4:59

[GoogleCodeExporter]

Ah, must have read that too fast.  I saw the discussion of the gray screen, 
which I wasn't seeing, but not of the menus.  Really the problem with the menus 
I saw was that they would simply disappear as soon as the mouse button was 
released.  Only occasionally did I see the mouse offset problem.

Original comment by rm.rf.do...@gmail.com on 20 Aug 2010 at 1:20