On RHEL6, when starting virt-viewer --full-screen, metacity will
remaximize & force-fullscreen when leaving fullscreen, which prevents
user from accessing window titlebar, and end up with an incorrect
fullscreen state.
Thanks Owen Taylor for help debugging this:
<owen> elmarco: So the interesting thing here is that the "legacy" isn't
triggered off a configure request to a particular size, mutter seems to
constrain the window back to fullscreen size on its own when it sees a
change to WM_NORMAL_HINTS
<owen> commit 4943d79d6844af3f7fc0a15ceadb69d95c4c5c61
<owen> Author: Peter Bloomfield <PeterBloomfield@BellSouth.net>
<owen> Date: Wed Jan 20 10:59:07 2010 -0500
<owen> prevent window self-maximisation
<owen> Is not in rhel6 metacity
<owen> So probably that's the main difference
<owen> can you just make your program not fullscreen initially but wait until
it's mapped? (gets map-event on the toplevel)
<elmarco> owen that seems to work
<owen> I don't have a better solution to offer - sorry for the ugliness (code and
initial mapping appearance)
https://bugzilla.redhat.com/show_bug.cgi?id=876445
Since fdaa9b0ca, virt-viewer allows to fullscreen a single window. It
feels more symetric to leave a single window from fullscreen as well,
unless the application was started in fullscreen.
Fix send key menu popup position.
The current code wasn't correctly translating the menu coordinates
based on the toplevel windows position, it was always using origin 0.
https://bugzilla.redhat.com/show_bug.cgi?id=913601
Since some of the arguments are expecting following value, make it more
explicit in the man and --help that -- can seperate options from server
name or location.
https://bugzilla.redhat.com/show_bug.cgi?id=843103
Currently, going from window to fullscreen mode changes all display to
fullscreen and realize automatic positionning on corresponding client
monitor. However, it allows for much more flexibility to allow entering
fullscreen on the current monitor each windows seperately. This way the
user can decide on arbitrary monitor arrangement.
https://bugzilla.redhat.com/show_bug.cgi?id=558241
Virt-viewer hides the display window 0, but doesn't disable the display.
This is inconsistent with other displays, and prevent the guest OS from
reconfiguring the main display.
(for monitor 0 to be really disabled in multi-monitor guest, the agent
need to support sparse monitor config. If not, the first display windows
will be reopened to match the new un-sparse configuration)
Note also the current Linux vdagent crashes when disabling 1st monitor,
to be solved seperately.
Related bug:
https://bugzilla.redhat.com/show_bug.cgi?id=958550
If a monitor is already in fullscreen, setting auto-conf to true will
not move it until it is re-fullscreen
This was unnoticed, because usually, the first client window is opened
on the first monitor. Also we may argue than relying on g_object_set()
property order is lame and fragile, we better split it in two seperate
calls as this might break upstream.
https://bugzilla.redhat.com/show_bug.cgi?id=872288
In case the virt-viewer setting file is meant to temporary, you may use
the delete-this-file=1 option to ask the client to remove it, once it
has been read. This is useful for example in ovirt context, where
connection settings file are generated and can't be reused.
Currently, in multi-screen scenarios, when closing one remote-viewer
window, the corresponding screen gets disabled in the guest OS.
This can be confusing as this behaves very differently from
File/Quit. This commit will exit the whole application when the user
tries to close one of virt-viewer window.
With gtk-2 we have a special hack, where at first we make the
virt-viewer-display request its actual size, and then once the window is
mapped, we request a size of 50x50 to allow the user to resize the window
to something smaller.
With gtk-3 >= 3.8.1 this is broken, and the window gets resized to a
smaller size as soon as we change the size request to 50x50.
gtk-3 has a much better way of dealing with this in the form of widgets
being able to specify both a minimal and a natural size. This patch changes
virt-viewer to use this with gtk-3, instead of the gtk-2 hack.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
gtk-3's widget size negotiation code differentiates between the minimum
size and the natural size of a widget, fix ovBox to pass this along from
its underlying widget to its parent.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
We've 3 similar zoom function zoom in / out / reset. in / out do not
schedule a window resize when there is no display, where as reset does,
which is not consistent. Also there is some duplicate code between them.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When exiting remote-viewer, VirtViewepApp::dispose() calls
virt_viewer_app_set_connect_info() with NULL parameters to free all
internal fields. However, _set_connect_info() calls
virt_viewer_app_update_pretty_address() which will always allocate
a new string even if the fields it's using to fill the string are NULL.
This commit fixes the leak by checking if the fields have non-NULL
values before creating the newly-allocated string.
==24180== 14 bytes in 1 blocks are definitely lost in loss record 540 of 8,671
==24180== at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==24180== by 0x32D2B0A187: __vasprintf_chk (vasprintf_chk.c:80)
==24180== by 0x32D52845AA: g_vasprintf (stdio2.h:210)
==24180== by 0x32D52640DC: g_strdup_vprintf (gstrfuncs.c:517)
==24180== by 0x32D526417B: g_strdup_printf (gstrfuncs.c:543)
==24180== by 0x4136E6: virt_viewer_app_update_pretty_address (virt-viewer-app.c:1681)
==24180== by 0x414100: virt_viewer_app_set_connect_info (virt-viewer-app.c:1902)
==24180== by 0x4141D0: virt_viewer_app_free_connect_info (virt-viewer-app.c:1910)
==24180== by 0x4127C6: virt_viewer_app_dispose (virt-viewer-app.c:1353)
==24180== by 0x425488: remote_viewer_dispose (remote-viewer.c:131)
==24180== by 0x32D5E14787: g_object_unref (gobject.c:2986)
==24180== by 0x4280AF: main (remote-viewer-main.c:323)
They don't need to be wrapped inside if HAVE_XXX blocks in Makefile.am
as when XXX is not available, XXX_CFLAGS and XXX_LIBS will expand to
the empty string, and thus we can carry them unconditionally in
our app_CFLAGS/app_LDFLAGS variables.
Some of the code is checking for spice-gtk/oVirt availability
by using #ifdef HAVE_XXX, and some of the code is using #if HAVE_XXX.
As configure.ac only AC_DEFINE() HAVE_XXX when XXX could be found,
let's use the #ifdef HAVE_XXX form everywhere
Marking display menu items as non sensitive for shown displays make no sense,
since the user can always close them through the window-manager.
Having a window for a display shown when the display is not selectable nor
ready, can happen when the agent goes away. This happens for example when using
a dual monitor config with a Linux guest and then switching to a text console
inside the guest.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
virt_viewer_window_menu_send() compares the label of the menu item
that was clicked on with a list of known labels to know which
key combination should be sent to the guest.
However, the menu label can be translated, but the table doing
the label -> key combination mapping uses untranslated labels.
This means the menu item will not send any key combination when
clicked if translated.
This can be observed with fr_FR where "Ctrl+Alt+_Del" is translated
to "Ctrl+Alt+_Suppr".
On windows, the client window may end up with a non-visible toolbar,
and overlapping the windows statusbar. To workaround this, let's
maximize the client the first time leaving fullscreen.
https://bugzilla.redhat.com/show_bug.cgi?id=916810
Even if the display has not been explicitely disabled, as long as
the display is "selectable"
Fix regression introduced with "Do not disable extra client monitors"
3b981d953f
gtk_window_present() may forcefully call gdk_window_show(), which will
call ShowWindow(). Although gdk call is not supposed to move the
window if it's already visible, it does restore the window position on
Vista+. For example, a snapped window will be moved back to its
previous position.
Gtk+ ShowWindow() is currently using SW_SHOWNOACTIVATE, it should
probably use SW_SHOWNA instead, but that didn't help anyway for a
snapped window.
Since virt_viewer_window_show() already ensure the window is visible,
I am not sure why gtk_window_present() is there in the first place, so
just remove it.
https://bugzilla.redhat.com/show_bug.cgi?id=912713
If the application was started in fullscreen, window geometry has not
been saved, since the window was not realized. We can unfullscreen and
restore 1:1 window to match guest display size with
virt_viewer_display_queue_resize()
https://bugzilla.redhat.com/show_bug.cgi?id=916810
Because of what apparently is a gtk+2 bug , we
cannot recreate the submenu every time we need to refresh it,
otherwise the application may get frozen with the keyboard and
mouse grabbed if gtk_menu_item_set_submenu is called while
the menu is displayed. Reusing the same menu every time
works around this issue.
https://bugzilla.redhat.com/show_bug.cgi?id=922712
Restore the auto-conf client monitor configuration whenever the agent
is started. This ensures the guest has the expected number of monitors
enabled when rebooting in fullscreen.
https://bugzilla.redhat.com/show_bug.cgi?id=918997
When we are in fullscreen-auto-conf virt-viewer-session-spice sends a
monitor-info message to the agent with the exact client monitor info, and
virt-viewer-display-spice should not override that.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Even if the display is disabled, we should keep sending key events to
guest. It can wake up from sleep for instance.
There is a single widget per window, so we can directly send key
events there. If the menu is active, it has the grab, so the window
doesn't receive those key events.
https://bugzilla.redhat.com/show_bug.cgi?id=870710
Since the sensitivity of the display menu-check-items depends on show_hint,
we need to call virt_viewer_app_update_menu_displays on show_hint change.
This fixes the following scenario:
1) Linux guest with upto 4 displays on a single qxl dev
2) Configure it for 2 displays
3) Switch to a text-console in the guest (ie send ctrl+alt+F3)
4) All displays except for disp 1 are now not sensitve in the menu
5) Switch back to X
6) The second display in the view->displays menu is still not sensitive
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add some missing checks for not having a display. Note that where
functions should not be called (ie menu items should be disabled) I've
used g_return_if_fail.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
With commit 81ed9d13 "virt_viewer_window_enter_fullscreen: Pass in monitor for
fullscreen window" we need a monitor number to determine where to move
the window when going fullscreen.
Since the VirtViewerDisplay needs to know the fullscreen monitor number too,
to determine the fullscreen size it was being stored there. But we don't
always have a display, leading to errors like:
(remote-viewer:7996): remote-viewer-CRITICAL **:
virt_viewer_display_get_monitor: assertion `VIRT_VIEWER_IS_DISPLAY(self)'
failed
And to the monitor number not always being stored. This patchset fixes this
by storing the monitor number inside VirtViewerWindow, and passing it to
VirtViewerDisplay only when we've a display.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When a display is pinned to a certain monitor for fullscreen, it will be moved
there when going fullscreen. Currently we use gdk_screen_get_monitor_at_window
to determine which monitor we are on and get the size from that monitor.
But this is racy, sometimes the size_allocate function runs before the move
has finished and we get the size from the wrong monitor:
https://bugzilla.redhat.com/show_bug.cgi?id=918570
Since if the display is pinned to a certain monitor, the display will always
end up on that monitor we can avoid the race by simply using that monitors
size.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Rather then passing in a move boolean + coordinates to move the window
to for fullscreen mode, simply pass in the monitor, so that the underlying
objects can also use the monitors size to determine the display size.
Note: pass in -1 to use the monitor the window is currently on.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
