dlvhdr / gh-dash

A beautiful CLI dashboard for GitHub 🚀
https://dlvhdr.github.io/gh-dash
MIT License
6.75k stars 190 forks source link

Confirm quit #355

Open Omnikron13 opened 2 months ago

Omnikron13 commented 2 months ago

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 least esc 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 or q again, hitting y, hitting return, etc.) should mean the nag is outweighed by avoiding the flow-breaking drop back to the terminal.

NickLarsenNZ commented 3 weeks ago

There is now the confirmQuit setting, but it should default to true so you don't have to dig around to get this expected behavior.

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.

NickLarsenNZ commented 3 weeks ago

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).

Omnikron13 commented 3 weeks ago

I think the prompt should be a y/N thing, and escape is considered an N.

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 Esc has a strong connotation of 'cancel' rather than 'confirm'.

The prompt probably should be y/n, though I do still think a 'double tap' of the q key should also work, for the sake of ergonomics.

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 y & q for yes, n & Esc for no, and ofc. enter/return for the selected option (heck, even mouse support is an option then, for those Osu players outlier users who are big mouse fans).

Omnikron13 commented 2 weeks ago

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...