zetigu
commented
1 year ago The tag idea is good. While reading the How to organize your qubes I like how the qubes are organized in a schematic. Adding tags would allow forming groups of qubes. Sure a search box could work. Adding a group selection bar on top could also allow to display only cubes matching a certain tag.
But if we want to display things in an organized manner, I thing a collapsible tree view would be great.
For that, adding an other tag sub category for service could allow displaying a tree like structure with collapsible sub element. I currently use a naming convention for my qubes instead of tag.
qube-GroupName
├─ ServiceNameA
├─qube-ServiceA-UniqueIdentifier1
├─qube-ServiceA-UniqueIdentifier2
├─ServiceNameB
├─qube-ServiceB-UniqueIdenfifier1
├─ServiceNameC
....Since I saw some discussion on renaming AppVM to qube, I used it here. On my system, I use tpl- instead of Template as it's shorter and more consistent with qube-.
Also, templates could use the same way to view groups and qubes that are using them.
Template-Name-Version-UniqueIdentifier1
├─GroupeNameA
├─ServiceNameA
├─ServiceNameB
├─ServiceNameC
├─All qubesTaking for example the blog with Carol:
Templates:
tpl-fedora-36-full
├─ qube-web-credit-cards
├─ qube-web-credit-history
tpl-fedora-36-thunderbird
├─ qube-web-email-finance
├─ qube-web-email-personal
├─ qube-web-email-shopping
tpl-fedora-36-minimal
├─ qube-web-banking-companyA
├─ qube-web-banking-companyB
├─ qube-web-banking-companyC
tpl-fedora-36-finance
├─ qube-off-financial-planning
tpl-fedora-36-vault
├─ qube-off-vault-taxes
├─ qube-off-vault-passwordGrouping :
Order by qube name in subgroup | Order by template name in subgroup
qube-GroupName | Template Name
├─ Personal
├─ qube-web-email-finance | Template-Fedora-36-Web-Thunderbird
├─ qube-web-email-personal | Template-Fedora-36-Web-Thunderbird
├─ qube-web-email-shopping | Template-Fedora-36-Web-Thunderbird
├─ qube-web-credit-cards | Template-Fedora-36-Full
├─ qube-web-credit-history | Template-Fedora-36-Full
├─ qube-web-Windows10-taxes-win |
├─ Private
├─ qube-off-vault-taxes | Template-Fedora-36-Vault
├─ qube-off-vault-password | Template-Fedora-36-Vault
├─ qube-off-financial-planning | Template-Fedora-36-Finance
├─Companies
├─ qube-web-banking-companyA | Template-Fedora-36-Minimal
├─ qube-web-banking-companyB | Template-Fedora-36-Minimal
├─ qube-web-banking-companyC | Template-Fedora-36-MinimalAnd you could add template grouping to the previous example when there are more than 3 qubes sharing the same template in a given group.
This could work for the menu and Qube Manager. Note that I use KDE, so a solution portable to multiple window manager would be best. Never know, Qubes-OS might go back to KDE :)
For your example, you could do Metakey, qu->tab->o->tab->ident->va->tab->sup->tab->t->tab->enter
to launch : qube-off-identityA-Vault/terminal.desktop
and
Metakey->ident->tab->B->tab->va->tab->t->tab->enter
for the identityB.
It would be nice to have option to graph the qubes and their interconnections like the images in the blog for easy comprehension of network routes and connections. Would be great for new users or for quick complex system that you setup for a short time use and can't get your head to remember.
@QUser534 does this make sens to your need ? Note that I'm just a user like you :)
How to file a helpful issue
The problem you're addressing (if any)
First, I want to thank you for this great effort. The new app menu is a huge improvement. My favorite thing about it is that it hides / filters qubes from users based on whether you want to see App / Templates / Services qubes.
Hiding irrelevant qube menus is probably the best features because it reduces the mental tax on a person having to see things that they currently are not interested in. It is good design.
problem to solve I think the filtering / hiding can be taken one step further. Many users have a lot of qubes that are used in different contexts. For example, I have several qubes for different "identities" like my personal life, work at Company1, Company2, etc. Each one has a vault for sensitive files for each one along with a general net-connected qube along with some other utility qubes. This is just my setup many other people have different setups. Such as simple a Personal set of qubes along with a Work set of qubes
Improving the filtering will enable all these qubes to be managed better.
The solution you'd like
The solution to this context problem is making the menu filterable on a tag. Each qube can be assigned one or more tags. By default All qubes are shown in the menu. However, a person could select the tag filter to only show "Work" tagged qubes. This would filter out all the various App / Template / Service Qubes by that tag. Each qube can have more than one tag, so for example networking may have all the tags if designed. Upon re-opening the menu it would remember the last filter setting.
The design of it could simply be a like this
Currently you already have the Apps / Templates / Services filters on the menu. This would place a box above each those three filters ("Drop Down Tag Filter Header ") which when clicked would just be a drop-down box where a tag could be selected. When a tag was selected it would alter the visible Apps / Templates / Services.
addendum: in addition to user-defined "tags" the same box could include special tags. Probably the more useful or perhaps only useful tag would be "State: Currently Running". This way ONLY running qubes are visible in the menu. 90% of time (all cases except starting a qube) that is what a user wants, so it would be a useful tag. If you don't want such a "Filter" in the "Tag" box or even if you reject the Tag filter it might be useful to enable Filter by currently running state.
This could even be expanded later to a more comprehensive filtering UI like many menu search boxes have:
This design would create two new filters compared to the current one. "[[Tag Filter]" is the same tag filter drop down box as described in the last section. However, the "search box" would enable filtering the menu display based on the search keywords. So, basically it would filter the menus by both the search text + tag.
Tags would be defined in the normal Qubes Manager. It doesn't need to be anything complex. Simply a "Tags" field that is comma separated list of tags. I imagine stored in the Qubes preference database
The value to a user, and who that user might be
Filtering out content not useful to the current context is very important to reduce mental load. This filtering mechanism based on tags will allow a flexible way for users to define their own Qubes filtering contexts that make sense for their own use-case. A typical and simple one would be assigning "Work / Personal" tags to qubes and therefore when they are in Work-mode not have to see Personal related qubes in the App Menu. This reduces mental burden, reduces mistakes, etc.
Unrelated to this, but if Qubes are assigned tags it also enables more powerful QrExec policies. Just as an example, denying Copy / Pasting between qubes of certain tags ("Personal" tagged qubes cannot paste into "Work" qubes, etc). Not related at the app menu but I just thought I would add that having qubes be taggable could be useful meta-information for other future qubes ideas.