[virt-tools-list] [PATCH] window: move window again after fullscreen

[Marc-André Lureau]

----- Original Message -----
> Hi,
> 
> On 10/04/2013 06:43 PM, Jonathon Jongsma wrote:
> > ----- Original Message -----
> >> From: "Marc-André Lureau" <marcandre.lureau at gmail.com>
> >> To: virt-tools-list at redhat.com
> >> Sent: Friday, October 4, 2013 8:13:08 AM
> >> Subject: [virt-tools-list] [PATCH] window: move window again after
> >> fullscreen
> >>
> >> Some WM get fullscreen position wrong, in some racy ways (metacity on
> >> rhel6 for instance).  Setting window position after entering fullscreen
> >> seems to solve the problem. Though it's better to move before entering
> >> fullscreen, to avoid extra resizes.
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=809546
> >> ---
> >>   src/virt-viewer-window.c | 3 +++
> >>   1 file changed, 3 insertions(+)
> >>
> >> diff --git a/src/virt-viewer-window.c b/src/virt-viewer-window.c
> >> index 0f62feb..d6b1c54 100644
> >> --- a/src/virt-viewer-window.c
> >> +++ b/src/virt-viewer-window.c
> >> @@ -552,6 +552,9 @@ virt_viewer_window_enter_fullscreen(VirtViewerWindow
> >> *self, gint monitor)
> >>       virt_viewer_window_move_to_monitor(self);
> >>
> >>       gtk_window_fullscreen(GTK_WINDOW(priv->window));
> >> +
> >> +    /* move again, some WM get fullscreen position wrong, in some racy
> >> ways.. */
> >> +    virt_viewer_window_move_to_monitor(self);
> >>   }
> >>
> >>   #define MAX_KEY_COMBO 4
> >> --
> >> 1.8.3.1
> >>
> >> _______________________________________________
> >> virt-tools-list mailing list
> >> virt-tools-list at redhat.com
> >> https://www.redhat.com/mailman/listinfo/virt-tools-list
> >>
> >
> >
> > I mentioned this via IRC already, but I suspect that this workaround may
> > not work properly when client monitors are different resolutions due to
> > the fact that we ignore further allocations after the first one when we go
> > into fullscreen mode. Can you get somebody to test this?
> 
>  From my own experience working on this, I believe you are right, but there
> is not a whole lot we can do here. This way at least setups with
> identically sized monitors should work. If we get complaints about things
> not working on setups with different size monitors, we should probably
> file a bug against metacity, rather then to try to hack around this.

metacity maintainers are very reluctant to change metacity policy, as this tends to break other use cases easily (also metacity is mostly on maintainance mode, afaik). We already worked around metacity bugs, I wouldn't be surprised if we get the same answer.

Anyway, I agree that it would be worth to check if this is still broken when display have different size.

Also, I am afraid that win32 (and other WM or systems) may behave differently. Sorry, but I can't verify on a dozen of setup everytime I fix something. If it breaks something else, we will figure out during testing phase. But a priori, this simple change shouldn't break (the position should be unchanged).