IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This reverts commit 10264d0d1ecbd67d3e59e3a1a3032936b0635eda.
Commit a830275344c88aef12166661b68ea2b4429c7212 required the domain
name to be placed just after the '--wait' option. It broke the
command line api, because running 'virt-viewer $vm --wait' was considered
as the error.
Related: rhbz#1209398, rhbz#1211573
Since the domain name is required as a parameter for the '--wait'
option (commit a830275344c88aef12166661b68ea2b4429c7212 ), it is
neccessary to check whether all domains names are the same. Otherwise
it wouldn't be clear which name should be used.
related: rhbz#1211573
When using a user with administrator rights, the VMs this user can
access from the user portal and the admin portal are different, and
REST API users must indicate which set of VMs they want through a
specific header. libgovirt already has support for that in its API, but
virt-viewer was not making use of that API.
This commit adds support for an 'admin' field in the [ovirt] section of
.vv files so oVirt can indicate remote-viewer whether this header should
be set or not.
This wasn't causing any problems because the _add_display() function has
an early return for the case that the display has already been added to
the session, but it's quite confusing when reading the code to see this
_add_display() function being called for every display every time we get
a monitor configuration update.
Positions of displays can be changed by guest, it is important to
react to this change by rearranging client's windows otherwise
mouse actions can be assigned to a wrong window.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1206216
The zoom level should be changed when zoom levels of the window and
the display are different. It is wrong to check the previous value of
the window because it could be set just for the window and not for
the display (e.g. when setting zoom level using the command line).
Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1206460
The display has default dimensions (100x100) when it is disabled.
Calculating the minimal zoom for the display will give wrong value
for the newly opened display.
It is better to wait for setting the zoom level to the moment when
the display is enabled and ready.
Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1206460
As since 88f634179e56742a21fb4c7efc270e4203322d74 virt-viewer can be
used without a domain-name, let's require it when using --wait.
Resolves: rhbz#1209398
Using virt_viewer_signal_connect_object() instead of g_signal_connect()
ensures that menu_display_visible_toggled_cb() won't be executed after
the display object be disposed.
Backtrace for the crash:
#0 0x00007ffff070592b in g_type_check_instance_is_a (type_instance=0x8851f0, iface_type=<optimized out>) at gtype.c:4016
#1 0x000000000041ee06 in virt_viewer_display_get_session (self=0x8851f0) at ../../src/virt-viewer-display.c:702
#2 0x0000000000417be7 in menu_display_visible_toggled_cb (checkmenuitem=0x93f790 [GtkCheckMenuItem], display=0x8851f0) at ../../src/virt-viewer-app.c:2187
#6 0x00007ffff06fe29f in <emit signal ??? on instance 0x93f790 [GtkCheckMenuItem]> (instance=instance@entry=0x93f790, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3361
#3 0x00007ffff06e3b9f in g_closure_invoke (closure=0x93faa0, return_value=return_value@entry=0x0, n_param_values=1, param_values=param_values@entry=0x7fffffffc230, invocation_hint=invocation_hint@entry=0x7fffffffc1b0) at gclosure.c:768
#4 0x00007ffff06f54c9 in signal_emit_unlocked_R (node=node@entry=0x6d73e0, detail=detail@entry=0, instance=instance@entry=0x93f790, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffc230) at gsignal.c:3549
#5 0x00007ffff06fded0 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffc3f0) at gsignal.c:3305
#7 0x00007ffff5eb6158 in gtk_check_menu_item_activate (check_menu_item=0x93f790 [GtkCheckMenuItem]) at gtkcheckmenuitem.c:299
#8 0x00007ffff5eb6158 in gtk_check_menu_item_activate (menu_item=0x93f790 [GtkCheckMenuItem]) at gtkcheckmenuitem.c:419
#12 0x00007ffff06fe29f in <emit signal ??? on instance 0x93f790 [GtkCheckMenuItem]> (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3361
#9 0x00007ffff06e3b9f in g_closure_invoke (closure=closure@entry=0x6d5aa0, return_value=return_value@entry=0x0, n_param_values=1, param_values=param_values@entry=0x7fffffffc6b0, invocation_hint=invocation_hint@entry=0x7fffffffc630) at gclosure.c:768
#10 0x00007ffff06f51bd in signal_emit_unlocked_R (node=node@entry=0x6d5ba0, detail=detail@entry=0, instance=instance@entry=0x93f790, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffc6b0) at gsignal.c:3479
#11 0x00007ffff06fded0 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffc870) at gsignal.c:3305
#13 0x0000000000417c5e in menu_display_visible_toggled_cb (checkmenuitem=0x93f790 [GtkCheckMenuItem], display=0x8851f0) at ../../src/virt-viewer-app.c:2200
#17 0x00007ffff06fe29f in <emit signal ??? on instance 0x93f790 [GtkCheckMenuItem]> (instance=instance@entry=0x93f790, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3361
#14 0x00007ffff06e3c45 in g_closure_invoke (closure=0x93faa0, return_value=return_value@entry=0x0, n_param_values=1, param_values=param_values@entry=0x7fffffffcb50, invocation_hint=invocation_hint@entry=0x7fffffffcad0) at gclosure.c:768
#15 0x00007ffff06f54c9 in signal_emit_unlocked_R (node=node@entry=0x6d73e0, detail=detail@entry=0, instance=instance@entry=0x93f790, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffcb50) at gsignal.c:3549
#16 0x00007ffff06fded0 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffcd10) at gsignal.c:3305
#18 0x00007ffff5eb6158 in gtk_check_menu_item_activate (check_menu_item=0x93f790 [GtkCheckMenuItem]) at gtkcheckmenuitem.c:299
#19 0x00007ffff5eb6158 in gtk_check_menu_item_activate (menu_item=0x93f790 [GtkCheckMenuItem]) at gtkcheckmenuitem.c:419
#23 0x00007ffff06fe29f in <emit signal ??? on instance 0x93f790 [GtkCheckMenuItem]> (instance=instance@entry=0x93f790, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3361
#20 0x00007ffff06e3c45 in g_closure_invoke (closure=closure@entry=0x6d5aa0, return_value=return_value@entry=0x0, n_param_values=1, param_values=param_values@entry=0x7fffffffcfd0, invocation_hint=invocation_hint@entry=0x7fffffffcf50) at gclosure.c:768
#21 0x00007ffff06f51bd in signal_emit_unlocked_R (node=node@entry=0x6d5ba0, detail=detail@entry=0, instance=instance@entry=0x93f790, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffcfd0) at gsignal.c:3479
#22 0x00007ffff06fded0 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffd190) at gsignal.c:3305
#24 0x00007ffff608648e in IA__gtk_widget_activate (widget=widget@entry=0x93f790 [GtkCheckMenuItem]) at gtkwidget.c:5048
#25 0x00007ffff5f6cacd in IA__gtk_menu_shell_activate_item (menu_shell=0x70ece0 [GtkMenu], menu_item=0x93f790 [GtkCheckMenuItem], force_deactivate=<optimized out>) at gtkmenushell.c:1303
#26 0x00007ffff5f6ce96 in gtk_menu_shell_button_release (widget=0x70ece0 [GtkMenu], event=<optimized out>) at gtkmenushell.c:730
#31 0x00007ffff06fe29f in <emit signal ??? on instance 0x70ece0 [GtkMenu]> (instance=instance@entry=0x70ece0, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3361
#27 0x00007ffff5f578ad in _gtk_marshal_BOOLEAN__BOXED (closure=0x6c7180, return_value=0x7fffffffd4e0, n_param_values=<optimized out>, param_values=0x7fffffffd540, invocation_hint=<optimized out>, marshal_data=<optimized out>) at gtkmarshalers.c:86
#28 0x00007ffff06e3c45 in g_closure_invoke (closure=closure@entry=0x6c7180, return_value=return_value@entry=0x7fffffffd4e0, n_param_values=2, param_values=param_values@entry=0x7fffffffd540, invocation_hint=invocation_hint@entry=0x7fffffffd4c0) at gclosure.c:768
#29 0x00007ffff06f5cef in signal_emit_unlocked_R (node=node@entry=0x6c73f0, detail=detail@entry=0, instance=instance@entry=0x70ece0, emission_return=emission_return@entry=0x7fffffffd660, instance_and_params=instance_and_params@entry=0x7fffffffd540) at gsignal.c:3587
#30 0x00007ffff06fdac2 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffd710) at gsignal.c:3315
#32 0x00007ffff608790c in gtk_widget_event_internal (widget=widget@entry=0x70ece0 [GtkMenu], event=event@entry=0x944f90) at gtkwidget.c:5017
#33 0x00007ffff6087be7 in IA__gtk_widget_event (widget=widget@entry=0x70ece0 [GtkMenu], event=event@entry=0x944f90) at gtkwidget.c:4814
#34 0x00007ffff5f55b94 in IA__gtk_propagate_event (widget=0x70ece0 [GtkMenu], event=0x944f90) at gtkmain.c:2501
#35 0x00007ffff5f55f5b in IA__gtk_main_do_event (event=0x944f90) at gtkmain.c:1696
#36 0x00007ffff5bae7dc in gdk_event_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at gdkevents-x11.c:2425
#37 0x00007ffff03e40ba in g_main_context_dispatch (context=0x693d50) at gmain.c:3122
#38 0x00007ffff03e40ba in g_main_context_dispatch (context=context@entry=0x693d50) at gmain.c:3737
#39 0x00007ffff03e4450 in g_main_context_iterate (context=0x693d50, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3808
#40 0x00007ffff03e4772 in g_main_loop_run (loop=0x748980) at gmain.c:4002
virt_viewer_app_set_hotkeys() calls virt_viewer_app_set_enable_accel()
which notify the display about "enable-accel". However the display
begins to exist after the virt_viewer_app initialization.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1206106
Do not allow to zoom out if it is not possible due to the width of
the top menu. It avoids emitting size allocation events that will
change the display resolution of the spice guest.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1206460
When using virt-viewer --reconnect, virt-viewer currently crashes when
a SPICE VM is destroyed with "virsh destroy"
What happens is that when the guest is destroyed, virt-viewer receives a
SPICE_CHANNEL_ERROR_IO notification in
virt_viewer_session_spice_main_channel_event(). This triggers the
emission of the "session-disconnected" signal, which will end up calling
spice_session_disconnect() (indirectly through
virt_viewer_app_disconnected/virt_viewer_app_deactivate).
Since spice-gtk commit ff25f3e, the actual session disconnection is
done from an idle. When the "session-disconnected" emission stops, the
VirtViewerSession instance is destroyed. However, the associated
VirtViewerDisplaySpice are still alive as the various SpiceChannels
instances hold a reference through the "virt-viewer-displays" GObject
data.
These channels are destroyed when the idle queued by spice_session_disconnect()
run. The associated VirtViewerDisplay are in turn destroyed too, but
this causes attempts to use the VirtViewerSession associated with the
displays, which has already been destroyed. This causes a crash.
This commit adds a virt_viewer_session_spice_clear_displays() which is
similar to virt_viewer_session_clear_displays(), but makes sure the
"virt-viewer-displays" references are dropped too. This ensures the
VirtViewerDisplay instances don't outlive the VirtViewerSession
they are associated with.
Backtrace for the crash:
#0 0x0000000000413f0f in display_show_hint (display=0x85ab50 [VirtViewerDisplaySpice], pspec=0x939bd0 [GParamFlags], user_data=0x0) at virt-viewer-app.c:949
#4 0x00000031ff22a29f in <emit signal notify:show-hint on instance 0x85ab50 [VirtViewerDisplaySpice]> (instance=instance@entry=0x85ab50, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3361
#1 0x00000031ff20fc45 in g_closure_invoke (closure=0xa98f50, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7fffffffc700, invocation_hint=invocation_hint@entry=0x7fffffffc680) at gclosure.c:768
#2 0x00000031ff2214c9 in signal_emit_unlocked_R (node=node@entry=0x674f80, detail=detail@entry=1678, instance=instance@entry=0x85ab50, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffc700) at gsignal.c:3549
#3 0x00000031ff229ed0 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffc8d0) at gsignal.c:3305
#5 0x00000031ff214175 in g_object_dispatch_properties_changed (object=0x85ab50 [VirtViewerDisplaySpice], n_pspecs=<optimized out>, pspecs=<optimized out>) at gobject.c:1056
#6 0x00000031ff216661 in g_object_notify (pspec=0x939bd0 [GParamFlags], object=0x85ab50 [VirtViewerDisplaySpice]) at gobject.c:1149
#7 0x00000031ff216661 in g_object_notify (object=0x85ab50 [VirtViewerDisplaySpice], property_name=<optimized out>) at gobject.c:1197
#8 0x000000000041e5ab in virt_viewer_display_set_show_hint (self=0x85ab50 [VirtViewerDisplaySpice], mask=1, enable=0) at virt-viewer-display.c:691
#9 0x000000000042b62d in update_display_ready (self=0x85ab50 [VirtViewerDisplaySpice])
at virt-viewer-display-spice.c:145
#13 0x00000031ff22a29f in <emit signal notify:ready on instance 0x898590 [SpiceDisplay]> (instance=instance@entry=0x898590, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3361
#10 0x00000031ff20fc45 in g_closure_invoke (closure=0x99b280, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7fffffffcc50, invocation_hint=invocation_hint@entry=0x7fffffffcbd0) at gclosure.c:768
#11 0x00000031ff2214c9 in signal_emit_unlocked_R (node=node@entry=0x674f80, detail=detail@entry=1696, instance=instance@entry=0x898590, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffcc50) at gsignal.c:3549
#12 0x00000031ff229ed0 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffce20) at gsignal.c:3305
#14 0x00000031ff214175 in g_object_dispatch_properties_changed (object=0x898590 [SpiceDisplay], n_pspecs=<optimized out>, pspecs=<optimized out>) at gobject.c:1056
#15 0x00000031ff216661 in g_object_notify (pspec=0xa83370 [GParamBoolean], object=0x898590 [SpiceDisplay]) at gobject.c:1149
#16 0x00000031ff216661 in g_object_notify (object=0x898590 [SpiceDisplay], property_name=<optimized out>) at gobject.c:1197
#17 0x00007ffff7522525 in update_ready (display=0x898590 [SpiceDisplay]) at spice-widget.c:236
#18 0x00007ffff752257e in set_monitor_ready (self=0x898590 [SpiceDisplay], ready=0)
at spice-widget.c:244
#19 0x00007ffff75274e6 in primary_destroy (channel=0x89f5c0 [SpiceDisplayChannel], data=0x898590)
at spice-widget.c:2169
#20 0x00007ffff7528918 in channel_destroy (s=0x909fa0 [SpiceSession], channel=0x89f5c0 [SpiceDisplayChannel], data=0x898590) at spice-widget.c:2484
#24 0x00000031ff22a29f in <emit signal ??? on instance 0x909fa0 [SpiceSession]> (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3361
#21 0x00000031ff20fc45 in g_closure_invoke (closure=0xa9bda0, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7fffffffd280, invocation_hint=invocation_hint@entry=0x7fffffffd200) at gclosure.c:768
#22 0x00000031ff2214c9 in signal_emit_unlocked_R (node=node@entry=0x9c17d0, detail=detail@entry=0, instance=instance@entry=0x909fa0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffd280) at gsignal.c:3549
#23 0x00000031ff229ed0 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffd450) at gsignal.c:3305
#25 0x00007ffff71c3248 in spice_session_channel_destroy (session=0x909fa0 [SpiceSession], channel=0x89f5c0 [SpiceDisplayChannel]) at spice-session.c:2217
#26 0x00007ffff71bd8b2 in session_disconnect (self=0x909fa0 [SpiceSession], keep_main=0)
at spice-session.c:281
#27 0x00007ffff71c1b27 in session_disconnect_idle (self=0x909fa0 [SpiceSession]) at spice-session.c:1853
#28 0x00000031fee4a0ba in g_main_context_dispatch (context=0x6a4400) at gmain.c:3122
#29 0x00000031fee4a0ba in g_main_context_dispatch (context=context@entry=0x6a4400) at gmain.c:3737
#30 0x00000031fee4a450 in g_main_context_iterate (context=0x6a4400, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3808
#31 0x00000031fee4a772 in g_main_loop_run (loop=0x9890f0) at gmain.c:4002
#32 0x0000003babc05f75 in gtk_main () at gtkmain.c:1219
#33 0x000000000043143b in main (argc=1, argv=0x7fffffffda48) at virt-viewer-main.c:12
All the situations where virt_viewer_update_display() can fail are
those when we won't be able to connect regardless of what changes on the
remote host. So, propagate the error instead of waiting for the guest to
start.
Related: rhbz#1085216
Remove all the dialogs used to report errors on extract_connect_info()
and just propagate the errors we got from it.
The only exception is virt_viewer_domain_event(), that is a callback
that doesn't have GError as argument. In this specific case, we show the
error dialog instead of propagating it.
Related: rhbz#1085216
This is part of a small re-factoring that will have all connection
errors, when we won't be able to connect regardless of what changes on
the remote host, being treated by virt_viewer_app_initial_connect(),
avoiding weird behaviors as we have nowadays (like more than one error
dialog being shown or having the virt-viewer waiting forever for a guest
that will never show up).
Related: rhbz#1085216
This is part of a small re-factoring that will have all connection
errors, when we won't be able to connect regardless of what changes on
the remote host, being treated by virt_viewer_app_initial_connect(),
avoiding weird behaviors as we have nowadays (like more than one error
dialog being shown or having the virt-viewer waiting forever for a guest
that will never show up).
Related: rhbz#1085216
This is part of a small re-factoring that will have all connection
errors, when we won't be able to connect regardless of what changes on
the remote host, being treated by virt_viewer_app_initial_connect(),
avoiding weird behaviors as we have nowadays (like more than one error
dialog being shown or having the virt-viewer waiting forever for a guest
that will never show up).
Related: rhbz#1085216
It is safe to clean up when running virt-viewer without specifying
vm name if no vm was chosen. It brings back behavior before 88f6341.
The 'if (dom == NULL && err != NULL)' part was affected by commits
824c4b9, 1eaaf8c, 15c7d17 so the check for 'err' is not needed anymore.
Since the error is propagated to the main, report the error there.
To make it work GError VIRT_VIEWER_ERROR_FAILED is set for all
failing states and it is reported using virt_viewer_app_simple_message_dialog().
This applies for:
libvirt authentication dialog (e.g. virt-viewer --attach guest)
'recent connection' dialog (e.g. remote-viewer)
'vm choose' dialog when connecting without specifying the vm name
This is done by using a new GError VIRT_VIEWER_ERROR_CANCELLED.
Although commit 88f6341 allowed to use virt-viewer with a wrong guest name,
the user is informed about the nonexistent guest only by a dialog showing
the list of running machines or informing about the connection error.
Resolves https://bugzilla.redhat.com/show_bug.cgi?id=1201177
When using the configuration file to specify which remote monitors should be
enabled when using the --full-screen option, it sometimes left additional
displays enabled, or didn't place the displays on the right monitor, or didn't
fullscreen them.
This was especially true when not enabling the first display on the remote
host. For example:
monitor-mapping=2:2;3:3
(note that configuration file uses 1-based indexes, rather than 0-based
indexes, so the numbers used below will be 1 less than those above)
Previously, when performing fullscreen auto-conf, we were configuring displays
starting at #0 and ending at ndisplays. So for the previous configuration, we
looped from i = 0 to i < 2 (i.e. display #0 and #1) even though we should have
configured display #1 and #2. After this fix, we configure the exact displays
that were specified in the monitor-mapping configuration.
Resolves: rhbz#1200750
We don't need the added complexity of 'constructor', since we only want
to do some final initializing after all of the properties have been set,
etc. So just use the simpler 'constructed'.
When using the configuration file to specify which remote monitors
should be enabled when using the --full-screen option, it sometimes left
additional displays enabled, or didn't place the displays on the right
monitor, or didn't fullscreen them.
Part of the problem was that we were creating the first display window before
loading the monitor mapping configuration from the settings file. So even if
the first display was disabled in the configuration, the first window will
still be created with an id of 0, and therefore didn't get set to fullscreen.
Moving the main window creation to the 'constructor' vfunc instead of the
object init func ensures that the configuration is all loaded before we attempt
to do any fullscreen autoconf.
Related: rhbz#1200750
_update_displays_geometry() must be called every time a display is
enabled/disabled, avoiding gaps (when a display is disabled) or overlaps
(when a display is enabled) between the monitors.
This is what happens when we have 3 displays enabled (each one
represented by: width x height + x position + y position) ...
Display #0 Display #1 Display #2
+---------+ +----------+ +---------+
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
+---------+ +----------+ +---------+
(680x804+0+0) (504x804+680+0) (408x804+1184+0)
Whether the Display #1 is disable, a message will be sent down to the
vdagent, representing the new arrangement of the monitors:
Display #0 Display #2
+---------+ +---------+
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+---------+ +---------+
(680x804+0+0) (408x804+1184+0)
However, taking a look on the x position, a gap can be identified as
Display #0 starts at position (0,0) and has 680 pixels of width. But
Display #1 only starts at position (1184, 0), leaving 504 pixels as a
gap. The proper message, however, should represent the following
arrangement ...
Display #0 Display #2
+---------+ +---------+
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+---------+ +---------+
(680x804+0+0) (408x804+680+0)
... avoiding then gaps and overlaps.
Resolves: rhbz#1111425
https://bugzilla.redhat.com/show_bug.cgi?id=1111425
virt_viewer_app_set_connect_info() has a debug statement printing
gport/gtlsport. It checks that gtlsport is not NULL before printing it,
but makes no similar check for gport. Since it's possible to get a NULL
gport when using ovirt:// after the previous commit, it's better to check
it too.
If a remote oVirt VM don't specify a port/secure port number, we'd still
try to pass it down to spice-gtk, which would then complain that 0 (the
default value) isn't a valid port number.
This commit make sure we filter out the default port/secure-port value
and pass NULL to spice-gtk instead when we get these values.
When using ovirt://, the foreign menu will only be shown in the primary
window after getting notified about OvirtForeignMenu::files (ie when
it managed to fetch some ISO files to show in the foreign menu).
However, for secondary windows, the foreign menu will be added to the
window even if there are no files to show. This commit makes sure we
destroy the window foreign menu whenever it would be empty.
When parsing info returned by oVirt REST API, the hostname should be
present. However, I recently run remote-viewer against a buggy oVirt
instance where the hostname was missing. This commit handles better this
situation by displaying an error message and exiting.
VMs managed by oVirt can be hidden behind a proxy. This commit allows
remote-viewer to make use of this information when it's available
A recent oVirt instance is needed so that it's available through the
REST API, as well as libgovirt 0.3.3 or newer.
With older oVirt/libgovirt versions, the worst that can happen is a
runtime warning in the console, and an impossibility to connect to VMs
behind a proxy, so this commit is not raising the minimum libgovirt
requirement.
When connecting to a remote host (using qemu+ssh://...) that has a
virtual machine listening to "127.0.0.1", virt_viewer_is_reachable() must
take --direct into account, otherwise it can end up connecting to a local
virtual machine listening to "0.0.0.0" instead of returning that the
guest is not reachable.
Resolves: rhbz#1085216
