| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
G_SOURCE_REMOVE was introduced in GLib 2.32 and has its value defined as
FALSE.
|
|
|
|
| |
Caught by Covscan.
|
| |
|
|
|
|
|
| |
Functions name says it all, it is only implement for Spice, checking
for webdav channel presence.
|
| |
|
|
|
|
| |
Add a menu item Preferences under File and show the preferences dialog
|
| |
|
|
|
|
| |
Connect/disconnect webdav channel to enable or disable sharing folder
|
| |
|
|
|
|
| |
See properties comments for details.
|
| |
|
|
|
|
|
|
|
|
|
| |
It is deprecated since govirt 0.3.1 (and virt-viewer already depends on
govirt 0.3.2).
Silences:
(remote-viewer:19420): libgovirt-WARNING **: Passing a full http:// or https:// URI to ovirt_proxy_new() is deprecated
(remote-viewer:19420): libgovirt-WARNING **: Passing an URI ending in /api to ovirt_proxy_new() is deprecated
|
|
|
|
|
| |
Commit c3d24f8b sets transient parent for the most part of the
GtkDialogs, but seems like this one was forgotten.
|
|
|
|
|
|
|
|
|
|
|
| |
When connecting to a remote libvirt instance, a VM may only be listening
on localhost for SPICE/VNC connections. In such a situation, virt-viewer
then tries to connect to localhost, which is not correct as this
'localhost' referred to the remote libvirt host it connected to.
This commit adds a couple of tests on the libvirt URI used and the
<graphics> listen address to error out in this situation.
Resolves: rhbz#1108523
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to solve several problems with sizing and resizing displays, a
'map' handler was added to VirtViewerDisplay. The first time the map
handler runs, its queues a resize to attempt to ensure that the window
gets created at its desired size. Subsequent map events generate a call
to _make_resizable(), which was an attempt to ensure that the window was
always 'shrinkable' on the Microsoft Windows platform. Recent testing
suggests that this _make_resizable() is not actually necessary on
Windows anymore, since it is possible to shrink the display even when
this call is removed.
In addition, the call to _queue_resize() is a bit of an indirect
solution to the problem of ensuring the proper size at startup. What we
really want is to guarantee that the very first size request negotiation
returns the desired size rather than the minimum size. In order to do
this, we've added a flag to determine whether we've ever received a size
request, and if not, we return our desired size, even if 'dirty' is not
set.
|
|
|
|
|
|
|
|
|
| |
Using %d as a format-specifier for intptr_t causes a warning with
mingw64:
virt-viewer-events.c: In function 'virt_viewer_events_add_handle':
virt-viewer-events.c:103:5: warning: format '%d' expects argument of
type 'int', but argument 5 has type 'intptr_t' [-Wformat=]
g_debug("Converted fd %d to handle %d", fd, _get_osfhandle(fd));
|
|
|
|
|
| |
Silence the Gtk 3.14 message:
"GtkDialog mapped without a transient parent. This is discouraged."
|
|
|
|
|
|
|
|
| |
Setting the zoom-level using the command line option '--zoom' is not
working for vnc guests. This problem can be solved by emitting
the "display-desktop-resize" signal when vnc is initialized.
https://bugzilla.redhat.com/show_bug.cgi?id=1170071
|
|
|
|
|
| |
When running virt-viewer without argument, and no VM are found, you get
two error dialogs. Only one is enough.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SpiceSession in spice-gtk v0.27 will remove channels from session during
disconnect (and not when they are actually disposed). When no channels
are left, session-disconnected is emitted, and the VirtViewerSession
will be unref from the application. Use a weak reference to self to
avoid crashing after calling spice_session_disconnect()
As a workaround for existing clients, spice-gtk v0.27 will defer the
disconnection to idle time. But the fix still makes sense and would
prevent potentially future issues if spice-gtk changes back to sync
disconnection.
(the alternative of calling ref/unref would needlessly recreate a
SpiceSession with a call to create_spice_session(), which is something
we can avoid when leaving the application)
|
|
|
|
|
| |
Even when the server doesn't provide a display connection address,
virt-viewer is able to connect to guest with libvirt attach.
|
|
|
|
|
| |
Provide error details if the display can only be access through libvirt
--attach method.
|
|
|
|
| |
Use a UI dialog to inform of connection error.
|
|
|
|
|
|
|
| |
- do not overwrite err if ->initial_connect() sets it
- remove need for waitvm if the display server isn't yet started (note:
this function might be untested, I am not sure relying on libvirt events
is enough)
|
|
|
|
|
|
| |
- remove need for waitvm if the display server isn't yet started (note:
this function might be untested, I am not sure relying on libvirt events
is enough)
|
|
|
|
|
|
|
|
| |
Some refactoring to make the code easier to read, mostly code
movement/reindenting and introduction of a "wait" label which has the
same purpose as "done".
This also adds a "goto wait" within an if block, but this does not
change the initial code flow, just makes it more explicit.
|
|
|
|
|
|
| |
This error type isn't really an error, it is used to skip error report
code. The functions can simply return FALSE on failure, without GError
set, to indicate that program should quit normally.
|
| |
|
|
|
|
|
| |
This is libvirt specific, no need to share it in the VirtViewerApp base
class.
|
|
|
|
|
|
| |
This isn't required, but makes it easier to track reference issues, as
you have guarantee that callbacks won't be executed if the objects are
disposed.
|
|
|
|
| |
Once we have priv->domain_event, we don't need priv->withEvents anymore
|
|
|
|
|
| |
The usage of virConnectDomainEventRegister() is no longer recommended
according to the libvirt's documentation.
|
|
|
|
| |
Avoid a possible use/free after the object has been freed.
|
|
|
|
|
|
| |
Although all the used functions have a explicit check for a valid
virConnPtr, let's be safe and only use priv->conn when its value is
non-NULL.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's currently possible to destroy any virt-viewer window, including the
main window. However, some part of the code expects that the main window
is always present, for example to present status messages.
In particular, stopping the guest (or running virsh destroy) will close
all windows: virt_viewer_session_clear_displays will get called, which
will call into virt_viewer_app_remove_display_removed, and finally into
virt_viewer_app_remove_nth_window, which will destroy the window being
removed if it holds the last reference to it.
So going through virt_viewer_session_clear_displays, all
VirtViewerWindow instances and their corresponding GtkWindow have been
destroyed. This is already an issue as VirtViewerApp::main_window will
be pointing to freed memory.
When using virt-viewer --reconnect, this will cause a crash when
restarting the guest in virt_viewer_app_create_session as it tries to
get a valid GtkWindow through:
GtkWindow *window = virt_viewer_window_get_window(priv->main_window);
This commit avoids this issue by special casing the main window in
virt_viewer_app_remove_nth_window to ensure it never gets removed.
This is similar to what is done in virt_viewer_app_hide_all_windows.
|
|
|
|
|
|
|
| |
Commit 13f493200 changed virt_viewer_app_initial_connect to return a
gboolean rather than an int, but one call site was not updated to the
new convention, and was still checking for a negative value rather than
for FALSE in order to detect failures.
|
|
|
|
|
|
| |
As spice-gtk macro for checking the version numbers was broken, let's
check for 0.26 and avoid to have virt-viewer broken on a few distros
for a good long time.
|
|
|
|
| |
This was introduced in libvirt 1.0.6 but we only require libvirt 0.10.0
|
|
|
|
|
|
|
| |
This causes warnings with older compilers
virt-viewer-vm-connection.c:52: warning: declaration of 'select' shadows
a global declaration
/usr/include/sys/select.h:109: warning: shadowed declaration is here
|