<ctrl><shift>P (qvm-pause --all) should also show a notification informing the user of what they have done and how to undo it

[Summertime]

Qubes OS version:

4.0

Affected component(s):

The default hotkey settings

---

Steps to reproduce the behavior:

Be a new user who didn't read the documentation enough (is it in any documentation?) and then pressed P

Expected behavior:

see "All VMs paused. Press P to unpause" in the top right of my screen

Actual behavior:

Feeling very confused and lost, needing to restart (which takes forever due to the paused VMs), and then after doing so, search online to find a random github issue which hints at what happened when I wanted to open the command palette in my text editor!

General notes:

This could also be solved with having a "tour" application, or for a very quick "fix": have the default background have the default hotkeys written on it!

---

Related issues:

[Aekez]

Feeling very confused and lost, needing to restart (which takes forever due to the paused VMs)

This I think is really good idea you bring up (imho), especially the unlock in the upper right corner idea, and the tour application idea is also pretty neat.

• Some reflection: Actually the the tour idea might also be a good idea for more broader and different applications in Qubes too? I.e. if people are willing to pitch in to do this kind of work like they do with docs. Or heck, why not have the docs build-in into Qubes itself and when opened, ask the user if they want to update the latest Qubes docs from the Qubes site? i.e. access them from the Qubes widget.

I'd like to add some extra minor details to consider.

Consider and communicate whether user using pause to pause long-term is safe and desirable
There also doesn't seem to be any common-knowledge among Qubes users, docs explaining, or logic build-in into the Qubes systems, which affects whether the user would use ctrl+shift+p / ctrl+shift+alt+p as a means to pause/unpause VM's (and in addition lock-pause-screen ofc) for more long-term purposes rather than short-term purposes. For example while out doing other businesses away from home, work, or when the computer is running when sleeping, etc. For example, is it a recommended feature to use if away from your system for a longer period of time (if accepting the risk of local-attacks on pause-screen of course)?

The benefit of that is if you got something that you need to keep running, it'd be nice if the VM environments exposed to the internet or otherwise can be kept safe while away, rather than having to restart all the VM's just to be safe.

Consider some extra pause flexibility
Something else to consider is whether having greater control of which VM's goes to sleep on various different hot-key activations is desired, i.e. a Qubes feature that can allow modifications of this nature.

• Examples
  • Pause all VM's except the active window, and make it clear to the user (same as the OP issue).
  • A manager window which can be used to set a more complex variation of which VM's should be immune to a specific hot-key pause. For example if you got the same couple of VM's that must keep running while away, but you'd like everything else to stop.
  • Pause sys-vm's and internet functionality only, but not to pause the VM's (i.e. running something offline).
  • The more complex pause features would probably need some ways to make it easier to use in practice too.

Some of these might warrant a new issue if they are pursued though, but for now listing some ideas here.

[Aekez]

Feeling very confused and lost, needing to restart (which takes forever due to the paused VMs)

This I think is really good idea you bring up (imho), especially the unlock in the upper right corner idea, and the tour application idea is also pretty neat.

• Some reflection: Actually the the tour idea might also be a good idea for more broader and different applications in Qubes too? I.e. if people are willing to pitch in to do this kind of work like they do with docs. Or heck, why not have the docs build-in into Qubes itself and when opened, ask the user if they want to update the latest Qubes docs from the Qubes site? i.e. access them from the Qubes widget.

I'd like to add some extra minor details to consider.

Consider and communicate whether user using pause to pause long-term is safe and desirable
There also doesn't seem to be any common-knowledge among Qubes users, docs explaining, or logic build-in into the Qubes systems, which affects whether the user would use ctrl+shift+p / ctrl+shift+alt+p as a means to pause/unpause VM's (and in addition lock-pause-screen ofc) for more long-term purposes rather than short-term purposes. For example while out doing other businesses away from home, work, or when the computer is running when sleeping, etc. For example, is it a recommended feature to use if away from your system for a longer period of time (if accepting the risk of local-attacks on pause-screen of course)?

The benefit of that is if you got something that you need to keep running, it'd be nice if the VM environments exposed to the internet or otherwise can be kept safe while away, rather than having to restart all the VM's just to be safe.

Consider some extra pause flexibility
Something else to consider is whether having greater control of which VM's goes to sleep on various different hot-key activations is desired, i.e. a Qubes feature that can allow modifications of this nature.

• Examples
  • Pause all VM's except the active window, and make it clear to the user (same as the OP issue).
  • A manager window which can be used to set a more complex variation of which VM's should be immune to a specific hot-key pause. For example if you got the same couple of VM's that must keep running while away, but you'd like everything else to stop.
  • Pause sys-vm's and internet functionality only, but not to pause the VM's (i.e. running something offline).
  • The more complex pause features would probably need some ways to make it easier to use in practice too.

Some of these might warrant a new issue if they are pursued though, but for now listing some ideas here.

[SurinameClubcard]

I'd like to add that during the transition of 3.2 to 4.0, some "advanced" features were pushed back, away from the GUI, towards the command line. E.g., the UpdateVM setting is no longer available in the Qubes Manager. Although I understand the reasoning (to make it less intimidating to new users), I'd rather see a menu option like "Turn advanced features on", which allows power-users-without-all-the-command-line-kung-fu-skills to be able to at least see and if needed change that setting/those settings. By default, that option should be "off". And, Ctrl-Shift(-Alt)-P, a black belt third dan keystroke, should only be enabled if the "Turn advanced features on" switch is set to "on".

[SurinameClubcard]

I'd like to add that during the transition of 3.2 to 4.0, some "advanced" features were pushed back, away from the GUI, towards the command line. E.g., the UpdateVM setting is no longer available in the Qubes Manager. Although I understand the reasoning (to make it less intimidating to new users), I'd rather see a menu option like "Turn advanced features on", which allows power-users-without-all-the-command-line-kung-fu-skills to be able to at least see and if needed change that setting/those settings. By default, that option should be "off". And, Ctrl-Shift(-Alt)-P, a black belt third dan keystroke, should only be enabled if the "Turn advanced features on" switch is set to "on".