My GUI ideas from Qubes OS Summit 2025

General Discussion
1

Hello,

some ideas came to my mind at the Qubes OS Summit 2025 at the talk “The Future Of Qube Manager: Design Session” by Marta “marmarta” Marczykowska-Górecka and Christopher Hunter. I don’t know if Marta has written down my ideas already somewhere else. That’s why I’m posting them here for discussion.

My first idea is: A right-click on the title bar (or a dedicated button on the title bar) of a qube’s window opens the normal window menu but that menu also contains buttons for all devices that can be attached to that qube or detached from that qube. A simple click on one of those button does the desired action.

My second idea is: A global keyboard shortcut triggers a “meta qube” view to at least the currently focused qube: Instead of showing the normal window content, the window shows information like CPU usage and memory usage, but also shows buttons for attaching/detaching USB devices. In general, everything that could be interesting for the user in interaction with that qube should be visible. After hitting the same global keyboard shortcut, the normal window content reappears.

What do you think? @marmarta

Best regards,
tokideveloper

2 Likes
2

Since we have enough space within a window, the buttons for attaching/detaching USB devices could be enriched with a lot of meta information for identifying the correct USB device, for example:

  • webcam: the current video (maybe on demand)
  • microphone: amplitude meter (maybe also on demand)
  • data storage: tree view of partitions (like this via lsblk)
  • in general: all information already shown in the Qubes Device Widget
  • also in general: a timestamp when the device has been attached to the computer (this is not my idea, I just got it by someone else)
1 Like
3

I am not Marmarta but I can comment on the above. It is doable. But a little bit hard. This has to be done per DE (XFCE, Plasma, …). The patches should go to:

And then finally the menu could be PyGTK or PyQt. I believe it won’t be needed/liked by i3 users. So we could pass on i3. It would be also a little bit in the way of Wayland migration.

This is also doable. Using X11’s _NET_ACTIVE_WINDOW and from there we have our custom _QUBES_VMNAME hint. Again this would not be Wayland friendly and it would be necessary to find the Wayland alternative for later migration.

1 Like
4

Thank you, Ali, for your reply!

I am not Marmarta but […]

This discussion shall be open to everyone. :slight_smile:

Wayland has already been mentioned at the Summit as an obstacle. Another (Wayland-friendly?) way could be (triggered by the mentioned global keyboard shortcut) to just open a normal, centered dom0 window showing the mentioned qube-related information and device actions. Having such a normal (dom0) window could also solve the problem with too small (domU) windows.

1 Like
5

This is true right now, but may not be the case in the future. IF the Wayland version of gui-daemon will use client-side-decoration (instead of relying on window manager / compositor to draw them), we’ll have much more control over the title bar and its menu.

2 Likes
6

I just discussed with a friend of mine and he proposed yet another idea:

There shall be a Device-Widget-like tray icon button in the color of the qube in focus. When pushing that button, a Device-Widget-like menu appears but without submenus for selecting a qube. Instead, the qube in focus is used as the implicitly selected qube. Of course, the submenu should have the name (and color) of that qube on top for verification.

What do you think?

7

There shall be a Device-Widget-like tray icon button in the color of the qube in focus. When pushing that button, a Device-Widget-like menu appears but without submenus for selecting a qube. Instead, the qube in focus is used as the implicitly selected qube. Of course, the submenu should have the name (and color) of that qube on top for verification.

Addition:

The menu should have three or four sections:

  1. Devices not attached but attachable to the qube in question (a click attaches the device)
  2. Devices attached to and detachable from the qube in question (a click detaches the device)
  3. Devices attachable to the qube in question but currently attached to other qube(s) (not clickable, just for information!)
  4. Devices not attachable due to policy (not clickable, just for information)
8

I think there are some interesting ideas here, but I could add a lot of other things I wish for in a title-bar context menu… maybe it would be interesting to make your post title be “What do you wish to do with a right click …?”

Here are some (vague and confused) ideas that fall out of my brain:

  • For devices, I would prefer a sub-menu. It would be busy with a lot of devices.
  • Another submenu for “change NetVM”, but only for some templates/appvm/disps. An option to prevent to change - to lock- NetVM (maybe needs some special policy).
  • A list of windows for this VM, with click to switch to and raise one, or all of them.
  • Run another application in this VM.
  • Open terminal in this VM
  • Access Settings for this qube.
  • “Arbitrary prompt xyz”: with an action. For example, prompt is “Lockdown!” and action is to set NetVM to None and to tag this qube “special tag”, “special tag” means this qube is now in lockdown, it can never have net access again (requires policy).
  • …and probably some more.

There are too many possibilities for a lot of workflows - I would like to have different menu content for different templates/appvm/disps.

Perhaps it would even be an API to configure the menu - with a global default, and possibilities to override (require or prohibit) items, to prevent override, to display only, to allow changes, to hide or display as inactive , if prevented by policy…

To explain why - some motivations :

Sometimes I just use my qubes - the content of one window is enough. Current behaviour is good.

Sometimes I go from window, to Q menu, to qube Settings, to qubes manager, and back and forth. It’s all for one qube, and I could do it all from a single window with enough right-click options, and less chance of a mistake.

Sometimes (my work qubes) I want to say: just don’t show me anything that might make me think outside the ‘work box’. Make it minimal.

Sometimes I want to avoid making mistakes, like “no NetVM change” - but maybe this is better by policy.

Sometimes I make a mistake in a qube, and I want it contained, like “Lockdown!”

Dreams! And it sounds too complicated, but maybe there are some ideas there.

9

OK, I went and watched again the discussion from Berlin.

  • 25 minutes - maybe it is @tokideveloper . Very good point. Certainly close to the above.
  • 33 minutes - can I explain or train my boss or my teenage children how to do this? This is a key question. Does not count if your boss is at Qubes Summit!
  • 46 minutes - YES.
    • There are experts, who fettle and tweak their qubes and their QubesOS. They will never be happy, but they will always find a way to do what they need to do.
    • There are the novices, who are probably quite techy, and will be experts one day. They know how to ask the experts.
    • Lastly, there are regular people - client users. They use whatever they are given, and they need just enough to get their work done, where their work is probably unrelated to infosec, compartmentalization, VMs, and all the rest. Every new keyword and concept they have to learn is an extra obstacle to adoption of QubesOS. But QubesOS can be a way to protect their organisation and them.

Some extra comments, maybe for @marmarta …

For sure, it is necessary to steal the big screens of every developer. I cannot read any of the text of the mock-up. Develop on 1024×768 or less, and scale up, not the other way. (Personal pet-peeve)

I see the world a bit like this:

If there is a task bar, the “tray” part is for global stuff.

For a “power user” there is a lot less global stuff - they are happy messing with NetVM, package installation in templates, and more.

For a “client user”, it is probably an important way to “what is my network?”, “make the music louder”, “turn on the mic and camera so I can do a teams meeting”…

Devices: our main use case is this: I’m working on a doc. “Hey, I need that bit of data on my “off-site” usb key in this presentation !” How do I plug that in, and make that data so it appears right here? Ideas of choosing device or partition, mount points and bash shell are big obstacles here! (I have no answer)

I feel like qubes manager is where I (want to) go only when I really need to hunt among the qubes for some admin reason. Am I still using Fedora 36 anywhere? Which qube has LeakyFirewall as its NetVM? Which one is using 200Gb of disk? It is not where I want my “clients” to have to go.

For the rest of my gang - my clients (Very small non-tech business), I really need an absolutely minimal interface to the available or running qubes. This could allow discovery of the full complexity of Qubes, but it would be really good to be able to fold everything back -really easily- to the minimal view, to make it all less frightening! I think it would be a very useful exercise to find the least informative interface which still gave access, in a progressive way, to the details.

My sincere apologies to @tokideveloper. I have filled their thread with a lot of things I have been sitting on for months. Shall I take them away to a new thread?

10

@phceac and all:

Thank you for your thoughts!

Yes, that’s me at 25 minutes (my first idea). It’s also me at 40 minutes (my second idea).

Now, I watched the talk on YouTube, too. I think, separating qube managing from usage is important as someone said at the summit. So, in my view, a global keyboard shortcut or a right-click on the title bar should only show actions that are for usage, not for managing. And the more often it’s used, the bigger (i.e. easier to access) it should be. :slight_smile:

Concerning right-click:

For devices, I would prefer a sub-menu. It would be busy with a lot of devices.

I agree.

Another submenu for “change NetVM”, but only for some templates/appvm/disps. An option to prevent to change - to lock- NetVM (maybe needs some special policy).

The first idea sounds good. I wouldn’t need the second one, at least not yet.

A list of windows for this VM, with click to switch to and raise one, or all of them.

I don’t know what you mean by “raise”.

Run another application in this VM.

This is a nice idea and I think it could be done using the application finder (global shortcut Alt+F3) with (and this is new) a preselected qube (the qube in focus).

Open terminal in this VM

Also via the application finder. Maybe a default application could be set in the qube’s settings and is preselected when opening the application finder?

Access Settings for this qube.

Also via application finder. But the settings are rather for managing than using that qube.

“Arbitrary prompt xyz”: with an action. For example, prompt is “Lockdown!” and action is to set NetVM to None and to tag this qube “special tag”, “special tag” means this qube is now in lockdown, it can never have net access again (requires policy).

Interesting.

Beyond that:

My sincere apologies to @tokideveloper. I have filled their thread with a lot of things I have been sitting on for months. Shall I take them away to a new thread?

IMHO, content that is related to my ideas can stay here. The other things should be moved to another thread.

11

I like especially the idea of being able to open a terminal this way. (conceivably also a file manager?) With numbered disposables I must note the number and dig it up out of the qui-domains menu (it won’t be anywhere else that I am aware of, certainly not my “main” menu).

2 Likes
12

I like especially the idea of being able to open a terminal this way. (conceivably also a file manager?)

Regarding my second idea, the apps in the Q menu related to the qube in focus could also be shown as button for launching.

With numbered disposables I must note the number and dig it up out of the qui-domains menu (it won’t be anywhere else that I am aware of, certainly not my “main” menu).

Good point!

13

The thread Quick Quality-of-Life Improvements has some examples of using shell scripts to launch applications like terminal or file manager from the active window.

2 Likes