Hello everyone, I had an idea and would like to see what everyone else thinks. Maybe this even gets pushed to the Qubes devs if enough people like it.
The “pitch?”
We all use Qubes for compartmentalizing our daily lives. In an example I will use, I will showcase a person that may or may not represent my use case.
John Smith is a Qubes User. He has a qube for work, a qube for untrusted browsing, and all the other normalitites. However, John likes making qubes. One day he makes many many qubes. A vault qube could turn into three seperate vault qubes, or a web browser qube could become multiple web browser qubes.
Why dont we help make this easier so you dont have a string of qubes laying around. We could make groups, dropdown groups maybe, and inside you could nest qubes. I could click on work as a folder and work-vault, work-browser, work-vpn could all show up. Or maybe you dont want to seperate it like that, maybe you like a folder called “Web Browsers” or “Vaults.” I think this is a cool idea
Thank you much for your response, hopefully they bring it into Qubes 4.2 natively as an install like she hoped. I think that would be wonderful. Have a great day fsflover!
I’d like to see something like this as well. The menu quickly gets very long. As a work around, I usually prefix the name of the appvm, so I get entries grouped together alphabetically.
proj1-browser
proj1-vault
proj1-email
To be fair however, many of my projects or compartments have only a single VM anyway.
This feature would be so amazing to have, but that github post posted over 2 years ago, why is this so hard to develop this kind of things? I’m genuine curious why is it so difficult, because it’s a UI(and a fairy simple) feature. What language do you use for this to be developed?
Reading through the issue on GitHub, my understanding is that the proposal recognizes the potential value of grouping qubes for different purposes, but is explicitly scoped to group qubes for the purpose of organizing them in the “Q menu”.
However, as @unman points out in that conversation, it turns out that such menu grouping can be achieved by customizing the menu via the tools provided by the desktop enviroment (e.g. XFCE how-to, in the XFCE docs, KDE offers similar tools, and any major desktop environment probably does too).
That is not a problem that’s specific to Qubes OS, and the solutions don’t need to be specific to Qubes OS (and they already exist!).
If you use KDE you can already customise the menu, and work with submenus,
dispensing completely with the emphasis on Templates and qubes. It allows
you to organise the menu exactly as you wish, using drag and drop.
So you can (e.g) have a menu item -
Project1 ->
browser
keepasxc
thunderbird
Where each of these applications is run from a different qube.
This functionality has been present in Qubes for a long time, and
provides exactly what @NeverCat was asking for.
I often work with users with such menus, moving the emphasis on HOW
it’s done (Templates/qubes/disposable templates/disposables) to WHAT is done.
For many users this is far more productive.
I’ve noticed that users who have struggled with, and mastered, the
structural elements of Qubes are highly resistant to this approach.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
You can’t (and I’m sure you already know this–but I’ll ramble here for the benefit of others).
For that matter, you can’t run, say, LibreOffice on your LibreOffice qube from the manager either, regardless of how the qubes are organized; so the manager is only useful in certain cases.
I keep my Qubes Manager reasonably well organized by naming AppVms (and disposables) with a capital first letter. That pushes them to the top of the list as compared with a template like “deb11a-libre-office” which has a lower-case letter at the beginning of its name. In fact I go even further than that, the AppVM/DispVM names start with D1 through D7 (D for “domain”) so they will sort by color (1=red, 2=orange…6=purple, 7=gray) as well as being at the top. The latter is probably something most people would find ugly, though–I doubt most would want to do that.
For “runtime” things I also use the KDE menu though I haven’t gone quite as far as Unman has; I still have things grouped by what qube they are on. But templates (and dvm templates that are templates for named dispVMs) are buried in a submenu well away from the AppVMs/DispVMs just so they don’t get in the way; I still have access to them, just not quite as readily. Once a template is built, I almost never need to access it. (Which makes wanting to keep templates away from AppVMs entirely sensible IMHO.)
You can run the command…provided you know exactly what the command is. Sometimes it’s a bit cryptic because it’s expected you’ll click on an icon; and the icon may not have the exact name of the executable. For instance, it’s “LibreOffice” on the icon, but libreoffice on the command line; so it’s possible someone will try typing “LibreOffice”. Maybe their installer puts a soft link in, maybe not.
In any case an icon in a menu is much more convenient than having to type a name in a popup.
(I admit I was totally unaware of “run command in Qube” being there until about a week ago.)
As for my method of organization not working for you, sure. I didn’t expect anyone else would like it; I know I don’t like very many others’ methods. I figure by throwing different ideas out there someone might be helped to think of something that suits them better than what they have today.
The OP is unclear on which qubes he wants to group together, but it sounded functional rather than “templates near their appvms” and I have seen complaints in the past about templates “getting in the way.” I do, on the other hand keep dvm template entries (i.e., the ones that fire up the dvm template itself) near the actual dvm launcher menu entries–this is the one case where the “same” qube will appear, by default, in a menu twice, though it’s not really the same qube. The xfce menu, by the way, does physically separate the two by default if I recall correctly.