Re: [TilEm-devel] WIP

[Benjamin M. <flo...@us...>]

>> Actually, the pause is *more* important; you need a pause of at least
>> 5 interrupt periods - around 50 ms - between two presses of the same
>> key.  In contrast, a key only needs to be pressed for one interrupt
>> period in order to be recognized.
> Interesting. Is the 50ms delay between the two presses or between the first
> release and the next press? The later looks more sensible but I'd rather not
> waste debugging time over such a subtle difference.

Yes, I meant between releasing the key and pressing it again.  Sorry,
I should have been clearer.

>> For 1-to-1 key bindings, of course, you want to hold the key down
>> exactly as long as the PC key is pressed.
> Sure. More generally the last key of a sequence will be held down exactly as
> long as the PC key is pressed.

Yeah, that makes sense.  Although I would enforce a minimum duration
(20 ms?) for the last key of a multiple-key sequence.  (I'd almost be
inclined to enforce a minimum duration for single keys as well, but
that could screw up games. :P)

>> What sort of hacks did you have in mind?  I don't think that would be
>> any dirtier than what I'm already doing to properly handle key-release
>> events.  (If your binding is Ctrl+X -> skGraphvar, then the X key is
>> considered to have "activated" the Graphvar keypress, so you need to
>> hold down Graphvar as long as the X key is held down - regardless of
>> what the modifier keys are doing.)
> I don't know how key input works in Gtk but in Qt it's fairly clean and
> handling key releases does not require any sort of hack.

Key-release handling is a long-standing (and very annoying) bug in the
old TilEm GUI.  It's a case where the simple and obvious solution is
just plain wrong.  And the current Qt GUI suffers from it, too.
Simple experiment: press 1, then press Shift, then release 1, then
release Shift.  Now try to press any other key on the calculator.  You
can't - or rather, the calculator won't do anything, because it
believes the "1" key is still held down.

(The "1" key is a silly example; the annoying case is where you need
to press Shift first, e.g., to type ^ on a US keyboard.  Then if you
release Shift before releasing the other key, it gets stuck.)

> I did not have any specific hack in mind because I've not actually tried the
> CTRL+X+Y case but my experience of writing a text editing widget makes me
> think it's not likely to be clean (try SHIFT+A+B in most text editors and
> you'll see what I mean).

I assume you're talking about the fact that only the second letter is
repeated?  Yes, we only receive repeating key-press events for the
most-recently-pressed key, but other keys still generate release
events as usual.

I'm glad you mentioned this, though, because typematic repeating is
something else I hadn't thought about.  If possible, we should
disregard typematic key events, since those can cause problems both
for one-to-one bindings ("pressing" a key you don't intend, due to
changing shift state while the key is held down) and for sequences
(where, if you hold down a key, the buffer gets filled up much faster
than it gets emptied.)

(In GTK+ programs, it's possible to detect typematic repeating by the
fact that you receive multiple key-press events for the same keycode,
without an intervening key-release.  This requires a little bit of
voodoo at the Xlib level.  Something similar is probably true for Qt,
but I haven't investigated.)

Benjamin