[virt-tools-list] [virt-manager][PATCH 0/4] Allow hiding window decorations and menu bar

[Cole Robinson]

On 01/01/2019 07:28 PM, Povilas Kanapickas wrote:
> The screen estate used by the virt-manager itself in the console mode reduces
> the amount of screen estate available to the VM. virt-manager currently supports
> the fullscreen option to make maximum use of the available screen. Unfortunately,
> this hides the OS taskbar, which makes this approach less usable for workflows
> that need to use the taskbar, e.g. when switching between many different VMs at
> the same time.
> 
> The PR introduces a "hide decorations" menu option. This option hides the menubar
> and the OS window decorations of the VM viewer. Essentially, it's the fullscreen
> option without actually going full screen, i.e. the window mechanics are still
> preserved and the window can still be hidden, obscured and so on. This mode can
> be turned off much like the fullscreen option - my moving mouse near the top edge
> which shows the usual two-button box.
> 
> The PR also slightly changes how the "revealer" box works. In non-fullscreen mode
> the assumption that it's easy to navigate to the exact top pixel of the window
> no longer holds. So the eventbox is now a completely separate rectangle from the
> revealer itself and thus can span much wider span of the window and be more than
> a single pixel high. This way we don't grab mouse events from much larger area
> than we want whenever the box with buttons is shown which would have been an
> issue with the previous implementation if I just increased the width of the
> eventbox.
> 

Thanks for the patches. It's an interesting idea but the use case seems 
very niche to have explicit support in virt-manager IMO. Even the idea 
of hiding window decorations seems quite obscure, not even 
vncviewer/tigervnc has it AFAICT.

Also in my testing it doesn't look to be implemented for gtk on wayland 
which is kinda the way forward, so we end up with a UI element that is a 
no-op depending on the desktop config. Maybe that's fixable but I don't 
know offhand

I like the idea of splitting out the overlay logic to its own class 
though, helps readability, so I pushed patch #1

Thanks,
Cole