Hacker News Reader

Comment by voldacar | Hacker News Reader

Couldn't you just stop receiving keypresses when a UI transition begins and then re-enable input once the new UI state has been established?

View on HN

Yes, but it still means that when input is re-enabled later, the buttons are in an unknown state and you don't know if you'll be receiving unexpected button up events.

Also, it's very frustrating for users when input gets dropped on the floor at times where they don't expect. Determining when to queue that input and when to forget it is a real art. Humans have subtle, complex expectations there and there's no simple solution.

The problem is "key down" and "key up" are usually separate events. If you write software in a way that you always expect a "key up" to be preceded by a "key down", you'll have problems like the above mentioned.

Seems like a great place to use state machines. That’s not a total solution, of course: if “hold X” and “hold A” have very different behaviors, developers still have to code those states to be exclusive...unless they shouldn’t be. Ain’t easy, that’s for sure.

A robust solution should probably use state machines coupled with generative testing, so that all of those unexpected combinations can be generated and handled before the testers try button-mashing, without relying on developers to think of and write all the individual test cases.

of course, but that doesn't stop a case where a button was already pressed down when input get re-enabled which would mean a button up event would still fire without a corresponding button down.

Reply on news.ycombinator.com