Re: [platform-swt-dev] Mouse events/dragging

[Scott Kovatch <skovatch@xxxxxxxxx>]

On 9/11/08 10:31 AM, "Silenio Quarti" <Silenio_Quarti@xxxxxxxxxx> wrote:

> We also subclass NSButton and in that case the NSButton.mouseDown() method
> needs to be called.

Where is this happening? I see what looks like an override of sendSelection,
but that's it.

> It is easy to know that the super implementation of
> NSButton needs to be called, but what about the other leaf widgets we
> subclass. For example, I seem to remember that NSOutlineView some times
> bubbles up the events and some times does not, depending where you click on
> the view (expanders, item, blank area).  If there is a reasonable way of
> determine when to call super we should move the code into control.

I think that the mouseDown and mouseUp processing in Display is what's
throwing me off here.  The code in the NSXXXMouseDown and NSXXXMouseUp cases
look like they belong in mouseDown handlers in Control.
 
> There is another problem, when super.mouseDown() is called in NSButton, the
> button starts a tracking event loop. So no
> NSButton.mouseMoved()/mouserReleased() events are delivered until the mouse
> button is released. Most of the logic to work around this is in
> SWTAppliction.nextEventMatchingMask().
> 
> Also, NSTrackingArea has a big issue that it does not handle overlapping
> widgets. So we were not able to use it and implement SWT.MouseEnter,
> SWT.MouseExit events. The current implementation diffs the current control
> under the mouse pointer..

I agree with you here.  We had to do exactly the same thing in the AWT and
generate the enter/exit events that way.

I think I'm expecting to see this in Shell and not Display, however.
Probably not important, though.

The OS X AWT implementation is still fairly fresh in my mind, and while I'm
not trying to bring that code into the SWT, I do approach this code with
some biases, as there are lots of areas of overlap.
 
> Another issue, SWT composites are subclasses of NSView, so it does not track
> mouse move events when the mouse button is pressed on it and dragged. If you
> move the code into Control, we probably need to implement something similar to
> what NSButton does (tracking event loop).

You won't get distinct mouse move events, but you do get mouseDragged events
with each delta of the mouse location. Each call to mouseDragged should
generate a mouse motion event.

I guess that what's throwing me off is that in some ways, it looks like
there were two different approaches to handling mouse events. One wound up
not working so well, but instead of tossing it, a second one was added that
uses some of the first one. (That's not meant as criticism, just an
observation.) I'm just trying to figure out where to inject the drag
detection and event generation.

If we can find the situations where relying on the Widget behavior of
calling up the responder chain is needed I think we should add it as needed.
I think there's definitely some simplification that can be done without
breaking things.

-- Scott