On 10.04.2013 19:05, Greg Ercolano wrote:

>       If you wrote the code in pure Xlib, you'd still encounter this problem,
>       the workaround apparently being to access the LEDs directly I think.
>       Anyway, not sure if hacking X11's event structure in the case of 
> capslock
>       is a good idea or not -- seems like an X11 bug to me, and not sure if 
> it's
>       appropriate for FLTK to try to cover that up with a hack.
>       Would like to hear what other devs say.

There's a (big?) warning that using another Xlib call to get the key
state has at least two drawbacks:
  (1) Speed. It's slow because it needs another client/server roundtrip.
  (2) AFAIK all you can get is the CURRENT keyboard state. This can 
differ from the state as seen (or should be seen) when processing 
events, since this is an asynchronous call. I.e. event handling can be 
three key presses and two releases "behind", and calling for the current 
state would give you no better values. Note that speed may not be so 
problematic, if you're working with X on a local machine, but X is 
designed to be a remote protocol over tcp/ip.

This is all off the top of my head, and ISTR that I read such a warning 
in the FLTK code somewhere, but I don't have personal experience with 
native X11/Xlib calls. The same problem arises with Windows, BTW, 
although tests showed in this case that it seemed to work.

So, if there is not an OBVIOUS bug in the FLTK code WRT direct event 
handling, I'd recommend leaving it as-is. We should not try to fix one 
bug and get another unpredictable behavior.

The intended behavior (warning about CapsLock in password entry fields) 
can be achieved even when the warning is issued when a real key press 
arrives, so it's usually not too late - and this works reliably, as my
tests and Ian's tests seem to show.


fltk mailing list

Reply via email to