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

[Silenio Quarti <Silenio_Quarti@xxxxxxxxxx>]

platform-swt-dev-bounces@xxxxxxxxxxx wrote on 09/11/2008
04:55:04 PM:

> 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.
> 

What I mean is if we push the code that sends the
SWT.MouseDown events into
Control.mouseDown(), we need to determine if Widget.mouseDown()
should be called.
Widget.mouseDown() calls super_objc_msgSend(), which
is NSButton.mouseDown() for buttons.
If we do not call Widget.mouseDown() ever, buttons
will not work. If we call always, buttons
will work and since NSButton.mouseDown() does not
call NSResponder.mouseDown() (it seems, I cannot guarantee this),
events do not bubble up. On the other hand, for our
Composite (which is a subclass of NSView), calling
Widget.mouseDown() ends up calling NSResponder.mouseDown()
and the events bubbles up. It is
easy to determine for these two cases when to call
Widget.mouseDown(), but there are other cases
where it depends on where I clicked on the widget
and that is why our own hittest was
adding.


> > 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.


I aggree it would be much cleaner and make more sense.


>  
> > 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 only reason it is not in Shell is that NSApplication.sendEvent()
dispatches
mouse move events always to the keyWindow (maybe mainWindow,
not sure), so if
the user moves the mouse over a window that is not
the keyWindow, SWT.MouseEnter,
SWT.MouseExit and SWT.MouseMove would not be delivered
to the widget under the
mouse pointer. This is not the behavior on the other
implementations of SWT (even
carbon).


> 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
doesnot 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.


Yes, It is strange. I left the old approach to work
around OS bugs/features
as necessary. We would not send the SWT event from
there.

 
> 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.


Finally, we spent a couple of weeks hummering out
the details, running test code
and getting it to match the other platforms. We starting
out implementing it the
way you suggested and we failed. I am saying you will
fail, but I do not think
it is worth spending time on it right now.

Call me if you want.


> -- Scott
> 
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-swt-dev