-
Notifications
You must be signed in to change notification settings - Fork 191
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Confirm quit #355
Comments
There is now the Also, the app still quits if you hit escape again (as per the prompt: "Really quit? (press q/esc again to quit)"). I think the prompt should be a y/N thing, and escape is considered an N. |
I had a quick try at fixing that, but it looks like you can only bind keys once (or rather, when hitting a key, it seems to match the first binding which might have other keys combined o be named awkwardly in the new context). |
Hm, I suppose it could be considered equally 'intuitive' behaviour either way, though I think on reflection I'm more inclined to agree with you that The prompt probably should be Actually, to really drill down into the UX design on something like this, it would probably best be presented as a modal confirmation popup with 'yes/no' buttons, with (default?) bindings |
I remembered localisation is a thing, so there's also that for even something as simple seeming as a y/n prompt.... 'Y/N has long transcended the yes/no origins in computing' is probably a valid counter for those specific keys, but, arbitrary named virtual keys for such things is worth considering is strong localisation is desirable... |
Accidentally hitting
esc
/q
and losing the flow of what you are doing isn't the end of the world, but atm it seems a little too easy to accidentally do.As it stands those keybinds insta-quit the dashboard, even in circumstances where instincts from other UIs & general expectations suggest it shouldn't.
Most notably, when you have hit
?
and have the 'help' (cheatsheet?) open, it is quite easy to absent mindedly expect at leastesc
to just close that, not exit the entire program.I'd propose hitting those keys when you most recently opened up a kinda sub-window like that, it should close those in reverse order before attempting to quit the whole dashboard.
I think perhaps a 'really quit?' prompt would be a nice QoL improvement. Imo having quick and easy options to confirm the quit (e.g. hitting
esc
orq
again, hittingy
, hittingreturn
, etc.) should mean the nag is outweighed by avoiding the flow-breaking drop back to the terminal.The text was updated successfully, but these errors were encountered: