Option to show only active VMs in the Applications Menu

[frozentime345]

The problem you're addressing (if any)
A clear and concise description of the problem, if any, that this enhancement is intended to address.
Too many vms to launch programs from.

Describe the solution you'd like
If you have something in mind, a clear and concise description of what you want to happen. If you don't have something in mind, indicate as much.
A start menu with only active vms(ie similar to the one from the panel) would be cool.

Where is the value to a user, and who might that user be?
Efficiency, anyone.

Which users is this most likely to benefit? What user needs does this address? How might a user summarize this change or new thing?
Those who have a lot of vms

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
I usually just run a terminal from the panel thing and then launch program from there but that creates the issue of having a bunch of terminals open as well as the intended programs.

Additional context
Add any other context or screenshots about the feature request here.

Relevant documentation you've consulted
A list of links to the Qubes documentation (or other relevant software documentation) pages you have already consulted.

Related, non-duplicate issues
A list of links to other bug reports, feature requests, or tasks in the qubes-issues tracker. Do not describe any other unreported bugs, features, or tasks here.

[andrewdavidwong]

This is very closely related to #2646. Currently and historically, the Qube Manager is separate from the Applications Menu, so it makes sense to have these as separate issues, but one can easily imagine one day combining the functions of both, in which case this issue would be merged into that one.

[andrewdavidwong]

Many users use the Applications Menu shortcuts to start VMs. If only active VMs are displayed, how will the user start them?

[frozentime345]

Maybe a keyboard shortcut that opens a dom0 input(i.e similar to filecopy) or just another start menu dedicated just to starting things. the true start menu if u will =p Maybe access the alternate start menu using a keyboard combination like left click + ctrl on the start menu.

[andrewdavidwong]

Maybe a keyboard shortcut that opens a dom0 input(i.e similar to filecopy) or just another start menu dedicated just to starting things. the true start menu if u will =p Maybe access the alternate start menu using a keyboard combination like left click + ctrl on the start menu.

That doesn't sound like it would be very user-friendly. I suspect that most users would not find the key combination discoverable and would get confused by there being two "start menus."

[frozentime345]

Well by default it would be the normal start menu right? Maybe the option for this should include another option to choose the key combination so it's obvious how to use it.

[jpouellet]

Not sure how it'd be implemented without ugly hacks, but having the running VMs listed in a top section of the Q application menu above the full list of VMs would be nice IMO.

The Q application menu is a rather poor experience for me since the list occupies literally 3 or 4 full vertical-screens-full and needs excessive scrolling and looking for the VM I want. (Yes, I heavily compartmentalize and actually have that many VMs.)

Perhaps such a feature should be automatically enabled/disabled based on the number of VMs you have? (might not make sense to duplicate them if you only have, say, 10 VMs)

[jpouellet]

I could also seen an argument for unifying the two Q menus. Perhaps something worth making a PoC and getting user feedback on, idk.

[marmarek]

TBH, with large number of VMs, launcher (alt+f3) + its search function is more convenient.

[brendanhoar]

Maybe add a stub menu item at the top "Search Programs (Alt-F3)" which both indicates the key sequence and also performs the equivalent of hitting the key sequence.

[jpouellet]

Unfortunately, Alt-F3 is rather close to Alt-F4 (close window, for many things) :/

Accidentally hitting the wrong key with focus on e.g. a DispVM browser with lots of tabs can be rather annoying.

Not saying it's a bad idea (i like it in general), just that the default keyboard shortcut is problematic.

It would be nice if we had some window-manager-agnostic solution too.

[andrewdavidwong]

Maybe add a stub menu item at the top "Search Programs (Alt-F3)" which both indicates the key sequence and also performs the equivalent of hitting the key sequence.

Unfortunately, Alt-F3 is rather close to Alt-F4 (close window, for many things) :/

Unless I'm mistaken, these sound like upstream issues.

[brendanhoar]

@andrewdavidwong - are upstream issues that are exacerbated/triggered by being dom0 in Qubes mostly an upstream responsibility or mostly a Qubes responsibility? Honest question, I hope.

With Qubes, regular usage leads to an very large menu tree. As my daily drive, that becomes an extremely large menu tree, esp. if properly cloning VMs and templates for versioning (to checkpoint them before updates/changes), etc.

B

[jpouellet]

Unless I'm mistaken, these sound like upstream issues.

The choice of keyboard shortcut? I suppose so.

esp. if properly cloning VMs and templates for versioning (to checkpoint them before updates/changes)

(off topic, but...) This is probably unnecessary. See revisions_to_keep option of qvm-pool.

[brendanhoar]

esp. if properly cloning VMs and templates for versioning (to checkpoint them before updates/changes)
(off topic, but...) This is probably unnecessary. See revisions_to_keep option of qvm-pool.

(off topic, but...) Ha! I was wondering what that option was. Looks like the value for pool00 on my primary system at the time of installation was 1. TBF, I think I prefer it this way, though.

[andrewdavidwong]

@andrewdavidwong - are upstream issues that are exacerbated/triggered by being dom0 in Qubes mostly an upstream responsibility or mostly a Qubes responsibility? Honest question, I hope.

With Qubes, regular usage leads to an very large menu tree. As my daily drive, that becomes an extremely large menu tree, esp. if properly cloning VMs and templates for versioning (to checkpoint them before updates/changes), etc.

That's a fair question.

The fact that the menu tree is large is not unique to Qubes. There could be many reasons for having a large menu tree on a non-Qubes system. Likewise, there are some Qubes users who have only a few VMs and hence have a small menu tree.

If the Applications Menu widget itself handles large menu trees poorly, I'd think that's an upstream problem. On the other hand, organizing large numbers of Qubes VMs is a Qubes-specific issue (#2646).

[unman]

There came a point where I stopped using the default menu tree. With KDE it's straightforward to customise the Menu - with Xfce, it's not that difficult.
Surely it's not beyond the wit of any user to customise their menus themselves? Honest question.
Do we really need a section in the docs to tell people how to do this? Or point to XFce and KDE tutorials on how to do it? IMO it's only slightly beyond basic use and doesn't seem to have anything Qubes specific to it.

[brendanhoar]

@unman - One way I could read your comment is: Qubes usage overwhelms the utility of the default KDE menu.

[marmarek]

Maybe a solution for large menu is to (optionally?) group not by qube but by application, or application category?
Assumption: Each qube have only few applications added to the menu (email qube has only email client, qube for some web application has only web browser etc).
Then grouping by application would lead to much shorter top level menu - for example there would be "Firefox"/"Chromium"/... menu, with list of web-browser-enabled qubes listed inside.
It could be also done by application category - each application's .desktop file specify a list of categories, as used for grouping in non-qubes use case. We could use it too.
One potential issue with this approach is, categories are controlled by the qube - it is extracted from there together with other metadata about available applications. So, a qube could relocate its applications to a different place in the menu. But there still will be qube name prefix with each entry, this cannot by bypassed (at least we hope so).
On the other hand, it may mean that the second level of the menu will be quite long... For example I have added "Terminal" to every application's menu, so a "Terminal" submenu will list all the qubes.

[unman]

One way I could read your comment is: Qubes usage overwhelms the utility of the default KDE menu.

This seems a bizarre misreading.
It's precisely the utility of the KDE menu that allows easy customisation - easier than with Xfce.

This is undoubtedly one of those personal preferences - some people like huge menus, or desktops with many, many shortcuts. Some dont.
I would much prefer to see users educated in how to organise menus if they want to, rather than attempt to second guess what might be best for them.
My preference, (as I've said many times), is to hide the implementation as much as possible. The default Qubes menu tree brings it to the foreground.

[brendanhoar]

@unman - please forgive my error. I meant to type xfce and not KDE in my comment, which did make what I wrote rather bizarre.

Your comments above are wise and I concur about making it straightforward for users.

Anyway...my failed-to-be-made-well point was that the xfce ALT-F3 application search is one of those "high-utility but not easily discoverable by non-sophisticated users" features that Qubes could give a slight lift to via a menu item, since Qubes is already manipulating menu items. That's all.

Brendan

[andrewdavidwong]

Related: #4005

[ninavizz]

Tagging #5677 as relevant

[marmarek]

This is already covered in the new menu, which has an option to sort running qubes on top.