Hi Brett, On Saturday, July 06, 2002, 10:10:04 AM, you wrote:
BH> I have found that it is not entirely reliable though (event with the bug fix BH> of events: copy []). You can get the slider very far away from the mouse. I BH> haven't tried /forever option, not sure how, where, when you can use Eat BH> apart from your example. We tried to merge two approaches, Romano's (pulling out events from the event port when they are not needed) and mine (compressing events for the whole /View). It's likely that the thing has some problems, but it shows that something can be done in this direction. BH> So I haven't tried it with a real app either. EAT/FOREVER should not have problems, except when you really want ALL events. However, it was not tested much, and of course is mainly a hack. BH> It seems though that the app should process as many events as it can handle, BH> without slowing the user. Basically, this is what EAT does. It lets the app receive all the events, but if they start to queue (because the app responds slowly), it does not send useless events (i.e. moves that are overridden by the next move, etc.). It preserves the order of events, and does not remove events across event/type changes. We have to find a better way to make the filtering happen on a face-by-face basis instead of globally; I think the best solution would be to send all the queued events at once to a face, so that the face feel decides if it should skip some or not. However this would require changes by RT... Regards, Gabriele. -- Gabriele Santilli <[EMAIL PROTECTED]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
