The 'path' part of the URI will always start with a '/' when present as
this is what separates it from the hostname. When rebuilding the final
URI, the current code inserts a '/' by itself between the hostname and
the path, which results in URIs with an extra '/':
https://ovirt.example.com//some/path/api
This is not only cosmetic as this can cause issues with cookie handling
if libgovirt accesses //some/path/api while the cookie is set for
/some/path/api.
When the user launches remote-viewer with an ovirt URI of the form
ovirt://user@host/vmname
Pre-populate the authentication dialog with the specified username. We
don't support specifying the password on the commandline, since that is
a potential security risk.
rhbz#1061826
When launching from a vv-file, we want to use the ca specified in the vv
file and not load additional certs from the fallback ca-file. This
ensures that the ca-file property of the spice session is unset when
loading a ca from a vv-file.
Resolves: rhbz#1127762
use <display>:<monitor>;<display>:<monitor> instead of simply implying the
display from the array index (e.g. <monitor>;<monitor>). This allows you to set
up sparse guest displays (e.g. display 1 + 3).
For example, to configure display 1 to be fullscreen on monitor 2 and display 2
to be fullscreen on monitor 3:
monitor-mapping=1:2;2:3
This allows the user to obtain the GUID and vm name of the currently-connected
guest. Obviously, this only works with spice. In the future, it will allow them
to set guest-specific configuration options (using a GUID as a key)
Going to fullscreen, and then exiting causes these messages to show up
on the console:
(remote-viewer:14481): GLib-CRITICAL **: Source ID 784 was not found
when attempting to remove it
glib documentation says this should be the last thing done in the
dispose() call, which makes sense as this could invalidate still-needed
data in the parent object.
Encapsulate things a bit better by adding
virt_viewer_app_get_option_group() which provides a GOptionGroup rather
than exposing an array of options. This option is then set as the main
option group, and additional options can be added by subclasses, so the
effect to the user should be equivalent.
This silences an automake 1.14 warning:
src/Makefile.am:35: warning: source file 'view/autoDrawer.c' is in a
subdirectory,
src/Makefile.am:35: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the
'subdir-objects'
automake: automake option hasn't been enabled. For now, the
corresponding output
automake: object file(s) will be placed in the top-level directory.
However,
automake: this behaviour will change in future Automake versions: they
will
automake: unconditionally cause object files to be placed in the same
subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option
throughout your
automake: project, to avoid future incompatibilities.
Declaring a local variable as part as a for loop
such as 'for (unsigned int i; i < N; i++)' is a C99 specific feature.
Running configure with --enable-compile-warnings=minimal does not add
-std=c99 to the compile flags, so it's better if the codebase does not
require C99 support from the compiler.
Commit 6edde5786 introduced a regression wrt shrinking windows on windows
guests. This seems to be because resizing a display often causes the notebook
widget to switch to the status page temporarily (often so quickly that it's not
noticeable to the eye). This causes a quick 'unmap' and 'map' event sequence on
the display widget. Apparently the timing of these events varies enough between
linux and windows guests that it is only noticeable on windows gueststhe timing
of these events varies enough between linux and windows guests that it is only
noticeable on windows guests. The exact sequence that causes the bug appears to
be as follows:
1 user resizes window smaller
2 display widget gets a new allocation, which causes it to send a display
reconfiguration to the guest
3 client receives a new show-hint for the display which causes it to switch
temporarily to the 'status' notebook page
4 display widget gets unmapped
5 Client receives another new show-hint, which causes the display widget to get
re- mapped, which causes client to send a display reconfiguration to the guest
(using the old size)
6 client receives new (smaller, from step 2) display size and temporarily
changes to the new size
7 client receives new (larger, from step 5) display size and changes back to
original size.
To fix the issue, we only explicitly request a resize in response to the very
first map event, and for any subsequent map events, we simply call
_make_resizable() as before.
The Windows MSI product version is restricted to a 3 component
version number, whose fields are a max value of 255.255.65536
Since the main virt-viewer version takes up 3 components already,
we have the munge the micro version together with the first
component of the release version. eg we have
$VERSION[0].$VERSION[1].($VERSION[2] << 8 + $RELEASE[0])
This causes problems for RHEL which needs to have 2-component
release versions to deal with z-stream builds. eg a RHEL
version might be virt-viewer-0.5.6-2.el6_4.3 and we've
no easy way of adding the final '.3' to the Windows product
version.
If we reduce the primary virt-viewer version to just 2 components,
then we can leave the 3rd component for exclusive use by the RPM
release number. eg so we'd make product version up using
$VERSION[0].$VERSION[1].($RELEASE[0] << 8 + $RELEASE[1])
In course of normal development, we'd increase the $VERSION[0]
for each release. ie next release is 1.0, then 2.0, then 3.0.
This means we retain the ability to put out "stable" branch
releases for any historical version by doing 1.1, 1.2 instead
of having to re-add a 3rd component.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
You can reproduce the error by starting the client in kiosk and shuting
down the guest.
#0 0x000000317e432915 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x000000317e4340f5 in abort () at abort.c:92
#2 0x000000317fc4a98a in g_logv (log_domain=0x318730e657 "Gtk",
log_level=<value optimized out>, format=
0x31873a50a8 "A floating object was finalized. This means that
someone\ncalled g_object_unref() on an object that had only a
floating\nreference; the initial floating reference is not owned by
anyone\nand must be remo"..., args1=0x7fffffffd5f0)
at gmessages.c:557
#3 0x000000317fc4aa23 in g_log (log_domain=<value optimized out>,
log_level=<value optimized out>,
format=<value optimized out>) at gmessages.c:577
#4 0x000000318717ba72 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#5 0x0000000000426eb5 in
virt_viewer_display_spice_finalize (obj=0x6fec20
[VirtViewerDisplaySpice])
at virt-viewer-display-spice.c:67
#6 0x0000003180c106a4 in g_object_unref (_object=0x6fec20) at
gobject.c:2712
#7 0x0000000000425b5d in destroy_display (data=0x6fec20) at
virt-viewer-session-spice.c:596
#8 0x000000317fc1667b in g_ptr_array_foreach (array=0x74a040,
func=0x425ae7 <destroy_display>, user_data=0x0)
at garray.c:1306
#9 0x000000317fc16e7b in g_ptr_array_free (farray=0x74a040,
free_segment=1) at garray.c:938
#10 0x000000317fc2906a in g_data_set_internal (datalist=<value optimized
out>, key_id=1297, data=0x0, destroy_func=0)
at gdataset.c:351
#11 g_datalist_id_set_data_full (datalist=<value optimized out>,
key_id=1297, data=0x0, destroy_func=0) at gdataset.c:598
#12 0x00000000004268d0 in
virt_viewer_session_spice_channel_destroy (s=0x800000 [SpiceSession],
channel=
This unref doesn't seem to be related to any reference, although it
was probably introduced in the first place to clear the floating ref,
wrongly. See following commit for a working solution.
rhbz#1104064 had a couple of symptoms. The first was fixed in
6edde57862.
The second symptom is that displays could also become tiny when clicking 'View >
Zoom > Normal Size'. This was because VirtViewerDisplay returned early from
_display_set_zoom_level() if the zoom level was being set to the current zoom
setting. However, the calling function (_window_set_zoom_level()) also tries to
queue a resize event for itself after setting the zoom level on the display. If
the display doesn't queue a resize event for itself, its size request will only
be 50x50 during the window resize negotiation. This causes the display to become
tiny and zoomed out. Queueing a resize on the display widget ensures that it
will request the proper size during the next allocation.
When enabling a new display on linux guests, the new window would be tiny
(50x50) and zoomed way out. This was caused by the fact that when the display
widget received the 'map' event, it unconditionally cleared the 'dirty' flag,
which meant that it would only request 50x50 size. This behavior was intended to
fix a bug on the windows client which wprevented windows from resized smaller
than the guest display resolution. Unfortunately, due to the timing of the 'map'
and allocate events, the widget became very small.
Instead of clearing the 'dirty' flag directly when a widget is mapped, we
now queue a resize event, which will guarantee that the widget attains its
desired size and will then clear its dirty flag (allowing it to be resized).
Testing on windows indicates that this fix still solves the 'unshrinkable
window' problem while also preventing the tiny secondary display bug.
Resolves: rhbz#1104064
Some display have no associated window (for ex, if it doesn't fit
on client monitors).
(remote-viewer:22275): remote-viewer-CRITICAL **: virt_viewer_window_set_display: assertion `VIRT_VIEWER_IS_WINDOW(self)' failed
(remote-viewer:22275): remote-viewer-CRITICAL **: virt_viewer_app_remove_nth_window: assertion `win != NULL' failed
https://bugzilla.redhat.com/show_bug.cgi?id=1107518
Trying to connect to a remote virtual machine using
virt-viewer -c qemu+ssh://example.com/system --direct $vm_name
will currently fail with an error message saying it's not possible to
localhost. This happens with VMs which listen on a wildcard address (eg
'0.0.0.0').
This was introduced by commit 74b1b62 which changes the host to connect to
to 'localhost' when trying to connect through ssh to a VM listening on a
wildcard address. This is only valid when using a ssh tunnel, and should
not be done with --direct. The fallback code which uses the hostname from
the libvirt URI is what makes the most sense in this situation (wildcard
listen address + --direct).
This commit introduces a virt_viewer_app_get_direct() so that this can be
implemented.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1079211
Coverity warns that 'type' can sometimes be used or free after already having
been freed. This can happen when open_recent_dialog is true and we jump back up
to the retry_dialog label. To prevent this, make sure the freed variables are
set to NULL after freeing.
Previous commit accidentally broke gtk2 build by using
gtk_widget_get_preferred_size(). We can't simply use gtk_widget_size_request()
for the gtk2 build since this will generally return 50x50 whenever we're not in
the middle of a resize, so we need to add a compatibility function.
