I'm wondering about the current idiom for disabling keyboard
autorepeat in Tk.
>From my tests it seems that autorepeated keys[*] always generate
Release-Press sequences with the same timesatmp (%t). So it seems the
only method implies setting up an very short [after] on Release,
cancel it on Press, and consider a true Release when it gets to
completion.
Questions:
- is it the best bethod ?
- what is a safe value for the timer (guaranteeing that it won't
complete *between* the notification of the two events) ? (a large
value delays the true Release notification).
-Alex
Thanks, but (1) it is X-specific and (2) it is system-wide (I mean
display-wide).
In fact I'm not looking for an external workaround, I just want to
know if there's a better Tcl-only solution.
Otherwise, I think there's room for a TIP.
-Alex
Check
http://groups.google.de/group/comp.lang.tcl/browse_thread/thread/94319c195f862856
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/bdd9524e3e766ab2
HTH
R'
Yes. So, basically, the answer is: "the recommended idiom is the
above", right ?
-Alex
>
> -Alex
>
G!
uwe
FWIW, on Windows you don't get a <KeyRelease> between autorepeated
<KeyPress> events. (Or at least I didn't get that when I tested!)
> So it seems the
> only method implies setting up an very short [after] on Release,
> cancel it on Press, and consider a true Release when it gets to
> completion.
Since the release is guaranteed to precede the press, what you could do
is just save the timestamp of the last release. Since that's just a
simple variable, it'll be easy to implement.
Another thing to check is whether the serial numbers are the same or
not; if they're the same, then that gives you an even better way of
detecting that it's not a real release/re-press. But I can't check that
on Windows for you; this is an area where it seems that the platforms
aren't precisely equivalent.
Donal.
Yes.
R'
Even worse: not even consistent between unix and windows...
Why this ?
> > So it seems the
> > only method implies setting up an very short [after] on Release,
> > cancel it on Press, and consider a true Release when it gets to
> > completion.
>
> Since the release is guaranteed to precede the press, what you could do
> is just save the timestamp of the last release. Since that's just a
> simple variable, it'll be easy to implement.
Yes but in my case (and in the case of many games, see the Asteroids
on the wiki) I also want a callback to be called on the Release event.
So I need the [after] in order to do something after the last Release.
> Another thing to check is whether the serial numbers are the same or
> not; if they're the same, then that gives you an even better way of
> detecting that it's not a real release/re-press. But I can't check that
> on Windows for you; this is an area where it seems that the platforms
> aren't precisely equivalent.
On Windows you've just said there was no fake Release, so here it
suffices to keep a flag recording the fact that we are in the Pressed
state...
So, the method with the equality of timestamps *and* the [after] works
in all cases and OSes.
But I'm far from saying I'm *happy* with such a kludge :^{
Ain't it TIPpable ?
-Alex
Since it is arguably a fault in the way Xservers handle key events, no.
TIPs don't apply to Xservers (unless they're written in Tcl, of course.)
Donal.
What I mean is: it is frustrating to have to deploy such a complicated
script-level workaround. It would be both more efficient and easier
for Tcl developer to do it in C...
-Alex
Being curious: how would it be easier in C?
R'
It would be more likely to happen if you were to suggest with a patch
instead of a vague complaint... ;-)
Donal.
Read again: easier for the Tcl developer.
That means: we write it in C, and immediately Tk becomes more
consistent across platforms. The common behavior becomes what's
already happening on windows: several Press and just one Release. So
the interested Tcl scripter just has to keep a flag to tell fake Press
from true ones.
-Alex
Who said I wouldn't ?
My original post was to rule out a cleaner solution; I hate wasted
efforts :-)
-Alex