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. -- Albrecht _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
