[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] Mouse events/dragging
|
Scott,
In response to your last question (FWIW maybe you knew this already, and
I'm not that familiar with the code you're referring to):
SWT clients can add listener "filters" to a display listening for mouse
down or other events. The listener must receive mouse down events from all
buttons and other controls, and must receive them before any listeners
listening to a specific button. The filter can swallow the mouse down
event (doit=false), which is supposed to suppress the native mouseDown
handling as well as notification to normal SWT listeners of that widget.
Maybe events could be dispatched in Control, but it would have to be done
using the current filters on that control's display. I don't think a
switch statement is a performance concern.
-Randy
Silenio Quarti
<Silenio_Quarti@c
a.ibm.com> To
Sent by: "Eclipse Platform SWT component
platform-swt-dev- developers list."
bounces@eclipse.o <platform-swt-dev@xxxxxxxxxxx>
rg cc
Subject
09/11/2008 01:31 Re: [platform-swt-dev] Mouse
PM events/dragging
Please respond to
"Eclipse Platform
SWT component
developers list."
<platform-swt-dev
@eclipse.org>
We also subclass NSButton and in that case the NSButton.mouseDown() method
needs to be called. 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.
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..
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).
Silenio
Scott Kovatch <skovatch@xxxxxxxxx>
Sent by:
platform-swt-dev-bounces@xxxxxxxxxx To
g "Eclipse Platform SWT
component developers list."
<platform-swt-dev@xxxxxxxxxx
09/11/2008 12:47 PM g>
cc
Please respond to Subject
"Eclipse Platform SWT component [platform-swt-dev] Mouse
developers list." events/dragging
<platform-swt-dev@xxxxxxxxxxx>
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.
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
