Community
Participate
Working Groups
As reported by bug #242481, AbstractTool#placeMouseInViewer(Point) calls Display#setCursorLocation(Point), which does not cause a MouseMove event to occur on MacOSX, so that accessible dragging does not work on the MacOSX Cocoa platform. As investigated in bug #331993, using Display#post(Event) with a dummy mouse move event seems to be the better option, as the API contract of Display#setCurserLocation(Point) does not guarantee a resulting mouse move event on all platforms, while Display#post(Event) guarantees consistent behavior across all platforms.
Replaced call to Display#setCursorLocation(Point) with using Display#post(Event) to dispatch a dummy SWT.MouseMove event, as the accessible dragging mechanism depends on obtaining a mouse move event as a result of placing the cursor location (which does not happen on all platforms). Committed changes to cvs R3_6_maintenance branch as well as cvs HEAD (3.7).
(In reply to comment #0) > As reported by bug #242481, AbstractTool#placeMouseInViewer(Point) calls > Display#setCursorLocation(Point), which does not cause a MouseMove event to > occur on MacOSX, so that accessible dragging does not work on the MacOSX Cocoa > platform. As investigated in bug #331993, using Display#post(Event) with a > dummy mouse move event seems to be the better option, as the API contract of > Display#setCurserLocation(Point) does not guarantee a resulting mouse move > event on all platforms, while Display#post(Event) guarantees consistent > behavior across all platforms. Why not report the inconsistency to the SWT team and see if they can fix it rather than working around the problem downstream?
(In reply to comment #2) > (In reply to comment #0) > > As reported by bug #242481, AbstractTool#placeMouseInViewer(Point) calls > > Display#setCursorLocation(Point), which does not cause a MouseMove event to > > occur on MacOSX, so that accessible dragging does not work on the MacOSX Cocoa > > platform. As investigated in bug #331993, using Display#post(Event) with a > > dummy mouse move event seems to be the better option, as the API contract of > > Display#setCurserLocation(Point) does not guarantee a resulting mouse move > > event on all platforms, while Display#post(Event) guarantees consistent > > behavior across all platforms. > > Why not report the inconsistency to the SWT team and see if they can fix it > rather than working around the problem downstream? Anthony, that's what I did in bug #331993. The question I raised there is whether it is regarded part of the API-contract of Display#setCursorLocation(Point) that a mouse move event is dispatched as a side-effect. As this does not seem to be the case, Display#post(Event) seems to be a valid solution for us, as it guarantees a respective event to be dispatched, and furthermore is supposed to work on all platforms. If you think Display#getCursorLocation(Point) should always also dispatch a mouse move event, I would propose to reopen #331993. As it does not affect API, we could revert our fix, if Display#setCursorLocation(Point) was changed accordingly.
(In reply to comment #3) > Anthony, that's what I did in bug #331993. ... Randy, I meant you of course. I apologize.
> The question I raised there is > whether it is regarded part of the API-contract of > Display#setCursorLocation(Point) that a mouse move event is dispatched as a > side-effect. As this does not seem to be the case, Display#post(Event) seems to > be a valid solution for us, as it guarantees a respective event to be > dispatched, and furthermore is supposed to work on all platforms. Does it move the mouse on the screen, too? I added my 2 cents to 331993. SWT should have cross-platform behavior. Just because some behavior isn't explicitly stated in javadoc shouldn't mean that all bets are off. Where does SWT say that Control#setFocus() on a control causes a focus-lost event on some other control, and a focus-gained event on that control, and in that order? (Unless that control already had focus)
(In reply to comment #5) > > The question I raised there is > > whether it is regarded part of the API-contract of > > Display#setCursorLocation(Point) that a mouse move event is dispatched as a > > side-effect. As this does not seem to be the case, Display#post(Event) seems to > > be a valid solution for us, as it guarantees a respective event to be > > dispatched, and furthermore is supposed to work on all platforms. > > Does it move the mouse on the screen, too? On Mac, it does. On Windows XP, I observed that neither Display#setCursorLocation(Point) nor Display#post(Event) with a MouseMove seems to actually "move" the cursor.
> On Mac, it does. On Windows XP, I observed that neither > Display#setCursorLocation(Point) nor Display#post(Event) with a MouseMove seems > to actually "move" the cursor. Strange, it was originally written on win32 and it definitely moved the cursor. For example, PERIOD key would move the mouse around to each resize handle, changing the mouse cursor to NorthEast, etc.
W(In reply to comment #7) > > On Mac, it does. On Windows XP, I observed that neither > > Display#setCursorLocation(Point) nor Display#post(Event) with a MouseMove seems > > to actually "move" the cursor. > > Strange, it was originally written on win32 and it definitely moved the cursor. > For example, PERIOD key would move the mouse around to each resize handle, > changing the mouse cursor to NorthEast, etc. Well, it does exactly this on the Mac. On WinXP I could just observe the changing of the cursor.
(In reply to comment #8) > W(In reply to comment #7) > > > On Mac, it does. On Windows XP, I observed that neither > > > Display#setCursorLocation(Point) nor Display#post(Event) with a MouseMove seems > > > to actually "move" the cursor. > > > > Strange, it was originally written on win32 and it definitely moved the cursor. > > For example, PERIOD key would move the mouse around to each resize handle, > > changing the mouse cursor to NorthEast, etc. > > Well, it does exactly this on the Mac. On WinXP I could just observe the > changing of the cursor. I opened bug #332170 for this, where I attached a snippet to reproduce it.
Due to Randy's comments and the succeeding discussion on bug #331993, as SWT will now address the issue, reopening this one, so the GEF changes can be reverted
Reverted changes (while performing a rename and adding a comment) in cvs R3_6_maintenance branch and cvs HEAD, as the problem will be fixed on the SWT side. Marking this one as invalid. I will add a dependency from bug #242481 to bug #331993, so the SWT fix can be tracked.
