Dialog sits atop other VM window

[ninavizz]

The way the overlays are currently implemented in the client, is as dialogs. As such, a known Linux quirk that's happening is such that when I click on an sd-dev window, the dialog remains on top of the sd-dev window, from sd-app. When I try to click onto the dialog to type, it only lets me type into the first text field on sd-dev.

This is deeply frustrating. As a user, I need to click on the main VM window for sd-app to be able to enter text into the overlay. While this doesn't "block" users, it's a big drag. Especially for non-Linux users who expect more overlay-y behavior.

Post Beta I'd like to see this fixed, so that the overlays behave like overlays. Even tho I know that's a ton of work in QT... and that a ton of work has already been done, to make the dialogs look like overlays. <3

When I try to use the screenshot tool, it also blocks it.

[sssoleileraaa]

Another problem with the dialog always on top is that the tooltip doesn't show up when you hoverover a truncated filename.

[eloquence]

Here's another screenshot that illustrates the issue Nina is describing:

I actually can't type into the password box, even when clicking into it -- instead it types into the terminal behind it, even after clicking directly into the text input. To be clear, none of these are "Linux quirks", they are just characteristics of the dialogs we've implemented. So this should be tracked as a pretty severe bug in the dialog behavior.

[ninavizz]

Thank you for the clarification on that, @eloquence! Yes, I experienced the same behavior... and from our convo, assumed that was normal for Linux users.

Agreed, the inability to select the correct thing to click into, feels very problematic.

I do think I found a workaround, which was to select the VM in the Domains menu, then to click on the dialog—but it'd be a drag to have to keep that in a cheatsheet taped to the workstation laptop.

[sssoleileraaa]

I think we can fix this by reversing a hack to remove the window frame in Qubes

[ninavizz]

I will gladly take an ugly Qubes window frame, over the no-can-type functionality quirk.

I will then be more adamant, that we have Admins provision their workstations to use myyyy window theme (I think it's Atlanta), and to kill the extra window buttons at the top. My own Qubes'ing has gotten far saner from just that one tiiny change.

[eloquence]

If we agree it's a good idea, changing the theme is a one-line command (xfconf-query -c xfwm4 -p /general/theme -t 'string' -s 'Atlanta' in dom0) and something we can add to do the update-xfce-settings script that already makes other tweaks (e.g., icon size).

[eloquence]

The behavior when you alt+tab back and forth while an export dialog is open is pretty bad and can result in dialogs not being obviously clickable/closeable. I'm going to tentatively promote this to release blocker for visibility, obviously we may have to defer to next release given limited time.

[sssoleileraaa]

I can fix this by no longer setting the Qt.Popup WindowFlag and also agree making this a modal is the way we should have gone.

[ninavizz]

FYI, this was the issue I'd referenced about "dialogs sitting atop other VM windows" from Export, as it may relate to Delete, @emkll. Unsure what the resolution status might be, but eventually this issue and how we're doing delete/export, should all interconnect in a standard for overlay panes (both modal and not modal).