Albrecht Schlosser wrote:
> FLTK is (as all GUI's) event driven, and there is some event queue handled by
> the OS or some low level layer (like X11). Now, imagine that there are 100
> drawing events in the event queue, and you press a key. This will be event
> #101
> in the queue. FLTK would need to work its way through 100 events and call
> drawing functions that result in X server actions. After that, it will
> process
> your key press event.
>
> OTOH, Fl::get_key() will query the X server immediately and thus circumvent
> the
> event queue. Your key press will be processed in an asynchronous way, which
> would normally be *bad*, but in this case (just to stop the program) it is
> maybe
> the intended behavior.
Interesting.. should the docs for get_key() and event_key() make mention
of this? Sounds useful to avoid the problem sparkaround encountered,
though maybe it's implementation specific.
Currently the docs seem to warn that get_key() is actually the slower
of the two; from the 1.3.x docs:
int Fl::get_key(int key) [static, inherited]
Returns true if the given key is held down now.
Under X this requires a round-trip to the server and is much slower than
Fl::event_key(int).
Maybe the docs can elaborate on what context
get_key() vs event_key() can best be used in.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
