Closed huyz closed 1 month ago
Yes, that should be possible.
@huyz I pushed a commit to the devel
branch that implements the following behaviour:
hitting q
or Ctrl+c
brings up the usual quit dialog; the option selected by default is the safest, namely "Do not quit". This prevents quitting Moulti after mistakenly hitting q, Enter
instead of tab, Enter
(at least in moulti run
mode).
hitting Ctrl+c
moves the focus from "Do not quit" to "Quit and leave the process running in the background"
hitting Ctrl+c
again moves the focus to "Terminate the process and quit"
at this stage, hitting Ctrl+c
yet another time actually terminates the process and quits.
In the end, it takes up to 4 Ctrl+c
to destroy both the running process and Moulti. This is the same amount of keys as before (q, tab, tab, enter) but of course smashing Ctrl+c is easier.
Hmmm to be honest, I'm not thrilled about this. I was looking for 2 keystrokes but this way I'd have to hit 4. Plus this idea is unprecedented with all the apps I've ever used and when it comes to UIs, intuitiveness derives from similarity to existing UIs. If this were released, I'd probably skip this shortcut and instead I'd most likely continue hitting ctrl-c once and then moving my hand to the mouse to click the red button as I do today, even if it's a bit slower.
I don't see the benefit of this scheme, except perhaps to give the yellow button its own key sequence. But that one is still long at 3 strokes.
If you really wanted to assign a keyboard shortcut to each button, you could make it so the sequence were 2 strokes for each: Blue button would be ctrl-c or q and then (a), which would be displayed on the button itself. Yellow button would be ctrl-c or q and then (b). And finally red button would be the same but (c). This way the key sequences would be short at 2 keys for all options, there would be no guesswork as to what key would jump to the intended button. A, b, c could be replaced by one of the first letters of each button, as is commonly done (e.g. (O)k and (C)ancel). Most importantly this would be intuitive as that's very much how confirmation dialogs work.
But myself I'm most interested in hitting ctrl-c twice to signify "I really mean kill everything". Could even implement both schemes
I was looking for 2 keystrokes
assign a keyboard shortcut to each button
I am totally fine with keyboard accelerators, here they are:
(I would have implemented them from day 1 if the Textual framework offered them out of the box, but I assume this feature would conflict with regular key bindings).
Now, "kill everything" is reachable through either q, t
or Ctrl+c, t
.
Same for other options.
As to the idea of killing everything with only 2 Ctrl+c strokes (i.e. 2 identical keystrokes), I am against it because I have unwillingly killed way too many processes (typically text editors sent to the background) by smashing Ctrl+d twice. My lesson there was that 2 strokes only is dangerously error-prone, and that was confirmed by bash implementing IGNOREEOF
(and zsh implementing something similar):
IGNOREEOF Controls the action of an interactive shell on receipt of an EOF character as the sole input. If set, the value is the number of consecutive EOF characters which must be typed as the first characters on an input line before bash exits. If the variable exists but does not have a numeric value, or has no value, the default value is 10. If it does not exist, EOF signifies the end of input to the shell.
As you can see, that concept of "many" identical strokes is neither an original invention of mine, nor as extreme as the default value mentioned above. Plus, I think that hitting Ctrl+c 4 times, with visual feedback, alongside a logical path ranging from "no consequence" to "just sent SIGTERM to that very important process of yours", is a reasonable tradeoff.
I'm happy with the keyboard accelerator. q t
is just fine for me. Thanks!
This feature is now available as part of Moulti 1.14.0.
Do you think you could have it so that hitting CTRL-C twice would automatically select the
Terminate the process and quit
? This is something I very often need to do with Ansible playbooks.