Re: GSAppKitDefined events: queue, or send directly to window?

[Eric Wasylishen]

Hi Fred,
I think your point makes sense - having the backend sending events directly to 
gui, bypassing the event queue, sounds like a hack. 

Actually, I checked OS X 10.6, and if you put an application in to a loop 
calling [NSApp nextEventMatchingMask:...], and print out the result of [aWindow 
frame], it will print the frame of the window when the loop started, even if 
you move the window around. This happens regardless of the run loop mode 
parameter. So, GNUstep's current behaviour with the X11 backend is consistent 
with that - my patch would do more harm than good.

I think the correct fix for the menu bug I noticed is rewriting the cursor 
tracking code so it doesn't use an event tracking loop, but instead uses 
-mouseDown, mouseMoved:, etc. That's another project though..

Cheers,
Eric

On 2011-02-15, at 1:11 PM, Fred Kiefer wrote:

> Hi Eric,
> 
> in general the Windows backend is full of hacks, most of which are just
> workarounds for other hacks and most of the others not needed.
> 
> I think that we should try to keep the events in the order in which they
> arrive. Otherwise we could get rather bizarre results. In this specific
> case on the other end it really may help to send the event directly. I
> could agree on committing your patch now and having everybody test it
> for a while. When we get a problem with it, we just revert before the
> next release.
> Overall I would prefer an implementation where NSAppKitDefined events
> where handled by gui even when in an event tracking loop.
> 
> Fred
> 
> Am 15.02.2011 20:53, schrieb Eric Wasylishen:
>> Hey,
>> I noticed that when the win32 backend is notified of a window's position 
>> being changed or resized by the WM, it sends a NSAppKitDefined event 
>> directly to the relevant NSWindow using sendEvent: rather than queuing it. 
>> The x11 backend, on the other hand, queues these like regular input events. 
>> I wonder which one of these is the correct approach?
>> 
>> 
>> There is an annoying bug where if you position a vertical main menu near the 
>> top of the screen in GNOME, and open one of the first submenus which 
>> overlaps the GNOME top of screen toolbar, the menu highlight gets offset 
>> from the mouse location by 10 or so pixels.
>> 
>> What happens is the GNOME WM moves the submenu down so it's not overlapping 
>> the toolbar. However, since GNUstep is running in an event tracking loop, it 
>> doesn't process the NSAppKitDefined which would update the NSWIndow's frame 
>> - then, it uses the out of date window frame to calculate which menu item is 
>> under the mouse which ends up being incorrect.
>> 
>> I was able to fix this just by modifying the x11 backend to act like the 
>> win23 one, sending NSAppKitDefined events for window size and location 
>> directly to the window instead of queuing them. I didn't notice any problems 
>> as a result, but does this sound like something I should commit?
>> 
>> Cheers,
>> Eric
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev