----- 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. _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
