On Fri, 15 Feb 2019 at 01:28, BALATON Zoltan <bala...@eik.bme.hu> wrote:
>
> On Thu, 14 Feb 2019, Peter Maydell wrote:
> > - (void)sendEvent:(NSEvent *)event
> > {
> > COCOA_DEBUG("QemuApplication: sendEvent\n");
> > - [super sendEvent: event];
> > + if (!cocoaView || ![cocoaView handleEvent:event]) {
> > + [super sendEvent: event];
> > + }
>
> I think the menu problem may be because now all mouse events go to our
> handleEvent method and it may swallow those that should operate the menus
> somehow while previously [super sendEvent] took care of those events and
> only left the remaining mouse events in queue? Maybe we should test in
> handleEvent if the mouse event is within our window and forward everything
> else to super? But I'm not sure and could be wrong, only guessing.
Menus definitely did work for me (both mouse interaction and
keyboard shortcuts), so I'm not sure why you're seeing something
different.
My understanding is that the new code should eat exactly the
same set of events that the old code did:
* in the old code, only our custom "pull events off the queue"
code took events from OSX, and it passed them to handleEvent;
only events handleEvent called [NSApp sendEvent] on would
ever get to the OSX menu/etc handling
* in the new code, OSX's run loop takes events off the queue:
they go to our NSApplication sendEvent method, which passes
them to handleEvent. Only events that handleEvent returns false
for will ever get to the OSX menu/etc handling
and (absent bugs) handleEvent should now return false for exactly
the set of events that it previously called sendEvent on.
I know menu handling in OSX is a bit odd because the menu
drag stuff uses a 'private event loop' to handle events
while the menu is down. Maybe something is interacting
badly with that.
thanks
-- PMM
