- Reuse #ifdef HAVE_SPICE_GTK block for include.
- Move declaration of vfunc together with others of the same class.
- Move variable declaration to the top of the function.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
The 3.0 release was the last one that still supports GTK2. For the
Windows builds the support to GTK2 was dropped in the previous release.
Let's do the same for the entire project now.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
The button is visible in the fullscreen toolbar when waiting for a guest.
Clicking on it causes the runtime warning:
virt-viewer-CRITICAL **: virt_viewer_session_usb_device_selection: assertion 'VIRT_VIEWER_IS_SESSION(self)' failed
Avoid the debug message on close:
virt-viewer-DEBUG: Unable to get comment from key file: Key file does not have group '39cd210d-5d45-478a-91fe-b3680307f2df'
Avoid calling gtk_widget_queue_resize() and emiting
the "display-desktop-resize" signal.
The only user of the properties is virt_viewer_display_spice_set_desktop()
which will call the function and emit the signal after setting both
"desktop-width" and "desktop-height" properties.
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Nowadays the value for MIN_DISPLAY_{WIDTH,HEIGHT} is 50. This arbitrary
value doesn't bring any benefit, doesn't provide a useful size for a
desktop to be usable and can actually trigger some undefined behavior
when reaching resolutions that are lower than the ones provided by the
video drivers (as in rhbz#1296878).
In order to avoid these issues and provide a minimum resolution that can
still be useful for our users, let's use the same values for minimum
width and height used by the linux QXL drivers (320x200).
This also requires us to adjust the minimum requested widget size when
zoom is enabled so that we don't accidentally request a size smaller
than the driver can support.
Related: rhbz#1296878
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Otherwise we can have warnings when resizing the virt-viewer window to
the smallest possible size, like:
(virt-viewer:11187): GLib-GObject-WARNING **: value "50" of type `gint'
is invalid or out of range for property `desktop-height' of type `gint'
Related: rhbz#1296878
0a7fa73f is the commit that dropped support for gtk2 for the nsis
installer.
03c014cb is the commit that dropped support for gtk2 for the msi
installer.
We're telling autoconf to look in the m4/ directory for
files, but this directory doesn't exist in a clean checkout
until libtoolize has run. Older versions of autoconf consider
this to be a fatal error.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Any copyright line must use 'Copyright (C) <year> Red Hat'
per the syntax-check rule.
Use of -a / -o args to "test" is non-portable and should
instead be done with 'test ... || test ...'
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Makefile.am: Use helper variables from git.mk
man/Makefile.am: This should be $(dist_man_MANS) instead of $(man_MANS)
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
After removing m4/.gitignore file in previous patch, I started getting
the following error when running autogen.sh.
ln: failed to create symbolic link ‘m4/intltool.m4’: No such file or directory
cp: cannot create regular file ‘m4/intltool.m4’: No such file or directory
intltoolize: cannot copy '/usr/share/aclocal/intltool.m4' to 'm4/intltool.m4'
The problem is that intltoolize requires te m4/ directory to be present,
and this directory is actually created by running autoreconf, so it
should be called before intltoolize.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
When running in fullscreen it is possible to end up in a situation
where we have more displays enabled than monitors. This can happen
if displays that were enabled in the previous connection to the guest
doesn't match displays requested when entering the fullscreen mode.
This commit solves the problem by disabling displays that should not be
enabled in the fullscreen mode.
Resolves: rhbz#1212802
As sorted_displays is a vector containing all displays' order, its
allocation size must be the maximum display id + 1 instead of the
maximum display id. Also, fix the size used for sorting and iterating
the sorted_displays vector.
Valgrind log:
==15946== Invalid write of size 4
==15946== at 0x4169C0: virt_viewer_align_monitors_linear (virt-viewer-util.c:581)
==15946== by 0x42248B: virt_viewer_session_on_monitor_geometry_changed (virt-viewer-session.c:438)
==15946== by 0xBB41F03: _g_closure_invoke_va (gclosure.c:831)
==15946== by 0xBB5BC7C: g_signal_emit_valist (gsignal.c:3214)
==15946== by 0xBB5C764: g_signal_emit_by_name (gsignal.c:3401)
==15946== by 0x4328F3: virt_viewer_display_spice_monitor_geometry_changed (virt-viewer-display-spice.c:93)
==15946== by 0x432D60: virt_viewer_display_spice_size_allocate (virt-viewer-display-spice.c:224)
==15946== by 0xBB41CD4: g_closure_invoke (gclosure.c:768)
==15946== by 0xBB53538: signal_emit_unlocked_R (gsignal.c:3549)
==15946== by 0xBB5BEEF: g_signal_emit_valist (gsignal.c:3305)
==15946== by 0xBB5C29E: g_signal_emit (gsignal.c:3361)
==15946== by 0x637D6F6: gtk_widget_size_allocate_with_baseline (gtkwidget.c:6093)
==15946== Address 0x18c79d4c is 0 bytes after a block of size 12 alloc'd
==15946== at 0x4C2A9C7: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==15946== by 0xBDD36D1: g_malloc0 (gmem.c:127)
==15946== by 0x41698D: virt_viewer_align_monitors_linear (virt-viewer-util.c:577)
==15946== by 0x42248B: virt_viewer_session_on_monitor_geometry_changed (virt-viewer-session.c:438)
==15946== by 0xBB41F03: _g_closure_invoke_va (gclosure.c:831)
==15946== by 0xBB5BC7C: g_signal_emit_valist (gsignal.c:3214)
==15946== by 0xBB5C764: g_signal_emit_by_name (gsignal.c:3401)
==15946== by 0x4328F3: virt_viewer_display_spice_monitor_geometry_changed (virt-viewer-display-spice.c:93)
==15946== by 0x432D60: virt_viewer_display_spice_size_allocate (virt-viewer-display-spice.c:224)
==15946== by 0xBB41CD4: g_closure_invoke (gclosure.c:768)
==15946== by 0xBB53538: signal_emit_unlocked_R (gsignal.c:3549)
==15946== by 0xBB5BEEF: g_signal_emit_valist (gsignal.c:3305)
Resolves: rhbz#1272650
Related: rhbz#1267184
Creating the monitors hashtable only after checking for the existence of
apply_monitor_geometry vfunc avoids leaking the hashtable in the case
where the vfunc doesn't exist.
Related: rhbz#1267184
When the connection to libvirtd is lost, virt-viewer starts polling for
libvirtd to come back. The polling mechanism is also used when
connecting to very old libvirtd which don't support
virConnectDomainEventDeregisterAny().
Currently, once we could reconnect to libvirtd, virt-viewer will keep
polling, thus behaving as if the libvirtd connection does not support
virConnectDomainEventDeregisterAny(). This commit makes sure we stop
polling once the new libvirtd connection is established.
This has the side-effect of preventing
https://bugzilla.redhat.com/show_bug.cgi?id=1271519 from occurring with
recent libvirt as it's caused by some race occurring when using the
polling code.
When starting virt-viewer in fullscreen mode, we generally try to
arrange guest displays exactly the same as client monitors. So if a
client machine has two monitors, we'll try to enable display 0 and 1 on
the guest (in that order). However, when using the configuration file to
map fullscreen displays to different monitors, the guest displays may
not be sequential, or there may be displays missing. For example,
consider the following configuration:
monitor-mapping=1:2;2:1
In virt_viewer_session_spice_fullscreen_auto_conf(), we were building an
array of GdkRectangles for the initial monitors that we want to enable
on the guest. We then configured the guest displays using the index of
the array for the as the id of the guest display. But when displays
are sparse or are out-of-sequence, the array index will not match the
>ntended display ID. This created problems where displays were arranged
incorrectly. By changing the simple array into a GHashTable, we can keep
the display ID together with the GdkRectangle until we need to use it,
and things will be configured correctly.
This regression was introduced by c586dc8c.
Fixes: rhbz#1267184
Make "main-window" a construct-only property of VirtViewerSessionSpice.
This allows us to set it in the constructor and encapsulate all of the
setup within the gobject constructor rather than doing extra work in the
_new() function.
As, in theory, file ids are stables, seems that we have been using the
wrong id for remote-viewer.exe (not sure if since forever or if the path
changed).
That's what msidump shows:
ffidenci@cat ~/src/upstream/virt-viewer/dump $ grep "fil808B4A5BAB4ACD727D3823632E798743" File.idt
ffidenci@cat ~/src/upstream/virt-viewer/dump $ grep "fil808B4A5BAB4ACD727D3823632E798743" Registry.idt
reg29E29C5608128A0192FB9DC3C18562A6 0
VirtViewer.vvfile\shell\open\command
"[#fil808B4A5BAB4ACD727D3823632E798743]" "%1" CProgIds
ffidenci@cat ~/src/upstream/virt-viewer/dump $ grep "remote-viewer.exe" File.idt
fil610DF9E49759B1DEC646290195F96F8A cmp7677A8696936707272DCA43B1BF26760
remote-viewer.exe 855735 512 837
So, let's use the correct id (fil610DF9E49759B1DEC646290195F96F8A) from
now on.
Related: rhbz#1146016
Currently libxml2 is pulled as an indirect dependency when virt-viewer
is built with support to ovirt or libvirt (pulled by rest or libvirt,
respectively). However, {virt,remote}-viewer itself depends on libxml2
and not having it as an explicit dependency will cause errors on opening
remote-viewer when it is built without support to ovirt/libvirt.
Previously, there was a single function for controlling the enabled
state of a display: virt_viewer_display_set_enabled(). Unfortunately,
this function is used for two slightly different things:
A. It informs the local display widget that the display has become
disabled or enabled on the server. In other words, it tries to
synchronize the 'enabled' state of the local widget with the actual
state of the remote display.
OR
B. It tries to actively enable a currently-disabled display (or vice
versa) due to some action by the user in the client application.
This causes the client to send a new configuration down to the
server. In other words, it tries to change the state of the remote
display.
There is some conflict between these two scenarios. If the change is due
to a notification from the server, there is no need to send a new
configuration back down to the server, so this results in unnecessary
monitor configuration messages and can in fact cause issues that are a
little bit hard to track down. Because of this, I decided that it was
really necessary to have two separate functions for these two different
scenarios. so the existing _set_enabled() function will be used for
scenario A mentioned above. I added two new
functions (_enable() and _disable()) that are used to send new
configurations down to the server.
Previously, when we received a new monitors update from the server, we
only called virt_viewer_display_set_enabled() for the displays that were
enabled. We simply assumed that those that were not enabled were already
set to disabled. This assumption is currently valid, but I have some
changes in the pipeline where this is not true. This change ensures that
we update the enabled state of all monitors when we get an updated
monitors conifguration.
When a display widget receives a new size allocation, we generally emit
a monitor-geometry-changed signal so that we can reconfigure the
displays. But if the widget for a *disabled* display is allocated,
there's no reason to send down a new configuration. We don't need to
emit this signal. This doesn't currently cause any problems, but I ran
into issues while testing some other uncommitted changes.
