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

[Scott Kovatch <skovatch@xxxxxxxxx>]

On 9/12/08 7:40 AM, "Silenio Quarti" <Silenio_Quarti@xxxxxxxxxx> wrote:

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

I discovered this on my own yesterday, and I think I'm understanding what
you've done some more as a result.

I have to keep reminding myself this is not the AWT.  In the AWT you react
to a native event, package it up as an AWTEvent, and then post it to the
event queue. I think we had event consumption, but it was terribly
convoluted.  In the SWT you are intercepting the native event before it even
gets to the NSView and potentially blocking dispatch of the event.

>> 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 agree it would be much cleaner and make more sense.


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

Maybe we're still in the transition from hacking to final product, but I
think some more comments would be helpful throughout this part of the code.
After some reading, it looks like key events don't go through this part of
the code, and get handled directly by each NSResponder.  That's not what I
would expect at first reading of the code.

> Call me if you want.

I may call later today. I'm going to pile up a few questions first.

One thing I've noticed is that I think findControl() has a bug or two in it.
When you click the wrong component is being found, which hints at the wrong
coordinate reference being used somewhere.  You can see this in the Canvas
example, as the mouse downs aren't being reported.  Once I know more I'll
write a bug.

Scott