gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A question on discardEventsMatchingMask:beforeEvent:


From: Fred Kiefer
Subject: Re: A question on discardEventsMatchingMask:beforeEvent:
Date: Wed, 26 Jan 2011 10:33:19 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.16) Gecko/20101125 SUSE/3.0.11 Thunderbird/3.0.11

Am 26.01.2011 01:41, schrieb Banlu Kemiyatorn:
> ----- Original message -----
>> Yes, this seems to have changed in the documentation. Best we can do is
>> to write a few tests on Cocoa to see what the actual behaviour is and
>> then implement an addition method on GSDisplayServer if needed.
>>
>> With regards to the event compression, could you please provide examples
>> how we could get the same effect to backend event compression with
>> application event compression without adjusting each and every existing
>> GNUstep application?
> 
> Why dont we just fix NSApplication to discard them from the server queue with 
> DPSops? But rather filter them through DPS ops, I think we should just move 
> the NSEvent queue to NSApplication by letting backend postEvent: the 
> translated events directly to NSApp then NSApp keep them in its own queue 
> (rather queue them in display server like current design) And then we filter 
> them in sendEvent: (since we can look up the queue we can filter anything we 
> dont want and can easily overide by custom application class) Unwanted 
> NSEvent just got discarded at this point. And we also dont need more DPSop 
> this way.
> 
> 1) DPSGetEvents invoke backend to translates all xevents in xqueue to 
> nsevents and post all to NSApp queue.
> 2) NSApp sends them after discarding base on the masking type and window etc.
> 
> 
> The downside is there will be a lot of nsevent we didnt actually want got 
> discarded in NSApp level which probably is more expensive than discarding X 
> or other input events at their gates.
> So may be we can also have extra filter that can be turned on in back but 
> pleasfully not by default.

I don't even think we need to move the event queue from GSDisplayServer
to NSApplication for that. The difference between your and my position
is mostly that I see these extra NSEvents as a much bigger problem and
want to make sure that no normal application gets hit by that. What
about adding a compress events flag on GSDisplayServer that will be true
by default and settable from application code? That way we normally have
the same behaviour as now and if an application wants to flood itself
with events, there is a way to do this.


>> Am 25.01.2011 19:22, schrieb Banlu Kemiyatorn:
>>> Apple docs said that NSWindow -discardEventsMatchingMask:beforeEvent:
>>> should just forward to NSApp
>>> but a note on NSApplication -discardEventsMatchingMask:beforeEvent:
>>> states
>>>
>>> "Typically, you send this message to an NSWindow object, rather than
>>> to the application object. Discarding events for a window clears out
>>> all of the events for that window only, leaving events for other
>>> windows in place."
>>>
>>> out implementation in NSWindow is like
>>>
>>> - (void) discardEventsMatchingMask: (unsigned int)mask
>>> beforeEvent: (NSEvent*)lastEvent
>>> {
>>> [NSApp discardEventsMatchingMask: mask beforeEvent: lastEvent];
>>> }
>>>
>>> wouldn't that mask the events off all windows?
>>>
>>> What would be bad if we store all the events from server queue on a
>>> queue on NSApplication (so we don't need to fix op for server ?) and
>>> let the display server directly postEvent:atStart: to the app.
>>> Beside that it would allow applications to manipulate the event queue
>>> directly, like custom event flood filtering, I think that would ease
>>> the work on multiple input devices/points implementation in future as
>>> well.
>>> For the point of filtering, I am concerned of the point that tons
>>> unused NSEvents would be discarded anyway but I don't think it's
>>> backend's decision to decide what application developer would want.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]