Comment by kazinator

Comment by kazinator 3 days ago

One thing I'd like to see fixed in computer keyboard input in general is how Shift is handled for capitals.

I find it next to impossible to type "Now" really fast without having it come out as "NOw" much of the time. (Why I'm using this example is that it's the first word of the "Now is the time ..." test sentence).

The timing required is strict. The Shift key must be down before the letter key is down.

Keys activate strictly and immediately on the down event.

Note that virtual buttons on most contemporary GUIs, clicked by mouse, do not work this way. You must click and release the button for it to activate. If you click OK on some dialog, but change your mind while still holding down the mouse button, you can back out of it, by moving the cursor out of the button's area. You also cannot click down outside of the button, then move into the button and release. The button must receive both mouse down and mouse up, without the pointer leaving the area, in order to activate.

I'd like a mode in which the down events of non-modifier keys are deliberately delayed by some configurable number of milliseconds, so that when the user hits a modifier key at around the same time, and that key lands a little bit late, it is still taken into account.

It would also be nice to be able to experiment with a mode in which keystrokes are generated by their up events, not down, and the modifier is sampled at that time.

zaat 3 days ago

I can't find any viable alternative. Keyboard is much faster than those click and release interfaces. Keyboards also have repeat keys, when you press a character for a long time you can actually press and depress the shift key and see the change in the line of characters input. This is extremely useful feature in games, graphic design software and other applications.

Generation of keystroke based on the up event, beside been incompatible with repeating keys for long strokes, will slow down typing significantly, as it requires tracking timing pressing keys for longer duration. I'm pretty sure that this isn't only effect of me being used to track keypress timing on the way down, but an unavoidable result of the duration of the action.

Waiting for up event on contemporary GUI, when the contempt UI is a sluggish fit-to-nothing dirty touchscreen in a public kiosk is sensible. When you know an interface will yield more errors than intended input it is only sensible to assume that any input is a mistake unless the user is making an effort to validate it.

Reply View 1 reply

kazinator 3 days ago

Keyboard repeat is only useful in ANSI terminal games on Unix, and games on some old 8 bit home computers that didn't have up and down events (Apple II+, ...).
A game written for an IBM PC and everything after that can know exactly which keys are being held down and when they are released by intercepting the "scan codes" (or abstract keyboard events in a GUI event loop).
All that is missing is synthesizer-like velocity and pressure info. :)
> will slow down typing significantly
Only for people who have to look at the screen. :)
The hunt-and-peck beginners who look at their fingers are not effect, and neither are those who can look at something else or close their eyes.
A serious concern affecting even those people is that using the release event could reorder things, causing mistakes. Like say if someone types the sequece wh (involving two hands) such that they release the w later than h.

Reply View | 0 replies

akira2501 3 days ago

> The timing required is strict.

Your keyboard has a serial interface to your computer. Events are generated serially. If you press one first it will register first.

> keystrokes are generated by their up events

We don't do this because then you can't have auto repeat.

Reply View 1 reply

kazinator 3 days ago

> If you press one first it will register first.
While that is obviously so, there are two events: a press and a release event.
The thing I run into is that the release time: Shift being held over too long, into the start of the next character. Now comes out as NOw because the up event for Shift comes after the down event for w.
So I don't think my proposals are necessarily the right ones.
Perhaps this: when a shifted letter is being typed (the down event came in a shifted state), then the rule should apply that an up event should be received to generate the keystroke, and that up event should still be in the shifted state.
Refinement: when a shifted letter is being typed in a situation where the Shift was held over from a previous shifted letter, then apply the logic. Thus N is not delayed; it comes out on the downstroke. But if Shift is still held while o is typed, that is a held-over Shift, and so the rule applies; the state machine must see an up event for the o and then decides whether it is shifted. If Shift is released before the o, then o is issued on the down event as usual.
Another idea: when a shifted letter is being typed in a Shift-holdover state, then issue the keystroke for the letter either on the release of the Shift, or the release of the letter, whichever comes first. If Shift is released first, assume it was a holdover and don't capitalize the keystroke. If the letter is released first, issue the capitalized keystroke. In the situation where the intent is to type Now, this will hardly result in a noticeable delay for the o, since the Shift hold-over period is very brief.
> you can't have auto-repeat
Auto-repeat is an arbitrary behavior that kicks in due to a timer going off while a key is continuously held down.
It generates multiple fake keystrokes even though there aren't multiple down events.
So of course you can still have it generate multiple keystrokes even though there aren't multiple up events (including generating the first keystroke in spite of there not being any up event).

Reply View | 0 replies