Annoying app menu behavior

Johnboy · July 17, 2025, 2:06am

There is one annoying thing about the new app menu that annoys me since the beginning:
Whenever i start a VM and there are states changing of other VMs in the background, the focus of the mouse gets lost. Meaning: I want to click a link e.g. Terminal, Firefox, … but I have to wait until the VMs in the background settle (starting, shutting down) because it’s simply not possible.
E.g. try to run qubes-vm-update and try to launch a dispVM. It’s simply not possible but to wait until the VMs started.

fsflover · July 17, 2025, 2:47pm

Is this what you mean?

github.com/QubesOS/qubes-issues

Keep app menu open and in foreground while other windows open

opened 04:37PM - 25 Nov 23 UTC

closed 02:11PM - 26 Nov 23 UTC

jimi3

ux C: desktop-linux-xfce4 P: default C: app menu R: self-closed

If it is in any way possible keep the Q Menu open after clicking on Q, don’t let… any new windows that are popping up close the Q Menu, open them though in background behind the Menu. What happens, example: 1. Start Program A which loads AppVM 2. Click Q Menu and search for the other Application 3. Now once A pops up it shuts down Q Menu (not fun) Q Menu needs to be resilient and stay up.

This also might be relevant:

github.com/QubesOS/qubes-issues

Hard/impossible to give keyboard focus to override_redirect window opened while another VM was focused

opened 10:52AM - 13 Sep 16 UTC

rustybird

C: desktop-linux C: gui-virtualization ux P: default needs diagnosis affects-4.2

#### Qubes OS version: - R3.1 with KDE (every "focus stealing prevention" level)… - R3.2-rc3 with Xfce4 --- If an undecorated window (i.e., using override_redirect) is opened from a VM while a window from a different VM is focused, clicking on the undecorated window is not enough to give it keyboard focus: - Case A, the undecorated window is reading keyboard input by grabbing the VM's keyboard. In this case, the user has to focus _another_ (non override_redirect) window in that VM to make keyboard input arrive. This can e.g. break [dmenu](http://tools.suckless.org/dmenu/). - Case B, the undecorated window is reading keyboard input by requesting focus explicitly. In this case, there does not seem to be any way the user can give it focus at all. ### Steps to reproduce the behavior: For testing, I've used a Python script that opens an override_redirect window and prints all X11 events to the terminal: https://gist.github.com/rustybird/6dd826a990c643609519e63c61482e63 1. Minimize all windows belonging to the VM, except for one terminal. 2. Run `sleep 10; ./window.py` in the terminal. 3. Focus a window from another VM before the popup appears. 4. Move the pointer to the popup without traveling through the terminal. 5. Click on the popup. The popup window will receive mouse clicks, but no keyboard input.

Johnboy · July 23, 2025, 8:39am

Hi,
I don’t think so.

Picture 1:

Mouse cursor (missing) is on “Firefox”. I can click it. VM fires up. All good.

Picture 2:

While the dispVM from Picture 1 in the background fires up, I want to open another dispVM with Firefox. Mouse cursor (not visible) is on “Firefox” (same as in Picture 1). But the VM from Picture 1 changed from prepare/start to started. It seems the app menu is dynamic, in this case the focus of the mouse cursor got lost and I cannot click on “Firefox” anymore since it vanished (should look as on Picture 1 with the blue background).

This is a bit annoying when handling several VMs at once.
The old app menu was static (IIRC), so this didn’t happen before.