[virt-tools-list] virt-viewer: Having per window full-screen state causes monitor arrangement issues

[Marc-André Lureau]

----- Original Message -----
> Hi,
> 
> On 09/20/2013 03:28 PM, Marc-André Lureau wrote:
> >
> >
> > ----- Original Message -----
> >> Hi,
> >>
> >> On 09/20/2013 02:06 PM, Marc-André Lureau wrote:
> >>> Hi
> >>>
> >>> I think the issue is when a window go fullscreen, we take its monitor
> >>> geometry and disable auto-alignment. This can cause overlap, when all
> >>> monitors aren't fullscreen.
> >>>
> >>> When we leave fullscreen, ltr-alignment is applied, all is "fine"
> >>>
> >>> So it looks to me like we should do better alignment on "all" monitors
> >>> whatever happens. I think current alignment spice-gtk code is too simple
> >>> and needs to be improved. What do you think? I will try to see what I can
> >>> do.
> >>
> >> I agree some better alignment for the windowed / mixed case would be good.
> >>
> >> What I suggest to do for now is do auto ltr arrangement using the current
> >> algorithm, on all monitors (except for the all windows fullscreen case),
> >> and
> >> update monitor coordinates for all monitors, including fullscreen ones,
> >> each
> >> time a windows size changes (which includes going fullscreen / windowed).
> >>
> >> As said the all windows fullscreen case is special, in that case we should
> >> just use the actual physical monitor coordinates and not do any
> >> auto-align.
> >
> > I thought about it, but it might reorder and move monitors whenever you
> > unfullscreen/fullscreen. That can really be annoying.
> 
> Only on setups with more then 1 row of monitors, we already use the window
> root coordinates to decide
> which display goes first in the sorted list when doing auto-align, so for
> normal multi0monitor setups
> with just a single row of monitors (be it 2, 3 or 5) no re-ordering should
> happen.
> 
> > I am thinking now to just use window root coordinates and size (yes,
> > following the way you started using window coordinates). So, never use
> > alignment. That leaves the following problems:
> > - window gaps and overlaps: either we ignore this problem or we improve
> > alignment to cope with this. Note overlap might be actually wanted for
> > mirrors.
> 
> Yes overlap if the actual windows overlap should not be an issue
> 
> > And gap could probably be ignored?
> 
> That means a window could be dragged into the gap, leaving only
> a small but visible, or after re-arranging a window could even
> be completely hidden by a gap, so I do believe gaps could be
> a problem.

It's the job of a WM to ensure that windows remain visible. Afaik, this is not an issue with GNOME or Windows.

> 
> Also this would mean that just moving a window a bit (without
> moving its upper left corner passed the upper left corner of
> another display) will cause a re-configuring of the guest
> monitors.

Just a move won't trigger reconfiguration, but something else will (widget allocate, zoom, resize ..)

> > - resizing a display inside the guest in fullscreen (scaled), will create
> > even bigger overlaps or gaps.
> >
> > Tbh, I don't see how automatic alignment could work without breaking some
> > use cases. I welcome suggestions
> 
> For now I would stick with what I've suggested, so keep the current
> ltr auto-align, while adding code to make sure we update coordinates
> whenever necessary + use physical monitor coordinates in the all
> monitors full-screen case.

I think it's equally bad (if not worse) that monitors are "swaped" whether they are all in fullscreen or not (in your example) (you will get your startmenu/taskbar jumping from window/monitor) 

> Alternatively you could simply always do ltr auto-align, but then
> setups with more then 1 row of monitors will always be broken, even
> in the all fullscreen case.

I think ltr-alignment code is really too stupid, it will always bring issues like that.