Community
Participate
Working Groups
It looks like some change in SWT broke mouse move listeners and hence a lot of things in the Eclipse UI (e.g. JavaDoc-Hovers). I currently don't have Eclipse 3.7 builds but this is reproduceable the latest Eclipse 4.1 build (I20110126-2200). The only possibility to get JavaDoc-Hovers is to press the left mouse button and move the mouse over an element without nothing happens. To find out what happened I've attached a hacked the move mouse listener in org.eclipse.e4.ui.workbench.renderers.swt.SashLayout and it only print debug statements when I press the left button and move the mouse in the area not occupied by the editors and views. I'd say this is a blocker because it make Eclipse 4.1 fairly unusable for development.
Could this have something to do with gesture stuff and the system thinks I'm on a touch panel?
Can reproduce - working on it.
Not sure - the gesture/touch stuff is high on the list of possible suspects.
This problem comes from changes made to Display.findControl which is used to determine who to send the MouseMove from. Code was added to take advantage of new API available in 10.6+ (Snow Leopard). The fallback code (for systems less than 10.6) makes use of Carbon calls - which work on 32 bit but fails for 64 bit. Here's a proposed patch which uses the new API where available and falls back on the old way of locating windows on systems less than 10.6
Created attachment 187768 [details] Patch Scott, if you're OK with the patch, please release it. We need to schedule another I build for tonight. Thanks!
Fixed in HEAD > 20110127 Ready for a rebuild! (please!)
Bogdan's analysis is exactly right. I have applied the attached patch for the time being. We'll have to revisit this post-M5. Fixed > 20110127
I'm seeing this problem on an application that is being run from within eclipse - specifically protege 4.1 . Instructions at http://protegewiki.stanford.edu/wiki/CompileProtege4InEclipseFromSvn Is it possibly related to this bug or should I file another.
