[platform-swt-dev] Mouse events/dragging

[Scott Kovatch <skovatch@xxxxxxxxx>]

Title: Mouse events/dragging

Folks,

I’m trying to understand the delivery of mouse events in the Cocoa port. It looks like there’s a lot of work being done in the Display object that would be better done in the Control or other subclasses.

I understand how events make it to a window now, but I think that could also be simplified a bit. It should be sufficient to call [NSApp sendEvent:event] and have the event go directly to the window targeted by the event. Right now, Display is trying to get the hit control and then entering a big case statement based on the event type, and calling mouseDown on the found Widget. That won’t scale when you throw in all of the kinds of events an NSView can handle.

Talking to Steve N., he said this is because mouse events were bubbling up the container hierarchy, but after some code review I see why. In the Cocoa version of Widget, you’re calling, in effect, [super mouseDown:event] in the mouseDown handler, as well as making analagous calls to [super <event handler>]. In the SWT this is probably never what you want to do, though it’s not uncommon in a Cocoa app. NSViews are a subclass of NSResponder, and the behavior of super is to send the event to the next handler in the responder chain. That explains why each parent also sees the event, and why you may have been generating mouse events on the wrong widget. Subclasses of Widget may need to override the handler and then call the Java superclass implementation, but not the Cocoa superclass implementation.

If we take out the calls to callSuper() in all of the Widget base event handlers you can move much of the code in Display.applicationSendMouseEvent() into Control, which is where it belongs, IMHO. You might also be able to get rid of the override of [SWTApplication sendEvent:], since right now I think it’s just being used as a hook to grab events and dispatch them.

Was there some other problem you were addressing by dispatching the event yourself? I can look into this today, but I doubt it would be ready before the current M build.

Scott
--------------- 
Scott Kovatch
Flex Engineering
Adobe Systems, Inc.
skovatch@xxxxxxxxx

I am Scott Kovatch, and I approved this message.