[RFC] Keyboard shortcuts for qubes-manager

[Jean-Philippe Ouellet]

Hello,

As requested in [1] and implemented in [2], I am proposing to add
keyboard shortcuts to qubes-manager.

Specifically, at this time I am proposing to add the following:
1. Ctrl+N for New VM
2. Delete / Backspace (no Ctrl) for delete vm
3. Ctrl+C for Clone, because Clone and Copy start with C
Ctrl+Shift+N may also be a good candidate here, idk.
4. Space for start & shutdown
We can use the same key because only one of those is enabled.
Chosen because I use space to start & stop music and videos in
nearly all players, just here it's a VM.
5. Ctrk+K for Kill
6. Ctrl+E for settings
Thinking is you are going to [e]dit the VM, and is not a key people
may already have differing expectations for (for example Ctrl+S may
be expected to be Shutdown, or Save (whatever that would mean))
7. Ctrl+U for Update
8. Ctrl+R for "Run command in VM"
9. Ctrl+H for show/hide inactive VMs
10. Ctrl+Shift+H for show/hide internal VMs

I am hereby requesting comments on the above. (With the hope that it
does not generate excessive bikeshedding.)

Note that in [3] I introduced the Qt standard Alt+key menu navigation,
so all menus are already fully keyboard-usable, so these changes here
are not intended to be for the most frequently used things, rather than
comprehensive coverage.

I am purposefully not assigning all keys here because once you assign a
key and people start using it, it's really annoying to users to change
it out from under them. IMO we should consider these assignments
relatively immutable once they go into a release.


[1]: https://groups.google.com/d/topic/qubes-devel/YNqCYnxwgPI/discussion
[2]: https://github.com/QubesOS/qubes-manager/pull/19
[3]: https://github.com/QubesOS/qubes-manager/pull/13

[Holger Levsen]

Hi,

first of all: yay, keyboard shortcuts! Thanks for your work on this!

two minor comments:

On Tue, Dec 20, 2016 at 02:31:13PM -0500, Jean-Philippe Ouellet wrote:
> 3. Ctrl+C for Clone, because Clone and Copy start with C
> Ctrl+Shift+N may also be a good candidate here, idk.

CTRL-C is not a good choice here, I think, cause C already is cancel and
copy…

> 5. Ctrk+K for Kill

CTRL-Shift-K maybe?


--
cheers,
Holger

[Jean-Philippe Ouellet]

On Tue, Dec 20, 2016 at 2:48 PM, Holger Levsen <hol...@layer-acht.org> wrote:
> On Tue, Dec 20, 2016 at 02:31:13PM -0500, Jean-Philippe Ouellet wrote:
>> 3. Ctrl+C for Clone, because Clone and Copy start with C
>> Ctrl+Shift+N may also be a good candidate here, idk.
>
> CTRL-C is not a good choice here, I think, cause C already is cancel and
> copy…

Good point. I had not thought of that. Ctrl+Shift+N then? Something else?

>> 5. Ctrk+K for Kill
>
> CTRL-Shift-K maybe?

Is this because you are worried about accidental use? Or some other reason.

We already do have a confirmation dialog before a VM is actually
killed, keyboard shortcut or not.

[Chris Laprise]

On 12/20/2016 02:31 PM, Jean-Philippe Ouellet wrote:
> Hello,
>
> As requested in [1] and implemented in [2], I am proposing to add
> keyboard shortcuts to qubes-manager.
>
> Specifically, at this time I am proposing to add the following:
> 1. Ctrl+N for New VM
> 2. Delete / Backspace (no Ctrl) for delete vm
> 3. Ctrl+C for Clone, because Clone and Copy start with C
> Ctrl+Shift+N may also be a good candidate here, idk.
> 4. Space for start & shutdown
> We can use the same key because only one of those is enabled.
> Chosen because I use space to start & stop music and videos in
> nearly all players, just here it's a VM.
> 5. Ctrk+K for Kill
> 6. Ctrl+E for settings
> Thinking is you are going to [e]dit the VM, and is not a key people
> may already have differing expectations for (for example Ctrl+S may
> be expected to be Shutdown, or Save (whatever that would mean))
> 7. Ctrl+U for Update
> 8. Ctrl+R for "Run command in VM"
> 9. Ctrl+H for show/hide inactive VMs
> 10. Ctrl+Shift+H for show/hide internal VMs

I don't think that most of these functions are used frequently, and the
shortcuts proposed are more appropriate for editing a document or
database. Also, 'space' for start/stop is something I would actually
patch to remove from my system; there are VMs I do not want starting
accidentally because I pressed the spacebar, and spurious prompts to
shutdown VMs would be a nuisance. This is a media player type of mapping
that's inappropriate for VMs.

The ones I think would be really time-saving (and safe) are:

4. Shutdown VM: SHIFT+Esc
6. Settings: Ctrl+E
8. Run in VM: Ctrl+R
9. Show/hide inactive VMs: Ctrl+H

What would be TRULY useful is a global shortcut to shutdown the VM of
the active window. That would save a great deal of mousing effort. I
think it can be done easily in KDE shortcuts, but it would be nice to
have for all DEs.

Additionally, some global shortcut to Pause/Unpause VMs may be quite
useful to certain users who examine the behavior of software. This could
be optional, or maybe done through the DE.

As for adding features to Qubes Manager, that may be moot. There is
supposed to be a feature freeze on QM.

Chris

[Holger Levsen]

On Tue, Dec 20, 2016 at 03:15:29PM -0500, Jean-Philippe Ouellet wrote:
> > CTRL-Shift-K maybe?
> Is this because you are worried about accidental use? Or some other reason.

yes

> We already do have a confirmation dialog before a VM is actually
> killed, keyboard shortcut or not.

I was aware and still I think it's better to make it less easy to press
it accidently.


--
cheers,
Holger

[Jean-Philippe Ouellet]

On Tue, Dec 20, 2016 at 4:14 PM, Chris Laprise <tas...@openmailbox.org> wrote:
> On 12/20/2016 02:31 PM, Jean-Philippe Ouellet wrote:
>> As requested in [1] and implemented in [2], I am proposing to add
>> keyboard shortcuts to qubes-manager.
>>
>> Specifically, at this time I am proposing to add the following:

>> ...

>
> I don't think that most of these functions are used frequently,

I use them frequently enough to want to add shortcuts for them. I
imagine the same is likely true for at least some others.

> and the shortcuts proposed are more appropriate for editing a document or database.

Okay? So? I do not understand what this implies.

> Also, 'space' for start/stop is something I would actually patch to remove
> from my system; there are VMs I do not want starting accidentally because I
> pressed the spacebar, and spurious prompts to shutdown VMs would be a
> nuisance. This is a media player type of mapping that's inappropriate for
> VMs.
>
> The ones I think would be really time-saving (and safe) are:
>
> 4. Shutdown VM: SHIFT+Esc
> 6. Settings: Ctrl+E
> 8. Run in VM: Ctrl+R
> 9. Show/hide inactive VMs: Ctrl+H

I think you have identified two separate problems:

1) The possibility that accidentally starting sensitive VMs may be
harmful to users

This is a real deficiency. I think avoiding a startup shortcut
altogether is reasonable because of this. Or, barring that, at least
separate the startup and shutdown into two shortcuts which are not
keys next to each other. At least in my use it is far more often that
a VM is started via a .desktop file or on demand as a NetVM of
something else being started than started manually via qubes-manager.

2) Space is too easy to hit accidentally, and thus is not suitable as
a shortcut to manipulate VMs.

Also a fair criticism. I originally had it as Ctrl+Space. If we go the
only-shutdown route I question whether space makes much sense at all
anymore.

Personally, I think Shift+Esc is a little awkward and inconsistent
with the rest of the shortcuts. Any other suggestions?

> What would be TRULY useful is a global shortcut to shutdown the VM of the
> active window. That would save a great deal of mousing effort. I think it
> can be done easily in KDE shortcuts, but it would be nice to have for all
> DEs.

I find myself closing all VM windows before shutting down the VM out of habit.

If we agree this is a good idea, and identify a suitable shortcut,
then I believe the right place to do this is in the gui daemon,
similarly to how Ctrl+Shift+{C,V} are done currently, and this would
be DE-agnostic.

Then it comes down to identifying a shortcut which would be suitable
and acceptably non-conflicting.

The simplest things are often the most controversial... :/

I proposed earlier [1] that I think it would be a good idea to
dedicate an entire modifier key to qubes itself. This would allow us
to have a guaranteed-collision-free shortcut namespace, as well as be
able to make keystrokes starting with this modifier invisible to
AppVMs. I think it is reasonable to expect users to be able to select
a suitable such key on their respective keyboard layouts. Choosing a
default such key is again controversial. [1]

[1]: https://github.com/QubesOS/qubes-issues/issues/881#issuecomment-262648022
[2]: https://github.com/QubesOS/qubes-issues/issues/881

> Additionally, some global shortcut to Pause/Unpause VMs may be quite useful
> to certain users who examine the behavior of software.

Can you elaborate on who would use this? and why?

> As for adding features to Qubes Manager, that may be moot. There is supposed
> to be a feature freeze on QM.

Uhh, first I've heard of this... I've made ~10 changes to it in the last month.

I am aware of the impending rewrite, but do not see why this should
prevent quality-of-life improvements to the existing one in the mean
time.


In any case, I've quite likely spent more time discussing this now
than all users collectively are likely to save pressing keyboard
shortcuts instead of using the mouse. Ah priorities...
https://xkcd.com/1205/ :)

[Chris Laprise]

On 12/20/2016 09:10 PM, Jean-Philippe Ouellet wrote:
> On Tue, Dec 20, 2016 at 4:14 PM, Chris Laprise <tas...@openmailbox.org> wrote:
>> On 12/20/2016 02:31 PM, Jean-Philippe Ouellet wrote:
>>> As requested in [1] and implemented in [2], I am proposing to add
>>> keyboard shortcuts to qubes-manager.
>>>
>>> Specifically, at this time I am proposing to add the following:
>>> ...
>> I don't think that most of these functions are used frequently,
> I use them frequently enough to want to add shortcuts for them. I
> imagine the same is likely true for at least some others.
>
>> and the shortcuts proposed are more appropriate for editing a document or database.
> Okay? So? I do not understand what this implies.

Some are reminiscent of browsing or word processing: Ctrl+N, New
document. Del/Backspace, remove info. Ctrl+C, copy.

As Esc is often used to stop something in a wide array of program types
(and is intentionally inconsistent with other shortcuts), it seems
appropriate to stop VMs. Its small and far away from frequently-used
keys, so with qualifier seems appropriate.

>> What would be TRULY useful is a global shortcut to shutdown the VM of the
>> active window. That would save a great deal of mousing effort. I think it
>> can be done easily in KDE shortcuts, but it would be nice to have for all
>> DEs.
> I find myself closing all VM windows before shutting down the VM out of habit.

With file managers, terminals, document editors, I finish and find
myself wishing I didn't have to go back to QM to shutdown the VM. Excess
running VMs has been an issue with Qubes in general.

> If we agree this is a good idea, and identify a suitable shortcut,
> then I believe the right place to do this is in the gui daemon,
> similarly to how Ctrl+Shift+{C,V} are done currently, and this would
> be DE-agnostic.
>
> Then it comes down to identifying a shortcut which would be suitable
> and acceptably non-conflicting.
>
> The simplest things are often the most controversial... :/
>
> I proposed earlier [1] that I think it would be a good idea to
> dedicate an entire modifier key to qubes itself. This would allow us
> to have a guaranteed-collision-free shortcut namespace, as well as be
> able to make keystrokes starting with this modifier invisible to
> AppVMs. I think it is reasonable to expect users to be able to select
> a suitable such key on their respective keyboard layouts. Choosing a
> default such key is again controversial. [1]
>
> [1]: https://github.com/QubesOS/qubes-issues/issues/881#issuecomment-262648022
> [2]: https://github.com/QubesOS/qubes-issues/issues/881

I like the general idea of a global Qubes shortcut, something like
VMware or Vbox use. Even just something that brings QM (or its
successor) to the current screen/focus is good.

>> Additionally, some global shortcut to Pause/Unpause VMs may be quite useful
>> to certain users who examine the behavior of software.
> Can you elaborate on who would use this? and why?

Definitely thinking about technical users here: Analysis of traffic,
malware, etc. Maybe an option that could be enabled.

>
>> As for adding features to Qubes Manager, that may be moot. There is supposed
>> to be a feature freeze on QM.
> Uhh, first I've heard of this... I've made ~10 changes to it in the last month.

Yes, I noticed some already. I don't understand why they are letting
changes through now. QM is supposed to be moribund. I've seen comments
from staff saying changes should wait for the new stuff.

>
> I am aware of the impending rewrite, but do not see why this should
> prevent quality-of-life improvements to the existing one in the mean
> time.
>
>
> In any case, I've quite likely spent more time discussing this now
> than all users collectively are likely to save pressing keyboard
> shortcuts instead of using the mouse. Ah priorities...
> https://xkcd.com/1205/ :)

If nothing else, smoother workflow and less halting of thought process
would be worth it. One thing that impressed me about OS X is how every
tool has strategically placed keyboard shortcuts.

Chris

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Dec 21, 2016 at 12:40:35AM -0500, Chris Laprise wrote:
> On 12/20/2016 09:10 PM, Jean-Philippe Ouellet wrote:
> > On Tue, Dec 20, 2016 at 4:14 PM, Chris Laprise <tas...@openmailbox.org> wrote:
> > > What would be TRULY useful is a global shortcut to shutdown the VM of the
> > > active window. That would save a great deal of mousing effort. I think it
> > > can be done easily in KDE shortcuts, but it would be nice to have for all
> > > DEs.
> > I find myself closing all VM windows before shutting down the VM out of habit.
>
>
> With file managers, terminals, document editors, I finish and find myself
> wishing I didn't have to go back to QM to shutdown the VM. Excess running
> VMs has been an issue with Qubes in general.

https://github.com/QubesOS/qubes-issues/issues/832 ?
I have a PoC for this, will post soon.

> > > As for adding features to Qubes Manager, that may be moot. There is supposed
> > > to be a feature freeze on QM.
> > Uhh, first I've heard of this... I've made ~10 changes to it in the last month.
>
> Yes, I noticed some already. I don't understand why they are letting changes
> through now. QM is supposed to be moribund. I've seen comments from staff
> saying changes should wait for the new stuff.

Qubes 3.2 is going to be supported for at least a year. While we're not
planning any improvements to QM ourself, we do accept changes (if not
breaking/removing existing functionality).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYWnBcAAoJENuP0xzK19csV88H/2c4h3Mut1mTavJXaUvTplUl
NV026bwa04VSageMtzBQarBUYg+moCBLK0230Vm7YWKu5eIzhycDPzTrAtwa4GH6
At+b3U01Jf9HVCzsHRCVCdQYZMhdLFzbhfHQshPOS8ebIZYv2vGoESkwiHAsR2Vk
J74qL8IolkZkA1foX8+Bui/V5sqgyf9x+U8W2ezO5vUr7Dqhr+EI+HiOv5FlGr9R
sx4YzI0fUe7Sqv+ryODy1F5MRAKtj3SSnMndB5Z+2AXglzAaBkaS4Uzef0Cw4H0V
1GZGz86K5gxPSJxxWVSoPfYYDWnYn/1CfTvaTF4IWcOUgNolgwyMZXqxQTg4NFM=
=5RIJ
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

On Wed, Dec 21, 2016 at 12:40 AM, Chris Laprise <tas...@openmailbox.org> wrote:
> On 12/20/2016 09:10 PM, Jean-Philippe Ouellet wrote:
>> On Tue, Dec 20, 2016 at 4:14 PM, Chris Laprise <tas...@openmailbox.org>

>>> and the shortcuts proposed are more appropriate for editing a document or
>>> database.
>>
>> Okay? So? I do not understand what this implies.
>
> Some are reminiscent of browsing or word processing: Ctrl+N, New document.
> Del/Backspace, remove info. Ctrl+C, copy.

I acknowledge that this is the case, and still do not see what
actionable difference it makes. Yes, we are using things people are
likely to already be familiar with from other contexts. To me that
sounds like a good thing. Are you saying it is not?

> As Esc is often used to stop something in a wide array of program types (and
> is intentionally inconsistent with other shortcuts), it seems appropriate to
> stop VMs. Its small and far away from frequently-used keys, so with
> qualifier seems appropriate.

Esc currently closes the modal per-vm settings dialogues. I press it
for that purpose, and I imagine others do too. To have it overloaded
to also mean "stop vm" would be surprising and unintuitive. I do not
like it. If anything I think we should make Esc close the top window
too, and not overload it with any different behavior based on
modifiers.

> With file managers, terminals, document editors, I finish and find myself
> wishing I didn't have to go back to QM to shutdown the VM. Excess running
> VMs has been an issue with Qubes in general.

I think a keyboard shortcut is a very poor solution to that underlying
problem from a UX perspective.

I think https://github.com/QubesOS/qubes-issues/issues/832 is a better approach.

> I like the general idea of a global Qubes shortcut, something like VMware or
> Vbox use.

> Even just something that brings QM (or its successor) to the
> current screen/focus is good.

Note that a Qubes-reserved modifier and a shortcut to bring up QM are
distinct. The latter may use the former, but the former certainly has
other uses as well.

>>> Additionally, some global shortcut to Pause/Unpause VMs may be quite
>>> useful
>>> to certain users who examine the behavior of software.
>>
>> Can you elaborate on who would use this? and why?
>
> Definitely thinking about technical users here: Analysis of traffic,
> malware, etc. Maybe an option that could be enabled.

Okay. My proposed PR had Ctrl+P for pause. We can keep that.

> Yes, I noticed some already. I don't understand why they are letting changes
> through now. QM is supposed to be moribund. I've seen comments from staff
> saying changes should wait for the new stuff.

¯\_(ツ)_/¯

IMO I've spent too much time on these minor cosmetic improvements
already. I'd like to get back to auditing stuff.

[Chris Laprise]

On 12/21/2016 07:06 AM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Wed, Dec 21, 2016 at 12:40:35AM -0500, Chris Laprise wrote:
>> On 12/20/2016 09:10 PM, Jean-Philippe Ouellet wrote:
>>> On Tue, Dec 20, 2016 at 4:14 PM, Chris Laprise <tas...@openmailbox.org> wrote:
>>>> What would be TRULY useful is a global shortcut to shutdown the VM of the
>>>> active window. That would save a great deal of mousing effort. I think it
>>>> can be done easily in KDE shortcuts, but it would be nice to have for all
>>>> DEs.
>>> I find myself closing all VM windows before shutting down the VM out of habit.
>>
>> With file managers, terminals, document editors, I finish and find myself
>> wishing I didn't have to go back to QM to shutdown the VM. Excess running
>> VMs has been an issue with Qubes in general.
> https://github.com/QubesOS/qubes-issues/issues/832 ?
> I have a PoC for this, will post soon.

I still prefer my #2 suggestion there: If apps shutdown with a Ctrl+Q
shortcut, then a Ctrl+Alt+Q or similar shortcut to shutdown the VM would
make a lot of sense.

When users start encountering VMs automatically shutdown as soon as they
begin to switch back to them--even if on occassion--they'll disable the
flag for automatic idle shutdown on all their VMs. Even if they had set
them manually to begin with, that means the modification to Qubes didn't
help.

Think of a VM as a *runtime environment*. If Java or .Net automatically
shutdown due to their running apps being idle, you would be sitting
there right now wondering what these obscure "Java" and ".Net" thingies
were. Its "very unorthodox", probably in the sense that its not going to
help except in niche cases (like shutting down unused proxyVMs, which
consume a lot less RAM to begin with).

Chris

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Dec 21, 2016 at 10:59:29AM -0500, Chris Laprise wrote:
> On 12/21/2016 07:06 AM, Marek Marczykowski-Górecki wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > On Wed, Dec 21, 2016 at 12:40:35AM -0500, Chris Laprise wrote:
> > > On 12/20/2016 09:10 PM, Jean-Philippe Ouellet wrote:
> > > > On Tue, Dec 20, 2016 at 4:14 PM, Chris Laprise <tas...@openmailbox.org> wrote:
> > > > > What would be TRULY useful is a global shortcut to shutdown the VM of the
> > > > > active window. That would save a great deal of mousing effort. I think it
> > > > > can be done easily in KDE shortcuts, but it would be nice to have for all
> > > > > DEs.
> > > > I find myself closing all VM windows before shutting down the VM out of habit.
> > >
> > > With file managers, terminals, document editors, I finish and find myself
> > > wishing I didn't have to go back to QM to shutdown the VM. Excess running
> > > VMs has been an issue with Qubes in general.
> > https://github.com/QubesOS/qubes-issues/issues/832 ?
> > I have a PoC for this, will post soon.
>
>
> I still prefer my #2 suggestion there: If apps shutdown with a Ctrl+Q
> shortcut, then a Ctrl+Alt+Q or similar shortcut to shutdown the VM would
> make a lot of sense.

It may be a surprise to you, but not every application can be closed
with Ctrl+Q ;) And even if that's the case, it may want to ask some
final question ("Do you want do save this file?") and/or actually save
some data. So shutting down a VM when you choose to close some
application there, may not be the best option. Some solution for this
would be waiting for the application you choose to close actually
terminate. And here we're back to my solution.

> When users start encountering VMs automatically shutdown as soon as they
> begin to switch back to them--even if on occassion--they'll disable the flag
> for automatic idle shutdown on all their VMs. Even if they had set them
> manually to begin with, that means the modification to Qubes didn't help.

Well, you can adjust it, change criteria, change timeout etc. This is
exactly why I want to first have it opt-in and collect feedback.

> Think of a VM as a *runtime environment*. If Java or .Net automatically
> shutdown due to their running apps being idle, you would be sitting there
> right now wondering what these obscure "Java" and ".Net" thingies were.

Actually, if you close Java application, its runtime environment is also
gone. And in most cases you don't have an easy option to keep it alive.
And I think this is very accurate comparison - VM is in fact a runtime
environment for an application. I can easily envision a VM running just
Java Virtual Machine _instead of_ Linux - something like this doesn't
exist right now, but it's very valid idea.

> Its
> "very unorthodox", probably in the sense that its not going to help except
> in niche cases (like shutting down unused proxyVMs, which consume a lot less
> RAM to begin with).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYWq4gAAoJENuP0xzK19csIOgH/2sqMDJmG30EoPwlb3QmDEFS
0sTWooy0Fhsz4SXaesdHUzXx7BqxMdDwLca0TFVcz79PE7NoK7MYAB0sUVc492b0
UgQeTjVfK8wc+JoIas9LWRzbJlW7+V0wSE+Y02QY6KQU8xKycREH0NF9FpINnbkW
HAbW8pChlwZVeojuej9cV+gYRoI1NxgU3Iatjsuevuxux9UXXLIC28eVvNXaop54
uIlnlEkQQrxLH4FKdF9XW9GfUpW0RdnKKvndjrIm12JLPMJFW4m1hRHNoLZ6590i
7Pcy1r3DTO5hsgzwCDTkCcLCqGTSlPC2eK3dcyZA5I9RN6LIIENabQhBGpF4XQs=
=j+13
-----END PGP SIGNATURE-----

[Chris Laprise]

On 12/21/2016 10:12 AM, Jean-Philippe Ouellet wrote:
> On Wed, Dec 21, 2016 at 12:40 AM, Chris Laprise <tas...@openmailbox.org> wrote:
>> On 12/20/2016 09:10 PM, Jean-Philippe Ouellet wrote:
>>> On Tue, Dec 20, 2016 at 4:14 PM, Chris Laprise <tas...@openmailbox.org>
>>>> and the shortcuts proposed are more appropriate for editing a document or
>>>> database.
>>> Okay? So? I do not understand what this implies.
>> Some are reminiscent of browsing or word processing: Ctrl+N, New document.
>> Del/Backspace, remove info. Ctrl+C, copy.
> I acknowledge that this is the case, and still do not see what
> actionable difference it makes. Yes, we are using things people are
> likely to already be familiar with from other contexts. To me that
> sounds like a good thing. Are you saying it is not?

How often are VMs created? Maybe Ctrl+N would be appropriate.
Del/Backspace, Ctrl+C, Spacebar... No.

A list of VirtualBox shortcut keys:
http://kbmode.com/windows/virtualbox-keyboard-shortcuts/

There are a lot, and all but the Help function use modifiers. Since
Qubes' UI is in flux, I suggest defining small numbers of them for any
given point release.

>> As Esc is often used to stop something in a wide array of program types (and
>> is intentionally inconsistent with other shortcuts), it seems appropriate to
>> stop VMs. Its small and far away from frequently-used keys, so with
>> qualifier seems appropriate.
> Esc currently closes the modal per-vm settings dialogues. I press it
> for that purpose, and I imagine others do too. To have it overloaded
> to also mean "stop vm" would be surprising and unintuitive. I do not
> like it. If anything I think we should make Esc close the top window
> too, and not overload it with any different behavior based on
> modifiers.

I think its less confusing to use a combo like Ctrl+Esc than anything
that uses Spacebar--to shutdown a VM. But maybe a letter combo is
better. VBox uses Host+Q.

>
>> With file managers, terminals, document editors, I finish and find myself
>> wishing I didn't have to go back to QM to shutdown the VM. Excess running
>> VMs has been an issue with Qubes in general.
> I think a keyboard shortcut is a very poor solution to that underlying
> problem from a UX perspective.
>
> I think https://github.com/QubesOS/qubes-issues/issues/832 is a better approach.

OTOH, its common practice to offer a shortcut key for stopping VMs, as
VBox and VMWare Workstation do. Inactivity timers... I've yet to see
that for a desktop runtime environment (essentially what an AppVM is). I
think that's because its just better UX to have the user exercise their
intention on a case by case basis for this function.

>
>> I like the general idea of a global Qubes shortcut, something like VMware or
>> Vbox use.
>> Even just something that brings QM (or its successor) to the
>> current screen/focus is good.
> Note that a Qubes-reserved modifier and a shortcut to bring up QM are
> distinct. The latter may use the former, but the former certainly has
> other uses as well.
>
>>>> Additionally, some global shortcut to Pause/Unpause VMs may be quite
>>>> useful
>>>> to certain users who examine the behavior of software.
>>> Can you elaborate on who would use this? and why?
>> Definitely thinking about technical users here: Analysis of traffic,
>> malware, etc. Maybe an option that could be enabled.
> Okay. My proposed PR had Ctrl+P for pause. We can keep that.
>
>> Yes, I noticed some already. I don't understand why they are letting changes
>> through now. QM is supposed to be moribund. I've seen comments from staff
>> saying changes should wait for the new stuff.
> ¯\_(ツ)_/¯
>
> IMO I've spent too much time on these minor cosmetic improvements
> already. I'd like to get back to auditing stuff.

See Marek's comment upthread. It could be my memory playing tricks on
me... :)

Chris

[Chris Laprise]

Doesn't surprise me at all. :)

My proposal is simply to save the step of switching to QM... clicking on
the small 'Q' in systray, looking through the screenful of VMs, click
one, move mouse to toolbar or right-click-find-option-in-middle. Its
annoying.

OTOH, I already know how to make my apps Save. I can press Ctrl+S in
kate or Thunderbird before I use a combo like RControl+H to shutdown the
VM--What VirtualBox uses. It allows me to get it done quickly and
mindfully, without the aggravation of unintended shutdowns.

Going further, the shutdown process could be made contingent on the
currently-focused window closing. This makes sense, since the VM
identity is derived from the window as well.

>
>> When users start encountering VMs automatically shutdown as soon as they
>> begin to switch back to them--even if on occassion--they'll disable the flag
>> for automatic idle shutdown on all their VMs. Even if they had set them
>> manually to begin with, that means the modification to Qubes didn't help.
> Well, you can adjust it, change criteria, change timeout etc. This is
> exactly why I want to first have it opt-in and collect feedback.
>
>> Think of a VM as a *runtime environment*. If Java or .Net automatically
>> shutdown due to their running apps being idle, you would be sitting there
>> right now wondering what these obscure "Java" and ".Net" thingies were.
> Actually, if you close Java application, its runtime environment is also
> gone. And in most cases you don't have an easy option to keep it alive.
> And I think this is very accurate comparison - VM is in fact a runtime
> environment for an application. I can easily envision a VM running just
> Java Virtual Machine _instead of_ Linux - something like this doesn't
> exist right now, but it's very valid idea.

I guess I'm not comfortable with the idea of equating "open windows"
with "running application". Its a stretch.

But beyond that, I believe the occasional "UX Interruptus" of shutting
down while user tries to run an app will lead most people who try it to
eventually disable it.

Chris

[Jean-Philippe Ouellet]

On Wed, Dec 21, 2016 at 12:10 PM, Chris Laprise <tas...@openmailbox.org> wrote:
> How often are VMs created?

Personally? At least daily. And deleted nearly as often.

I try to use a separate VM for each project I work on that has a
different set of trusted 3rd parties, and find myself wanting
something like DispVMs but with short-term (~several day) persistence.

> Maybe Ctrl+N would be appropriate. Del/Backspace,
> Ctrl+C, Spacebar... No.

So these shortcuts are inappropriate here simply because they remind
you of a different type of application? If they make sense here, who
cares what else they remind someone of? Call me thick, but I still
don't get it...

> A list of VirtualBox shortcut keys:
> http://kbmode.com/windows/virtualbox-keyboard-shortcuts/

They have a ton of them, and "which keys are still unbound?" likely
played a large role in their assignment. IMO their results should not
motivate our decision here.

> There are a lot, and all but the Help function use modifiers. Since Qubes'
> UI is in flux, I suggest defining small numbers of them for any given point
> release.

Agreed, which is why I'm only targeting the ones I expect are most used.

> I think its less confusing to use a combo like Ctrl+Esc than anything that
> uses Spacebar--to shutdown a VM. But maybe a letter combo is better. VBox
> uses Host+Q.

According to the thing you linked, they use Host+H, and Host+Q for
"Close" (presumably closing a window).

What about Ctrl+S for [S]hutdown? (/ [S]top)

> OTOH, its common practice to offer a shortcut key for stopping VMs, as VBox
> and VMWare Workstation do. Inactivity timers... I've yet to see that for a
> desktop runtime environment (essentially what an AppVM is). I think that's
> because its just better UX to have the user exercise their intention on a
> case by case basis for this function.

There are *MANY* ways in which Qubes is different (better) than the
more traditional (primitive) VM managers. We are a whole integrated
desktop experience, not merely a way to run VMs. I think it's only
natural that some things make sense for Qubes and not for those other
softwares with quite different use cases.


Anyway, enough bikeshed painting. It's just keyboard shortcuts...

Unless someone very seriously disagrees, I propose we proceed with the
plan proposed at the top of the thread with the following differences:
1. remove shortcut for Start VM
2. add Ctrl+P for Pause VM
3. something not-space for Shutdown (Ctrl+S?)

And move the auto-shutdown / shutdown-current-VM discussion to a
different thread, because it is a different problem. Here's a
shutdown-focused-vm PoC [1] based on my open-terminal-in-focused-vm
script [2]. Just bind it to whatever keystroke you want using your
favorite mechanism for doing so is. Xfce provides a suitable
convenient one already.

[1]: https://gist.github.com/jpouellet/d57fb4e98ca3f5ad4ac0ec2596d18154
[2]: https://gist.github.com/jpouellet/0f74459699433cabc26c389caf36b455

[Unman]

> --

I feel like I'm intruding on a personal quarrel here, but there's a
bikeshed in need of some paint.

So - I like keyboard shortcuts: I use them all the time using the
Meta key. I don't use Qubes Manager much, so mine are based on Xfce and
custom scripts/commands.

That said, I think the proposed actions are sensible, but the proposed
shortcuts are not. This isnt because they remind me of some other
application, but because they are ALREADY USED in other applications.

In my experience, "naive" users of qubes get the hang of it quite
quickly, but still will sometimes find themselves typing in to the wrong
window. If this has never happened to you then you are better than me.
The problem with using shortcuts that already have a place in the
lexicon is that it would be relatively easy for them to be grabbed by
the Manager window instead of the intended target window, with obvious
unexpected consequences.

That's why I would strongly advocate the use of a Qubes specific key,
like Virtualbox does.
Can I suggest that you take advice from one of the UX folk before you
take a final decision?

unman

[Jean-Philippe Ouellet]

On Wed, Dec 21, 2016 at 6:02 PM, Unman <un...@thirdeyesecurity.org> wrote:
> I feel like I'm intruding on a personal quarrel here,

Err... I hope that's not how it appears.

Ultimately I want Qubes to be better. If I am taking things in the
wrong direction, I would certainly like to know!

> but there's a bikeshed in need of some paint.

:)

> So - I like keyboard shortcuts: I use them all the time using the
> Meta key. I don't use Qubes Manager much, so mine are based on Xfce and
> custom scripts/commands.

How do you do routine shutting down, etc.?

> That said, I think the proposed actions are sensible, but the proposed
> shortcuts are not. This isnt because they remind me of some other
> application, but because they are ALREADY USED in other applications.
>
> In my experience, "naive" users of qubes get the hang of it quite
> quickly, but still will sometimes find themselves typing in to the wrong
> window. If this has never happened to you then you are better than me.
> The problem with using shortcuts that already have a place in the
> lexicon is that it would be relatively easy for them to be grabbed by
> the Manager window instead of the intended target window, with obvious
> unexpected consequences.

Forgive me, but I'm having trouble understanding this argument.

It appears to me that this argument applies equally to all
applications as opposed to just QM. Yet, it is simply impossible for
all applications to choose unique keys because there are only so many
keys... So, why should QM try to choose obscure and unique shortcuts
whereas other applications do not. (Or... do they and I've just never
noticed?)

I'm not trying to disagree or reject your feedback, I just don't
understand why it's QM's concern.

I think this discussion is worthwhile as the concept applies equally
to the selection of keyboard shortcuts in the new QM as well.

> That's why I would strongly advocate the use of a Qubes specific key,
> like Virtualbox does.

I am completely in favor of a qubes-reserved modifier too, and not
just in the context of this proposal. Perhaps that should be addressed
first and we table this proposal in the mean time?

> Can I suggest that you take advice from one of the UX folk before you
> take a final decision?

Sure. Who should be pinged? Still @bnvk?

[Unman]

On Wed, Dec 21, 2016 at 06:46:30PM -0500, Jean-Philippe Ouellet wrote:
> On Wed, Dec 21, 2016 at 6:02 PM, Unman <un...@thirdeyesecurity.org> wrote:
> > I feel like I'm intruding on a personal quarrel here,
>
> Err... I hope that's not how it appears.
>
> Ultimately I want Qubes to be better. If I am taking things in the
> wrong direction, I would certainly like to know!
>
> > but there's a bikeshed in need of some paint.
>
> :)
>
> > So - I like keyboard shortcuts: I use them all the time using the
> > Meta key. I don't use Qubes Manager much, so mine are based on Xfce and
> > custom scripts/commands.
>
> How do you do routine shutting down, etc.?

I have meta+Q mapped to close window: on the deskop this triggers the
Logout prompt window, so Tab gets to Shut Down.

If you meant shutting down of qubes, then I tend not to do this: I tend to
keep them about until I need them. I do have a script to kill the VM of
the active window, mapped to Meta+1, for the odd occasions when I want
to kill a qube.

>
> > That said, I think the proposed actions are sensible, but the proposed
> > shortcuts are not. This isnt because they remind me of some other
> > application, but because they are ALREADY USED in other applications.
> >
> > In my experience, "naive" users of qubes get the hang of it quite
> > quickly, but still will sometimes find themselves typing in to the wrong
> > window. If this has never happened to you then you are better than me.
> > The problem with using shortcuts that already have a place in the
> > lexicon is that it would be relatively easy for them to be grabbed by
> > the Manager window instead of the intended target window, with obvious
> > unexpected consequences.
>
> Forgive me, but I'm having trouble understanding this argument.
>
> It appears to me that this argument applies equally to all
> applications as opposed to just QM. Yet, it is simply impossible for
> all applications to choose unique keys because there are only so many
> keys... So, why should QM try to choose obscure and unique shortcuts
> whereas other applications do not. (Or... do they and I've just never
> noticed?)
>
> I'm not trying to disagree or reject your feedback, I just don't
> understand why it's QM's concern.

I think the difference is that QM operates at a level above the qube- it
appears to be a window like those of qubes, but it controls and
modifies the behaviour of qubes. Other windows dont do this.
That's why I favour the use of a Qubes specific key: as you do.

>
> I think this discussion is worthwhile as the concept applies equally
> to the selection of keyboard shortcuts in the new QM as well.
>
> > That's why I would strongly advocate the use of a Qubes specific key,
> > like Virtualbox does.
>
> I am completely in favor of a qubes-reserved modifier too, and not
> just in the context of this proposal. Perhaps that should be addressed
> first and we table this proposal in the mean time?
>
> > Can I suggest that you take advice from one of the UX folk before you
> > take a final decision?
>
> Sure. Who should be pinged? Still @bnvk?
>

yes, I think so.