On Sat, Mar 24, 2012 at 11:29 PM, Evan Laforge <[email protected]> wrote:
> Can anyone on linux reproduce?  If so, I'll file a STR and maybe look
> into fixing it.  I have an easy workaround (just use event_key(),
> which I avoided on OS X due to a different bug), but it's clearly a
> bug.  I think my app is unusual in caring a lot about keyups :)

Waaaiiit... I just dug up an old message from me reporting the exact
same thing.  And on further thought, Bill was right, that you can't
use event_text for keyups.  Sorry about the noise!

Since I need to know what letter went up, now I keep a keys_down map
from event_key to event_text, so I can figure out what the "down" text
was for a given key when it goes back up.  I need the map anyway to
suppress spurious keyups, e.g. if a keydown shifts focus from a
different app (e.g. command-tab), then the focused app gets a keyup it
didn't see a keydown for.

I need the keyup text because it's easier to bind keys to '~' rather
than '`' + SHIFT, and maybe not even accurate since different key
layouts might have different mappings for shifted symbols.

I'm suspicious of the "keep a key table" approach because those things
get out of sync so easily, but I don't see another way around.  If
fltk doesn't want to keep a table internally so it can have an
accurate event_text(), maybe we could clear it out on keyups to at
least prevent people from accidentally relying on something that
*usually* works?

_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to