[HN Gopher] Three ways of handling user input (2022)
___________________________________________________________________
Three ways of handling user input (2022)
Author : stcucufa
Score : 58 points
Date : 2024-04-28 08:06 UTC (1 days ago)
(HTM) web link (dubroy.com)
(TXT) w3m dump (dubroy.com)
| julik wrote:
| This series of articles is massively underrated. Even modern
| React setups with hooks and the like, with modern state handling,
| are rife with data races which happen at the input level. This
| article and the followup to it present a very compelling approach
| to handling input in a structured way and avoiding those data
| races.
| eviks wrote:
| Do such issues exist in popular desktop GUI frameworks?
| julik wrote:
| Judging by the fact that apps in iOS that are produced by
| Apple itself have races with resizing menus when you rotate
| the device the answer is a resounding "yes".
| seanmcdirmid wrote:
| Yes on Android also.
| eviks wrote:
| thanks, but that's why I mentioned desktop, was curious
| whether they still retain this type of fundamental fail
| despite "decades of improvements", it's much less of
| surprise re. the web/mobile
| jkaptur wrote:
| Yes. There's nothing particularly magical about any UI
| framework. They all have to deal with the fundamental fact
| that UIs are enormously stateful, the state is a function of
| approximately everything the user has ever done, various
| inputs arrive asynchronously and unpredictably,
| responsiveness SLOs are in the 10ms range, and the hardware
| is generally diverse and off-site.
| giovannibonetti wrote:
| This reminds me of Evan Czaplicki's PhD Thesis [1] on how
| concurrent functional reactive programming (FRP) can be
| used to solve most (if not all) of those challenges with
| little effort from the application developer.
|
| [1] https://elm-lang.org/assets/papers/concurrent-frp.pdf
| eviks wrote:
| The "fixed" version doesn't return on Escape and the first bug
| doesn't appear after you've moved the box (and both sometimes get
| glued to the mouse pointer even on mouse up). Doesn't seem like a
| great solution
| leecommamichael wrote:
| What about the other 10 ways that appear when you program for
| your OS rather than a browser?
| sumnole wrote:
| Fortunately, all input handling techniques can be reduced to
| relatively few concepts.
| mncharity wrote:
| When dealing with inputs of diverse latencies, another approach
| is a replayable event stream with app state that's checkpointed
| or otherwise retractable. My laptop had cameras tracking hands on
| keyboard, creating fused input. For key events with finger id and
| position on keycap, keycap touching as modifiers, and keycap
| touch events without pressing. But while you want ui response to
| keypress to be very fast, tracking info wouldn't become available
| until the next video frame finally showed up and was processed.
| Integrating voice faces similar issues - speech-to-text "launch
| the missiles!" might shortly later become "lunch is mussels, in
| butter!", with launch needing retraction. Which required adapting
| app state and its modification.
| yjftsjthsd-h wrote:
| > My laptop had cameras tracking hands on keyboard, creating
| fused input.
|
| What laptop is that?
| mncharity wrote:
| ThinkPad P53 "portable workstation" with DIY cameras on
| sticks mounted on back of screen. Here mostly a keyboard-cam
| that flopped up-and-over to look down on the keyboard, and a
| convex mirror bar along the base of screen for crappy touch
| detection. But also fisheyes hinged up to corners.
| Python/MediaPipe/libev under an Electron/browser stack.
| yjftsjthsd-h wrote:
| Ah, so the laptop is normal and you've tacked on a DIY rig
| so it can see your keyboard. Is there a
| writeup/blogpost/repo somewhere? That's an interesting idea
| Joker_vD wrote:
| One of the most annoying "dropped input" problems for me is in
| the Linux (GNOME's?) locking screen. To unlock the machine you
| need press e.g. Space to get the password entry textbox to appear
| and focused on, then type in the password and the press Enter --
| that's all fine. However, after locking the screen, the monitor
| powers down, and so the first keypress turns the monitor back on
| and then only _after some delay_ it puts focus to the password
| entry textbox. That means that if I go to my machine and rapidly
| type "Spacebar, hunter42, Enter", about 2 or 3 first characters
| of my password are ignored, and I get a "wrong password!"
| notification -- again, after some delay because preventing on-
| site brute-forcing is important.
|
| Constrast that with pressing F11, two arrows down to pick the
| correct OS, Enter, in quick succession during the boot, before
| the monitor boots up and starts showing the info (for some
| reason, this monitor I use takes about much time to boot up as
| the computer itself) -- this has never failed me yet because
| apparently the bootloaders don't just throw the keyboard events
| away.
| atoav wrote:
| The delay is important for increasing security, but then why
| not have it _after_ the check?
___________________________________________________________________
(page generated 2024-04-29 23:01 UTC)