Option to show internal qubes and their dependents (e.g., in App Menu)

[GWeck]

Qubes OS release

R4.2 current weekly build

Brief summary

In Qubes R4.2, the new app menu does not show newly created dispVMs if their template is the default-mgmt-dvm.

Steps to reproduce

Create a new dispVM by right-clicking on some AppVM in the Qube Manager, and select the command Open console in qube. Then open the app menu and look for the dispVM just created and displayed in the Qube Manager.

Expected behavior

The new dispVM should be shown, possibly as some subentry to its dvm template default-mgmt-dvm, like it is the case for dispVMs created from some other dvm template, like fedora-37-dvm.

Actual behavior

The new dispVM is not shown in the app menu.

[andrewdavidwong]

If this is intentional, then it's arguably a UX bug, since the behavior of the system is defying users' expectations without taking appropriate steps to manage their expectations or explain the ostensibly inconsistent behavior.

[marmarta]

default-mgmt-dvm is an internal qube. No internal qubes show in the menu (this or the previous one). I think the problem here is, if anything, showing this qube by default in Qube Manager - internal qubes are not to be touched in general, they do their thing in the background.

[GWeck]

I see - that explains the behavior, but I find it somewhat confusing.

Could a configurable option be provided to show internal qubes and their possible dependants?

[marmarta]

I guess, sure? But this will require some place to put those options, so a bit of UX-design-problem here. Maybe in the global qubes config...

[GWeck]

That's a good, plausible location.

[andrewdavidwong]

default-mgmt-dvm is an internal qube. No internal qubes show in the menu (this or the previous one). I think the problem here is, if anything, showing this qube by default in Qube Manager - internal qubes are not to be touched in general, they do their thing in the background.

Yes, so I think this shows that more UX work may still remain for #6604, because users are still confused about the nature of "internal" qubes. So, they either need to be better hidden (which sounds like the path you're leaning toward) or better explained (in the broad sense of any UX solution that allows users to understand them).

The part about hiding internal qubes in the Qube Manager, specifically, sounds like #8042.

I guess, sure? But this will require some place to put those options, so a bit of UX-design-problem here. Maybe in the global qubes config...

I'll update this issue to describe the enhancement request you're describing, but it might also be worth considering whether this should just be closed as a duplicate of #6604 (and #6604 reopened to pursue a more general UX strategy for dealing with internal qubes, especially if you favor the hiding strategy, which seems like the opposite of this issue post-update).

[GWeck]

Hiding internal qubes could be problematic at least for default-mgmt-dvm because this qube can be the parent of update qubes and the terminal qubes as described above. Are these to be considered internal, too?

• If not, they seem to hang in the air if their parent is hidden.
• If yes, why are there actions performed by something invisible?

So, for me, hiding internal qubes causes more problems than it solves.

[marmarek]

User is not supposed to run any applications in internal qubes manually, so hiding them from the menu makes sense. This applies to both default-mgmt-dvm and any DispVM based on it (for example an update mgmt qube is meant only to run that update, not anything else). They are shown in domains widget (side note: options to run terminal or file manager should be hidden for those, but they currently aren't), so you can see what takes your CPU/memory, and if something goes horribly wrong, you can kill them. But you really shouldn't do anything else with them.

[andrewdavidwong]

User is not supposed to run any applications in internal qubes manually [...] But you really shouldn't do anything else with them.

Yes, but how is the user supposed to know this? The problem is that not enough is done UX-wise to communicate this information to the user. The user is right to question why only these qubes are missing from the App Menu and suspect it's a bug. It seems inconsistent, because there is no indication that these qubes are any different from all the other ones. Maybe we need some kind of special "internal" icon that always appears next to these qubes and has an explanatory tooltip stating that it's an internal qube and explaining what that means and/or a warning that pops up every time the user tries to interact with one of them.

[GWeck]

This looks like two different, conflicting requirements:

• Show internal qubes so that the user won't wonder why there is something doing something hidden and eating resources.
• Hide internal qubes so that the user cannot do something malicious to them.

Both are valid, but contradicting positions. A compromise might be to show them, as you pointed out, in some special way, perhaps greyed out as some sort of inaccessible,l and blocking any attempt to do something with them (except killing them ???).

[marmarta]

Ok, I've now introduced two changes to make this better communicated:

• internal qubes will be filtered out by default in qube manager, but can be shown in the 'View' menu
• they will show up in the qui-domains widget, but the menu will be truncated (just log + shutdown/kill) and have an explicit "Internal qube" label with a tooltip explanation to the tune of "Please don't mess with it if you aren't 100% sure you know what you're doing".

[marmarta]

Ok, I think this can be closed: the internal qubes remain as they are (discouraging users to touch them), but there is a way to kill one in case of problems.