A UI shouldn’t lose your inputs.
This may seem obvious, but I often see applications that behave incorrectly if your inputs come too fast. One common situation where I see interfaces falter is keyboard shortcuts that bring you to a text input. Keypresses after the shortcut should always land in that input.
A common example is an app launcher. On GNOME I tap Super and type to search my apps. If I type Superfoo it should search for “foo” every time. GNOME works correctly here. No matter how overloaded and laggy my system is, and no matter how fast I type, the search is accurately captured. KDE’s KRunner does not pass this test. Oftentimes the first few characters of my search will land in the previously-focused application. I think this is because it is implemented as a separate process, and it can take a moment to start up and capture keyboard focus. macOS’s Spotlight also fails, although the failure window seems much smaller than KDE’s and required significant system load to hit.
Ghostty handles paste events asynchronously. Typing Ctrl+Shift+vEnter can trigger the Enter first, then the pasted text lands on the next line.
This occurs on web apps too. I’ll pick on Linear as they appear to have thought about this to some degree. Some shortcuts like a1 will reliably self-assign the ticket no matter how fast I type or how locked up my system is. Even complex interactions like mbCtrl+VEnter will mark the current issue as blocked by the issue in my clipboard. That is how it should work!
However, they aren’t perfect. /foo can have various behaviours depending on how fast you type. It should search for “foo” every time, but I have seen a few failures:
This can happen for mouse events too. For example Firefox has an excellent feature where after clicking the close button on a tab, the next tab’s close button will always land in the exact same spot. Even if the tabs were previously compressed because too many are open, they will wait until you move your mouse away to expand again. This way you can just keep clicking in the same location to close many tabs with ease.
But the tab closing animation ruins this! There is a gap in time where the old tab hasn’t gone away and clicks just disappear. So you can’t simply click 4 times to close 4 tabs, it may close fewer than you intended. You instead need to wait until the previous click is fully processed before performing the next click. This isn’t the worst failure mode but can make workflows where you close lots of tabs unnecessarily slow and annoying. Ctrl+W doesn’t appear to suffer this issue and always closes the right number of tabs.
This reminds me of the classic moving click target UX failure. This is the opposite of that: instead of the target jumping away as you try to click, the predictable target is instead not ready yet.
The main difficulty in implementing this correctly is that you need some sort of global input routing that buffers events until the application is ready for them. This can be quite difficult in browser applications as there is no way to “defer” input events other than completely blocking the main thread. So if follow-up keypresses are required you need to synchronously adjust focus, which may be difficult in your framework. This typically also precludes any form of lazy loading. Alternatively you would need to implement your own focus and input event handling logic, which is almost certainly a bad idea.
Asynchronous work is a complicated case in general, because buffering inputs for an extended period is confusing to the user. What if that work can fail? Do you drop the buffered input events? Or feed it to the previously focused input control? Do you need some sort of timeout? Luckily I find that this case is very rare. (Although the clipboard example above is one of these cases.)
If you have any sort of UI automation, this is easy to test: feed the keys in as a single batch and be sure that your app handles them properly!
Typing speed shouldn’t affect functionality! Keyboard shortcuts are designed for people to go fast, nothing will harm your productivity more than familiar keyboard shortcuts doing something unexpected! (Bonus points if those inputs aren’t lost, but trigger a completely different action like “delete”.) It is easy to say that it is a 2 millisecond gap and no one will hit a window that small, but that gap may be much larger on a low-end machine swapping like crazy. Or maybe my local LLM is hogging my GPU for a second or two. Don’t let fingers race your UI, just close the gap.
]]>I randomly had the idea that it would be interesting to “dig into” all possible Sudoku puzzles. So I created Digdoku. The landing page is an “empty” puzzle, each link leads to a puzzle with one additional square filled. Values that are not possible are excluded. So you can never get an invalid puzzle by clicking links (but you can by editing the URL).
The concept is simple. Basically for every unset cell it attempts to solve the puzzle with every number from 1-9. If any solution is found that value is possible, otherwise it is omitted.
This “eager” removal of impossible values means that it functions as a solver as well. By the time you click all of the provided squares (or often sooner) there will be only one possible grid, and it will be revealed.
However, implementing this simple solution is fairly slow. So some optimizations were necessary. These are primarily around skipping options that are easily determined to be impossible or were already found to be possible. The solver is still mostly a brute-force depth-first solver with some very basic rules put on top (such as eliminating duplicate values in a box/column/row group and if a value can only be in one place as a group it must be that).
The slowest case I am aware of takes about 100ms on my desktop. It could almost certainly be much faster, I suspect another order of magnitude would be fairly easy to achieve. But in the first version some cases took over six minutes, so I’m calling it good enough for now.
One downside is that the URL only keeps minimal state, so a lot of options need to be re-eliminated every step of the way. Maybe compiling to WASM and running an incremental solve client-side would be better. Might be something interesting to try. It would also avoid the risk that my single-core VPS gets overloaded if this gets popular. I do have caching enabled, but I suspect after a few clicks hits will become quite rare.
There is also something about a simple HTML response that I am very fond of. Theoretically you could pre-render every possible grid into a static site. But according to Wikipedia there are 6.6e27 valid Sudoku grids, so I’ll hold off on the pre-render for now.
]]>PostgreSQL major version upgrades are something that NixOS currently doesn’t handle for you. This is my process, documented mostly so that I can remember it next time I want to upgrade.
I use the standard NixOS module for Postgres. My main config looks like this:
Notable features:
Log in as the postgres user. (sudo -su postgres)
Define the old version old=16
Get the old and new versions:
Initialize the new data directory. Be sure to use the arguments from your config!
Copy the configuration (this is really only needed if you have extensions that need to be loaded, the main value we care about is shared_preload_libraries. But copying the whole file is easiest and the NixOS module will overwrite it anyways when starting the new version.).
Run the check
Stop the old Postgres. systemctl stop postgresql
Run the migration. This is the same command as the check without --check.
Start the new PostgreSQL server. (This is typically done by activating the new configuration such as sudo nixos-rebuild switch.)
At this point the new version is running. Note that rolling back will cause data loss as new changes are being made only to the new data directory.
You may wish to rename the old directory so that if you do accidentally roll back it is more likely that things fail rather than losing data. But if you have insecure apps that let the first user be admin that may be a bad idea. Maybe you could do something like put a file there or a directory owned by root? But I haven’t tested any of these things.
As suggested by pg_upgrade run vacuumdb --all --analyze-in-stages.
At some point in the future once you are confident that the new DB is running fine (a few weeks doesn’t hurt) you can remove the old data.