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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
With glib 2.80 it will only examine G_MESSAGES_DEBUG env once for the
lifetime of the process. As a result our --debug flag has ceased to have
any effect.
This re-implements debugging using g_log_set_handler which works with
all glib versions, but requires us to implement timestamping ourselves.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
* Switch to using libvirt+minimal instead of libvirt project,
for shorter build times
* Actually do a git build job in CentOS Stream & AlmaLinux
* Drop AlmaLinux 8
* Update to latest Alpine versions
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
On Alpine, 'musl-dev' won't get pulled in by default, even if gcc is
asked for, and thus C programs won't link.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The project package lists previously held in libvirt-ci.git are
being moved into their respective project git repos.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently translated at 100.0% (182 of 182 strings)
Translation: virt-viewer/virt-viewer
Translate-URL: https://translate.fedoraproject.org/projects/virt-viewer/virt-viewer/zh_Hans/
Signed-off-by: eirik song <eirik.song@gmail.com>
Added translation using Weblate (Chinese (Simplified))
Signed-off-by: eirik song <eirik.song@gmail.com>
Translated using Weblate (Chinese (Simplified) (zh_CN))
Currently translated at 100.0% (182 of 182 strings)
Translation: virt-viewer/virt-viewer
Translate-URL: https://translate.fedoraproject.org/projects/virt-viewer/virt-viewer/zh_CN/
Signed-off-by: eirik song <eirik.song@gmail.com>
The application uses an application-id of
"org.virt-manager.virt-viewer" (see function
remote_viewer_new in src/remote-viewer.c).
So far, there was a mismatch between this
application-id and the desktop file name,
resulting e.g. in no proper window icon being
used when running the app on KDE Plasma Wayland.
Adjust the name of the desktop and appdata
files to match the application-id as expected.
Also update the translatable strings using this
command:
ninja -C _build virt-viewer-pot
Fixes: https://gitlab.com/virt-viewer/virt-viewer/-/issues/135
Signed-off-by: Michael Weghorn <m.weghorn@posteo.de>
The virt-viewer code currently only works with librest 0.7
/ libgovirt < 0.3.9.
Check for this condition in meson to prevent later compile
time errors.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Add a configuration file for codespell; it is tweaked to work on the
current codebase, i.e. skipping non-sources.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
The connection file created by oVirt contains the trusted CA.
When https://gitlab.gnome.org/GNOME/gtk-vnc/-/merge_requests/24 is
merged, we can pass this CA certificate to gtk-vnc to have it trusted.
This can replace manually putting the cacert.pem into ~/.pki/CA/
Signed-off-by: Jean-Louis Dupond <jean-louis@dupond.be>
The command depends on POSIX-compatible shell being the default shell on
the remote side of SSH, but that might not be the case. To make sure
the command gets parsed correctly this commit encloses it in extra
single quotes (to avoid it being parsed by the remote shell) and passes
that string as a parameter to `sh -c`.
Signed-off-by: Martin Kletzander <nert.pinx@gmail.com>
When using the result of find_program, meson may expand
it to include both an interpretor path and the script
path. If we then add the interpretor path too, we fail.
Using 'full_path()' ensures we get only the script path.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This refresh switches the CI for contributors to be triggered by merge
requests. Pushing to a branch in a fork will no longer run CI pipelines,
in order to avoid consuming CI minutes. To regain the original behaviour
contributors can opt-in to a pipeline on push
git push <remote> -o ci.variable=RUN_PIPELINE=1
This variable can also be set globally on the repository, though this is
not recommended. Upstream repo pushes to branches will run CI.
The use of containers has changed in this update, with only the upstream
repo creating containers, in order to avoid consuming contributors'
limited storage quotas. A fork with existing container images may delete
them. Containers will be rebuilt upstream when pushing commits with CI
changes to the default branch. Any other scenario with CI changes will
simply install build pre-requisite packages in a throaway environment,
using the ci/buildenv/ scripts. These scripts may also be used on a
contributor's local machines.
With pipelines triggered by merge requests, it is also now possible to
workaround the inability of contributors to run pipelines if they have
run out of CI quota. A project member can trigger a pipeline from the
merge request, which will run in context of upstream, however, note
this should only be done after reviewing the code for any malicious
CI changes.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The container jobs only exist if there was a dockerfile change in the
pipeline, so the dep from the 'codestyle' job needs to be marked as
optional
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The non-released bleeding edge distros have frequent packaging problems
that make it impossible to have reliable CI. Make them all optional
non-gating jobs.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This also includes an update of the translatable strings
from running `ninja -C _build virt-viewer-pot`.
Signed-off-by: Michael Weghorn <m.weghorn@posteo.de>
The positional parameter used to be treated as 'input', but since we
already set 'input' explicitly it is redundant. With latest meson
versions it now generates an error
data/meson.build:4:7: ERROR: Function does not take positional arguments.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We now display the current ISO as subtitle on the HeaderBar. On the
glade UI file, we get rid of the GtkAlignment object that was used to
put some space between the tree view and dialog buttons. The "Select
ISO" label is gone too.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
With the possibility of having ISO images in storage domains of DATA
type, we need to store the id of the object as well as its name. This is
not the case with ISO storage domains, which only hold the name of the
image. This patch makes it possible to use deal with both types
transparently for the user.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1835640
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
This function only existed to make use of glib compat, now that we
require a version of glib that already exports the symbol, the call is
not required anymore.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
This uses the command "lcitool manifest ci/manifest.yml" to re-generate
all existing dockerfiles and gitlab CI config.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is to be used with the command "lcitool manifest ci/manifest.yml"
to re-generate all existing dockerfiles and gitlab CI config.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The '-r' shortcut was alread used for '--reconnect' in virt-viewer.
The --auto-resize arg is a fairly niche use case so doesn't really
need a shortcut.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is implemented by switching from GTK accelerators to using the
display's grab sequence handling when a modifier-only hotkey is
configured.
Signed-off-by: Paul Donohue <git@PaulSD.com>
Previously, virt_viewer_update_smartcard_accels() and
virt_viewer_update_usbredir_accels() needed to be called after
configuring hotkeys and before any smartcard/usbredir devices were
connected in order to properly configure the hotkeys. However, those
were not called if hotkeys were configured via the config file.
In addition, the code did not support reconfiguring hotkeys after
devices were connected, which could cause future problems, eg. if a GUI
is added to support reconfiguring hotkeys.
Signed-off-by: Paul Donohue <git@PaulSD.com>
This is mostly just code de-duplication and cleanup. The only
functional change is that the case-sensitive accel support from the
command-line hotkey handling now also applies to the config file.
Signed-off-by: Paul Donohue <git@PaulSD.com>
"win.<action>" and "app.<action>" were mixed up in a few places.
Smartcard actions use "app" and other actions use "win".
Signed-off-by: Paul Donohue <git@PaulSD.com>
The next commit fixes a bug which was causing
gtk_application_get_accels_for_action() in
virt_viewer_update_smartcard_accels() to incorrectly return nothing.
Now that it is correctly working,
gtk_application_get_accels_for_action() is internally trying to call
gdk_keymap_get_for_display(), which fails if there is no available X11
display. This causes the CI pipeline to fail since the CI pipeline
doesn't have an X11 display.
To work around this, disable the smartcard hotkey test.
Signed-off-by: Paul Donohue <git@PaulSD.com>
It is no longer possible to just install an extra package to run regular
centos into centos stream.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Since glib >= 2.69 we get warnings:
../src/ovirt-foreign-menu.c: In function 'ovirt_foreign_menu_next_async_step':
../src/ovirt-foreign-menu.c:319:13: error: Not available before 2.60 [-Werror]
319 | G_GNUC_FALLTHROUGH;
| ^~~~~~~~~~~~~~~
../src/ovirt-foreign-menu.c:345:13: error: Not available before 2.60 [-Werror]
345 | G_GNUC_FALLTHROUGH;
| ^~~~~~~~~~~~~~~
../src/ovirt-foreign-menu.c:351:13: error: Not available before 2.60 [-Werror]
351 | G_GNUC_FALLTHROUGH;
| ^~~~~~~~~~~~~~~
../src/ovirt-foreign-menu.c:357:13: error: Not available before 2.60 [-Werror]
357 | G_GNUC_FALLTHROUGH;
| ^~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
GLib is right to warn about this, since it does not know that we
provided our own back-compat definition of the macro. For now we have to
temporarily purge glib's macro entirely in order to get rid of the
warning that is bogus for our usage.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The current docker:dind container has broken default seccomp filter that
results in clone3 being blocked, which in turn breaks Fedora 35 rawhide.
This custom image has a workaround that causes the seccomp filter to
return ENOSYS for clone3 instad of EPERM, thus triggering glibc to
fallback to clone correctly.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The desktop-width / desktop-height properties are set to have a min
valid value of 320x200, and this also matches the minimum window
dimensions reported to GTK.
In practice when a guest restarts, spice can report width/height
values smaller than this
(virt-viewer:9359): GLib-GObject-WARNING **: 12:57:05.556: value "64" of type 'gint' is invalid or out of range for property 'desktop-width' of type 'gint'
(virt-viewer:9359): GLib-GObject-WARNING **: 12:57:05.556: value "64" of type 'gint' is invalid or out of range for property 'desktop-height' of type 'gint'
There is not an obvious need to enforce this minimum on the properties,
as the window dimension sizing will do the right thing regardless.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When the last window is closed we optionally show a confirmation dialog
to check if user wants to quit. If the user cancels, we need to ensure
the display menu state gets set back to checked.
We called g_action_change_state correctly, but a later call to
g_simple_action_set_state used the "visible" variable which was not
correctly reset back to TRUE upon cancel.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If authentication fails we reshow the same authentication dialog box
again. Rather than leaving the previous incorrect information in the
text entry boxes we need to clear them.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We intentionally stopped generating a changelog from git history in the
switch to meson, since the tiny number of people who care can just look
at the git history directly. For end users the "NEWS" file is a more
consumable record of what's changed at a high level.
The empty ChangeLog was still in git though from the autoconf days and
thus ended up in the meson generated dist. It was also still mentioned
in syntax check rules and the RPM spec.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
%meson will force enable all features, so simply omitting the
BuildRequires is not sufficient to disable spice/ovirt. Meson
must be explicitly told to do so.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
My clang version 11.0.0 (Fedora 11.0.0-2.fc33) complains:
../src/virt-viewer-app.c:610:9: error: variable 'keymaps' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
if (keymap_string) {
^~~~~~~~~~~~~
../src/virt-viewer-app.c:614:10: note: uninitialized use occurs here
if (!keymaps || g_strv_length(keymaps) == 0) {
^~~~~~~
../src/virt-viewer-app.c:610:5: note: remove the 'if' if its condition is always true
if (keymap_string) {
^~~~~~~~~~~~~~~~~~~
../src/virt-viewer-app.c:595:27: note: initialize the variable 'keymaps' to silence this warning
gchar **key, **keymaps, **valkey, **valuekeys = NULL;
^
= NULL
1 error generated.
Initialize the variable to fix the uninitialized use.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
This fixes
commit 7040dded11aa363d54684da3295d8cd50a2eab3a
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Fri Feb 19 12:51:44 2021 +0000
icons: remove obsolete usb icon
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The gtk_accelerator_parse code is case sensitive when resolving key
names, however, the spice_hotkey_to_gtk_accelerator method converts
everything to uppercase. The latter allows the user to provide "f"
as the key and get it converted to "F" which matches a GDK key name.
The latter breaks for most other keys though, eg "comma" is required
to be all lowercase and "Menu" must have the initial capital.
To cope with this we try the gtk_accelerator_parse call twice, once
with the spice munged key name for back compat, and once with the
exact user specified key name.
https://gitlab.com/virt-viewer/virt-viewer/-/issues/30
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.
Translation: virt-viewer/virt-viewer
Translate-URL: https://translate.fedoraproject.org/projects/virt-viewer/virt-viewer/
Signed-off-by: Fedora Weblate Translation <i18n@lists.fedoraproject.org>
Update translation files
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.
Translation: virt-viewer/virt-viewer
Translate-URL: https://translate.fedoraproject.org/projects/virt-viewer/virt-viewer/
Signed-off-by: Fedora Weblate Translation <i18n@lists.fedoraproject.org>
GTK-VNC has native support for remote desktop resize, provided that we
always give the widget the full available allocation. This requires that
we turn off VirtViewerDisplay's code for keeping aspect ratio, and
instead enable GTK-VNC's equivalent.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When the VirtViewerDisplay class resizes the child display widget, it
attempts to preserve the remote desktop aspect ratio. This is useful in
general, if the display widget can't do this itself. The implication,
however, is that VirtViewerDisplay also has to take ownership of the
remote framebuffer resize functionality.
It is thus useful to disable VirtViewerDisplay's aspect ratio
preservation when the display widget can do this natively, as it can
then also do desktop resizes natively.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently the GActionMap is registered during the application
startup. This takes place after the command line args are processed,
so prevents the CLI processing from using actions.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Normally we will honour the server requested behaviour for cursor,
either letting the server render it directly, or locally rendering
a cursor that the server provided us.
There are times, however, where the server does the wrong thing. For
example it might tell us to render an empty cursor, leaving the user
with no visible cursor at all. In this case it can be helpful to ignore
what the server requests, and always display the default local cursor.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
SPICE provides a number of VM actions, but they are only supported if
the QMP tunnel is available. VNC doesn't currently support any, but
in future it will support some.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This ensures that the application exits when the user presses Ctrl-C
while an auth dialog is open.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This improves the UI for the password auth box by using an inline icon
for showing/hiding the password text. This is the UI pattern uses by
GNOME shell and other GTK applications.
The two svg files added here are copied from the GTK4 codebase which
is under the LGPLv2+.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If you press Ctrl-C while the auth dialog is active it gets ignored
because calling g_application_quit() won't break out of the model
g_dialog_run() call.
By removing the SIGINT handler after first firing, we can at least let
the user press Ctrl-C a second time to force quit.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Gtk uses the application ID to lookup resource entries compiled into the
application. The application ID must match the path in the gresource.xml
file for this to work correctly.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Without gtk-vnc we get implicit function declaration for
VIRT_VIEWER_IS_SESSION_VNC. Introduced at 8bc91ac "session: remove
"session-error" signal" in 2021-02-18
As we are already using #ifdef here, I've also changed the ternary to
an if for clarity.
Signed-off-by: Victor Toso <victortoso@redhat.com>
This needs to be set via an env variable so that it can be overridden by
vendors building their own MSIs downstream.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The download site is on virt-manager.org, not virt-tools.org, so lets
use that site, with TLS too.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
While the window titlebar already displays the ungrab sequence when a
grab is active, it doesn't hurt to also document it upfront for people.
Fixes https://gitlab.com/virt-viewer/virt-viewer/-/issues/10
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The MSI file can contain different content with each change in build ID,
but the filename never changes. This creates confusion as to whether the
MSI is actually up to date or not. It requires the looking inside the
MSI to see the encoded version.
The RPM uses 2 components from the %release field as input for the build
ID value. Use these as two parts of the filename, separated from the
version with a "-" similar to how RPM version/release are separated.
IOW, an RPM
mingw32-virt-viewer-msi-9.0-1.fc33.noarch.rpm
will result in
virt-viewer-x64-9.0-1.0.msi
while
mingw32-virt-viewer-msi-9.0-1.fc33.1.noarch.rpm
will result in
virt-viewer-x64-9.0-1.1.msi
Essentially we've just stripped the %dist part (".fc33") out of
the release, and default the second component to "0" if omitted.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This enables the app to use the dark theme when running in environments
where a dark theme is available.
This is not done in Windows because the dark theme looks quite odd when
run on older versions of Windows where GTK can't replace the titlebars
by default.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The header bar includes space for both a title and subtitle. By using
the latter for the ungrab hint, we avoid having such a long title.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The user interface for the fullscreen toolbar is now identical to that
seen when non-fullscreen. All that differs is that the toolbar autohides
in fullscreen mode and doesn't expand to fill the window width.
There is a complication with the timed revealer and menus. With
traditional GtkMenus, it appears a grab is held as long as the menu is
open, so the revealer won't hide the toolbar. With modern GtkPopover
based menus, however, the revealer hides the toolbar despite the menu
being open, and thus in turn hides the menu.
This hacks around the problem by setting the header buttons to force use
of a traditional GtkMenu instead of a GtkPopover. It is not quite as
visually pretty, but at least it works.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This removes the main menu bar in favour of using the GtkHeaderBar with
integrated bars. This reduces the amount of vertical screen real estate
consumed by the application, leaving more for the guest display. The new
buttons are laid out to make the more common actions available with a
single click.
The buttons are grouped into two sets. On the left hand side of the
header are buttons that are interacting with the server
- Send key
- USB device selection
- Monitor selection and VM pause/shutdown
whle on the right hand side are buttons interacting with the local user
interface
- Fullscreen
- Preferences / About / Guest detail / zoom level
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The machine pause/reset/powerdown and smartcard insert/remove operations
can implemented directly by the application class as they require no UI.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The first time this method is called we know that
usb_device_reset_accel_valid will be FALSE.
The other times this method is called all pass override=TRUE.
Thus the conditional test in virt_viewer_set_usb_device_reset_accel
always evaluates to TRUE and thus can be removed.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If the VncDisplay emits a signal and the VirtViewerSessionVnc
instance is no longer valid, using the pointer inside one of the
callbacks can lead to segfault.
To prevent that, use g_signal_connect_object instead of
g_signal_connect.
Related:
https://bugzilla.redhat.com/show_bug.cgi?id=1911224
Signed-off-by: Jakub Janků <jjanku@redhat.com>
This partially reverts commit de5cd71.
Problem with that commit is, that it practically renders
the "session-auth-*" signals from vnc session useless.
That's because gtk-vnc currently emits "vnc-error" before each
"vnc-auth-*" signal and the error callback in virt-viewer-app.c
calls virt_viewer_app_disconnected(), which in turn closes
the session.
As a consequence, virt-viewer never retries authentication
with vnc, it simply exits.
Since the last commit, vnc, similarly to spice, emits
"session-disconnected" with the appropriate error message. Thus
there's no need to maintain separate "session-error" signal
for now.
With vnc, this error message is shown to the user in a dialog,
if the disconnect happened during the init phase.
"session-auth-*" callbacks create their own dialogs, so
initialized must be set to TRUE to avoid having a dialog
displayed twice.
Related:
https://bugzilla.redhat.com/show_bug.cgi?id=1911224
Signed-off-by: Jakub Janků <jjanku@redhat.com>
"vnc-error" is always followed by "vnc-disconnected".
So save the error message and use it in "vnc-disconnected" callback.
"session-disconnected" already allows us to set a string
with details on why the disconnection happened.
This approach is also similar to the one in spice session
(GError is saved in virt_viewer_session_spice_channel_destroyed).
Signed-off-by: Jakub Janků <jjanku@redhat.com>
Instead of repeating an emacs footer in every source file, use config
files in the root of the repository. This fixes the bug that several
source files are missing the indent rules.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
All our targetted distros have this vintage glib letting us remove some
compat code, and introduce future use of new features.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Check whether accels are currently attached to a window before attaching
them when enabling window modifiers.
This commit fixes an assert in _gtk_accel_group_attach introduced by
cfcac9fb, which erroneously assumed that is harmless to re-add accel
groups that have already been added to a window.
Signed-off-by: Shawn M. Chapla <schapla@codeweavers.com>
A new 'codestyle' job is added for syntax-check, since that is not run
as part of the 'dist' target.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The USB SVG was mistakenly installed into a size specific dir, while the
main logo was not installed at all.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We know that the destination will already have a trailing NUL after the
three characters we're copying. The compiler can't see this though and
warns about lack of NUL termination.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This ensures that G_LOG_DOMAIN is used in all places, and in turns
highlights a bug in the test suite.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The gnulib syntax-check rules are spread across GNUmakefile, cfg.mk and
maint.mk. This made sense when we were getting two of the files from the
gnulib submodule. Now that we own all files though, we can at least
merge maint.mk and cfg.mk together. GNUmakefile can be eliminated when
we switch to meson.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The standard maint.mk from gnulib provides alot more than just the
'syntax-check' target. This can all be purged to give a more minimal
file.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We can assume that the distros we target have sufficiently new versions
of all our dependencies.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Following commit de5cd71, when the server closes the connection
(likely when qemu-kvm exits), a dialog is shown to the user.
This behavior change is not good for automatic tests that expect
virt-viewer to exit without any dialog.
This patch makes sure no dialog is shown for this error, by
checking if the VNC connection was already initialized.
Signed-off-by: Uri Lublin <uril@redhat.com>
If a user sets any hotkey, disable numpad hotkeys.
If a user does not set any hotkey and the default hotkeys
are enabled, then numpad hotkeys are enabled too.
This is a folloup for commits a40c8f4 and e89e82e + 8cc0667.
Currently setting (e.g. ctrl [123]) hotkeys for zoom (in/out/reset),
re-enable the default numpad hotkeys (ctrl [+-0]).
Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1791261
Suggested-by: Jakub Janků <jjanku@redhat.com>
Signed-off-by: Uri Lublin <uril@redhat.com>
Hotkeys should be disabled in kiosk mode. However, if no
"release-cursor" hotkey is specified, the default Ctrl+Alt
grab sequence keeps functioning even in kiosk mode.
That's because it's based on the spice/vnc functionality instead
of on the accelerators in virt-viewer.
That's especially problematic with spice, because the grab
sequence releases both the cursor and the keyboard. Thus the user
can escape from kiosk mode by pressing Ctrl+Alt followed by
Alt+Tab, for example.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1893584
Signed-off-by: Jakub Janků <jjanku@redhat.com>
A recent CentOS-8 update renamed the "PowerTools" repo to "powertools"
and since dnf is case sensitive wrt repo names, this broke ability to
build new containers.
The refresh fixes the repo name and pulls in other misc improvements
to containers.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If a vv file is used or the hotkeys are customized using the
--hotkeys cmd option, all hotkeys that are not explicitly
requested get disabled, this includes the zomm hotkeys.
As a consequence, the labels for zoom actions in the menu
disappear. However, the user can still perform these actions
using the keys on the numpad which are handled separately.
To fix it, check that the normal zoom hotkeys are enabled
before enabling the keypad ones.
Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1791261
Signed-off-by: Jakub Janků <jjanku@redhat.com>
There is nothing that would disable any aspect of kiosk mode that would
ever need to be enabled with a call to virt_viewer_window_show. To the
contrary, "re-enabling" kiosk mode in virt_viwer_window_show can, in
certain cases, result in accels becoming disable despite the keyboard
being released.
Signed-off-by: Shawn M. Chapla <schapla@codeweavers.com>
Previously, enabling window modifiers would only add accel groups that
had presumably been disabled to the window in question. This was fragile
and caused bad behavior in cases when the criteria for whether or not an
accel group should be enabled changed between the time the groups were
disabled and re-enabled, potentially leading to certain groups never
being re-added. There is no harm in adding accel groups that are already
added to a window, so this change simply eliminates the unnecessary
check.
Signed-off-by: Shawn M. Chapla <schapla@codeweavers.com>
Adds a "USB device reset" default keyboard shortcut (ctrl+shift+r), as
well as the option to override this shortcut with the --hotkeys opt.
Updates documentation accordingly.
Signed-off-by: Shawn M. Chapla <schapla@codeweavers.com>
Adds a "USB device reset" option to the File menu. When selected, "USB
device reset" will disconnect and reconnect all currently connected USB
devices.
Signed-off-by: Shawn M. Chapla <schapla@codeweavers.com>
Error: DEADCODE (CWE-561): [#def1]
virt-viewer-9.0/src/virt-viewer-display-vte.c:164: assignment: Assigning: "scroll" = "NULL".
virt-viewer-9.0/src/virt-viewer-display-vte.c:188: null: At condition "scroll", the value of "scroll" must be "NULL".
virt-viewer-9.0/src/virt-viewer-display-vte.c:188: dead_error_condition: The condition "scroll" cannot be true.
virt-viewer-9.0/src/virt-viewer-display-vte.c:189: dead_error_begin: Execution cannot reach this statement: "gtk_container_add((GtkConta...".
virt-viewer-9.0/src/virt-viewer-display-vte.c:189: effectively_constant: Local variable "scroll" is assigned only once, to a constant value, making it effectively constant throughout its scope. If this is not the intent, examine the logic to see if there is a missing assignment that would make "scroll" not remain constant.
Reported in https://gitlab.com/virt-viewer/virt-viewer/-/issues/7.
Signed-off-by: Frediano Ziglio <freddy77@gmail.com>
By default when connecting with VNC, an existing viewer will be kicked
off. This adds a --shared / -s flag which tells the server we are
willing the share the session with other clients.
This is wired up for VNC only.
https://bugzilla.redhat.com/show_bug.cgi?id=1060425
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This way the custom rules for translating MIME types are used, and thus
the MIME type XML files are properly extracted.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Since gettext is used to extract this file, there is no more need to
prefix the translatable tags with underscore as intltool required.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Even if the view has search capabilities built-in, show the VM names
sorted so it is easier to visually search for them.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Add a new column in the list models for the VM selection dialog, and use
this new column to hold the tooltip of the items in the list.
At the moment nothing is set in the new column, so there is no behavior
change.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Add a new column in the list models for the VM selection dialog, and use
this new column to hold the key of the VM. This way, the first column
represents the UI representation of the VM without affecting the key.
At the moment the VM name is set for both, so there is no behavior
change.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
It was released almost 6 years ago, so already available for a long time
in supported distributions. This way, it is possible to use
virDomainOpenGraphicsFD without checks.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
- use the "desktop-application" component instead of the old "desktop"
- do not specify a type for the id, and remove the .desktop suffix;
it is implicit for type=desktop-application
- move the URLs of screenshots within <image> tags
- simply remove the non-standard <updatecontact>, instead of converting
it to <url type="contact">, as it is the same
- add URLs for the bug tracking, and the translation system
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
The canonical location for AppStream XML files has been changed to
/usr/share/metainfo four years ago at least, with /usr/share/appdata
left as legacy location. It is time to switch to the right location.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
All the g_printerr does is printing the message of the GError with a
newline at the end. Hence, use a simple format string without the need
to translate it.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Currently there is a strings with four placeholders that represents
optional bits: the "press to release", a whitespace (!), the subtitle,
and the application title. This is suboptimal, because it hides the way
the title is composed, and makes it hard to properly translate.
Instead of this string puzzle, create separate strings for each case
(there are only four of them, and one is only the application title).
Each of the string has all the static text availale, with a proper
comment explaining the layout.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Give them a context to explain what is the "unknown thing", so it is
possible to provide proper translations.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Turn the menu labels into GTK accelerator strings, so we can parse them
to convert them into a proper user representation.
There is a small behaviour change: the menu items do not have mnemonics
anymore by default.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Switch the homepage URL to https, and synchronize the label with the
URL. Also, do not make the label translatable, as it is pointless (it is
only a URL).
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Use the standard gpl-2-0 license type of GtkAboutDialog, instead of the
custom license text: this way, the dialog will show a translated text
with the license type, and a link to the full license text.
As side change due to the editing of this file in glade 3.36: set the
logo icon name to "virt-viewer", even if at runtime a logo/image will be
loaded. glade needs a logo set, either as icon name or as pixmap.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Instead of showing just a generic error with a list of files group
files by error and show them.
This solves https://bugzilla.redhat.com/show_bug.cgi?id=1753563
Signed-off-by: Frediano Ziglio <freddy77@gmail.com>
The default key accelerator to release mouse if left control and
left alt but the current description is "Ctrl+Alt", change to
"Ctrl_L+Alt_L" to avoid misunderstanding.
This solves https://bugzilla.redhat.com/show_bug.cgi?id=1548371
Signed-off-by: Frediano Ziglio <freddy77@gmail.com>
Weblate gets confused if the same email address is mentioned multiple
times in the translation headers. Dedupe authors so that each author
is mentioned only once, with a range of years listed.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Weblate works a slightly different way than Zanata. Instead of manually
pushing a pot file and fetching po files, Weblate is going to work
automatically with GitLab Merge requests. The main pot file must be
committed to git, and then Weblate fully manages the .po files, using
merge requests to send updates back.
With this new system we don't have a separate .mini.po file. The main
.po file is partially minimized by removing locations but does not
have non-translated msgids removed. This is not a big downside if we
consider that over time most translations should trend towards 100%
translated, and we have purged all 100% non-translated languages.
The main .pot file is generated with alphabetic sort ordering instead
of the default source file location ordering, as this makes the diffs
stable across renames/code movement, which is something we used in the
old .mini.po files.
The only rules needed in the makefile are to refresh the .pot file
and to generate the .gmo files at install time. We must never touch
the .po files locally, not even to rebase them when the .pot is
updated, as that will create merge conflicts with Weblate. Weblate
will take care of all rebases of the .po files in its own fork of
the git repo, and open merge requests to send changes back when
needed.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There is no benefit to keeping .po files in git for languages which
have zero translated strings. make should also be honouring the list
in the LINGUAS file, not repeating it.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Previously meson searched $PATH for libgcrypt-config, but it no longer
does this for cross-builds.
The dockerfile changes can be dropped when the following hits rawhide
container images:
https://bugzilla.redhat.com/show_bug.cgi?id=1856446
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Do not leak memory in case of task cancelled.
Quote "msg" in case it contains some no-xml character that could
came from translated strings.
Signed-off-by: Frediano Ziglio <freddy77@gmail.com>
Make "modifiers" static, potentially avoids a copy to stack.
Use G_N_ELEMENTS also to allocate keys, as in the next loop
allowing to easily change "modifiers" size.
Signed-off-by: Frediano Ziglio <freddy77@gmail.com>
Instead of a fail simply reply that there are no ISO files.
Message text was suggested by Radek Duda who reported the issue.
Signed-off-by: Frediano Ziglio <freddy77@gmail.com>
Currently on every distro we build against the latest git libvirt
and related deps. We need to test multiple axis:
- A variety of libvirt versions
- A variety of distro versions
So this changes most jobs to build against the distro provided
libvirt and related deps. The CentOS 8 job is kept building
against latest git master libvirt and deps.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We get this indirectly via govirt, but since we directly use its APIs,
we should list it as an explicit dep too.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that we support both ISO and DATA storage domain types, we need to
make sure that the files are listed correctly. In this case we give the
domains of ISO type the precedence over DATA ones.
This change extends previous commit bbda3aa which made it possible for
storage domains of type DATA to be considered valid.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Unlike the StorageDomain objects of ISO type, the DATA ones require a
specific API recently added to libgovirt to support them. This commit
makes use of those new functions under #ifdef guards and adds proper a
check to configure.ac.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1847223
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
This prevents the silent overwriting of the file, and still makes sure the user knows why we don't proceed.
Fix BZ#1752514
Signed-off-by: Julien Ropé <jrope@redhat.com>
Instead of building our own DCO check image, just reuse the common image
provided by the libvirt-ci project.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The current code is using a single event handler for leave/enter and
looking at the mouse coordinates to decide whether it entered or left
the widget. This logic is completely broken when the window is
mimimized, because the mouse coordinates of the leave event are still
within the window boundary.
Switch to just have a separate handler for enter/leave events and stop
looking at mouse coordinates entirely.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The project primary git repo has moved from pagure.io to
gitlab.com/virt-viewer/virt-viewer. We want users to submit
code contributions, bug reports and support questions to the
gitlab project, not the mailing list, nor bugzilla, nor the
virt-manager.org site.
We're still using virt-manager.org for hosting downloads of
source and pagure.io for MSIs, but we'll aim to change that
too.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The error code returned by virt_viewer_session_open_fd() and
virt_viewer_session_channel_open_fd() were not checked. The file
descriptor passed to them could then be left opened even if the function
failed, causing a leak of resources.
This was reported by a Coverity scan, logged under
https://bugzilla.redhat.com/show_bug.cgi?id=1655792
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Julien Ropé <jrope@redhat.com>
When doing a screenshot, if the user provides a filename without a file
extension, an error occurs because the image format could not be determined.
This patch adds a .png extension to such filenames, so that there is a default
file format for screenshots.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1752514
Reviewed-by: Victor Toso <victortoso@redhat.com>
Signed-off-by: Julien Ropé <jrope@redhat.com>
When the application is stopped, if the windows are in fullscreen, their
position on the client will be remembered.
This change uses the existing option 'monitor-mapping' in the settings
file to save the position and reuse it on next launch.
This implements part of the requirement from
https://bugzilla.redhat.com/show_bug.cgi?id=1179070
NOTE: this feature is effective only with GTK >= 3.22
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Julien Ropé <jrope@redhat.com>
When remote-viewer is started from terminal, CTRL-C sends a SIGINT
signal to the program causing immediate termination. On linux clients
usb redirected devices are left without any kernel driver attached,
causing them to appear as no more available to the host.
Add a SIGINT handler to allow a clean exit, in particular to allow
the kernel to attach back the host driver.
The issue is present on linux only.
To perform usb device redirection, virt-viewer leverages spice-gtk
library, which in turn relies on usbredir library, which uses libusb.
In order to take control of the usb device the auto-loaded kernel
driver must be detached. This is achieved (in the very end) with
libusb_detach_kernel_driver(). Then the device interfaces can be claimed
with libusb_claim_interface() and get in control to the application.
During normal application termination, the usb channel is teared down,
performing a reset of the usb device and giving back the control of the
device to the kernel (libusb_attach_kernel_driver()).
If the application quits without doing this, the device interfaces will
end up with no driver attached, making them not usable in the host
system.
Note that enabling libusb_set_auto_detach_kernel_driver() does not solve
the issue, as this is just a convenient API from libusb: libusb will
take care of detaching/attaching the driver to the interfaces of the usb
device each time a call to libusb_release_interface() and
libusb_claim_interface() is performed. An unexpected quit of the
application will skip the libusb_release_interface() call too, leaving
the interfaces without any driver attached.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1713311
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Francesco Giudici <fgiudici@redhat.com>
Since oVirt engine version 4.3.2.1, the API returns certificate data for
display connection in the VM XML, so users do not need to specify it
from the command line anymore. The certificate obtained from the XML
gets precedence over the one from the command line, which is still kept
to keep compatibility of older versions of oVirt.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1402909
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
On remote_viewer_session_connected() we are passing a dup of URI of
connection and freeing it afterwards. Problem is, we don't disconnect
from listening "session-connected" and on an eventual second emission
of this signal, remote-viewer crashes as seen in the backtrace below.
This can happen over switch-host migration message from
SpiceMainChannel.
A fix trying to use VirtViewerApp URI avoid the crash but introduces
regression while running remote-viewer with ovirt so, keeping the
changes to a minimum to avoid it, just use g_intern_string() for now.
Found it while improving migrate.py from spice/tests (server):
| Invalid free() / delete / delete[] / realloc()
| at 0x4839A0C: free (vg_replace_malloc.c:540)
| by 0x56EBD8C: g_free (in /usr/lib64/libglib-2.0.so.0.6000.6)
| by 0x11DED0: remote_viewer_session_connected (remote-viewer.c:658)
| by 0x564D741: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x56614F3: ??? (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x566A34D: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x566AF68: g_signal_emit_by_name (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x135E5D: virt_viewer_session_spice_main_channel_event (virt-viewer-session-spice.c:699)
| by 0x564D741: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x56614F3: ??? (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x566A34D: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x53149E3: emit_main_context (gio-coroutine.c:198)
| Address 0x18f1ecc0 is 0 bytes inside a block of size 23 free'd
| at 0x4839A0C: free (vg_replace_malloc.c:540)
| by 0x56EBD8C: g_free (in /usr/lib64/libglib-2.0.so.0.6000.6)
| by 0x11DED0: remote_viewer_session_connected (remote-viewer.c:658)
| by 0x564D741: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x56614F3: ??? (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x566A34D: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x566AF68: g_signal_emit_by_name (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x135E5D: virt_viewer_session_spice_main_channel_event (virt-viewer-session-spice.c:699)
| by 0x564D741: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x56614F3: ??? (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x566A34D: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x53149E3: emit_main_context (gio-coroutine.c:198)
| Block was alloc'd at
| at 0x483880B: malloc (vg_replace_malloc.c:309)
| by 0x56EBC98: g_malloc (in /usr/lib64/libglib-2.0.so.0.6000.6)
| by 0x5705C43: g_strdup (in /usr/lib64/libglib-2.0.so.0.6000.6)
| by 0x11EB80: remote_viewer_initial_connect (remote-viewer.c:696)
| by 0x11EB80: remote_viewer_start (remote-viewer.c:790)
| by 0x1250D3: virt_viewer_app_start (virt-viewer-app.c:1727)
| by 0x127108: virt_viewer_app_on_application_startup (virt-viewer-app.c:1870)
| by 0x564D741: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x5661638: ??? (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x566A34D: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x566A972: g_signal_emit (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x553ECA1: g_application_register (in /usr/lib64/libgio-2.0.so.0.6000.6)
| by 0x553F41D: g_application_run (in /usr/lib64/libgio-2.0.so.0.6000.6)
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Error caught by valgrind, the OvirtCollection object created in function
ovirt_foreign_menu_fetch_vm_async() was never freed.
433 (40 direct, 393 indirect) bytes in 1 blocks are definitely lost in loss record 16,708 of 17,677
at 0x5868FDF: g_type_create_instance (in /usr/lib64/libgobject-2.0.so.0.6000.6)
by 0x584B42C: ??? (in /usr/lib64/libgobject-2.0.so.0.6000.6)
by 0x584D347: g_object_new_valist (in /usr/lib64/libgobject-2.0.so.0.6000.6)
by 0x584D69C: g_object_new (in /usr/lib64/libgobject-2.0.so.0.6000.6)
by 0x558E823: ovirt_collection_new (ovirt-collection.c:304)
by 0x558E98C: ovirt_sub_collection_new_from_resource_search (ovirt-collection.c:375)
by 0x42D510: ovirt_foreign_menu_fetch_vm_async (ovirt-foreign-menu.c:994)
by 0x42D510: ovirt_foreign_menu_next_async_step (ovirt-foreign-menu.c:316)
by 0x42D70D: api_fetched_cb (ovirt-foreign-menu.c:1025)
by 0x570BC19: ??? (in /usr/lib64/libgio-2.0.so.0.6000.6)
by 0x570C7EC: ??? (in /usr/lib64/libgio-2.0.so.0.6000.6)
by 0x559005D: call_async_cb (ovirt-proxy.c:279)
by 0x55B5A07: ??? (in /usr/lib64/librest-0.7.so.0.0.0)
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
In the case of having a valid storage domain without any ISO files, this
variable can be reset to FALSE again in the next iteration of the loop,
resulting in a misleading error message presented to the user.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
gmaovirt-foreign-menu.c: In function 'storage_domains_fetched_cb':
ovirt-foreign-menu.c:721:9: error: format not a string literal and no format arguments [-Werror=format-security]
721 | g_debug(msg);
| ^~~~~~~
ovirt-foreign-menu.c:722:9: error: format not a string literal and no format arguments [-Werror=format-security]
722 | g_task_return_new_error(task, OVIRT_ERROR, OVIRT_ERROR_FAILED, msg);
| ^~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
gmake[3]: *** [Makefile:963: libvirt_viewer_la-ovirt-foreign-menu.lo] Error 1
gmake[2]: *** [Makefile:647: all] Error 2
gmake[1]: *** [Makefile:482: all-recursive] Error 1
make: *** [Makefile:410: all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.f14Lmj (%build)
Errors have been caught by https://ci.centos.org/job/virt-viewer-rpm/systems=libvirt-fedora-rawhide/589/
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Instead of fetching toplevel REST API query, we use the one relative
from the data center, which returns more detailed information,
especially the status of the storage domain.
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1427467
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
This patch improves the error shown to the user when a file transfer
fails.
The previous behavior was to create a simple message dialog box, with
the error description and the full list of the files that failed to be
transferred. When the list of files was long, the dialog box would
grow bigger than the screen.
Now, the file list is inserted inside a scrollable widget, whose
height is limited to 170px.
NB: these two calls would be more adapted, but they require GTK >=
3.22:
> gtk_scrolled_window_set_max_content_height(GTK_SCROLLED_WINDOW(scrolled_window), 170);
> gtk_scrolled_window_set_propagate_natural_height(GTK_SCROLLED_WINDOW(scrolled_window), TRUE);
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1496356
Signed-off-by: Kevin Pouget <kpouget@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
With this change one can get list of domains on the command line:
$ virt-viewer -c qemu:///system <TAB><TAB>
dom1 dom2 ... domN
The list of domains is fetched using virsh, hence the dependency
on libvirt-client recorded in the spec file. I think it's fair
to assume that Linux hosts with virt-viewer will have virsh
available too. If they don't, nothing breaks and no error message
is printed.
The completer script is inspired by libvirt.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Use saved CFLAGS and LIBS to avoid errors in the check programs.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Due to changes in commit 65ef66e4, when the initial connection fails,
virt-viewer just sat quietly and didn't indicate what was wrong. It also
did not exit as it did before. This is because we were using
virt_viewer_session_spice_channel_destroy() incorrectly. This function
was intended to be a callback that is called to clean up the VV session
when the SpiceSession tells us that a channel has been destroyed. It
does not actually destroy the channel, it only cleans up references to
that channel within virt-viewer. After calling this function, the
channel is not affected in any way. If the channel object was valid
before calling the function, it will be valid and unchanged after
calling the function as well.
The problem is that before commit 65ef66e4, this function
(_channel_destroy()) also had a side-effect of emitting a signal that
made us think that the SpiceSession was disconnected when it was not.
The application responded to this signal by exiting even though the
session was not properly disconnected and cleaned up.
We now no longer exit the application until the SpiceSession is properly
disconnected and cleaned up. So we need to make sure that this happens
when our initial connection fails. Therefore, when the main channel
receives an error channel-event, we should not call
virt_viewer_session_spice_channel_destroy(). This function should only
be called when a channel has actually been destroyed, and the channel is
not destroyed at this point. We should instead explicitly disconnect
the session, which will result in the channels being destroyed properly.
After the session destroys all of the channels, the 'channel-destroy' signal
will be emitted by SpiceSession, so the _channel_destroy() function will
eventually get called by the signal handler.
To make the proper use of the function more obvious, I also changed the
function name from _channel_destroy() to _channel_destroyed() and added
a comment.
Fixes: rhbz#1666869
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Similar to the virt-viewer.pot, .po files contain line numbers and file
names identifying where in the source a translatable string comes from.
The source locations in the .po files are thrown away and replaced with
content from the virt-viewer.pot whenever msgmerge is run, so this is not
precious information that needs to be stored in git.
When msgmerge processes a .po file, it will add in any msgids from the
virt-viewer.pot that were not already present. Thus, if a particular msgid
currently has no translation, it can be considered redundant and again
does not need storing in git.
When msgmerge processes a .po file and can't find an exact existing
translation match, it will try todo fuzzy matching instead, marking such
entries with a "# fuzzy" comment to alert the translator to take a
look and either discard, edit or accept the match. Looking at the
existing fuzzy matches in .po files shows that the quality is awful,
with many having a completely different set of printf format specifiers
between the msgid and fuzzy msgstr entry. Fortunately when msgfmt
generates the .gmo, the fuzzy entries are all ignored anyway. The fuzzy
entries could be useful to translators if they were working on the .po
files directly from git, but Virt-Viewer outsourced translation to the
Fedora Zanata system, so keeping fuzzy matches in git is not much help.
Finally, by default msgids are sorted based on source location. Thus, if
a bit of code with translatable text is moved from one file to another,
it may shift around in the .po file, despite the msgid not itself changing.
If the msgids were sorted alphabetically, the .po files would have
stable ordering when code is refactored.
This patch takes advantage of the above observations to canonicalize
and minimize the content stored for .po files in git. Instead of storing
the real .po files, we now store .mini.po files.
The .mini.po files are the same file format as .po files, but have no
source location comments, are sorted alphabetically, and all fuzzy
msgstrs and msgids with no translation are discarded. This cuts the size
of content in the po directory.
Users working from a virt-viewer git checkout who need the full .po files
can run "make update-po", which merges the virt-viewer.pot and .mini.po
file to create a .po file containing all the content previously stored
in git.
Conversely if a full .po file has been modified, for example, by
downloading new content from Zanata, the .mini.po files can be updated
by running "make update-mini-po". The resulting diffs of the .mini.po
file will clearly show the changed translations without any of the noise
that previously obscured content. Being able to see content changes
clearly actually identified a bug in the zanata python client where it
was adding bogus "fuzzy" annotations to many messages:
https://bugzilla.redhat.com/show_bug.cgi?id=1564497
Users working from virt-viewer releases should not see any difference in
behaviour, since the tarballs only contain the full .po files, not the
.mini.po files.
As an added benefit, generating tarballs with "make dist", will no
longer cause creation of dirty files in git, since it won't touch the
.mini.po files, only the .po files which are no longer kept in git.
The languages are minimized in the following commit since it is a
large mechanical process.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Add rules to handle pushing virt-viewer.pot to zanata, and refreshing .po
files with new content from zanata.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The <locales> element in zanata.xml is no longer relevant as this info
is recorded server side.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Historically we have relied on intltool to install a standard
po/Makefile.in.in which has very limited scope for customization.
intltool is deprecated in favour of standard gettextize tools,
but these share the same disadvantages.
Writing make rules for po file management is no more difficult
than any other rules virt-viewer has, so stop using intltool
and don't use gettextize ether.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The native glib2-devel package is needed for mingw builds in order to
get the glib-compile-schemas binary.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There is no reason for this object to define a private structure, so it
is fine to make everything private to the dialog itself.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
For proper compliance with the GPL and other licenses we need to be
clear about exactly what toolchain and dependent packages we used in
order to build the MSI installer we distribute.
Historically we've done this by including a "deps.txt" file which
provides a list of all the mingw{32,64}-* RPMs on the host system.
This is not sufficient information, however, because the build system
will in fact use various native packages too from the toolchain too,
notably including any program run by "configure" which covers various
shell utilities, and pkg-config, and then of course make & msitools
itself.
Rather than try to figure out which subset of host RPMs are used,
just list every single host RPM that is installed.
A key implication of this is that formal release builds should always
be done in a pristine build root populated with the minimal content
required for the build.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
virt_viewer_session_vnc_auth_credential uses gotos which jump over the
declaration of 'file', meaning its contents are uninitialized in the
jump target.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Modern C standard requires the function to be "void"
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We use GLIB_VERSION_MAX_ALLOWED to prevent use of functions from
GTK >= 3.12. When we do conditional compilation based on a GTK
version check, we must thus suppress the warning:
CC libvirt_viewer_la-virt-viewer-window.lo
../../src/virt-viewer-window.c: In function 'virt_viewer_window_enter_fullscreen':
../../src/virt-viewer-window.c:608:9: error: 'gtk_window_fullscreen_on_monitor' is deprecated: Not available before 3.18 [-Werror=deprecated-declarations]
gtk_window_fullscreen_on_monitor(GTK_WINDOW(priv->window),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/gtk-3.0/gtk/gtkdialog.h:32,
from /usr/include/gtk-3.0/gtk/gtkaboutdialog.h:30,
from /usr/include/gtk-3.0/gtk/gtk.h:31,
from ../../src/virt-viewer-window.c:28:
/usr/include/gtk-3.0/gtk/gtkwindow.h:391:10: note: declared here
void gtk_window_fullscreen_on_monitor(GtkWindow *window,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Compile out QMP channel support if spice-gtk version < 0.36.
(note: I didn't bother adding configure switch to enable it
explicitly, this could be added later if necessary)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
If the "org.qemu.monitor.qmp.0" port is available:
- enable the VM UI
- get and follow the VM state
- send the requested VM actions
This requires spice-gtk version 0.36 with SpiceQmpPort helper.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
QEMU defines a few Spice port channel names in
docs/spice-port-fqdn.txt that can be interacted with a terminal.
Create VirtViewerDisplayVte display for all known terminal channel,
and redirect read/write signals.
Note that if VTE support is disabled, or if the VTE console isn't
shown, spice-gtk will still process those port channels (discarding
the read if VTE is disabled).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Commit 65ef66e42 introduced a regression due to lack of type-safety on
signals. We mistakenly passed a GError rather than a string error
message to the signal.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Fixes the Windows case where the dialog fails to show with the following
message:
warning: "Could not find signal handler 'virt_viewer_window_menu_change_cd_activate'"
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Add "vm-running" property and modify "menu-vm-pause" check button
state when the running state changes.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Add a new "Machine" menu, which allows to Pause/Reset/Power Down a VM.
The menu is only visible if "vm-ui" app property is set.
When the application quits, it will also send a quit action to the VM.
This is a similar behaviour/UI as qemu -display gtk.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
virt_viewer_app_display_added() now handles VTE displays. They should
be skipped for monitor configuration, and they don't emit "show-hint".
(a VTE display has a monitor nth == -1, which is now a valid value)
The associated window will be hidden when virt-viewer is started.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
This will allow to connect to a Spice server using a unix socket path,
for example:
[virt-viewer]
type=spice
unix-path=/var/run/user/1000/qemu/test/spice.sock
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Christophe Fergeau <cfergeau@redhat.com>
The VTE display will have monitor id -1.
Eventually, having a base "console" class without monitor id could
avoid this allowance.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Currently, subtitle indicate the monitor number, ex: "Fedora (1)".
Custom subtitle use %d to place the monitor number.
Let's make this placeholder more generic to place the name of the
console, ex: "Fedora (Serial)".
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
spice-gtk discards configurations without any sized monitors.
Also shuts extra warnings when shifting the monitors.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
virt_viewer_display_get_preferred_monitor_geometry() may be called
during application initialization (when the VTE console is being
shown, virt_viewer_session_update_displays_geometry() is called when
the visibility menu item is toggled). But the other displays may not
yet be associated with a window, ignore them.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
This is not a graphical display, so the application will have to deal
with it with care.
You may argue that we need a large refactoring to introduce a more
generic "console" object, that could be either graphical or textual.
For now, this does work well enough for me.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
A following patch is adding a new display (VTE) that won't have the
send_key() or screenshot() callbacks. Activating those menu/actions
would lead to nothing or a crash. I chose to keep the UI consistent
for all display, but disable the menu sensitivity.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
The sensitivy of "menu-send" is getting more complex in the following
patch. Let's have the logic in a single place,
virt_viewer_window_set_menus_sensitive().
rebuild_combo_menu() is called in 2 cases:
1. notify::enable-accel: there is no need to update the sensitivy of
"menu-send"
2. on construction: default to false since display == NULL. It will be
later updated when virt_viewer_window_set_menus_sensitive(). The
default sensitivity is covered by previous .ui patch change.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
After commit df42f78d46 "remote-viewer: factor our
remote_viewer_initial_connect()", the initial connection code only gets
run in the !ovirt case. When ovirt is in use, the initial connection
never happens, meaning all we get when using ovirt:// is a blank
virt-viewer window.
This commit fixes that by moving creation of the ovirt session to
remote_viewer_initial_connect, and unconditionnally calling the
remote_viewer_initial_connect rather than only doing it in the !ovirt
case.
https://bugzilla.redhat.com/show_bug.cgi?id=1655537
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
For some reason, coverity was complaining that the definition of
cred_type_to_str was dead code, even though it wasn't. Changing the
storage to static silences the warning. Since that's a benficial change
anyway, let's change it. At the same time, make the pointer constant as
well and move it outside of the loop since it doesn't need to be inside
the loop.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
If j == -1, the memory allocated for rect will leak. So move the
allocation after the test.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
It was mainly meant to be used for automatic builds through
Test::AutoBuild, so it can be removed now.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The script was originally used by the Test::AutoBuild
project to perform periodic automatic builds; however, that
effort has been abandoned a long time ago, and these days
virt-viewer CI builds are happening on the Jenkins-based
CentOS CI environment under the libvirt umbrella[1], where
build recipes are maintained separately from the projects
themselves.
The script is still used to prepare releases, so it can't
be dropped from the repository: rename it so that its
purpose is more clearly communicated instead.
[1] https://ci.centos.org/view/libvirt/
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
We previously bumped the gtk+ requirement to 3.18 for the function
gtk_window_fullscreen_on_monitor(). But this function is only necessary
in Wayland. So add some preprocessor version checks to allow it to
compile on older distributions if they don't care about wayland support.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
On Windows, the arguments we get in GApplication::ocal_command_line
come from g_win32_get_command_line(), and g_option_context_parse_strv()
documentation says:
« On Windows, the strings are expected to be in UTF-8. This is in
contrast to g_option_context_parse() which expects them to be in the
system codepage, which is how they are passed as argv to main(). See
g_win32_get_command_line() for a solution. »
This was causing issues on Windows when running:
remote-viewer -t "你好" spice://<target-host>:5900
In fullscreen mode, we attempt to enable a guest display for each client
monitor and then place a fullscreen window for each display on the
appropriate monitor. Previously, we were using gtk_window_move() to move
the window to the proper monitor, and then calling
gtk_window_fullscreen() to enter fullscreen mode on that monitor.
However, under wayland, gtk_window_move() no longer has any effect for
toplevel windows, so all displays were showing up on top of eachother on
the same client monitor.
Fortunately, Gtk+ 3.18 added a new gtk_window_fullscreen_on_monitor()
API that works on Wayland. In theory this allows us to remove the call
to gtk_window_move() from the code. But to avoid potentially changing
behavior on xorg or older systems, I left the existing logic.
This requires a dependency bump for gtk+ from 3.12 to 3.18. Gtk 3.18 is
provided by the following distributions (or newer):
- RHEL 7.4
- Fedora 23
- Ubuntu 16.04LTS
Resolves: rhbz#1584561
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Spice and VTE display do not need to implement it.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Instead of modifying it in object initialization.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
virt_viewer_window_set_menus_sensitive() is the common function to set
sensitivity on menu items.
It was lacking "toolbar_send_key", so add it there too.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
There is a hack to maintain the toggle state to a desired state within
the "toggled" handler.
However it is only necessary for the ask-quit case. In this case, we
want to maintain the item active, which is simpler to handle than the
general case. Simplify the code by folding
virt_viewer_app_window_set_visible() and removing the static
"reentering" hack, only maintaining "active" on the last item.
Note that the hack was needed since there is no way to hook a signal
handler on "clicked" before "toggled" is emitted and handled by Gtk,
to avoid the recursion.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
We don't use class signal handlers, remove the extra pointers.
g_signal_override_class_handler() could be used instead when needed.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
- spice+unix:// was added in spice-gtk v0.28
- spice+tls:// was added in spice-gtk v0.35
This allows launchers to start remote-viewer when they encounter a
Spice URI with +unix or +tls.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Previously we were emitting the VirtViewerSession::session-disconnected
when we got the Spice::session::channel-destroy signal for the last
channel. However, since the channels are still valid at this point, and
because VirtViewerApp quits the application in response to the
session-disconnected signal, that means that the channels were never
being properly freed. This was particularly problematic for the usbredir
channel, which must disconnect any connected USB devices as part of its
destruction. By using the new SpiceSession::disconnected signal instead,
we can ensure that all channels have been disconnected and properly
destroyed before quitting the application.
It may be useful to know why the storage domain has not been listed,
given that there are different reasons for that. To make it easier to
provide more detailed debug messages, we move code from the callback
function to this new one.
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
With these new values, 0.3.3 for libgovirt and 0.8 for librest, we can
remove checks for OVIRT_REST_CALL_ERROR_CANCELLED and correspondent
rest_proxy_auth_cancel().
Distros that already ship these versions, such as Fedora, RHEL 7.4
onwards, and Ubuntu since 17.10.
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Even when the user adds comments, we should place the guest's name
unless it is present already.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1623756
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
oVirt REST API does not provide a way to know what is a valid ISO image
which can be assigned to a running VM. I've seen floppy disk images
(.vfd) in a domain, which is already filtered. Now I've seen an ISO
domain with .qcow2 files in it, which can't be assigned to a VM either.
This commit filters every file which does not have a .iso extension as
it's unlikely to be possible to use it.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
The ovirt code uses g_strv_contains() with fallback code in
glib-compat.h when we are using a glib version where it's not available.
However, when we use a glib version where g_strv_contains is available,
we get a compilation warning since we are compiling GLIB_VERSION_MAX_ALLOWED
set to 2.38.
This commit wraps both the compat code and the g_strv_contains() call in
a strv_contains() helper where we can hide the magic needed to avoid
deprecation warnings.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
This adds an unused parameter, but lets us get rid of this new warning
with gcc 8:
virt-viewer-window.c: In function 'get_image_format':
virt-viewer-window.c:930:33: warning: cast between incompatible function types from 'GHashTable * (*)(void)' {aka 'struct _GHashTable * (*)(void)'} to 'void * (*)(void *)' [-Wcast-function-type]
g_once(&image_formats_once, (GThreadFunc)init_image_formats, NULL);
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
This is no longer needed since 140cb84
'remote-viewer: remove --spice-controller'
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
On Windows, we can't use bindtextdomain(GETTEXT_PACKAGE, LOCALE_DIR); as
LOCALE_DIR is a compile-time constant, while the location of the
translations will be dependant on where the user installs virt-viewer.
This results in an untranslated virt-viewer UI on Windows. This commit
calls bindtextdomain() with a directory which is relative to the
installation path so that translation are properly found.
This is similar to what spice-gtk is doing:
https://cgit.freedesktop.org/spice/spice-gtk/tree/src/spice-glib-main.c
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
- Use macros for paths instead of absolute paths.
- Remove dangling %{gtk_arg} macro in configure.
- Fix scope of enable_autotools macro to avoid warning during build.
warning: Macro %enable_autotools defined but not used within scope
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Similar to last commit, as noticed by reporter in bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1477966
Man page should reference spice-client, not spice-gtk.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
The man page spice-gtk ships is named "spice-client", not "spice-gtk"
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1477966
This fixes commit 140cb84c2538bf0eab7dea2035dfecc4db74c784, where we
removed the spice-xpi-client-remote-viewer.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
This helper was useful to debug spice controller & activex plugin. Now
that the controller is gone, it is no longer needed.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Victor Toso <victortoso@redhat.com>
spice controller interface is being removed from spice-gtk.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Victor Toso <victortoso@redhat.com>
Some users want the ability to set connection details without writing
to a file or passing command line arguments.
Learn to read the connection file from standard input for such use
case.
This allows a parent process to set the connection details without
intermediary file.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Victor Toso <victortoso@redhat.com>
When connecting to a VM via oVirt instance, the original uri can not be
retrieved using virt_viewer_session_get_uri(). Consequently, it was
never saved, even though the connection succeeds and the actual callback
for "session-connected" signal, which saves the URI, is invoked.
To solve this problem, we always pass a copy of the guri as user-data
parameter for the callback, and if the call to
virt_viewer_session_get_uri() returns NULL, the parameter is used
instead.
Resolves: https://bugzilla.redhat.com/1459792
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
This last patch of the series is where we actually check if the storage
domain is active in the data center the VM is associated with. It makes
use of g_strv_contains(), which is available only in glib version 2.44.
Compatibility code has been added if building against older versions
than required.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1427467https://bugzilla.redhat.com/show_bug.cgi?id=1428401
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
It is possible that the data center the VM is associated with has more
than one storage domain associated with it as well, when only one is
active while the others are not.
The current ovir-foreign-menu code does not take it into consideration,
thus the ISO dialog may show invalid results with that scenario. We fix
this problem by making use of new functions in libgovirt, adding support
or hosts, clusters and data centers.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1427467https://bugzilla.redhat.com/show_bug.cgi?id=1428401
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
This can save us some bandwidth, as we are searching for the specific
virtual machine instead of retrieving the collection with all VMs, and
then iterating over the results after the transfer finishes.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Setting LC_ALL=C breaks python apps doing I/O on UTF-8 source
files. In particular this broke glib-mkenums
Traceback (most recent call last):
File "/usr/bin/glib-mkenums", line 669, in <module>
process_file(fname)
File "/usr/bin/glib-mkenums", line 406, in process_file
line = curfile.readline()
File "/usr/lib64/python3.6/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 849: ordinal not in range(128)
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
If the image format cannot be determined for a screenshot filename,
simply return an error informing the user that this is not a valid image
format.
In the past, if we couldn't determine the file type, we simply saved it
as a PNG, and appended a ".png" file extension to the filename. This has
several problems. First, it can result in some oddly-named files (e.g. a
screenshot named 'Screenshot.pdf.png').
Second, modifying the filename that is returned from the GtkFileChooser
undermines the overwrite-confirmation functionality that is built into
the gtk file chooser. When the user specifies a filename in the file
chooser dialog, the chooser will automatically check whether a file of
that name exists, and if it does, it will display a dialog asking
whether the user wants to overwrite it. But if we then append a ".png"
extension to the filename and save it, we may be overwriting an existing
file without warning. By returning an error for unrecognized file types,
we avoid this problem.
Resolves: rhbz#1455832
Currently, the user gets no feedback if the screenshot fails (e.g. if
they don't have permission to write in the chosen directory, etc). This
patch adds a simple dialog showing the error message when a screenshot
fails.
Since the code attempts to append ".png" to filenames without an
extension, it doesn't make much sense to have the default filename be
extensionless. Including the extension on the default filename makes
things more straightforward.
Related: rhbz#1455832
Otherwise, in kiosk mode, it'll be hidden from user.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1459800
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Similar to previous commit 5d9e6d2338cbb680fe761b86e6ca433b1234e6e0, now
dealing with the case of connecting directly to ovirt:// URIs, which was
left behind.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1459808
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Mainly a kiosk mode issue, similar to the spice fix in 6480e52f62b.
This patch saves the cancel/close state of auth dialog from
virt_viewer_auth_collect_credentials() in order to avoid an error
dialog to pop up to user in kiosk mode.
This happens due the fact that we call virt_viewer_app_disconnected()
twice:
- One with "session-cancelled" which is correct and well handled;
- The other with "session-disconnected" which is misleading as there
was no connection at this time. This will trigger the error dialog
with "Unable to connect to the graphic server %s".
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1446161
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Mainly an issue for kiosk mode due the fact that it'll not quit the
application on cancel. That means that authentication dialog can't
really be canceled and showing an input error such as "wrong password"
is misleading (no password should be taken in consideration on Cancel).
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1446161
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
When the transfer of a file finishes we stop considering that file's
size in the progress bar which makes it move back due the new
'transfer size' and 'transferred bytes' - for all the other files.
This patch aims to keep the progress smooth when a file is finished
using the notify::total-bytes from SpiceFileTransferTask to be aware
of all file's sizes.
Note that as we have only one progress bar for all files being
transferred, it is expected that it will go back when a new
file-transfer operation starts (e.g we drag-and-drop new files while
we are already transferring other files).
As requested, this patch also updates the string message to include the
amount of files that will be transferred in case we have more than one
file.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1449572
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Take a look at the shutdown event detail before killing
the connection. Otherwise it breaks the SPICE seamless migration
feature.
Regression since commit a62827d28c6b69e90102e4c1c8043cbddad8929a
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1442929
Signed-off-by: Pavel Grunt <pgrunt@redhat.com>
Acked-by: Daniel P. Berrange <berrange@redhat.com>
Support for more than one key combo for accelerator is available
since GTK 3.12 through GAction. It is currently not possible to
use mnemonics also for numpad keys, for more info see:
https://bugzilla.gnome.org/show_bug.cgi?id=699823
Resolves: rhbz#1337575
Reviewed-by: Victor Toso <victortoso@redhat.com>
The option -Wimplicit-fallthrough was added to -Wall recently which
generates a few warnings. Based on the comment above the switch, the
fallthrough is on purpose so let's add a comment to avoid the following
warnings.
ovirt-foreign-menu.c: In function 'ovirt_foreign_menu_next_async_step':
ovirt-foreign-menu.c:293:12: warning: this statement may fall through
if (menu->priv->api == NULL) {
^
ovirt-foreign-menu.c:297:5: note: here
case STATE_VM:
^~~~
ovirt-foreign-menu.c:298:12: warning: this statement may fall through
if (menu->priv->vm == NULL) {
^
ovirt-foreign-menu.c:302:5: note: here
case STATE_STORAGE_DOMAIN:
^~~~
ovirt-foreign-menu.c:303:12: warning: this statement may fall through
if (menu->priv->files == NULL) {
^
ovirt-foreign-menu.c:307:5: note: here
case STATE_VM_CDROM:
^~~~
ovirt-foreign-menu.c:308:12: warning: this statement may fall through
if (menu->priv->cdrom == NULL) {
^
ovirt-foreign-menu.c:312:5: note: here
case STATE_CDROM_FILE:
^~~~
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Only method for connecting to channel opened later was ssh, however
this method failes when unix socket is used:
<graphics type='spice'>
<listen type='socket' socket='/tmp/spice.sock'/>
</graphics>
Related: rhbz#1335832, rhbz#1411765
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Since libvirt 0.9.4 there is a new listen element which can be used
to specify address instead of using the attributes of graphics element.
Also add support for listen type socket - available for Qemu since
libvirt 2.0.0
Resolves: rhbz#1411765
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Add some tests that specify different numbers of client monitors to
ensure that the parsing handles those situations correctly.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
When started in fullscreen mode with a monitor-mapping configuration
option, we are getting the following warnings on the terminal:
(process:27428): Gdk-CRITICAL **: gdk_screen_get_n_monitors: assertion 'GDK_IS_SCREEN (screen)' failed
** (process:27428): WARNING **: Invalid monitor-mapping configuration: monitor #1 for display #1 does not exist
This is apparently because we were processing the fallback monitor
mapping before the graphic server display was opened, so
gdk_screen_get_default() returned NULL. This resulted in
gdk_screen_get_n_monitors() reporting that we had 0 monitors.
This patch moves the fallback monitor mapping parsing from
virt_viewer_app_init() to virt_viewer_app_on_application_startup(),
after chaining up to the base class startup() vfunc. The graphic server
display is opened in the base class vfunc, so by the time that returns,
we should be able to query the number of monitors.
The patch also adds a check in virt_viewer_parse_monitor_mappings() to
ensure that we pass a sane value for nmonitors.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Since 9c77a78af2ef85f3fcdce21b42d89566a9f7ee17 the vnc display has
stopped setting the show hint and started to ignore the initial zoom
setting. Let's handle it in a similar way as the spice display and set
the hint when the display is initialized and unset it on disconnect.
Resolves: rhbz#1436991
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Theoretically a VM name can be a valid VM id or uuid. In that case
connecting to the VMs may be problematic since virt-viewer selects
the VM by its id then by uuid if not found then by its name.
Introduce new command line options to cover this situation:
"--id" to connect to the VM by its id
"--uuid" to connect to the VM by its uuid
"--domain-name" to connect to the VM by its name
The options are mutually exclusive
Resolves: rhbz#1399077
Function is not used without oVirt.
> virt-viewer-window.c:1063:1: warning: 'iso_dialog_response' defined
> but not used [-Wunused-function]
Signed-off-by: Victor Toso <victortoso@redhat.com>
As remote_viewer_iso_list_dialog_new() is defined on
remote-viewer-iso-list-dialog.h which is only build with oVirt
integration.
> undefined reference to `remote_viewer_iso_list_dialog_new'
Note that the callback virt_viewer_window_menu_change_cd_activate() is
only visible if oVirt is built in.
Signed-off-by: Victor Toso <victortoso@redhat.com>
Two statements in virt_viewer_session_spice_main_channel_event() are
wrapped in a { } block, but this is unneeded.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
When running 'remote-viewer' without arguments,
and selecting a non-supported protocol, e.g. ssh://foo,
the generated error was silently swallowed by the retry loop.
This was introduced in 06b2c382468876a19600374bd59475e66d488af8.
Signed-off-by: Christophe de Dinechin <cdupontd@redhat.com>
We must take into account that users can close the dialog at anytime,
even during an operation of fetch or set ISO has not been finished. This
will cause the callbacks for those operations to be invoked with an
invalid object, crashing the application.
To fix this issue we need to pass a GCancellable to the asynchronous
operations, so they can be cancelled if the dialog happens to get closed
before they complete.
NOTE: This patch triggers a deadlock in libgovirt when the dialog is
closed before the operation completes. Bug reported in
https://bugzilla.gnome.org/show_bug.cgi?id=777808. We will need to bump
libgovirt dependency whenever it has a new release.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
It is needed to use the 'foreign' init option otherwise autotools
requires README
Fix make distcheck and spec file generation
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Also moves 'Change CD' menu item from the toplevel menu to a subitem
under 'File' toplevel menu.
In order to avoid object interdependency, it is necessary to make the
ovirt foreign-menu pointer from RemoteViewer, accessible via property,
so it can be passed to the dialog as an opaque GObject.
Finally, with this commit, we clean up ovirt foreign menu code, which
only deals with data, leaving the UI bits to be handled properly in the
new ISO list dialog.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
The motivation for this dialog started with rhbz #1310624, where it was
reported that foreign menu was causing too many debug messages to be
printed to the console, because remote viewer had a timeout of 5 seconds
to refresh the ISO list automatically.
As a workaround, the timeout was adjusted for 5 minutes, but it could
cause more problems, such as inconsistencies between what was shown by
remote viewer and what the server had configured.
Another issue caused by displaying the ISO files as a menu item was that
if the list was too long, it would take all the available space on the
screen. In the end, a menu item was not the correct choice of UI
component for this use case.
In order to solve both problems, we now present the ISO list as a
dedicated dialog, where the refresh of ISO list is triggered manually by
the user and the list is contained within the dialog, by displaying de
files in a treeview.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Also, to keep consistency around the codebase, changed the return value
of ovirt_foreign_menu_get_current_iso_name() from char * to gchar *.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Similar to the previous commit, the ISO dialog will fetch the result
asynchronously, rather than relying on the "notify::files" signal from
OvirtForeignMenu object. It also enables error to be shown if anything
goes wrong.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
The #endif is closing a #ifdef HAVE_OVIRT block, while another one is
opened right next, so there is no need to have those lines. Also, due to
the large amount of source code in between, add a small comment on the
last #endif to identify what it refers to.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Avoid showing the "Unknown" name in the guest detail dialog when
waiting for the domain to be started.
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Instead of having a warning message telling the user that they can't
have more displays enabled in fullscreen than the number of physical
displays, let's just have it as a debug message.
Related: rhbz#1368390
Acked-by: Fabiano Fidêncio <fabiano@fidencio.org>
The display id in the warning log is now consistent with the display
id in the "view->displays->display x" menu item
Related: rhbz#1368390
Acked-by: Fabiano Fidêncio <fabiano@fidencio.org>
After all ongoing file transfers are finished, save a list of the file
transfer tasks that had errors and display the list of failed files to
the user so that they know that a failure occurred and can potentially
retry the transfer. Previously, we just failed silently so the user
may not have even been aware that the transfer failed.
When transferring a large number of files, the file transfer dialog was
unusable because the window size would be larger than the client
desktop. To solve this, remove the list of individual files (and the
ability to cancel each file transfer independantly) and only display
a single overall progress bar that shows the status of all ongoing
transfers.
This also allows us to remove the delayed unref of the task since we
don't need to show the task information about each individual transfer
task until the window is closed. Removes TaskFinishedData type.
This patch requires new API from spice-gtk to calculate the overall
progress:
spice_file_transfer_task_get_total_bytes()
spice_file_transfer_task_get_transferred_bytes()
rpmbuild -ta only works if the tar.gz contains a single
spec file, so remove the mingw-virt-viewer.spec from
dist.
We should however be including both the spec.in files.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Use switch/case instead of lots of conditional blocks
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
When using client-side decorations, as well as in certain other
situations (wayland, and windows in some cases), the window gradually
resizes larger and larger.
This is caused by a change in how gtk interprets the sizes passed to
gtk_window_resize(), particularly when client-side decorations (CSD) are
involved. For example, In the past this size was assumed to include the
size of the CSD, but now it it assumes that the sizes only represent the
size of the window's content, without any decorations. However,
gtk_widget_get_preferred_size() (when called on a GtkWindow*), returns a
size that includes the size of the CSD. So
virt_viewer_window_queue_resize() was essentially growing the window by
the size of the CSD every time it was called.
To work around this issue, we need to calculate the preferred size of
the window's child, not the size of the entire window (including CSD).
Then we add the width of the window's border (just to be safe) and pass
those values to gtk_window_resize().
Normally virt-viewer relies on the VNC/SPICE widget seeing
an EOF on its underlying connection to detect when the
session is closed.
When tunnelling to a remote guest over SSH though, this
EOF can be delayed for a very long time, leaving a dead
session open.
This can be seen with
virt-viewer -c qemu+ssh://remotehost/system guestname
when on the remote shell run
virsh destroy guestname
and notice that virt-viewer does not see the shutdown
immediately.
When we get a domain stopped event we know the session
should be dead, so forceably close it, if not already
closed.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The following commit broke the display of the guest name in
the title for VNC displays:
commit 61a1bc4dcbb056755fe96c5945f84c1312041059
Author: Pavel Grunt <pgrunt@redhat.com>
Date: Wed Apr 15 13:50:35 2015 +0200
session-vnc: Set window for display to avoid gtk-vnc v0.3.8 crash
The VNC display widget of gtk-vnc v0.3.8 needs a window at the moment
The problem is that this causes the window to be associated
with the display before the guest name is available. Thus
when ensure_window_for_display() runs, the window is already
configured and so it never invokes the logic to set the title.
The fix is to unconditionally update the title in the
ensure_window_for_display() method, even if the window already
exists.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
When connecting to a RHEVM/oVirt machine through an expired vvfile the
user ends up in an endless loop of getting an error message, pressing
"Okay", re-scheduling a new connection retry. getting an error message
due to the expired vvfile and so on.
In order to avoid the issue, let's not re-schedule the connection retry
when the user tries to connect through a vvfile and it fails.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This is a temporary solution, as discussed in the bug. We will adjust
the timer to refresh the ISO list from 15 seconds to 5 minutes (300
seconds), while reworking in the UI to replace the menu with a dialog,
which seems a saner way to display the list.
Resolves: rhbz#1347726
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Here we added mnemonics for the buttons "Cancel" and "Connect" and also
for the "Connection Address" entry (as it was before moving this dialog
to a .ui file).
The "Recent connections" widget is left behind as GtkRecentChooserWidget
isn't suitable for mnemonic activation.
Resolves: rhbz#1351487
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
The "grab-notify" signal lets us know when our widget becomes
shadowed by a Gtk+ grab on another widget, or when it becomes unshadowed
due to a grab being removed.
That's exactly the case we face when dealing with "usb-redirection" and
"close" items of the fullscreen toolbar. And, currently, when these
widgets get closed the timed-revealer stays there forever. From now on
let's take advantage of the "grab-notify" signal and schedule a timeout
for the revealer when these widgets' windows get closed.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Since commit cc455b7f916110d7cfae6b7af753349e070c9494, the background
color has not been set correctly for Gtk+ 3.18 (Fedora 23), while it was
working fine for more recent version 3.20 (Fedora 24). Tracked down to
some changes in GtkNotebook code which can not be easily backported.
Instead of customizing background and foreground colors, let's just
stick with the default colors provided by theme.
Related https://bugs.freedesktop.org/show_bug.cgi?id=94276
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Adds metadata to be used with Gnome Software.
Includes name, summary, description and a few screenshots of remote-viewer.
Signed-off-by: Lukáš Venhoda <lvenhoda@redhat.com>
Acked-by: Daniel P. Berrange <berrange@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
VirtViewerTimedRevealer now derives from GtkEventBox/GtkContainer, so
it follows GTK+ conventions and takes ownership of the floating ref on
'toolbar'. Since VirtViewerWindow and VirtViewerTimedRevealer will have
the same lifespan, we don't need to own a reference on toolbar in
VirtViewerWindow.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
As suggested by Christophe, inheriting from GtkEventBox instead of
having one instance of it as a member can help us to get rid of
virt_viewer_timed_revealer_get_overlay_widget().
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
VirtViewerTimedRevealer::evBox is created in
virt_viewer_timed_revealer_new() and will be passed to
gtk_container_add() through gtk_overlay_add_overlay(overlay,
virt_viewer_timed_revealer_get_overlay_widget(priv->revealer))
This means VirtViewerTimedRevealer does not own a reference on evBox,
and that it should not try to release it in
VirtViewerTimedRevealer::dispose()
Backtrace for the crash:
#0 0x00007ffff3e92c9d in g_type_check_instance_is_fundamentally_a () at /lib64/libgobject-2.0.so.0
#1 0x00007ffff3e722a5 in g_object_unref () at /lib64/libgobject-2.0.so.0
#2 0x000000000041ebe3 in virt_viewer_timed_revealer_dispose (object=0x1127320) at virt-viewer-timed-revealer.c:128
#3 0x00007ffff3e723b6 in g_object_unref () at /lib64/libgobject-2.0.so.0
#4 0x000000000041c040 in virt_viewer_window_dispose (object=0x981f70) at virt-viewer-window.c:191
#5 0x00007ffff3e723b6 in g_object_unref () at /lib64/libgobject-2.0.so.0
#6 0x0000000000413a58 in virt_viewer_app_display_removed (nth=<optimized out>, self=0x680330) at virt-viewer-app.c:989
#7 0x0000000000413a58 in virt_viewer_app_display_removed (session=<optimized out>, display=<optimized out>, self=0x680330) at virt-viewer-app.c:1000
#8 0x00007ffff3e705e0 in g_cclosure_marshal_VOID__OBJECTv () at /lib64/libgobject-2.0.so.0 #9 0x00007ffff3e6d784 in _g_closure_invoke_va () at /lib64/libgobject-2.0.so.0
#10 0x00007ffff3e88cd9 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#11 0x00007ffff3e897eb in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0
#12 0x0000000000418973 in virt_viewer_session_remove_display (session=0x9c6de0, display=0x961a90) at virt-viewer-session.c:463
#13 0x0000000000420934 in destroy_display (data=<optimized out>) at virt-viewer-session-spice.c:851
#14 0x00007ffff3b6d0eb in g_ptr_array_foreach () at /lib64/libglib-2.0.so.0
#15 0x00007ffff3b6d180 in ptr_array_free () at /lib64/libglib-2.0.so.0
#16 0x000000000042072a in virt_viewer_session_spice_clear_displays (self=0x9c6de0) at virt-viewer-session-spice.c:94
#17 0x000000000042240d in virt_viewer_session_spice_close (session=<optimized out>) at virt-viewer-session-spice.c:459
#18 0x0000000000414be5 in virt_viewer_app_quit (self=self@entry=0x680330) at virt-viewer-app.c:285
#19 0x0000000000415500 in virt_viewer_app_maybe_quit (self=0x680330, window=window@entry=0x981a90) at virt-viewer-app.c:481
#20 0x000000000041c4ad in virt_viewer_window_delete (src=<optimized out>, dummy=<optimized out>, self=0x981a90) at virt-viewer-window.c:771
#21 0x00007ffff61807f1 in _gtk_marshal_BOOLEAN__BOXEDv () at /lib64/libgtk-3.so.0
#22 0x00007ffff3e6d784 in _g_closure_invoke_va () at /lib64/libgobject-2.0.so.0
#23 0x00007ffff3e887b3 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#24 0x00007ffff3e8933f in g_signal_emit () at /lib64/libgobject-2.0.so.0
#25 0x00007ffff62dde6c in gtk_widget_event_internal () at /lib64/libgtk-3.so.0
#26 0x00007ffff617f5ef in gtk_main_do_event () at /lib64/libgtk-3.so.0
#27 0x00007ffff5c7dd25 in _gdk_event_emit () at /lib64/libgdk-3.so.0
#28 0x00007ffff5cae672 in gdk_event_source_dispatch () at /lib64/libgdk-3.so.0
#29 0x00007ffff3b9895a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#30 0x00007ffff3b98d10 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#31 0x00007ffff3b98dbc in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#32 0x00007ffff41643cd in g_application_run () at /lib64/libgio-2.0.so.0
#33 0x000000000040fc1a in main (argc=3, argv=0x7fffffffdec8) at virt-viewer-main.c:41
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
virt_viewer_timed_revealer_new calls gtk_container_add on the instance
returned by gtk_revealer_new so VirtViewerTimedRevealer does not own any
ref on this GtkRevealer instance. Unrefing it in _dispose() is thus wrong.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Currently the menu item is created manually, while this patch changes it to be
retrieved from the UI file, and decides if it needs to be shown or hidden if the
ISO list is received from ovirt.
This a preparation for a upcoming UI change that will present the ISO list in a
separate dialog, instead of a submenu.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
GtkRevealer was intrudced in Gtk+ 3.10 and, combined with Gtk Overlay
(intoduced in Gtk+ 3.2), can provide a more sustainably implementation
of the AutoDrawer functionality.
This approach is completely based on the approach taken by virt-manager:
dc05600324
Resolves: https://bugs.freedesktop.org/show_bug.cgi?id=94495
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Fedora 24 has GLib 2.48.0, which brings a new dependency: PCRE.
The new dependency is already added to the wxi file (in msitools) and a
new msitools build including the fix is already done [0].
Let's just bump the version in our spec file and make sure we will be
using the msitools which includes the fix.
[0]: https://bodhi.fedoraproject.org/updates/FEDORA-2016-a7a2db6109
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Binds modifier's mask and key, also fixes a compile time warning
spotted by clang:
warning: cast from 'gchar *' (aka 'char *') to 'guint *' (aka 'unsigned
int *') increases required alignment from 1 to 4 [-Wcast-align]
return (guint*)g_array_free(a, FALSE);
Since commit 1f6f1a48 the resource path for icons has been broken.
The reason is that when moving the .ui files to $(srcdir)/resources/ui
the define used for the resources was changed to reflect the new
directory. However, this change wasn't needed by the icons and ended
up with virt-viewer not displaying a few icons.
Let's fix the issue by setting back the define to the previous one and
then tweaking the virt_viewer_util_load_ui() to add "ui" to the resource
path, for loading the ui files.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
I'd like to keep our resources all in the same place. In the future we
will be able to have:
$(srcdir)
|_ resources
|_ ui: for our {remote,virt}-viewer ui specific files
|_ gtk: for files that can be automatically handled by Gtk (like
| app-menu).
|_ css: for custom themes (like:
https://bugs.freedesktop.org/show_bug.cgi?id=94276)
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
When using GtkApplication, Gtk automatically searches for the menus of
the application at "org/example/app/gtk/menus.ui".
Currently we don't have a "menus.ui", but try to see this commit is a
first step in order to use app-menu.
For now, let's standardize that all our UI files will have the ".ui"
extension instead of the ".xml" one.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
It hasn't bitten us (so hard) so far but would from the moment we add
support to app-menu/headerbar.
By not chaining-up to the parent's method, gtk_window_set_application()
is never called. This causes GApplication object not being able to load
the app-menu, but using the "fallback" which only contains the "Quit"
item.
By chaining-up to the parent's method, g_application_hold() call on
virt-viewer-app.c can be removed, as it is already called by the
parent's window_added() method.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
By the comment in the code:
"For the gtk2 build, we need to queue a resize even if the zoom level
hasn't changed. This is due to the fact that VirtViewerWindow will
queue a resize event for itself immediately after calling this
function (in order to shrink the window to fit the new display size
if necessary). If we don't queue a resize here, the window will become
tiny because we will only request 50x50 during the window resize."
And it doesn't happen on gtk3 at all. So, let's just remove the comment
and just quere the resize when zoom-changes actually happen.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Since commit 01b66ef88bc142d6716b40b1e384e94a2629a99f virt-viewer
does not crash on connection to a guest using an invalid display
configuration (eg. Cirrus & QXL vga). That commit allowed existence
of NULL display, however the code handling monitors alignment does
not expect this and crashes when virt-viewer is shifting/aligning
its windows.
Avoid crashing by returning early on NULL display.
#0 0x0000000000411d0a in displays_cmp (p1=p1@entry=0xbad940, p2=p2@entry=0xbad944, user_data=user_data@entry=0x8eb180) at virt-viewer-util.c:544
#1 0x00007ffff3f16ac5 in msort_with_tmp (p=0x7fffffffd670, b=0xbad940, n=2) at gqsort.c:93
#2 0x00007ffff3f16ded in msort_r (b=b@entry=0xbad940, n=n@entry=2, s=s@entry=4, cmp=cmp@entry=0x411ce0 <displays_cmp>, arg=arg@entry=0x8eb180) at gqsort.c:278
#3 0x00007ffff3f16e78 in g_qsort_with_data (pbase=pbase@entry=0xbad940, total_elems=total_elems@entry=2, size=size@entry=4, compare_func=compare_func@entry=0x411ce0 <displays_cmp>, user_data=user_data@entry=0x8eb180) at gqsort.c:303
#4 0x000000000041277c in virt_viewer_align_monitors_linear (displays=displays@entry=0x8eb180 = {...}) at virt-viewer-util.c:586
#5 0x000000000041a92d in virt_viewer_session_on_monitor_geometry_changed (self=0x8f38a0 [VirtViewerSessionSpice], display=<optimized out>) at virt-viewer-session.c:373
#6 0x00007ffff4415908 in g_closure_invoke (closure=0x9306c0, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7fffffffd960, invocation_hint=invocation_hint@entry=0x7fffffffd900) at gclosure.c:801
#7 0x00007ffff4427a1d in signal_emit_unlocked_R (node=node@entry=0x668f80, detail=detail@entry=1551, instance=instance@entry=0x930440, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffd960) at gsignal.c:3627
#8 0x00007ffff442fab1 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffdaf0) at gsignal.c:3383
#9 0x00007ffff442fd9f in <emit signal notify:agent-connected on instance 0x930440 [SpiceMainChannel]> (instance=instance@entry=0x930440, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3439
#10 0x00007ffff4419fd4 in g_object_dispatch_properties_changed (object=0x930440 [SpiceMainChannel], n_pspecs=<optimized out>, pspecs=<optimized out> at gobject.c:1061
#11 0x00007ffff441c4f9 in g_object_notify (pspec=<optimized out>, object=0x930440 [SpiceMainChannel]) at gobject.c:1155
#12 0x00007ffff441c4f9 in g_object_notify (object=0x930440 [SpiceMainChannel], property_name=<optimized out>) at gobject.c:1202
#13 0x00007ffff5a63dd0 in notify_main_context (opaque=0x7fffd6fde990) at gio-coroutine.c:240
#14 0x00007ffff3f07d7a in g_main_context_dispatch (context=0x68da40) at gmain.c:3152
#15 0x00007ffff3f07d7a in g_main_context_dispatch (context=context@entry=0x68da40) at gmain.c:3767
#16 0x00007ffff3f080b8 in g_main_context_iterate (context=0x68da40, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3838
#17 0x00007ffff3f0838a in g_main_loop_run (loop=0x710de0) at gmain.c:4032
#18 0x00007ffff5f53045 in gtk_main () at gtkmain.c:1207
#19 0x0000000000411a22 in main (argc=1, argv=0x7fffffffdfa8)
Resolves: rhbz#1250820
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
When virt-viewer is "Waiting for guest domain to start" and
the Ctrl- or Ctrl+ keys are pressed to zoom the blank display
virt-viewer will crash in virt_viewer_display_get_desktop_size
because of a NULL display pointer. To reproduce start virt-viewer
on a VM not running and zoom the display.
Signed-off-by: Charles Arnold <carnold@suse.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
This reverts commit 191f9a8ab49f56aa48781b5eeaa4a1a65d626627.
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1342984.
Calling ImmDisableIME disable IME for the entire program.
On Windows 7 this also hide the keyboard application from the task bar
making impossible to switch keyboard while using remote viewer.
A recent commit in spice-gtk (7d881d2193bf5598b888a48bb4d8d7ad2e62f443,
"widget: Disable IME context on display widget") disable IME processing
just for SpiceDisplay. This avoid the above regression on Windows 7.
Not having this spice-gtk commit is not going to cause a huge
regression, so it's fine not to add strong coupling between this
commit and the spice-gtk commit which fixes this differently.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
So test-hotkeys include virt-viewer-app.h which includes
virt-viewer-window.h which includes virt-viewer-display.h which
in turn wants to include virt-viewer-enums.h. But, the enums
header file is generated at build time into builddir not srcdir.
Therefore it may happen if the two are distinct that compiler
fails to find the enums file:
In file included from ../../src/virt-viewer-window.h:29:0,
from ../../src/virt-viewer-app.h:28,
from ../../tests/test-hotkeys.c:27:
../../src/virt-viewer-display.h:28:31: fatal error: virt-viewer-enums.h: No such file or directory
#include "virt-viewer-enums.h"
^
compilation terminated.
The fix is to include builddir into paths where header files are
looked for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
In function virt_viewer_display_vnc_new() we are calling
virt_viewer_signal_connect_object() which is defined in
virt-viewer-util module. However, the header file for the module
is never included.
CC libvirt_viewer_la-virt-viewer-display-vnc.lo
virt-viewer-display-vnc.c: In function 'virt_viewer_display_vnc_new':
virt-viewer-display-vnc.c:251:5: warning: implicit declaration of function 'virt_viewer_signal_connect_object' [-Wimplicit-function-declaration]
virt_viewer_signal_connect_object(app, "notify::enable-accel",
^
virt-viewer-display-vnc.c:251:5: warning: nested extern declaration of 'virt_viewer_signal_connect_object' [-Wnested-externs]
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
The hotkey is valid if it has a valid value. The value is valid if it is
not empty and is successfully parsed by gtk_accelerator_parse().
These hotkeys formats are considered invalid:
"key" - missing value
"key=" - missing value
"key=abcd" - value cannot be parsed by gtk_accelerator_parse()
Resolves: rhbz#1339572
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
It should be enabled only if the "release-cursor" sequence was not
specified (by using "--hotkeys=release-cursor=sequence"), otherwise
both sequences would release the cursor.
The solution is taken from the spice-display code.
Resolves: rhbz#1339575
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
The oVirt integration code in remote-viewer assumes that
the caller owns a reference on the OvirtApi instance returned
by ovirt_proxy_fetch_api{,finish}.
This is incorrect as these 2 API calls have always been documented as
being (transfer none). This was working so far because libgovirt was
leaking an OvirtApi reference. This bug is fixed upstream, so we now get
a warning on remote-viewer exit about trying to unref an invalid object.
This commit fixes that by taking the ref we expect in OvirtForeignMenu,
and by not releasing a ref we do not own in remote-viewer.c
If jsessionid is not set in the .vv file and we try to use anyway the
REST API, an authentication dialog will be shown by remote-viewer, which
is very unwelcome. If we don't have a jsessionid set, we know we won't
be able to silently login to the REST API, so don't try to set a foreign
menu when it's not set.
This program attempt multiple redirection combination:
- passing handles using either CreateProcess or SetStdHandle;
- having a console or not;
- redirection stdout/stderr yes or not.
Worth to mention that for running this test program the user will need
either a native MingW or Wine (with .exe executables enabled in Linux
binfmt).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
This patch allows remote-viewer to redirect output/error streams to
files.
Also if launched from a console program (for instance from the command
prompt) you are able to see output from the console where you launch
the program.
This allow to launch the program with a syntax like:
> remote-viewer.exe --debug > log.txt 2>&1
or simply:
> remote-viewer.exe --debug
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Instead of maintain a file which includes every single icon that we use
from adwaita-icon-theme (adwaita-icons-needed.wxi.in), let's depend on
mingw-adwaita-icon-theme directly.
It reduces considerably the maintainability and the risk to have missing
icons. Although, the size of the final binary gets increased from ~35MB
to ~50MB.
Resolves: rhbz#1301064
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
The only reason for us to keep maintaining the nsis installer was the
activex plugin (spicex), which requires those nsis based installers.
As the next release of RHEV/oVirt won't use the activex plugin (spicex)
let's completely remove the nsis installer from our tree and focus on
only maintain the msi installer.
oVirt/RHEV is shipping virt-viewer based on 2.0 release and, if needed,
they can stick to 3.0 branch in a future update (in case their plan goes
wrong and they end up needing the nsis support).
Related: rhbz#1324885 and rhbz#1316560
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
In order to avoid the situation where a dialog flashes onto the screen
and then is immediately hidden, I've added a couple timeouts to the
dialog.
The first is a 250ms timeout before showing the dialog. This avoids
showing the dialog at all for very small, quick transfers.
There is also a 500ms timeout before hiding a finished task. This
ensures that even transfers that only take e.g. 251ms to transfer will
get shown to the user for at least 500ms rather than being hidden 1ms
after showing the dialog.
Related: rhbz#1332180, rhbz#1324521
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
This dialog will show the progress of files being transferred from the
client to the guest and allows the user to cancel ongoing file transfer
tasks. The user can cancel each transfer individually, or cancel all
ongoing transfers at once.
Resolves: rhbz#1332180, rhbz#1324521
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
virt-viewer _only_ supports guests that have either:
A) a signle graphics device with multiple displays (monitorid=0,
displayid=(0,1,2,3)).
B) multiple graphics device with a single display each
(monitorid=(0,1,2,3), displayid=0).
From now on, avoid crashing connecting to a guest which has a graphics
configuration that violates A or B. However, even avoiding the crash, we
cannot ensure the guest will work as expected.
Resolves: rhbz#1250820
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Spice release version 0.31 requires that only spice-client.h or
spice-client-gtk.h should be included directly. As a result,
compilation is now throwing warnings like:
warning: #warning "Only <spice-client.h> can be included directly" [-Wcpp]
warning: #warning "Only <spice-client-gtk.h> can be included directly" [-Wcpp]
This patch also bumps spice version requirement to 0.31, to ensure
those files are available.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
virt-viewer-auth.h does not use any libvirt types, so the #include is
not needed, and virt-viewer-auth.h is used while building remote-viewer,
which do not use libvirt compilation flags. This caused failures on
a freshly installed box without libvirt headers.
oVirt storage domains can be in various states (inactive, in
maintainance, ...). We only want to show the ISOs it contains in the
foreign menu when the storage domain is actually active, not in the
other states.
https://bugzilla.redhat.com/show_bug.cgi?id=1310450
Don't keep trying to use a monitor config when it already failed for one
monitor, otherwise virt-viewer can end up in a situation where none of
the displays are enabled but the program is still running.
So, in case of any failure, let's skip the whole monitor config, forcing
virt-viewer to use the "fallback" one instead.
Resolves: rhbz#1315206
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Let's take advantage of GResource for loading ui files in a better and
cleaner way than virt_viewer_util_load_ui() was doing.
It also brings the benefit, at least for developers, of being able to
test ui changes without having to "make install" virt-viewer.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Title currently says "About Glade". It's not a big deal because it's not
actually shown anywhere, but just for correctness let's change it to
"About Virt-Viewer".
Thanks Jonathon Jongsma for pointing this out.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Since commit a9ce19f it has not been possible to check app version from
a tty without X session running. The issue is that gtk_get_option_group
function opens the default display if passed TRUE as argument.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
This is a temporary solution for using autobuild.sh, as commit df403f5
introduced the -Wdeprecated-declarations and gtk-vnc provides a callback
for getting authentication credentials which uses GValueArray, forcing
virt-viewer to keep using g_value_array_get_nth(), which is deprecated.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Merge libvirt and libvirt-glib checking in PKG_CHECK_MODULES, then we
don't nee the LIBVIRT_GLIB_{CFLAGS,LIBS} in Makefile.am
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Since 51ce01d virt-viewer depends again on libvirt-glib.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Since 51ce01d virt-viewer depends again on libvirt-glib.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
libvirt-glib dependency was dropped in commit 296f91c in favor to
maintain the full glib event loop integration into virt-viewer tree.
This decision was taken because libvirt-glib was not mature enough at
that time, which is not the case nowadays.
The libvirt-glib version chosen as dependency (0.1.8) is the first
release that includes the fixes for the glib event loop integration that
were backported to virt-viewer last year.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
These function have been deprecated since Gtk 3.0 and is recommended to
use _override_color() and _override_background_color() instead.
As these new functions take a GdkRGBA as parameter, let's use
gdk_rgba_parse() instead of gdk_color_parse().
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
It has been deprecated since Gtk 3.10.
New strings have been added as the GTK_STOCK_* defines had their
translations done inside Gtk itself, but now the translations of the new
added labels must be done by virt-viewer translators.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
A few more pieces of old compatibility code can be dropped, as we
already depend on GLib 2.38.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Let's enable deprecated-declarations warnings as we want to:
1) Avoid insert/maintain deprecated widgets/methods
2) Avoid adding widgets/methods that are too new, what could cause
problems like virt-viewer not being able to build in a specific distro.
Patches for making these two items possible are coming, introducing
_VERSION_MAX_ALLOWED for both GLIB and GDK and removing (as much as
possible) deprecated widgets/methods/structures.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Since commit ed9b3f3 the main window is not hidden when disconnecting.
But it also is not hidden when a connection error occurs, leaving a
black display with a not so accurate message to the users in case they
try to connect to a non-valid address from the remote-viewer connection
window and in this case the main window (display #1) shuldn't be shown.
The impetus for this chance is the following:
- user runs remote-viewer without any argument
- the remote-viewer connection window shows up
- user attempts to connect to a non-valid address
- a dialog pops up indicating a failure connecting to the graphic server
- the main window shows up saying "Connecting to the graphic server"
- user clicks 'Ok'
- the main window stays there with the same message
As a user, I expect the program to not show the main window in
connecting failure cases. This patch accomplishes that.
The reason for using properties to access those members was to ensure
that they would only be set during the creation of the object. Now that
we removed that restriction, we set private members directly.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Most of this patch consists in code being shuffled around to fit the
expected flow while using the new APIs. I tried my best to make this
patch the less intrusive as possible. Main changes are:
- Updated build requirements
* glib version 2.38
* gtk+ version 3.10
* gio
- VirtViewerApp is now a subclass of GtkApplication.
Some mainloop calls were replaced:
* gtk_main() -> g_application_run()
* gtk_quit() -> g_application_quit()
- Unified command line option handling.
The logic has moved from the main functions and split in common
options, and specific ones for each application. With this, the main
functions were highly simplified, and now basically responsible for
instantiating the App object and running the main loop.
- All Window objects must be associated with the Application.
With this, there is no need to emit our own 'window-added'/'window-
removed' signals, as those will be emited by GtkApplication whenever
gtk_application_add_window() and gtk_application_remove_window() are
called. Also, 'window-removed' was not being used anywhere.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
- 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.
Coverity says:
Result is not floating-point (UNINTENDED_INTEGER_DIVISION)
interger_division: Dividing integer expressions "preferred->width * 100"
and "zoom", and then converting the integer quotient to type double. Any
remainder, or fractional part of the quotient, is ignored.
Coverity says:
You might overrun the 108 byte fixed-size string "addr.sun_path" by
copying "unixsock" without checking the lenght.
Note: This detect has an elevated risk because the source argument is a
paramenter of the current function.
To make clear why configure failed - e.g.:
Package requirements (spice-client-gtk-2.0 >= 0.28) were not met
Requested 'spice-client-gtk-2.0 >= 0.28' but version of spice-client-gtk-2.0 is 0.25
instead of
spice-gtk requested but not found
Related:
https://bugzilla.redhat.com/show_bug.cgi?id=1214577
When neither --with-spice-gtk=yes nor --with-spice-gtk=no is used,
spice-gtk is supposed to be automatically enabled/disabled depending
on its availability. However, this is not perfectly working as once
spice-gtk has been detected as available, configure will fail if
spice-protocol or spice-controller are too old. In this case, spice-gtk
support should just be disabled rather than configure failing
The zoom can be changed by resizing the window (VNC / Spice without
the agent). It is necessary to recalculate the zoom level before
changing it, otherwise zoom operations will not work correctly.
Resolves:
https://bugs.freedesktop.org/show_bug.cgi?id=90582
Under some circumstances (Xfce desktop environment, gtk3 client, RHEL6
guest having two monitors running locally) it is possible to create
a loop of resizing windows. It is caused by size request like 1x1 sent
to the guest. These request are created because _window_queue_resize()
is called when the window is being shown.
To avoid the problem, call gtk_widget_show() after its preferred and
default sizes are set.
Resolves:
https://bugs.freedesktop.org/show_bug.cgi?id=91405
virt_viewer_events_add_handle() creates a GIOChannel in order to watch the
fd it was given for changes.
virt_viewer_events_remove_handle() is freeing all the resources allocated by
virt_viewer_events_add_handle() except for this GIOChannel. This commit adds
the needed g_io_channel_unref() call to virt_viewer_events_remove_handle()
Based on commit 8e95b8d25a3eee6316aff2f83b0c449aaf10984a from
libvirt-glib.
Original author: Christophe Fergeau <cfergeau@redhat.com>
Related to: rhbz#1243228
Trying to remove a disabled timer or handle will cause
virt_viewer_events_remove_{handle,timeout}() to return an error
rather than removing it.
Based on commit 79699d73e6e1b7218e3bd8349d176752f86128b9 from
libvirt-glib.
Original author: Christophe Fergeau <cfergeau@redhat.com>
Related to: rhbz#1243228
It's possible to create a handle to watch for file events which do not
watch for any file event. Such a handle can be enabled later with
virt_viewer_events_update_handle() by setting some conditions to watch for.
When a handle is disabled after it has been created,
virt_viewer_events_update_handle() makes sure it removes the corresponding
virt_viewer_events_handle::source IO watch if any was set.
virt_viewer_events_add_handle() will always create a
virt_viewer_events_handle::source IO watch even if the handle is not
watching for any events.
This commit makes consistent by only creating a watch with g_io_add_watch()
when the caller asked to watch for some events.
Based on commit d71c143936a35cd6c3f23ae0cbf7f3215d944051 from
libvirt-glib.
Original author: Christophe Fergeau <cfergeau@redhat.com>
Related to: rhbz#1243228
The _event_timeout_remove and _event_handle_remove methods
were holding onto the global lock when invoking the free
callback. This is a violation of the libvirt events API
contract which requires free callbacks to be invoked in
a re-entrant safe context.
Based on commit dd17c3cc587c73a8c915238f9d9a3e200e89c93f from
libvirt-glib.
Original author: Daniel P. Berrange <berrange@redhat.com>
Related to: rhbz#1243228
The deletion of libvirt timeouts/watches is done in 2 steps:
- the first step is synchronous and unregisters the timeout/watch
from glib mainloop
- the second step is asynchronous and triggered from the first step.
It releases the memory used for bookkeeping for the timeout/watch
being deleted
This is done this way to avoid some possible deadlocks when
reentering the sync callback while freeing the memory associated
with the timeout/watch.
However, it's possible to call gvir_event_update_handle after
gvir_event_remove_handle but before _event_handle_remove does
the final cleanup. When this happen, _update_handle will reregister
the handle with glib mainloop, and bad things will happen when
a glib callback is triggered for this event after _event_handle_remove
has freed the memory associated with this handle watch.
This commit marks the timeouts and watches as removed in the
synchronous _remove callback and makes sure removed timeouts/watches
are ignored in _update callbacks.
Based on commit 3e73e0cee977fb20dd29db3ccfe85b00cc386c43 from
libvirt-glib.
Original author: Christophe Fergeau <cfergeau@redhat.com>
Related to: rhbz#1243228
Timeout and watch deletion is done from an idle callback. However,
we cannot assume that all libvirt event calls (the callbacks passed
to virEventRegisterImpl) will be done from the mainloop thread. It's
thus possible that a libvirt event call will run a thread while
one of the idle deletion callbacks runs.
Given that the 'handles' and 'timeouts' arrays are shared among all
threads, we need to make sure we hold the 'eventlock' mutex before
modifying them.
Based on commit 924178f6b35735458b37d30303fe7bc753dde0b1 from
libvirt-glib.
Original author: Christophe Fergeau <cfergeau@redhat.com>
Related to: rhbz#1243228
Based on commit 1fb34633ef3b318ea678b775d5e47debc98d2184 from
libvirt-glib.
Original author: Christophe Fergeau <cfergeau@redhat.com>
Related to: rhbz#1243228
In libvirt, it's perfectly possible and widely used to have disabled
timers (timeout=-1) and fire them up 'randomly' with timeout=0.
However, with current mapping into glib mainloop it's not possible
and causing troubles.
Based on commit a40a1732e0d53fcc44b8d348cec97152dafd2b88 from
libvirt-glib.
Original author: Michal Privoznik <mprivozn@redhat.com>
Related to: rhbz#1243228
Since 2.31, g_mutex_new() is deprecated.
Based on commit 2dc7476d32a9e158e688486e8f184c719c53bb4c from
libvirt-glib.
Original author: Daniel P. Berrange <berrange@redhat.com>
Related to: rhbz#1243228
Otherwise, it will crash next time it goes find()
Backtrace:
(gdb) where
#0 0x00007efcae715095 in g_io_create_watch () from
/lib64/libglib-2.0.so.0
#1 0x00007efcae7150ef in g_io_add_watch_full () from
/lib64/libglib-2.0.so.0
#2 0x00000000004275ba in virt_viewer_events_update_handle
(watch=<optimized out>, events=1) at
virt-viewer-events.c:158
#3 0x00007efcb1a62dce in virNetSocketUpdateIOCallback (sock=0x1e75c00,
events=1) at rpc/virnetsocket.c:1981
#4 0x00007efcb1a50113 in virNetClientIOUpdateCallback
(client=<optimized out>, enableCallback=<optimized out>) at
rpc/virnetclient.c:1639
#5 0x00007efcb1a50f82 in virNetClientIO (thiscall=0x20e0170,
client=0x1f2e060) at rpc/virnetclient.c:1793
#6 virNetClientSendInternal (client=client@entry=0x1f2e060,
msg=msg@entry=0x20e0100,
expectReply=expectReply@entry=false, nonBlock=nonBlock@entry=true) at
rpc/virnetclient.c:1962
#7 0x00007efcb1a52413 in virNetClientSendNonBlock (client=0x1f2e060,
msg=msg@entry=0x20e0100) at
rpc/virnetclient.c:2036
#8 0x00007efcb1a5243d in virNetClientKeepAliveSendCB (opaque=<optimized
out>, msg=0x20e0100) at
rpc/virnetclient.c:293
#9 0x00007efcb1a5ba02 in virKeepAliveTimer (timer=<optimized out>,
opaque=0x20d3d00) at rpc/virkeepalive.c:176
#10 0x00000000004272e9 in virt_viewer_events_dispatch_timeout
(opaque=0x1e6cd30) at virt-viewer-events.c:233
#11 0x00007efcae7231b3 in g_timeout_dispatch () from
/lib64/libglib-2.0.so.0
#12 0x00007efcae72279a in g_main_context_dispatch () from
/lib64/libglib-2.0.so.0
#13 0x00007efcae722ae8 in g_main_context_iterate.isra.24 () from
/lib64/libglib-2.0.so.0
#14 0x00007efcae722dba in g_main_loop_run () from
/lib64/libglib-2.0.so.0
#15 0x00007efcb054a045 in gtk_main () from /lib64/libgtk-3.so.0
#16 0x0000000000410a9c in main (argc=1, argv=0x7ffde58a7978) at
virt-viewer-main.c:124
Based on commit cff5f1c46f4b9661e112b85159fb58ae473a9a89 from
libvirt-glib.
Original author: Marc-André Lureau <marcandre.lureau@redhat.com>
Related to: rhbz#1243228
Based on commit 8f8d9ce5238dbcbce40aa04ba55b8c55f97c79c0 from
libvirt-glib.
Original author: Marc-André Lureau <marcandre.lureau@redhat.com>
Related to: rhbz#1243228
Take a global lock whenever changing any event callbacks to ensure
thread safety.
Based on commit f1fe67da2dac6a249f796535b8dbd155d5741ad7 from
libvirt-glib.
Original author: Daniel P. Berrange <berrange@redhat.com>
Related to: rhbz#1243228
The function virt_viewer_window_resize restricts window to be bigger
than a client's screen. It avoids extending the window to more client's
screens, it causes changes of the zoom level if the guest does not fit
into a screen.
Lets remove virt_viewer_window_resize (its behaviour was introduced
by the commit 6acb3856b6d8007752388f22f97aa8aaffdb7a5e). It will let
the window managers to handle resizing of the window.
Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=1221501https://bugzilla.redhat.com/show_bug.cgi?id=1205804
Instead of building every single source file twice (once for
virt-viewer, and once for remote-viewer), just build them into a
temporary library and link the final executables against that.
The one possible drawback to this approach is that we now use the same
log domain for both executables: 'virt-viewer'. Previously, the
remote-viewer executable used 'remote-viewer' for its log domain.
As virt-viewer builds for Windows are using GTK3 nowadays, we can easily
drop GTK2 support and avoid maintenance effort in something that is not
used/tested anymore.
As virt-viewer builds for Windows are using GTK3 nowadays, we can easily
drop GTK2 support and avoid maintenance effort in something that is not
used/tested anymore.
The new msitools release includes the necessaries changes for fixing
mingw-virt-viewer build (on fedora22).
These fixes are:
- an updated libvirt.wxi, removing storageencryption.rng file
- a new included libeproxy.wxi, a new dep for gtk3 since its 3.15.3
version.
When starting virt-viewer with the --reconnect switch to a guest that
has a password, if the user cancels the authentication dialog (e.g.
pressing 'Esc'), the window will display "Waiting for guest domain to
restart". Obviously, the domain will never restart because it's already
running.
After this fix, the application will simply exit when the user cancels
authentication, even if the --reconnect switch is used.
There's no reason that we need to ask if the user wants to retry auth
failures for VNC sessions but not ask for spice sessions. If the user
doesn't want to retry, she can simply click 'cancel' when the auth
dialog pops up, just as they do with spice.
When the user cancells an authentication dialog (e.g. by pressing 'Esc',
emit the session-cancelled signal to be consistent with the spice
session implementation.
Now that VNC and Spice both return the same signal on normal
authentication failures ('session-auth-refused'), the
'session-auth-failed' signal is too confusingly similar. Rename it to
-unsupported to make it obvious that it's a different type of
(unrecoverable) error.
The spice session implementation can retry authentication on its own,
whereas the vnc session needs to tear down the session and re-connect in
order to retry a failed authentication. This results in the following
inconsistent behavior:
VNC session:
- emits a 'session-auth-failed' signal when the client does not support
a particular authentication type (i.e.: a non-recoverable error)
Spice session:
- emits a 'session-auth-failed' signal when user enters an incorrect
password, and immediately retries auth internally
VNC session:
- emits a 'session-auth-refused' error when user enters an invalid
password (i.e.: a recoverable error)
Spice Session:
- never emits a 'session-auth-refused' signal
Because of these differences, the VirtViewerApp code to handle authentication
failures is a bit confusing and difficult to maintain. To fix this issue, make
both the spice and VNC sessions emit the same signal when similar errors occur.
We use the new session API added in the last commit to determine whether the
session supports automatic retries so we know how to handle the signal.
The spice session implementation can retry authentication on its own,
whereas the vnc session needs to tear down the session and re-connect in
order to retry a failed authentication. Add API to determine this so
that we can clean up some code related to authentication failures.
Most of the setup (connecting to signals, etc) for the SpiceSession was
done in create_spice_session(), but some was done afterwards in
virt_viewer_session_spice_new(). Consolidate all session configuration
in one place.
In addition to making it easier to maintain, create_spice_session() is
also called in virt_viewer_session_spice_close(). which results in a
spice session that is configured slightly differently than the first
session created in _new(). Consolidating everything in
create_spice_session() avoids that inconsistency.
Recent chooser didn't unselect on loosing focus.
Selecting recent connection, then modifying address in entry and
doubleclicking on the same recent connection caused remote-viewer to
connect to address in the entry,
Recent chooser now unselects on loosing focus, forcing to re-select when
doubleclicking the recent connection, which will now properly set the
address to connect to.
Changed connect dialog from GtkDialog to a GtkWindow.
Added the necessary signals and buttons, to keep the
behaviour of a dialog. (ESC to close, ENTER to submit)
Connect dialog from remote-viewer is now in its own file.
Most other dialog also have their own files.
This will make changing the dialog into a window easier.
Renamed connect_dialog to remote_viewer_connect_dialog.
Enabling hotkeys will trigger a rebuild of the 'send keys' menu
containing the new hotkeys. virt_viewer_app_set_hotkeys() was clearing
and then enabling the hotkeys before parsing the string containing the
new hotkeys. This was causing these hotkeys to be missing from the 'Send
keys' menu when they are set through the spice controller because the
'send keys' menu was rebuilt before the new hotkeys are set.
Resolves: rhbz#1055600
Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1146016
Without this parameter the installer will place the start menu icon in the
Admin users path rather than the 'AllUsers'. Unprivileged users are unable
to use the menu to start the remote-viewer.
N.B. Because previous installations mixed Users and PerMachine (AllUsers)
paths, this installation will *NOT* properly upgrade them. They must be
manually uninstalled first.
We currently display a generic error message when the current binary is
older than the minimum version specified in the vv file. The previous
commit added a 'newer-version-url' field to these .vv file. This commit
adds that URL to the error message if it's set.
If set, this URL will be displayed when one of the version checks
('version' of 'versions' key fail). This URL should contain explanations
about how to get an updated remote-viewer version.
This allows us to do a more accurate version check if the .vv file
producer wants to allow builds newer than x.y-z because they contain an
important bug fix.
This tries to use the list of versions added to .vv files by the
previous commit. If remote-viewer was built with an os-id specified, and
if it's found in the 'versions' .vv file key, then the version
associated with it is used for version checks, otherwise the 'version'
field is used if present.
This new configure flag allows to specify a string ID (eg fedora22,
ubuntu10.04, ..) identifying the OS this remote-viewer build will be
for. This will be used in combination with the new 'versions' field in
.vv files in order to make it possible for the creator of the .vv file
to specify which version it expects for the various OSes which may
connect.
Specifying a single minimal version in the .vv file is not enough as
the client version will be highly dependent on the OS it's running in.
Windows versioning is not the same as linux versioning, Fedora 21 and
Fedora 22 may have different release numbers for the same version,
and we may want to force a specific minimal release in case of a
critical bug fix.
This commit adds supports for a 'versions' field in .vv files where a
list of os-id:version couples can be stored.
This was removed by commit 28a6bd6 as WINDOWS_PRODUCTVERSION
needs a buildid without a dash. Apart from this variable,
all other uses of buildid/BUILDID in virt-viewer source tree
need a dash between the version number and the buildid to avoid getting
output like "3.01" instead of "3.0-1"
Rather than patching every location where BUILDID is used, this commit
appends the "-" before substituting/defining BUILDID in configure.ac.
This does not modifies the buildid configure.ac variable, this way
WINDOWS_PRODUCTVERSION won't get an unwanted '-'.
Skipping a display does not have an effect because displays will be
reconfigured and shifted on the guest side anyway.
these monitor mappings are not valid:
'monitor-mapping=1:2;3:1' - display #2 is not specified
'monitor-mapping=4:2;2:1' - displays #1, #3 are not specified
'monitor-mapping=3:3' - displays #1, #2 are not specified
This reverts commit 68148e1bd1a47ff370c78e2569a57ae0f3d8a400.
The commit in question was causing a regression about a tiny window
being displayed when opening a vnc guest.
The issue only happens with the gtk2 version of virt-viewer.
rhbz#1170071 that was solved by the reverted commit is avoided by
the commit c45a30e909656434aa842d48d828ef038ec7364a.
Resolves: rhbz#1201679
Notify user, that VNC does not provide uuid.
Set uuid to string "VNC does not provide guid".
This is more informative then just plain "Unknown".
User will now know WHY the GUID is unknown, when using remote-viewer.
If it's not already set, set guest name field in virt-viewer-app when using VNC.
Wait for VNC to be initialized (virt_viewer_display_vnc_initialized()).
In this callback get field guest name from app and check whether it
was already set before (FE from libvirt).
If not, set the guest name to name provided by VNC from
vnc_display_get_name().
This fill fix issue in remote-viewer: Guest name is Unknown when using VNC.
The minimum size of the desktop is 100x100 if the minimum window size
is greater than this, the zoom level is greater than NORMAL_ZOOM_LEVEL
related: rhbz#1206460
File->Screenshot, File->Preferences, View->Zoom and Send keys are now
sensitive only while quest is connected.
Changed behaviour of zoom:
Previously, zoom could be set while quest wasn't connected. The zoom
would then be set on connection. There was no indication of current zoom
level while not connected to guest.
Now, the menu is not sensitive while not connected to guest. Zoom can
now be only modified while connected to guest, or from the command line.
Whenever we reach these branches, we will abort or have to create a new
spice session (from the dialog showed to the user). So, destroying the
channel on these situations seems sane enough.
It also avoids an error dialog to be popped out twice with (basically)
the same information.
In theory, the dispose method can be called multiple times, so any
member variables that are unreffed should be set to NULL so that we
don't accidentally unref them multiple times.
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.
This patch rather checks whether the domain name was specified.
Related: rhbz#1209398, rhbz#1211573
This reverts commit a830275344c88aef12166661b68ea2b4429c7212.
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
This reverts commit 9ba2d28a0f35b69befd26d7c122bbe4cd626422f.
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
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
Push new pot with
cd po
make virt-viewer.pot
zanata push
Pull new translations with
cd po
zanata pull
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
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
It turned out that not only the current MSI broke the "component rule",
but also that our files are not versionized correctly. Windows Installer
applies some file versioning rules before replacing a file
http://msdn.microsoft.com/en-us/library/aa368599%28v=vs.85%29.aspx
Since msitools doesn't extract version from files and populate the Version
field of the File table, it "usually" keep the current file installed.
It's practically impossible to rely on version information from
files (from a quick look, only 5% of the files are versionized and even
less correctly, libgcrypt seems to do non-monotonic buildid for example)
So the rule that applies when files are not versionized is to check the
file hash, and the modified date. File hash was added recently in
msitools, but doesn't apply when the installed file itself has a
version.
In order to solve the above problems, it's simpler to just have a
different installation prefix. Windows Installer will see files with
different component guid, and won't be checking any file update rule. I
have verified the upgrade is working, not leaving any file behind and
updating registry correctly with this solution. Until the files are
correctly versionized, it looks like the only sensible thing to
do. Furthermore, this make it simpler to have several versions installed
in parallel later on (when we change productid)
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));
Add support to build the virt-viewer's msi using GTK3.
For the GTK3 build, in order to provide all used icons for Windows
systems we have to include manually all the icons we want to or add
adwaita-icon-theme as dependency. I've decided to go with the first
approach, what can be improved when we have "foreach" support in
msitools (https://bugzilla.gnome.org/show_bug.cgi?id=741296).
libgcc_s_sjlj-1 is needed by libgmp (on x86)
libgcc_s_seh-1 is needed by libgmp (on x86_64s)
libgmp-10.dll is needed by libnettle
libhogweed-2-5.dll is provided by libnettle
libnettle-4-7.dll is needed by gnutls
gnutls is needed by gvnc and libvirt
An interesting point here that worth to mention is the usage of /nonfatal
when including libgcc_s_{sjlj,seh}-1.dll. As we only have the _seh in x64
the build breaks trying to add "not found" files. A check for arch was
one option to solve the problem, but _sjlj may exist in x64 as well, when
using an old gcc. An explicit check if the file exists (in compile time)
was another idea, but for some reason the "-" part of the filename was
interpreted as a math operand, breaking the build.
With all that in mind, adding /nonfatal was the most convenient solution.
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
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)
- 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 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.
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 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
The G_N_ELEMENTS() type is size_t but this was being passed to
a format string with '%lu' which is of a different size on many
platforms. Just delete this part of the warning message since
it was not hugely useful.
virt_viewer_session_on_monitor_geometry_changed() gets called
immediately upon agent connection, but sometimes this is before any
displays have been received. Simply return early when this is the case.
When using a custom fullscreen display configuration, it's possible to
specify that e.g. a single screen should be fullscreen on client
monitor #4. Since we send down absolute positions and disable alignment
when all windows are in fullscreen, we can send configurations with a
very large offset to the top-left corner. This could result in the guest
trying to create a screen that was much larger than necessary. For
example when sending a configuration of 1280x1024+4240+0, the guest
would need to allocate a screen of size 5520x1024, which might fail if
video memory was too low. To avoid this issue, we shift all displays
so that the minimum X coordinate for all screens is at x=0, and the
minimum y coordinate is at y=0.
We have to check for the spice version where the
SPICE_CLIENT_ERROR_AUTH_NEEDS_PASSWORD_AND_USERNAME was introduced and
not for the one where spice_channel_get_error() was introduced.
The function app_window_try_fullscreen() will lookup the initial monitor
for the nth monitor internally, so we should pass in the display ID to the function
rather than the mapped monitor ID. This was causing 2 monitors on the
same monitor with a configuration like this:
monitor-mapping=1:2;2:1
Since a window is not created at startup for each display, the first
display(s) set when the application is opened will never receive and
treat the "notify::show-hint" signal on VirtViewerWindow, once the
callback is only set when the display is set to the specific window.
It causes problems like the "Send Key" menu not activated till an extra
display is added. To avoid this problem, let's force a call to
display_show_hint() everytime a display is set.
Resolves: rhbz#1152468
https://bugzilla.redhat.com/show_bug.cgi?id=1152468
It turns out that nc does not leave on server disconnect, and there
doesn't seem to be any option to do that, leaving client open, and
a bunch of idle processes.
Replacing nc with socat solves that, client is disconnected when
the VM is shut down, when the sever connection is closed.
https://bugzilla.redhat.com/show_bug.cgi?id=1030487
When user starts virt-viewer without specifying VM domain name
or with a wrong name a list of running machines is shown
and user may choose one of them.
When a user tries to connect to ovirt without specifying
VM name (remote-viewer ovirt://ovirt.example.com) or with
wrong VM name a list of available virtual machines is shown,
and the user may pick a machine he wants to connect to.
It turns out this is supposed to be done through update requests with a
CD image with an empty name, which is what the current code tries to do.
The only reason it's not working is because of server-side bugs with
oVirt < 3.5
The requirement on libgovirt is raised to 0.3.2 as
a small change is needed as well in libgovirt to allow empty filenames:
https://git.gnome.org/browse/libgovirt/commit/?id=bdb788fcc
Without this change, nothing too bad will happen, but the CD won't be
removed and warnings will be logged in the console.
The virDomainOpenGraphics API cannot label the socket
we pass to it. Prefer virDomainOpenGraphicsFD (if building
with libvirt 1.2.8 or later) which creates the socket for us
and works with SELinux too.
Fall back to the old API if the new one is unsupported
(i.e. the libvirtd on the host is older than the libvirt version
virt-viewer was compiled against).
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1141228
Signed-off-by: Ján Tomko <jtomko@redhat.com>
virt_viewer_auth_collect_credentials() was recently changed to return
a boolean instead of an integer (2561c171). This change introduced a
regression in the authentication dialog behavior, making it impossible
for the user to cancel.
As the function should return < 0 in error cases, let's explicitly
return/set the return value to -1 in error cases. Otherwise, the
function will return 0.
This patch also fixes a regression introduced by (a5ce2ed3).
https://bugzilla.redhat.com/show_bug.cgi?id=1142742
If uuid was never set, we never checked the 'fallback' monitor map.
Initializing the monitor map to the fallback value at startup solves
this issue. This allows fallback mode to work with older servers that
don't send the UUID.
Previously, the fullscreen floating toolbar and the "toggle-fullscreen"
hotkey (which maps to the menu item action) had slightly different
methods of exiting fullscreen. The floating toolbar method unset the
'fullscreen' property on the application (which causes all windows to
simultaneously exit fullscreen), whereas the hotkey did not. This had a
side-effect of preventing the display from auto re-sizing if it was
fullscreened again. After this change, both the hotkey and the toolbar
button will unset the application-level 'fullscreen' property when
exiting fullscreen mode.
Resolves: rhbz#1022608
Set the display's session property in the constructor. If the session is
not set, then virt_viewer_display_get_session() doesn't return anything
useful.
Currently, windows have a default size of 400x400 pixels. This is a
strange aspect ratio for a display, and it is also too small to be
useful for much. Since the default window size determines the initial
size of newly-enabled displays, it would be nice if we used a slightly
better size.
When setting the 'display' for a VirtViewerWindow, the initial size for
that window should be the size of the remote display. So we synthesize a
desktop resize event when setting a new display for a window. This is
only done for enabled displays. Disabled displays generally have a size
of 0x0, which would result in the window being at it's minimum size, so
just allow the window to use its default size.
Previously, a window was created at startup for each display, even if
the display was not enabled. This resulted in a fixed 1:1 association
between windows and remote displays. Since there was always one window
created at startup to display status messages (the "main window"), this
was always associated with remote display #1. But if the first remote
display was not enabled, we ended up with a extra black window with a
message saying ("Waiting for display 1...").
By creating windows on demand, we can re-use the "main window" for any
arbitrary display, even if it's not display #1.
Resolves: rhbz#1032939
When using the fullscreen display mapping configuration file, extra
monitors could end up enabled by mistake. This was because
virt_viewer_app_get_initial_monitor_for_display would end up returning
Nmonitor = Ndisplay when the display map hash lookup failed. In
reality, when a display map is specified, but the hash lookup fails,
the display should not be enabled. This function now returns -1 to
distinguish this case, and the display is not enabled when this value is
returned.
Resolves issue described at
https://bugzilla.redhat.com/show_bug.cgi?id=1129477#c9
Rather than requiring all callers to calculate the initial monitor
mapping before calling app_window_try_fullscreen, move the
responsibility for calculating the correct monitor into this function.
This makes it less likely that somebody will forget and a display will
get placed on the wrong monitor.
Right after being created, the SpiceDisplay 'display' private member is
added to the VirtViewerDisplaySpice GTK+ container with
gtk_container_add. This call will take ownership of the floating
reference that SpiceDisplay got upon creation.
This means VirtViewerDisplaySpice::display is a pointer to SpiceDisplay,
but it must not be unref'ed when the object is destroyed as we don't own
that reference.
As the container which owns the reference is the
VirtViewerDisplaySpice instance itself, we don't need to take an
additional reference here.
This fixes a crash when exiting remote-viewer after connecting to a
SPICE VM:
#0 0x00007ffff3f33a81 in g_type_check_instance_is_fundamentally_a (type_instance=0x874500, fundamental_type=80) at gtype.c:3981
#1 0x00007ffff3f19f96 in g_object_unref (_object=0x874500) at gobject.c:3067
#2 0x000000000042a1ea in virt_viewer_display_spice_finalize (obj=0x6ebc30) at virt-viewer-display-spice.c:65
#3 0x00007ffff3f1a257 in g_object_unref (_object=0x6ebc30) at gobject.c:3170
#4 0x0000000000428de7 in destroy_display (data=0x6ebc30) at virt-viewer-session-spice.c:649
#5 0x00007ffff3bbb51b in g_ptr_array_foreach (array=0x7e12a0, func=0x428d71 <destroy_display>, user_data=0x0) at garray.c:1502
#6 0x00007ffff3bbaadf in ptr_array_free (array=0x7e12a0, flags=FREE_SEGMENT) at garray.c:1088
#7 0x00007ffff3bbaa10 in g_ptr_array_unref (array=0x7e12a0) at garray.c:1036
#8 0x00007ffff3bcf9bd in g_data_set_internal (datalist=0xa0adb0, key_id=1622, new_data=0x0, new_destroy_func=0x0, dataset=0x0) at gdataset.c:407
#9 0x00007ffff3bcfe74 in g_datalist_id_set_data_full (datalist=0xa0adb0, key_id=1622, data=0x0, destroy_func=0x0) at gdataset.c:670
#10 0x00007ffff3f1a771 in g_object_set_data (object=0xa0ada0, key=0x437252 "virt-viewer-displays", data=0x0) at gobject.c:3461
#11 0x0000000000429b56 in virt_viewer_session_spice_channel_destroy (s=0x6eb910, channel=0xa0ada0, session=0x8cb3a0) at virt-viewer-session-spice.c:854
#12 0x00007ffff3f12d81 in g_cclosure_marshal_VOID__OBJECT (closure=0x8e8fd0, return_value=0x0, n_param_values=2, param_values=0x7fffffffcd80, invocation_hint=0x7fffffffccc0, marshal_data=0x0) at gmarshal.c:1272
#13 0x00007ffff3f0e143 in g_closure_invoke (closure=0x8e8fd0, return_value=0x0, n_param_values=2, param_values=0x7fffffffcd80, invocation_hint=0x7fffffffccc0) at gclosure.c:768
#14 0x00007ffff3f2aef0 in signal_emit_unlocked_R (node=0x7c1f20, detail=0, instance=0x6eb910, emission_return=0x0, instance_and_params=0x7fffffffcd80) at gsignal.c:3553
#15 0x00007ffff3f2a1f3 in g_signal_emit_valist (instance=0x6eb910, signal_id=219, detail=0, var_args=0x7fffffffd058) at gsignal.c:3309
#16 0x00007ffff3f2a746 in g_signal_emit (instance=0x6eb910, signal_id=219, detail=0) at gsignal.c:3365
#17 0x00007ffff529d784 in spice_session_channel_destroy (session=0x6eb910, channel=0xa0ada0) at spice-session.c:1990
#18 0x00007ffff529ed25 in spice_channel_dispose (gobject=0xa0ada0) at spice-channel.c:153
#19 0x00007ffff52acd26 in spice_display_channel_dispose (object=0xa0ada0) at channel-display.c:136
#20 0x00007ffff3f1a132 in g_object_unref (_object=0xa0ada0) at gobject.c:3133
#21 0x00007ffff52a4afb in spice_channel_delayed_unref (data=0xa0ada0) at spice-channel.c:2156
#22 0x00007ffff3bf21d1 in g_idle_dispatch (source=0xa35a00, callback=0x7ffff52a49f3 <spice_channel_delayed_unref>, user_data=0xa0ada0) at gmain.c:5320
#23 0x00007ffff3bef8eb in g_main_dispatch (context=0x68a920) at gmain.c:3064
#24 0x00007ffff3bf0661 in g_main_context_dispatch (context=0x68a920) at gmain.c:3663
#25 0x00007ffff3bf0853 in g_main_context_iterate (context=0x68a920, block=1, dispatch=1, self=0x6c8c60) at gmain.c:3734
#26 0x00007ffff3bf0c7c in g_main_loop_run (loop=0x889b20) at gmain.c:3928
#27 0x00007ffff69be44f in gtk_main () at gtkmain.c:1207
#28 0x0000000000431896 in main (argc=1, argv=0x7fffffffd648) at remote-viewer-main.c:183
Due to a GTK+ limitation and bad testing from my side, I've pushed
two patches trying to add support to use Ctrl + {+, -, 0} from numpad
to control zoom-in, zoom-out and zoom-reset.
Unfortunately, with the first patch (3a168815) I've duplicated the menu
items related to the zoom functions. With the second one (55cdb986),
provided to not show the duplicated menu items, we came back to the
initial state, where the numpad accelerators don't work.
So, in resume, multiple accelerators in a GTK+ widget are only supported
on applications using GApplication, what is not our case and won't be
till we drop the GTK+2 support.
Revert "Do not show duplicated menu items" and
Revert "Add support to use numpad accelarators for zoom-{in.out,reset}"
This reverts commits 55cdb9867df05f1c4f6c8e569a6f0c1e0bc28d99 and
3a168815b738076526ba0f3e9a82e6fb1db482e9.
When the support to use numpad accelerators for zoom-{in,out,reset}
was added (3a168815), by mistake, we have added duplicated buttons
in View -> Zoom.
The oVirt foreign menu support reused some existing bits from the older
SPICE controller foreign menu code. However, this controller code is
only built when spice-gtk support is built, while the oVirt foreign menu
code could be used with VNC as well. Trying to build the ovirt foreign
menu code without spice-gtk causes build issues due to missing
functions, or missing declarations, ...
The libgovirt/spice-gtk code which is entangled is the code to update
the foreign menu when its content changes, or when a new window is
opened. Making the oVirt-specific code independant from the
spice-gtk-specific code is not too complicated, but this comes at the
expense of a bit of code duplication, but this is only simple code
iterating over the GHashTable storing the opened windows.
Resolves: rhbz#1127156
We have to force displays to update geometry when the agent connects to
ensure the client will have the guest with the right resolution when the
guest has rebooted or the agent has crashed.
https://bugzilla.redhat.com/sho_bug.cgi?id=1021841
As virt-viewer uses GtkAccelMap for shortcuts and that GTK only can have
one key binding per accelerator (in accel_map_add_entry), let's also add
support specificly for the numpad keys in the virt-viewer code
https://bugzilla.redhat.com/show_bug.cgi?id=883433
When the .vv file has an [ovirt] section, we should try to create a foreign
menu out of it. This will allow remote-viewer to offer a menu to change the
currenty inserted cdrom.
Contrary to the ovirt:// case when we already have fetched an OvirtAPI
and OvirtVm instance in order to get the SPICE/VNC connection details,
when working from a .vv file, we'll need to get them from the REST API.
Authentication should happen through the JSESSIONID cookie, if that
fails we want to give up on using the foreign menu, so we don't need to
set up authentication callbacks.
For foreign menu support, we'll need a way to pass oVirt-specific
information in the .vv file. This will be done through an additional
[ovirt] section, this commit is in preparation for that.
This class is used to implement the so-called oVirt 'foreign menu'
which is a menu populated with ISO images available on the
oVirt instance that the user can dynamically insert into the
virtual machine he is currently viewing.
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
6edde57862ac30e74ce6412c93a2fa925ae4ea67.
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.
When using the --with-buildid configure paramater, the build id which is
substituted in the MSI wxs file is automatically prepended by a '-', but
the build id which is used in the C files does not get this '-'
automatically.
Currently, the linux and mingw spec files prepend a '-' on their own to the
--with-buildid argument, but this causes the MSI installer to show 2 '-'
during installation: "Please wait while Windows configures VirtViewer
0.6.0--1"
This commit always prepends a '-' to the buildid strings, and removes the
'-' from the spec files. This is to ensure the separator between version
number and buildid is not forgotten, which could give a confusing version
number.
Commit 8fa942 broke enabling of additional displays. We don't want to send down
display re-configurations due to events that happen while setting up windows for
enabled displays that we recieve from the server. However, by ignoring
allocations on unmapped windows, we fail to send display configurations for new
displays that a user is attempting to enable via the window menu. To
discriminate between these two cases, we check whether the display is in the
'ready' state or not.
- Unmapped displays with the 'ready' hint set can be assumed to be displays
that are enabled on the server that we are attempting to create windows for on
the client. In this case, we should *not* send a display configuration to the
server
- Unmapped displays with the 'ready' hint cleared can be assumed to be displays
that are not yet enabled on the server that we are trying to enable in the
client. In this case, we *should* send a display configuration to the server
Due to spice-gtk-0.23 missing SPICE_GTK_CHECK_VERSION macro, the
condition:
causes the following error:
virt-viewer-session-spice.c: In function 'virt_viewer_session_spice_main_channel_event':
virt-viewer-session-spice.c:525:64: error: missing binary operator before token "("
#if defined(SPICE_GTK_CHECK_VERSION) && SPICE_GTK_CHECK_VERSION(0, 23, 21)
^
Also one more warning is fixed in this patch:
virt-viewer-session-spice.c:476:19: warning: unused variable 'error'
[-Wunused-variable] const GError *error;
^
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
In some situation, (for example, guest without vdagent running), it's
possible to pass key combinations to virt-viewer. When using alt+f4,
this can cause the 'do you want to quit?' dialog to show while it's
non-functional.
This commit moves the check for kiosk mode to before we show this dialog.
When the --hotkeys option is given, all hotkeys that are not explicitly
specified are disabled. The method used to disable hotkeys is to change the
accel map entry to key=0, mods=0. However, when we decide whether to set a grab
sequence on the spice dispay widget, we simply use the return value for
gtk_accel_map_lookup_entry and assume that a TRUE value returned from this
function means that the hotkey is enabled. In reality, this function will
return TRUE for disabled hotkeys, but the 'key' variable will be set to key=0,
mods=0. The result is that if I start virt-viewer like this:
virt-viewer --hotkeys secure-attention=ctrl+alt+end ...
and the guest that I'm attached to uses server mouse mode, it will be impossible
to release the grab on the spice widget. Because we will explicitly disable the
grab keys in the spice widget and handle the 'release-cursor' hotkey in
virt-viewer, but the hotkey is an empty accel key.
Instead of simply checking the return value of gtk_accel_map_lookup_entry, we
have to inspect the return value for 'key' and check whether any keys are
actually assigned.
virt_viewer_app_set_kiosk creates a new window at startup for each client
monitor (regardless of whether the guest supports more than one display). This
seems unnecessary. Only do this if kiosk mode is actually enabled.
virt_viewer_app_get_nth_window() will return the proper window when passed 0 for
the 'nth' argument, so there's no need to avoid calling it in this case. It
just complicates the code logic.
When the zoom level is changed, the virt-viewer window gets resized. But we
don't want this to trigger a resize of the guest display. But occasionally
rounding errors cause the guest display to be reconfigured when zooming out. To
fix this, we first check whether the current size is the preferred size. If it
is, we don't send down a resize command to the guest.
In addition to preventing guest resizes in response to zooming, it also improves
the behavior when the guest display resolution is changed from within the guest.
Before this change, we'd have the following behavior:
A. guest changes display to WxH
B. client gets notified of change and resizes the window to WxH
C. client responds to window resize by sending a new monitor config command to the guest
With this change, the extra step C will be avoided because we're already at the
preferred size.
Resolves: rhbz#1004051
The code to determine scaling of windows was incorrectly
using the original desktop size instead of the host screen
size. The 128 pixel fudge factor was also causing windows
to be scaled when there was no need for them to be.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
When the zoom level is changed, the virt-viewer window gets resized. But we
don't want this to trigger a resize of the guest display. But occasionally
rounding errors cause the guest display to be reconfigured when zooming out. To
fix this, we first check whether the current size is the preferred size. If it
is, we don't send down a resize command to the guest.
In addition to preventing guest resizes in response to zooming, it also improves
the behavior when the guest display resolution is changed from within the guest.
Before this change, we'd have the following behavior:
A. guest changes display to WxH
B. client gets notified of change and resizes the window to WxH
C. client responds to window resize by sending a new monitor config command to the guest
With this change, the extra step C will be avoided because we're already at the
preferred size.
Resolves: rhbz#1004051
People seem to have a hard time understanding the --attach flag.
Rewrite the docs in the hope that people figure it out this time.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
deactivate() is called in response to a failed authentication attempt. If the
session is cleared here, when a user attempts to re-authenticate, it will issue
a warning and will not actually work. So only clear the session here if we're
not going to re-try authentication.
We were setting the show_hint to READY as soon as we got the vnc-connected
signal. But there may be an authentication step between vnc-connected and
vnc-initialized. In this case, we switch to an empty black display during the
authentication step instead of showing the 'waiting for display N' status.
The main window (display #1) is treated a bit differently from other windows,
since it is opened at app start and displays status messages while we attempt to
connect to the remote guest. As such, it should really stay open as long as the
app is running.
The impetus for this change is the following:
- user attempts to connect to a remote VNC display with a password
- user types the wrong password
- A dialog pops up indicating that authentication failed and asking if the user
would like to try to re-connect.
- User clicks 'Yes'
- Because the connection was disconnected, all windows are closed
- remote-viewer tries to reconnect again, at which point a new display window is
opened, and the window gets placed by the window manager (possibly on another
monitor altogether).
As a user, I expect the program to simply re-use the existing window when trying
to re-authenticate, instead of having the window disappear and then re-appear at
a different location. This patch accomplishes that.
Recent spice servers send the guest vm name and uuid to the client. We can use
these values to display the proper vm name in the window title if a title is not
specified on the commandline. We can also be smarter about the title in
virt-viewer as well.
If a title is specified on the comamndline (-t/--title=foo), we use that. If not,
we fall back to the vm name. If that is empty, we fall back to the uri of the
connection.
Comparison between old behavior and new behavior
Using new spice-server
Command Old title New title
------- --------- ---------
remote-viewer -t xyz spice://host:port xyz xyz
remote-viewer spice://host:port spice://host:port <vmname>
virt-viewer <vmname> <vmname> <vmname>
virt-viewer <uuid> <uuid> <vmname>
Using old spice-server
Command Old title New title
------- --------- ---------
remote-viewer -t xyz spice://host:port xyz xyz
remote-viewer spice://host:port spice://host:port spice://host:port
virt-viewer <vmname> <vmname> <vmname>
virt-viewer <uuid> <uuid> <vmname>
When trying to load ui files, we try to find the file in several directories.
If a file is not found in one directory, try to load it from the next directory.
However, if a file is found in a directory but we are not able to load it (e.g.
due to unsupported versions of glade used to generate it, etc), we should print
a warning to the terminal to help the developer debug the issue.
This is an unexpected failure (whereas not finding the file in that directory at
all is an 'expected' failure).
Libvirt uses gnulib for making winsock look like POSIX
sockets. This means that in the libvirt event handle
callbacks the application will be given a file descriptor
rather than a winsock HANDLE object. The g_io_channel_unix_new
method will detect that it is an FD and delegate to the
g_io_channel_win32_new_fd method. Unfortunately the glib Win32
event loop impl is not very good at dealing with FD objects,
simulating poll() by doing a read() on the FD :-(
The API docs for g_io_channel_win32_new_fd say
"All reads from the file descriptor should be done by
this internal GLib thread. Your code should call only
g_io_channel_read()."
This isn't going to fly for libvirt, since it has zero
knowledge of glib at all, so is just doing normal read().
Fortunately we can work around this problem by turning
the FD we get from libvirt back into a HANDLE using the
_get_osfhandle() method.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
virt_viewer_util_load_ui() looks first in the current directory, and then looks
in the system data dirs for a ui file to load, but if you install virt-viewer in
a different prefix, it will load the system UI file rather than the one from the
install prefix. Try to load the ui file from pkgdatadir first.
It's not enough to set the property to notify of its change. Add a
virt_viewer_app_set_enable_accel() helper, and call it after the changes
to accelerators are made when loading from file.
I verified the menu is correctly built when connection from controller
or command line too.
Updating the mime database creates files in the install directory, and
these files are not cleaned up on make uninstall, so this causes a make
distcheck failure.
d1c2bc1 updated configure.ac spice-gtk requirement to 0.22, but did not
update the various places which duplicated this requirement, namely the
.spec.in files and the README file.
remomte-viewer installs a file to $datadir/share/mime to register a
mime-type for its .vv files. However, after installing this file,
update-mime-database must be run in order to update the shared mime
database. This commit (inspired by what Nautilus/planner are doing) adds
what is needed for that.
If the mime type is not correctly registered, gvfs-info console.vv will not
return the correct mime type, and xdg-open console.vv will fail to start
remote-viewer, and will fall back to running gedit as the .vv file is a
text file.
https://bugzilla.redhat.com/show_bug.cgi?id=1044209
This ensures that the display is enabled when it gets its first Allocate event
(which causes a display reconfiguration). If the display is not enabled at this
point, it won't send down a new monitors_config message until the second
allocation, which may result in the display being disabled until a window is
resized.
The govirt package in f19 is an older one, and does not have some of the
functions used since the switch to govirt 0.3.0. As 0.3.0 broke ABI, it's
not convenient to backport it to f19.
Update the spec file to reflect the fact that oVirt support in git is no
longer buildable on f19.
It's possible to have only display N enabled without having all of the displays
before it. I experienced this a couple times with a windows guest where display
1 would show up before display 0 and we'd hit a warning that nth is not less
than nmonitors. So find the highest display ID and then create an array of that
size, leaving missing displays initialized to 0
This caused secondary displays on a windows guest to flicker under some
circumstances. The old code didn't re-configure displays in this case either, so
it shouldn't have been included in the display alignment refactor.
Don't rely on spice-gtk to do any alignment of displays. This patch sets the
disable-display-align property on the SpiceMainChannel, and makes the
VirtViewerSession in charge of doing all alignment. This means that every
display has to tell the VirtViewerSession when its "virtual monitor" has changed
configuration (and wants to reconfigure its display on the guest), rather than
sending it directly to the Main Channel. The session will then align the
displays (if necessary), and the spice session will send down new configuration
for all displays at once. This solves a couple of problems:
1. It allows the session to send down absolute coordinates only in the case
where *all* windows are fullscreen (so that we can still support
vertically-stacked displays, etc). But it auto-aligns displays if only a
subset of the displays are in fullscreen mode. This solves the problem of
overlapping regions on different displays when one monitor is in fullscreen
because only one monitor's configuration was updated and the others were not
aligned.
2. Allows us to always align based on the current position of each display. This
contrasts with the earlier behavior where the position used for alignment was
the window's position at the time when it was last resized. This caused
displays to be arranged in a seemingly non-deterministic manner if one window
was moved and then another window was resized (causing a display
re-configuration).
Solves rhbz#1002156
There are cases where multiple VirtViewerWindow objects are created before the
VirtViewerApp constructor has a chance to run. Since the constructor has not yet
run, priv->main_window will still be NULL, the test in
virt_viewer_app_window_new() will fail, and they will not get their initial zoom
level set. When the constructor finally runs, it set the zoom level of the main
window to the value set on the command line, but all other windows that had
already been created retained the default 100% zoom level.
By creating the main_window in the instance init function, we ensure that the
main window is created before we get any 'session-display-added' signals and all
displays will start out with consistent zoom levels.
VIRT_VIEWER_HIDE could be set as an environment variable to (theoretically) hide
displays whenever they were not ready. Unfortunately, this bit of functionality
appears bitrotten and doesn't work anymore (it prevents windows from opening
when you click 'view > displays > display 2', for instance).
Auto-conf should only happen at startup. It is triggered from several places due
to the somewhat unreliable ordering of events, but that doesn't mean we want to
run it several times. This patch ensures that we only do it once.
Fullscreen mode generally just assigns display 1 to monitor 1, display 2 to
monitor 2, etc. For custom setups, you can define a monitor mapping in the
settings keyfile per-vm. This requires a vm uuid (so only works in virt-viewer
or on versions of spice-server that send the uuid over the wire). The format is
pretty basic:
[6485b20f-e9da-614c-72b0-60a7857e7886]
monitor-mapping=2;3
The group name ("6485b20f-e9da-614c-72b0-60a7857e7886") is the uuid id of the
vm. This group has a single key: monitor-mapping. This key is an array of
integers describing the order in which to assign the monitors to a guest
display. Any monitors that are not listed in this array will not be configured
at startup. For instance:
monitor-mapping=2;1
will attempt to configure 2 displays on the guest and assign the first display
to monitor 2 and the second display to monitor 1.
monitor-mapping=2
will only configure a single display on the guest and place it on the second
monitor. Any monitor numbers listed in the keyfile are greater than the number
of monitors that are physically present, they will be ignored.
The VirtViewerApp::windows hash table owns the memory for both the keys
and values it stores. virt_viewer_app_remove_nth_window() uses
g_hash_table_steal() which does not call the 'free' function neither for
the key nor for the value. This method takes care of releasing the
reference for the value it extracted from the hash table, but not for the
key.
This commit fixes by explicitly taking a reference on the value rather than
stealing the one held by the hash table. We can then replace the use of
g_hash_table_steal() with g_hash_table_remove() which will take care of
freeing the removed key.
VirtViewerSessionSpice creates a reference-holding VirtViewerDisplay
array and associates it with the display SpiceChannel with
g_object_set_data(channel, "virt-viewer-displays").
When virt_viewer_session_spice_channel_destroy() is called and the display
channel is being destroyed, we should ensure these VirtViewerDisplay
references are dropped or the displays could outlive the session.
In my testing (start qemu with a f20 live cd, connect to it, when the
kernel has started booting and qxl is initialized (4 displays listed in the
display submenu), kill qemu), I was getting "invalid unclassed pointer in
cast to 'VirtViewerSessionSpice'" warnings through
#0 0x00000035bac504e9 in g_logv (log_domain=0x35bb039aa4 "GLib-GObject",
log_level=G_LOG_LEVEL_WARNING, format=<optimized out>,
args=args@entry=0x7fffffffc7c0) at gmessages.c:989
#1 0x00000035bac5063f in g_log (
log_domain=log_domain@entry=0x35bb039aa4 "GLib-GObject",
log_level=log_level@entry=G_LOG_LEVEL_WARNING,
format=format@entry=0x35bb041010 "invalid unclassed pointer in cast to '%s'")
at gmessages.c:1025
#2 0x00000035bb032e09 in g_type_check_instance_cast (type_instance=0x665580,
iface_type=<optimized out>) at gtype.c:4025
#3 0x0000000000426e9f in get_main (self=0x894190) at virt-viewer-display-spice.c:92
#4 0x0000000000426ece in show_hint_changed (self=0x894190)
at virt-viewer-display-spice.c:100
#5 0x00000035bb010298 in g_closure_invoke (closure=0x9f47c0,
return_value=return_value@entry=0x0, n_param_values=2,
param_values=param_values@entry=0x7fffffffcad0,
invocation_hint=invocation_hint@entry=0x7fffffffca70) at gclosure.c:777
#6 0x00000035bb02235d in signal_emit_unlocked_R (node=node@entry=0x651f60,
detail=detail@entry=1782, instance=instance@entry=0x894190,
emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fffffffcad0) at gsignal.c:3586
#7 0x00000035bb02a0f2 in g_signal_emit_valist (instance=<optimized out>,
signal_id=<optimized out>, detail=<optimized out>,
var_args=var_args@entry=0x7fffffffcc60) at gsignal.c:3330
#8 0x00000035bb02a3af in g_signal_emit (instance=<optimized out>,
signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3386
#9 0x00000035bb014945 in g_object_dispatch_properties_changed (object=0x894190,
n_pspecs=92, pspecs=0x0) at gobject.c:1047
#10 0x00000035bb017019 in g_object_notify_by_spec_internal (pspec=<optimized out>,
object=0x894190) at gobject.c:1141
#11 g_object_notify (object=0x894190, property_name=<optimized out>) at gobject.c:1183
#12 0x000000000041b617 in virt_viewer_display_set_show_hint (self=0x894190, mask=1,
enable=0) at virt-viewer-display.c:659
#13 0x000000000042712c in update_display_ready (self=0x894190)
at virt-viewer-display-spice.c:156
#14 0x00000035bb010298 in g_closure_invoke (closure=0x6ba480,
return_value=return_value@entry=0x0, n_param_values=2,
param_values=param_values@entry=0x7fffffffcfb0,
invocation_hint=invocation_hint@entry=0x7fffffffcf50) at gclosure.c:777
#15 0x00000035bb02235d in signal_emit_unlocked_R (node=node@entry=0x651f60,
detail=detail@entry=1798, instance=instance@entry=0xa2c250,
emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fffffffcfb0) at gsignal.c:3586
#16 0x00000035bb02a0f2 in g_signal_emit_valist (instance=<optimized out>,
signal_id=<optimized out>, detail=<optimized out>,
var_args=var_args@entry=0x7fffffffd140) at gsignal.c:3330
#17 0x00000035bb02a3af in g_signal_emit (instance=<optimized out>,
signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3386
#18 0x00000035bb014945 in g_object_dispatch_properties_changed (object=0xa2c250,
n_pspecs=92, pspecs=0x0) at gobject.c:1047
#19 0x00000035bb017019 in g_object_notify_by_spec_internal (pspec=<optimized out>,
object=0xa2c250) at gobject.c:1141
#20 g_object_notify (object=0xa2c250, property_name=<optimized out>) at gobject.c:1183
#21 0x00007ffff7044d9a in update_ready (display=0xa2c250) at spice-widget.c:257
#22 0x00007ffff7044df0 in set_monitor_ready (self=0xa2c250, ready=0)
at spice-widget.c:265
#23 0x00007ffff7049bb3 in primary_destroy (channel=0x9f40b0, data=0xa2c250)
at spice-widget.c:2131
#24 0x00007ffff704afd5 in channel_destroy (s=0x892880, channel=0x9f40b0, data=0xa2c250)
at spice-widget.c:2444
#25 0x00000035bb010298 in g_closure_invoke (closure=0xa27850,
return_value=return_value@entry=0x0, n_param_values=2,
param_values=param_values@entry=0x7fffffffd570,
invocation_hint=invocation_hint@entry=0x7fffffffd510) at gclosure.c:777
#26 0x00000035bb02235d in signal_emit_unlocked_R (node=node@entry=0x7cf600,
detail=detail@entry=0, instance=instance@entry=0x892880,
emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fffffffd570) at gsignal.c:3586
#27 0x00000035bb02a0f2 in g_signal_emit_valist (instance=<optimized out>,
signal_id=<optimized out>, detail=<optimized out>,
var_args=var_args@entry=0x7fffffffd700) at gsignal.c:3330
#28 0x00000035bb02a3af in g_signal_emit (instance=<optimized out>,
signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3386
#29 0x00007ffff6ceba87 in spice_session_channel_destroy (session=0x892880,
channel=0x9f40b0) at spice-session.c:1923
#30 0x00007ffff6cecf05 in spice_channel_dispose (gobject=0x9f40b0)
at spice-channel.c:149
#31 0x00007ffff6cf912c in spice_display_channel_dispose (object=0x9f40b0)
at channel-display.c:136
#32 0x00000035bb014ee8 in g_object_unref (_object=0x9f40b0) at gobject.c:3160
#33 0x00007ffff6cf300c in spice_channel_delayed_unref (data=0x9f40b0)
at spice-channel.c:2135
#34 0x00000035bac492a6 in g_main_dispatch (context=0x67a6b0) at gmain.c:3066
#35 g_main_context_dispatch (context=context@entry=0x67a6b0) at gmain.c:3642
#36 0x00000035bac49628 in g_main_context_iterate (context=0x67a6b0,
block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
at gmain.c:3713
#37 0x00000035bac49a3a in g_main_loop_run (loop=0x7baf60) at gmain.c:3907
#38 0x00000035bfdaa2d5 in gtk_main () at gtkmain.c:1158
#39 0x000000000042caf1 in main (argc=1, argv=0x7fffffffdc78) at remote-viewer-main.c:179
In that backtrace, the last ref to the VirtViewerDisplay instances is held by the
SpiceChannel:virt-viewer-displays object data which will only be released after
completion of spice_display_channel_dispose()
Commit 0d58d9c72 removed the setting of the
SpiceChannel:virt-viewer-display object data, but there was still a
call to g_object_get_data() trying to use it. Since it's only used to
output a debug log, we can remove this call and fix up the debug log.
When starting remote-viewer without argument, we are showing a
window where the user can enter connection details. We then
go on to try and connect to the URI the user specified, and if
the connection fails, we disconnect from the remote server, and then
we show again the connection window so that the user can correct the
URI if he entered it wrong.
However, when this happens, the window for the previous connection
will still be visible even if connection failed. To avoid this,
this commit makes sure we hide all windows when we get a disconnection
event.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1024309
remote-viewer behaviour is currently inconsistent in the connection dialog:
if the user enters a valid URI, but then remote-viewer fails to connect
to it, then we'll show again the connection dialog through a call
to virt_viewer_app_start() in remote_viewer_deactivated(). If instead we
enter an invalid URI in the connection dialog, then remote-viewer will
report an error and quit.
This commit makes sure in the latter case, we report the error and show
again the connection dialog. The user can press 'Cancel' in the
connection dialog to get out of remote-viewer as in this case, we
return directly FALSE rather than going through the cleanup: label
and looping.
remote_viewer_deactivated() can be calling virt_viewer_app_start()
without checking whether it returns TRUE or FALSE. It returns FALSE
when it was not successful (when it failed to parse the URI to connect
to for example, or whe the user presses Cancel in the connection dialog).
This means that if the user starts remote-viewer, enters a valid URI
in the connection dialog to which it cannot connect to
(spice://example.com:999) and then presses Cancel in the connection
dialog that appears after the connection failure, then remote-viewer
will be sitting there with an empty window doing nothing.
This commit ensures we chain to the parent class when
virt_viewer_app_start() returns FALSE, which causes remote-viewer to
exit.
When using the connection dialog, if the user picks an invalid
URI first causing a failed connection, and then picks/enters a valid
URI, remote-viewer window title will be set to the first invalid URI,
not to the second one which was entered.
As the user may have specified a window title to use on the command
line (-t option), we need to be careful not to override that when
setting the window title on the second attempt.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1024309
virt-viewer currenty builds with gtk+ 2.0 by default. Nowadays, gtk+ 2.0 is
legacy, and this default is inconsistent with spice-gtk which defaults to
gtk+ 3.0. This commit switches the default to gtk+ 3.0
When we enter fullscreen mode before the window is shown, we set up a signal
handler to enter fullscreen mode when the window is mapped. If we then leave
fullscreen mode before the window is mapped, we don't disconnect this handler,
so it will still enter fullscreen mode when it is shown.
Fixes rhbz #1009513
Remove the distinction between --full-screen and --full-screen=auto-conf. Just
make --full-screen behave like auto-conf did. There's really no advantage to
having two slightly different fullscreen startup modes.
Whether the hotkeys are set through command line, controller or file, we
should get the same keybinding result (clear unspecified, and enable
global bindings)
However, when started from command line arguments, without --hotkey
argument, it will have basic non-global default bindings.
https://bugzilla.redhat.com/show_bug.cgi?id=1023447
The CA certificate to use to authenticate the various hosts in
an oVirt instance can be fetched from https://ovirt.example.com/ca.crt.
However, the gio API we are using does not seem to be checking the
server-side certificate of ovirt.example.com before connecting to it,
which could lead to man-in-the-middle attacks. Now that the CA
certificate to use can be specified from the command line using
--ovirt-ca-file, we can remove this automatic fetching of the CA
certificate.
libgovirt 0.3.0 and newer can be passed from the commandline a CA
certificate to use during SSL communications. This commit adds support
for this option to remote-viewer.
When starting remote-viewer with no argument, a connection dialog
is shown. If the URI the user types in this dialog as trailing
or leading spaces, then connection will fail because remote-viewer
will keep them as if they were significant.
This commit makes sure we remove spaces at the beginning/end of
the URI before trying to use it.
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1024199
When you call virt_viewer_window_enter_fullscreen() on a hidden window, it
didn't actually change its fullscreen state. Instead, it sets up a map-event
handler to enter fullscreen after it is shown. When _set_display() is called on
a window that is pending fullscreen status, it initially sets the fullscreen
state of the display to FALSE, which can cause an unwanted resize to be sent
down to the guest. This patch changes the behavior to set its fullscreen state
to TRUE even before the window is shown.
Freezing property notifications prevents VirtViewerDisplaySpice from
synchronizing its fullscreen/auto-resize state with the base class until after
the notifications are thawed. During the time that notifications were frozen,
an allocation happens. The action we take on an allocation event depends on the
current state of the auto_resize variable, so this can result in an unwanted
resize.
Instead of storing the auto_resize member as an integer, use the enum, it makes
it slightly easier for debugging. Also, explicitly initialize the value.
This conflicts with the --full-screen switch, because if kiosk mode is disabled,
it sets disables fullscreen mode, which overrides the earlier call to enable
fullscreen.
In the 'Do you want to close the session dialog?', the default focus
is currently on the 'Do not ask me again' checkbox.
The purpose of this dialog is to make sure that the user does not
inadvertantly exit remote-viewer, this commit changes the default
action in this dialog to be 'cancel' rather than switching the
'Do not ask me again 'checkbox.
If VirtViewerSessionVnc::disconnected is called because of an
authentication failure, we get:
(remote-viewer:29588): gtk-vnc-DEBUG: vncdisplay.c Disconnected from VNC server
(remote-viewer:29588): Gtk-WARNING **: Attempting to add a widget with type
VncDisplay to a container of type VirtViewerDisplayVnc, but the widget is
already inside a container of type VirtViewerDisplayVnc, please use
gtk_widget_reparent()
#0 0x0000003136e50499 in g_logv (log_domain=0x3f2e13e143 "Gtk",
log_level=G_LOG_LEVEL_WARNING, format=<optimized out>,
args=args@entry=0x7fffffffd210) at gmessages.c:989
#1 0x0000003136e505ef in g_log (log_domain=<optimized out>, log_level=<optimized out>,
format=<optimized out>) at gmessages.c:1025
#2 0x00000000004230eb in virt_viewer_display_vnc_new (vnc=0x8a8250)
at virt-viewer-display-vnc.c:169
#3 0x0000000000422191 in virt_viewer_session_vnc_disconnected (vnc=0x8a8250,
session=0x86bf00) at virt-viewer-session-vnc.c:113
#4 0x00000031372104c7 in _g_closure_invoke_va (closure=closure@entry=0x8ad2b0,
return_value=return_value@entry=0x0, instance=instance@entry=0x8a8250,
args=args@entry=0x7fffffffd530, n_params=0, param_types=0x0) at gclosure.c:840
#5 0x0000003137229749 in g_signal_emit_valist (instance=0x8a8250,
signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffd530)
at gsignal.c:3238
#6 0x000000313722a3af in g_signal_emit (instance=<optimized out>,
signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3386
#7 0x00007ffff7dbeb5a in on_disconnected (conn=0x8b5aa0, opaque=0x8a8250)
at vncdisplay.c:1563
#8 0x00000031372104c7 in _g_closure_invoke_va (closure=closure@entry=0x7d55f0,
return_value=return_value@entry=0x0, instance=instance@entry=0x8b5aa0,
args=args@entry=0x7fffffffd820, n_params=0, param_types=0x0) at gclosure.c:840
#9 0x0000003137229749 in g_signal_emit_valist (instance=0x8b5aa0,
signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffd820)
at gsignal.c:3238
#10 0x000000313722a3af in g_signal_emit (instance=<optimized out>,
signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3386
#11 0x00007ffff7b97308 in do_vnc_connection_emit_main_context (opaque=0x7fffe3c91f40)
at vncconnection.c:578
#12 0x0000003136e49256 in g_main_dispatch (context=0x681840) at gmain.c:3065
#13 g_main_context_dispatch (context=context@entry=0x681840) at gmain.c:3641
#14 0x0000003136e495d8 in g_main_context_iterate (context=0x681840,
block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
at gmain.c:3712
#15 0x0000003136e499ea in g_main_loop_run (loop=0x830430) at gmain.c:3906
#16 0x0000003f2dfa8f75 in gtk_main () at gtkmain.c:1158
#17 0x0000000000429bf3 in main (argc=1, argv=0x7fffffffdcd8) at remote-viewer-main.c:179
This commit calls virt_viewer_session_clear_displays() before creating a dummy VNC display with
virt_viewer_display_vnc_new(), which avoids this warning.
This fixes the "send menu" for hotkeys set with non-modifiers keys. The
current order of press events is wrong, as it sends first non-modifiers
keys, and in general ctrl+t will work, t+ctrl will not.
https://bugzilla.redhat.com/show_bug.cgi?id=846006
ctrl_key_to_gtk_key() capitalizes all key names not explicitly specified in the
translation table. So 'end' becomes 'END', which is not a valid key name
according to GTK+. Un-comment out the 'end' item from the table and set it to
the properly capitalized key name ("End").
This allows users to specify e.g. "ctrl+alt+end" as a hotkey for
sending the secure attention sequence.
On Windows, the OS doesn't allow applications to handle Ctrl+Alt+Del, because
it's handled by the OS at a much lower level. Although we have a menu item to
send this sequence to the guest, it's not possible to send via the keyboard (in
the windows client). So add an alternative key sequence (defaulting to
Ctrl+Alt+End) to send this sequence to the guest.
Allow to run the client in kiosk mode with window-manager-less
environment.
This was a conditional workaroud on win32. I am making it
non-conditional to make fullscreen work on non-wm environment. Hence
I don't see the need to refer explicitely to the bug workaround, since
it is no longer something that should be removed, even when bgo 652049
is fixed.
In kiosk mode, it's useful to keep the app alive, even if the remote
session ended for example. Ie, we want to prevent the app from quiting
itself, even if the remote end closed, lost network, or crashed etc.
We want extra windows to remain blank after connection.
For example, if the remote has a single monitor, and client has more, we
don't want extra client monitors to say "Connected to graphic server"
all the time on other monitors. Instead, we leave them empty/black in
kiosk mode.
Open a window on each client monitor in fullscreen. If the remote
display has less monitors than the client, the extra client monitors
will still be used to prevent the user from accessing the windows or
desktop below, and also to show some status messages when necessary.
Since the returned window is weak, it can already returns existing
windows (instead of creating one and failing to insert).
This allows the following set_kiosk() function to create a main window
before the app constructor is called.
remote-viewer currently doesn't provide automatic ssh tunnels, and even if
it would, that would be explicit in the url given to remote-viewer (such
as spice+ssh://...)
https://bugzilla.redhat.com/show_bug.cgi?id=991261
At the moment, smartcard keyboard accelerators are always enabled when
specified, even if no software smartcard reader is in use. This commit only
enables the smartcard keyboard accelerators when a smartcard reader
has been found. This fixes rhbz#866944
This property will be set to TRUE when a software smartcard reader
is available, and FALSE otherwise. This property can only be TRUE
when using SPICE and when smartcard support is enabled, and when
both smartcard certificates and smartcard db directory are set.
The g_array_free() return value is 'char *' rather than 'void *'
so must be explicitly cast to 'uint8 *'.
The accelerator menu callback data is a GtkMenu rather GtkWidget
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Allow to add dynamically generated key combos later on.
This also removes the extra combo lookup, which used to be problematic
due to translations etc.
It turns out gdk on win32 already restores properly the window
size/positon when leaving fullscreen. On non-win32, the WM should
do the job.
This solves the first window having too small size after leaving fullscreen:
https://bugzilla.redhat.com/show_bug.cgi?id=978362
The fix 0dca975d64fcf0782ec7b3e3bd965f1bcf47c528 make the first window
unshrinkable right after start. Wait until the window is mapped and
remove the dirty-resizable state after (win32/gtk2).
Windows Installer expects version of form major.minor.build in order to
perform updates.
Following Daniel Berrange suggestion, compute a ProductVersion
compatible with this scheme by shifting virt-viewer "micro" release
number and adding the extra "buildid".
Virt-viewer sometimes opens one too many windows if the guest is
configured with more monitors than the client (the spice monitor
configuration request and the current config aren't related, so there is
some race). Instead, let's hide extra monitors that wouldn't fit in
auto-conf.
https://bugzilla.redhat.com/show_bug.cgi?id=985898
When trying to connect to a VM which uses SPICE with only a tls port
set:
<graphics type='spice' tlsPort='-1' autoport='no' listen='0' keymap='en-us'>
<listen type='address' address='0'/>
</graphics>
the connection will fail with
"Cannot determine the graphic address for the guest spice"
virt_viewer_extract_connect_info() indeed assumes that if no
non-TLS port is set, then this means we are trying to connect through
an already open socket, and otherwise the connection fails.
The presence of a TLS port is only checked when a non-TLS port is set.
This commit reworks that logic to start by extracting both the non-TLS
and TLS ports (only when using SPICE for the latter), and by only trying
to parse the socket to use if none of these 2 ports is set
This fixes rhbz#982840
Before this patch-set virt-viewer was calling spice_session_has_channel_type(
session, SPICE_CHANNEL_USBREDIR) from the session-initialized signal handler,
So as soon as the display channel gets added to the session, the check was
done. This causes the check to return FALSE for usbredir capable vms if
the usbredir channel(s) get added to the session after the display channed.
This patch refactors things to not depend on channel creation order.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This is a recent regression introduced by independant fullscreen windows
support, which reopened the bug "Resolution higher than native could not
be set in fullscreen"
https://bugzilla.redhat.com/show_bug.cgi?id=864929
data/remote-viewer.desktop: error: value
"x-scheme-handler/spice;application/x-virt-viewer" for string list key
"MimeType" in group "Desktop Entry" does not have a semicolon (';') as
trailing character
to fix
virt-viewer.c: In function 'virt_viewer_connect':
virt-viewer.c:686:13: error: format not a string literal and no format arguments [-Werror=format-security]
g_warning(error->message);
For some VMs, setting host subject on SpiceSession is needed to
be able to connect to it using SPICE/SSL. Until recently, this
was not exposed in oVirt REST API/libgovirt. Since
oVirt 3.2/libgovirt 0.1.0, the host subject is available, this
patch makes use of it.
This should fix connection to oVirt VMs that were migrated to a
different host than the one they were started on.
The controller "auto-display-res" flag should be use to reconfigure
guest to match client configuration. This is what the
--fullscreen=auto-conf option is already made for.
https://bugzilla.redhat.com/show_bug.cgi?id=967154
This field is used to invite the user to close running instances, when
updating the installation with an MSI. "A remote desktop client" isn't
specific enough, use a VirtViewer specific description.
There used to be a check to fullscreen the only visible display on
current monitor, by checking the number of visible monitors. Now that
fullscreen is independant for each display, and goes on current monitor,
it's useless.
However, this code path is still used for the app --full-screen, at
startup time. And it is still nicer to open the display on respective
client monitors, rather than all on current monitor.
The Spice session may outlive the virt-viewer session, due to it's async
nature. Use the more robust virt_viewer_signal_connect_object() to fix
delayed potential crashes.
In file included from virt-viewer-session-spice.c:41:
gbinding.c: In function 'on_source_notify':
gbinding.c:381: warning: unused parameter 'gobject'
gbinding.c: In function 'on_target_notify':
gbinding.c:422: warning: unused parameter 'gobject'
gbinding.c: In function 'g_binding_init':
gbinding.c:709: warning: unused parameter 'binding'
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
To avoid pkg-config accidentally falling back to
native versions, set the PKG_CONFIG_LIBDIR var
explicitly
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The MANUFACTURER env variable is mandatory since it is used
in the data files. wixl will exit with parser error if it
is not set
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
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"
3b981d953f270662360e5b0c78183924276a18ed
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>
The browser plugin code has been effectively unmaintained since
the day it was merged. There has always been a caveat that the
code has not been properly audited to ensure it is secure, and
being unmaintained doesn't give a warm secure feeling. These
days there are better solutions for the browser which are pure
HTML5 code, noVNC and SPICE-HTML5.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The virt-viewer connection file can now have a version=0.5 field. If
the virt-viewer version opening the connection doesn't provide at
least that version, an error is raised with the version required.
This should also fix the send-key menu showing in the wrong position with a
gtk2 build, when the tooltray icon is clicked on the 2nd or higher monitor.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
GLib deprecated the GValueArray type without providing an ABI
compatible replacement. Thus we need to disable dreprecation
warnings
../../src/virt-viewer-auth.c: In function 'virt_viewer_auth_vnc_credentials':
../../src/virt-viewer-auth.c:112:9: error: 'g_value_array_get_nth' is deprecated (declared at /usr/include/glib-2.0/gobject/gvaluearray.h:65): Use 'g_array_index' instead [-Werror=deprecated-declarations]
Rather than trying to manually keep track of authors,
just auto-generate the list from GIT logs
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
In order to build the MSI, you will need msitools:
http://ftp.gnome.org/pub/GNOME/sources/msitools/
The MANUFACTURER environment variable is mandatory and should be set
to the manufacturer/author of the MSI build.
Add a configure argument to append build version details, similar to
what Daniel Berrange proposed in the "use finer package version in
mingw-virt-viewer" thread on the ML.
Unfortunately, I don't see yet how we could avoid the browser dialog
asking which application to open. On Firefox, each user has a
mimeTypes.rdf, but we can't really modify it..
Process messages while waiting for pi.hProcess.
Avoid the spice-x from hanging in WaitForInputIdle(), although the
client itself might not be ready, not even started...
https://bugzilla.redhat.com/show_bug.cgi?id=903190
Sometimes the guest may shortly disable and then re-enable a monitor while
in fullscreen mode, this happens for example when changing display resolution
through gnome-display-properties inside the guest. This causes the client
window-manager to remap the window, and this can cause it to end up
on a different monitor.
This patch fixes this by remembering the position the window is places at
when going fullcreen and moving it there again when its gets (re-)shown.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Based on bug report by Hans:
The code block for saving was below this check:
if (priv->session) {
virt_viewer_session_close(VIRT_VIEWER_SESSION(priv->session));
if (priv->connected) {
priv->quiting = TRUE;
return;
}
}
Which means it never executes when quiting virt-viewer while conneced, causing
the "Do not ask me again" checkbox settings to not be saved.
This stops monitor order from the guest from being re-arranged in multi-
monitor setups when switching between fullscreen and windowed mode.
Note this relies on spice-gtk's auto monitor alignment code, which currently
does not properly handle setups where there is more then 1 row of monitors,
ie 2x1 - 5x1 will work fine, but 2x2 will not.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Now that we pass the real monitor coordinates, tell spice-gtk to use them,
rather then to use the passed coordinates as input for its automatic monitor
alignment. This fixes ie monitors in a 2x2 grid, showing up as a 4x1
configuration in the guest.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The g_message() and g_warning functions expect printf style of
arguments. That is, whenever we want to print a string, it has
to be preceded with "%s" format.
When remote-viewer is compiled without spice-gtk support, spice-session.h
will not get included in remote-viewer.c, causing these warnings:
remote-viewer.c: In function 'remote_viewer_start':
remote-viewer.c:693:9: warning: implicit declaration of function
'virt_viewer_session_set_file' [-Wimplicit-function-declaration]
remote-viewer.c:693:9: warning: nested extern declaration of
'virt_viewer_session_set_file' [-Wnested-externs]
This makes it much easier to build an updated Windows installer binary
as this can now be done using mock/koji/... by using this .spec and
a virt-viewer tarball.
The nsis file we ship is generating an installer for a GTK+2 build
of virt-viewer, so it's inconsistent for the mingw-virt-viewer
spec file to generate a GTK+3 build. Switch to building a GTK+2
version of virt-viewer in mingw-virt-viewer.spec
When building on f18, the build fails because of unpackaged
debug files. Use the appropriate mingw macro to generate
the mingw debug packages.
The build failure is:
RPM build errors:
error: Installed (but unpackaged) file(s) found:
/usr/i686-w64-mingw32/sys-root/mingw/bin/debug-helper.exe.debug
/usr/i686-w64-mingw32/sys-root/mingw/bin/remote-viewer.exe.debug
/usr/i686-w64-mingw32/sys-root/mingw/bin/virt-viewer.exe.debug
/usr/i686-w64-mingw32/sys-root/mingw/bin/windows-cmdline-wrapper.exe.debug
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/debug-helper.exe.debug
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/remote-viewer.exe.debug
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/virt-viewer.exe.debug
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/windows-cmdline-wrapper.exe.debug
Installed (but unpackaged) file(s) found:
/usr/i686-w64-mingw32/sys-root/mingw/bin/debug-helper.exe.debug
/usr/i686-w64-mingw32/sys-root/mingw/bin/remote-viewer.exe.debug
/usr/i686-w64-mingw32/sys-root/mingw/bin/virt-viewer.exe.debug
/usr/i686-w64-mingw32/sys-root/mingw/bin/windows-cmdline-wrapper.exe.debug
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/debug-helper.exe.debug
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/remote-viewer.exe.debug
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/virt-viewer.exe.debug
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/windows-cmdline-wrapper.exe.debug
When getting monitor info for going fullscreen, Get the monitor under
*our* window rather then under the root-window.
Noticed this not working properly when testing the monitor coordinates stuff,
but this should also help people seeing problems when using non equally sized
monitors.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Learn to connect to a VNC server with the connection details file, ex:
[virt-viewer]
type=vnc
host=localhost
port=2356
password=foobar
v2:
- add username/password support
https://bugzilla.redhat.com/show_bug.cgi?id=843410
remote-viewer can either use the default grab/ungrab handled by
spice-gtk, or override it and use the standard gtk+ accelerator
mechanism. However, the code currently assumes that if any accelerator
is set in remote-viewer, then the grab key has been overridden.
This commit makes sure the grab key is actually overridden before assuming
so.
Disable default accelerators when setting bindings from the controller
in case the controller does not override them all. This ensures we don't
inherit from the bindings set in VirtViewerApp::constructor if the controller
doesn't set any bindings for a given action.
In a recent commit, 3bb6f5ec805ecfe78eba6d4d98e3ffcab195273a, I
introduced a regression: going fullscreen would no longer match client
and guest resolution correctly.
A GdkScreen is not necessarily the physical screen monitor size.
Lookup the physical monitor size using
gdk_screen_get_monitor_geometry().
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=881020
SpiceSession has 'ca' property which is type of GByteArray*.
However, when we read the property from file, we read it as
string. For conversion g_byte_array_new_take() is used which
takes given pointer as guint8* so we need to do the cast.
make syntax-check is producing some errors about empty line at EOF
and missing #include <config.h> in src/virt-viewer-file.c
* src/virt-viewer-file.c: add #include <config.h>
* data/virt-viewer-debug.nsis.in: remove empty line at EOF
The .desktop file did not comply with the Desktop Entry spec as checked
with desktop-file-validate. Boolean keys are defined as taking only
'true' or 'false', the entry Terminal had False. MimeType is a string
list and therefore must be terminated with a ;
If VirtViewerSession:file is set, it should be used to define the
connection parameters. Also correct the mime type used in this case.
The mime type is needed to identify the kind of resources we are
adding to the recent list. The recent list can then be filtered and
various application handling that type may attempt to access that
resource.
Wait until the widget is actually on screen before removing its
size constrain. This solves 50x50 window secondary window size
when connecting to a multi-monitor spice guest.
This installer will provide with the tools and configuration needed to
debug virt-viewer & remote-viewer. It will install itself by default in
virt-viewer directory.
With current implementation, all binaries that need it call
bindtextdomain but not directly. They call a helper function
instead. This makes, however, syntax-check fail as it cannot
recognize it.
Original patch proposed by Eric Blake <eblake@redhat.com>
The previous change in 399aae55aa384bf91dff0fc770497c0d5f935fa9 rely
on correct session-connected signal. However, the spice backend
is emiting it too early, when the main channel is created, where
it should wait until it is connected instead.
In virt_viewer_app_activate(), priv->connected is set to FALSE when
the connect/active is successfull. However, we rely on it to know
whether the virt_viewer_app_disconnected() is an error, so only set it
to FALSE when connection failed.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=875697
When falling back to saving to .png, the filename might not
end with .png. This commit appends the .png extension to the
screenshot filename if it's missing.
Currently, the screenshots can only be saved to png. This commit
checks if the file extension is a known one, and will save to this
format if it is. Otherwise it will fallback to saving to png.
It makes sense for the screenshots to be saved in ~/Images,
especially as otherwise the filechooser will display
'recent documents' to which we cannot save. This commit also sets
the default screenshot name to 'Screenshot'.
The check that at least one of spice-gtk and gtk-vnc is present
uses a wrong variable name to check for spice-gtk presence, which
causes the check to think it's never present. This would make
gtk-vnc presence mandatory. This commit fixes the name of the
spice-gtk variable ($have_gtk_spice -> $have_spice_gtk).
One of previous commits (74b1b62510d939) allowed us to connect to
localhost directly if ssh transport was used. However, if there's
not transport, we SIGSEGV'ed as g_str_equal doesn't like NULL as
one of arguments. Change this to g_strcmp0 which does the same
service but is more friendly to NULL arguments.
Currently, if user wants to reconnect to a domain he can use
'-r' cmd line argument. This makes virt-viewer listen to
domain events. However, if connection to libvirtd breaks
somehow, we will receive no longer any event. Hence we must
reconnect to the libvirt.
When connecting to a VM that does not have a 'listen' tag in its
graphcs element, we have to guess where to try to connect to the VM's
display. The current default is the host specified in the connection
URI which is correct for most transports, however, the SSH transport
makes the display connection from the remote end, so in that case,
attempt to connect to localhost.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
virt-viewer-util.c: In function 'virt_viewer_util_init':
virt-viewer-util.c:289: warning: implicit declaration of function 'setlocale'
virt-viewer-util.c:289: warning: nested extern declaration of 'setlocale'
virt-viewer-util.c:289: error: 'LC_ALL' undeclared (first use in this function)
virt-viewer-util.c:289: error: (Each undeclared identifier is reported only once
virt-viewer-util.c:289: error: for each function it appears in.)
This is a simple program that will set some debug variable, and run
gdb and wait until it finished. This makes it possible to debug
"remote-viewer --spice-controller" easily, by setting the necessary
variables and keeping the parent process running (the activex whatches
its death)
To use it, replace the HKCU "Software\spice-space.org\spicex\client"
value "$INSTDIR\bin\remote-viewer.exe --spice-controller" with
"$INSTDIR\bin\debug-helper.exe remote-viewer.exe --spice-controller".
This helps track package version that were used during the
build of Windows installer. It's not ideal, but make up the
lack of package management on windows
It's currently not possible to configure guest with higher resolution
than native, as it will switch back to native, since the gtk widget
allocation will always end up being the size of the screen. We
special-case fullscreen mode, and only resize when entering
fullscreen. Furthermore, it avoids sending extra unnecessary resize
events to the guest whenever gtk+ call size allocate in various
stages, with different values.
https://bugzilla.redhat.com/show_bug.cgi?id=864929
Fix some unwanted guest resize due to rounding issues (at least when
scaling up)
We may want to save the original remote desktop size, instead of
always checking widget requisition. That way zooming shouldn't resize
guest at all, but it seems tricky to handle that special case vs user
window resize that should trigger guest resize.
https://bugzilla.redhat.com/show_bug.cgi?id=856678
The virt_viewer_display_idle() will queue a resize event that will
result in display size requisition of 50x50. If we later resize the
window to 1x1 in virt_viewer_window_resize() we end up with a tiny
window.
It is legitimate not to force that 1x1 window resize when toggling the
option. After the rest of the logic in virt_viewer_window_resize(), if
the remote desktop ends up being resize, that will trigger another
virt_viewer_set_desktop_size() and finally change the window size
appropriately.
https://bugzilla.redhat.com/show_bug.cgi?id=856610
The string '::' is just one of many possible ways to express
the IPv6 "any" address. Others include '::0', '0:0:0:0:0:0:0:0',
'0::0' and more. Instead of trying to do strcmp, actually try
parsing the address with GInetAddress and then simply use an
accessor to check what type it is
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Currently the remote viewer windows get the URI as their
title. Provide a --title STRING arg to remote-viewer to
let the user override the title with something more
meaningful to them.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Commit 2201a5a was supposed to free a SPICE ticket leak, but it's
actually introducing a double-free as the SPICE ticket is
unconditionally freed at the end of
virt_viewer_session_spice_main_channel_event
Callers manually add a trailing \n when they call virt_viewer_app_trace,
but it's sometimes forgotten, leading to rhbz#822794. This commit
removes the \n from all callers (it was missing in a few of them)
and adds it in virt_viewer_app_trace.
Now that we have 2 distinct binaries, remote-viewer and virt-viewer,
'PACKAGE' can no longer be used in error messages as the name of the
binary. This causes a small inconsistency when running
'remote-viewer --foobar' as the error message would be:
'Unknown option --foobar
Run 'virt-viewer --help' to see a full list of available command line options'
This commit makes sure we use argv[0] for this message.
Fixes rhbz#814150
GtkNotebook will use the currently visible widget as default page.
If we don't show status widget before we append the display, the
current page will be on display. Quoting Gtk+ documentation:
"Note that due to historical reasons, GtkNotebook refuses to switch to
a page unless the child widget is visible. Therefore, it is
recommended to show child widgets before adding them to a notebook."
This property will be set when the display can be selected to be
"enabled" and shown (this can involve creating/connecting an
additional guest monitor, and may need guest agent cooperation for
example).
Rely on spice-gtk display channel monitors property to manage
displays. The same display channel may now provide several monitors,
the SpiceDisplay widget must be told which monitor to display
This flag will help to track whether the display has been
removed/closed and whether it really has a valid display.
Ready in contrast, is used to "hide" temporarily the display (when
starting or redrawing the display, to avoid artifacts)
When display is released, detach signal automatically.
Fix various crash related to not cleaning up signal handlers properly,
due to no longer 1-1 only relation between display widget and channel.
Use virt_viewer_signal_connect_object(), a copy of telepathy
utility function tp_g_signal_connect_object(). This function
will take care of removing signal handler if any of emitter or
attached object are destroyed.
The following patches will have this condition met, since there is no
longer 1-1 relation between channel and display. The channels can
continue to be around when some of the display are removed.
Fix copied from libvirt, commit by Eric Blake.
glibc 2.15 (on Fedora 17) coupled with explicit disabling of
optimization during development dies a painful death:
/usr/include/features.h:314:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
Work around this by only conditionally defining _FORTIFY_SOURCE,
in the case where glibc can actually use it. The trick is using
AH_VERBATIM instead of AC_DEFINE.
This reverts commit 3ce6df7c309068f36e2602692da809a153ed5688. This
commit broke virt-viewer which expects this function to return -1
or 0 on error, and a positive value on success in
virt_viewer_initial_connect.
VirtViewerApp::activate is expected to return -1 on errors.
It calls the VirtViewerSession::open_* methods, which return FALSE
on error. However, VirtViewerApp::activate directly returns these
boolean instead of testing the returned value and properly returning
-1 on errors. This caused errors in these open methodes to be ignored.
==25063== 59 bytes in 1 blocks are definitely lost in loss record 5,163 of 9,502
==25063== at 0x4A0884D: malloc (vg_replace_malloc.c:263)
==25063== by 0x3DE384D2BE: g_malloc (gmem.c:159)
==25063== by 0x3DE3862D0B: g_strdup (gstrfuncs.c:356)
==25063== by 0x41F40A: connected (remote-viewer-main.c:186)
==25063== by 0x3DE400F663: g_closure_invoke (gclosure.c:777)
==25063== by 0x3DE40206D7: signal_emit_unlocked_R (gsignal.c:3547)
==25063== by 0x3DE402866C: g_signal_emit_valist (gsignal.c:3296)
==25063== by 0x3DE4028CCF: g_signal_emit_by_name (gsignal.c:3389)
==25063== by 0x41AA53: reemit_signal_VOID (virt-viewer-session-ovirt.c:211)
==25063== by 0x3DE400F942: _g_closure_invoke_va (gclosure.c:840)
==25063== by 0x3DE4027D87: g_signal_emit_valist (gsignal.c:3207)
==25063== by 0x3DE4028CCF: g_signal_emit_by_name (gsignal.c:3389)
==25063== 14 bytes in 1 blocks are definitely lost in loss record 623 of 9,502
==25063== at 0x4A0884D: malloc (vg_replace_malloc.c:263)
==25063== by 0x34561092F7: __vasprintf_chk (vasprintf_chk.c:82)
==25063== by 0x3DE3882F1A: g_vasprintf (stdio2.h:199)
==25063== by 0x3DE3862EDC: g_strdup_vprintf (gstrfuncs.c:509)
==25063== by 0x3DE3862F7B: g_strdup_printf (gstrfuncs.c:535)
==25063== by 0x40CBAE: virt_viewer_app_update_pretty_address (virt-viewer-app.c:1538)
==25063== by 0x40FB55: virt_viewer_app_free_connect_info (virt-viewer-app.c:1707)
==25063== by 0x40FBE9: virt_viewer_app_dispose (virt-viewer-app.c:1291)
==25063== by 0x3DE40144F7: g_object_unref (gobject.c:2981)
==25063== by 0x40C31A: main (remote-viewer-main.c:336)
==25063== 10 bytes in 1 blocks are definitely lost in loss record 491 of 9,502
==25063== at 0x4A0884D: malloc (vg_replace_malloc.c:263)
==25063== by 0x34561092F7: __vasprintf_chk (vasprintf_chk.c:82)
==25063== by 0x3DE3882F1A: g_vasprintf (stdio2.h:199)
==25063== by 0x3DE3862EDC: g_strdup_vprintf (gstrfuncs.c:509)
==25063== by 0x3DE3862F7B: g_strdup_printf (gstrfuncs.c:535)
==25063== by 0x40DE36: window_update_menu_displays_cb (virt-viewer-app.c:1640)
==25063== by 0x3DE383833F: g_hash_table_foreach (ghash.c:1524)
==25063== by 0x3DE400F663: g_closure_invoke (gclosure.c:777)
==25063== by 0x3DE40206D7: signal_emit_unlocked_R (gsignal.c:3547)
==25063== by 0x3DE402866C: g_signal_emit_valist (gsignal.c:3296)
==25063== by 0x3DE40287C1: g_signal_emit (gsignal.c:3352)
==25063== by 0x5772F95: gtk_widget_show (gtkwidget.c:3225)
==25063== 8,431 (72 direct, 8,359 indirect) bytes in 1 blocks are definitely lost in loss record 9,468 of 9,502
==25063== at 0x4A0884D: malloc (vg_replace_malloc.c:263)
==25063== by 0x3DE384D2BE: g_malloc (gmem.c:159)
==25063== by 0x3DE38616B1: g_slice_alloc (gslice.c:1003)
==25063== by 0x3DE3861C05: g_slice_alloc0 (gslice.c:1029)
==25063== by 0x3DE402F96F: g_type_create_instance (gtype.c:1872)
==25063== by 0x3DE40147A7: g_object_constructor (gobject.c:1849)
==25063== by 0x3DE4016260: g_object_newv (gobject.c:1632)
==25063== by 0x3DE40168AB: g_object_new (gobject.c:1542)
==25063== by 0x40C4BD: virt_viewer_util_load_ui (virt-viewer-util.c:41)
==25063== by 0x40C7EB: virt_viewer_auth_collect_credentials (virt-viewer-auth.c:43)
==25063== by 0x41B391: authenticate_cb (virt-viewer-session-ovirt.c:430)
==25063== by 0x3458C05E8F: ffi_call_unix64 (unix64.S:75)
==25063== 32 (16 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 3,962 of 9,502
==25063== at 0x4A0884D: malloc (vg_replace_malloc.c:263)
==25063== by 0x3DE384D2BE: g_malloc (gmem.c:159)
==25063== by 0x3DE38616B1: g_slice_alloc (gslice.c:1003)
==25063== by 0x3DE38629F2: g_slist_append (gslist.c:222)
==25063== by 0x41483C: virt_viewer_window_init (virt-viewer-window.c:323)
==25063== by 0x3DE402FA05: g_type_create_instance (gtype.c:1892)
==25063== by 0x3DE40147A7: g_object_constructor (gobject.c:1849)
==25063== by 0x3DE4015D70: g_object_newv (gobject.c:1713)
==25063== by 0x3DE401655F: g_object_new_valist (gobject.c:1830)
==25063== by 0x3DE4016893: g_object_new (gobject.c:1545)
==25063== by 0x40DA34: virt_viewer_app_window_new (virt-viewer-app.c:590)
==25063== by 0x40E300: virt_viewer_app_constructor (virt-viewer-app.c:1336)
==30355== 4 bytes in 1 blocks are definitely lost in loss record 53 of 9,267
==30355== at 0x4A0884D: malloc (vg_replace_malloc.c:263)
==30355== by 0x3DE384D2BE: g_malloc (gmem.c:159)
==30355== by 0x3DE3862D0B: g_strdup (gstrfuncs.c:356)
==30355== by 0x3DE40360FC: value_copy_string (gvaluetypes.c:276)
==30355== by 0x3DE40340CA: g_value_transform (gvalue.c:535)
==30355== by 0x3FDAE621DD: gdk_screen_get_setting (gdkevents-x11.c:3022)
==30355== by 0x3FDB3C7415: gtk_settings_get_property (gtksettings.c:1152)
==30355== by 0x3DE4017A74: g_object_get_property (gobject.c:1289)
==30355== by 0x414991: virt_viewer_window_disable_modifiers (virt-viewer-window.c:616)
==30355== by 0x415922: virt_viewer_window_keyboard_grab (virt-viewer-window.c:931)
==30355== by 0x3DE400F942: _g_closure_invoke_va (gclosure.c:840)
==30355== by 0x3DE4027D87: g_signal_emit_valist (gsignal.c:3207)
Fix switch-host migration with Spice.
spice-gtk doesn't like channels staying around when they should be
destroyed/finalized, ie removed from session.
spice-gtk should probably learned to handle better the case of non
cooperating clients, and be able to dissociate a channel from a
session without waiting for it to be disposed, but for now, the
relation is quite tight.
The gtk_widget_get_pointer() API is deprecated in GTK3 since it
is not aware of multiple pointers. Replace its usage in autoDrawer.c
with GdkDeviceManager and friends
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The GtkStyle API has been deprecated in favour of GtkStyleContext.
Update ovBox.c to use the latter if building with GtK3. Also replace
use of the gtk_widget_size_request API with gtk_widget_get_preferred_size.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Some distros (a 4-letters) don't have icotool.
Let's ship the .ico in the tarball.
The build will fail if icoutil is not installed when
building from git or when the .ico is absent. The error
should be explicit.
When disposing of the VirtViewerApp, we free the hash table
containing the windows. This causes each window to be freed,
which in turn causes the visibility callback to be invoked.
This can then get NULL pointers from the self->priv->windows
usage.
Blank out priv->windows before unrefing the hashs and add
a check to ensure priv->windows is non-NULL.
When running virt-viewer with the --reconnect argument, when
the session closes, the VirtViewerWindow instances were being
freed, but not the GtkWindow itself. So the orphaned window
stayed around doing nothing. The GtkBuilder instance was also
leaked.
Fix these two leaks & also add some debugging to help future
troubleshooting
Currently the window titles for remote-view have 'remote-viewer'
appended them. This is based off the argv[0] name. We should be
setting the GLib application name though, so we can get a localized
'Remote Viewer' string in the titlebar
remote-viewer is currently trying to use
SpiceUsbDeviceManager::auto-connect to control whether USB devices
should be automatically connected or not. However, this property
is more or less an internal spice-gtk property which is toggled
by SpiceGtkSession when the SPICE widget gets/loses focus.
SpiceGtkSession has an "auto-usbredir" property which can be used
by applications to enable/disable automatic usb redirection through
SPICE. Since this property is helpfully bound to
VirtViewerSession::auto-usbredir, use this when the controller
is told to enable/disable USB redirection.
Without this change, automatic USB redirection will always get reenabled
as soon as there's a focus change since SpiceGtkSession::auto-usbredir
defaults to be enabled in spice-gtk.
Builds are failing with an obscure error message
make[3]: Entering directory `/var/lib/builder/source-root/virt-viewer/build/icons'
GEN virt-viewer.ico
/bin/sh: -c: command not found
make[3]: *** [virt-viewer.ico] Error 127
This is because configure.ac does not enforce that icotool
is present on Win32.
* configure.ac: Mandate windres & icotool on Win32
When clicking the close button on a virt-viewer window with
a VNC session open, while the VNC session terminates, the
window does not go away.
The problem is that the virt_viewer_session_vnc_disconnected
method never gets invoked. The close button triggers a call
to virt_viewer_session_clear_displays which unrefs the
VirtViewerDisplayVnc instance. This in turn triggers a call
to gtk_container_destroy, which destroys all widgets it
contains, ie the VncDisplay * object.
With the VncDisplay object in its dispose phase, no signals
will ever be emitted, thus the 'vnc-disconnected' signal
never gets seen.
The design issue is that VirtViewerDisplayVnc is assuming
it owns the VncDisplay, whereas in fact the real owner is
the VirtViewerSessionVnc object.
The solution is to introduce a new virt_viewer_display_close
method which can be used to de-parent the widget before
VirtViewerDisplay is unref'd.
The VirtViewerSessionVnc object also needs to hold a full ref
on the VncDisplay object, not merely a floating reference
* virt-viewer-display-spice.c, virt-viewer-display.c,
virt-viewer-display.h: Add virt_viewer_display_close
* virt-viewer-display-vnc.c: Deparent VNC widget in
virt_viewer_display_close impl
* virt-viewer-session-vnc.c: Improve logging
* virt-viewer-session.c: Call virt_viewer_display_close
before unrefing display
* virt-viewer-window.c: Improve logging
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This has 2 advantages, and I can't figure any drawback:
- it fixes the issue of mnemonic hints being draw when pressing Alt
key (character underlined), even when they were disabled.
- it simplifies the code :)
This makefile is just fantastic, it forces you into good practices,
support various build targets (my windows builddir ignore the right
files etc..)
The more I use it, the more I like it.
The current code will attempt to dereference args if
--spice-controller, even if args is NULL.
Let's not accept any extra argument/uri on the command line if using
the controller. Beside, the conditionnal block looks better outside of
the if condition.
Lower warning message to debug level. There are various racy ways it
ends up calling show_display although the display is not yet
ready. This is not such a big problem, although it would be nice to
handle this case better
The current code only inform of focus state when the listener is ready.
spice-gtk controller code lacks signal when a client connects, but a
client will set the title when connected and send a notify signal.
Use this event to notify of application focus state.
Do not disconnect session when switching host (non-seamless migration
method).
Also, handle a bit better main channel events and do not disconnect on
unknown events, however raise unhandled event message to warning
level.
- auto-conf is an optionnal argument to --fullscreen:
it will set the guest display configuration to match the client
display configuration, by sending the client monitors size and
position to capable guests.
The current code notifies the controller when the remote-viewer
application starts, but not when the client is connected. We should do
the later instead
We require libvirt >= 0.9.7 to get virDomainOpenGraphics
We require spice-gtk >= 0.11 to get the fix for dealing with
authentication over an SSH tunnel
We requires spice-protocol >= 0.10.1 to get a constant
required by USB redirection
When running ./autogen.sh on a pristine git checkout, I got:
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
You should add the contents of '/usr/share/aclocal/intltool.m4' to 'aclocal.m4'.
Trying to resize not visible windows leads to the following being printed
to the console:
Gdk-CRITICAL **: IA__gdk_window_get_origin: assertion `GDK_IS_WINDOW (window)'
This gets triggered by the gdk_screen_get_monitor_geometry() call in
virt_viewer_window_resize()
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Note this button only gets shown on USB redir capable virtual machines.
Changes in v2:
-Use gtk_widget_set_visible for simpler code
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When quiting from the fullscreen menu call virt_viewer_app_quit instead of
gtk_main_quit so that the session gets properly disconnected before quiting.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Even though the previous patches in this series ensure that the session
gets properly finalized, we still need to wait for the disconnect signal,
as spice-glib uses co-routines which need some time to cleanly close the
connection / session.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Before this patch session-spice would emit the disconnected signal as soon
as the main channel is closed, but other channels may still be open at
that time and raising the disconnected signal usally leads to the app class
calling gtk_main_quit, at which point the other channels never get properly
finalized (as there co-routines still hold a reference to them).
This is esp. bad for usbredir channels as these re-attach the kernel driver
for redirected devices when finalized. So exiting without properly finalizing
them leads to the formerly redirected devices not being usuable until the
driver is manually reloaded or the device is unplugged and re-plugged
(the kernel does not automatically re-bind kernel drivers when userspace
closes a usbfs node).
This patch fixes this by delaying the emitting of the disconnect signal
until the last channel has been destroyed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
With this patch combined with the previous patches in this series, the
VirtViewerSession (finally) gets properly finalized on exit.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Before this patch there was a cyclic reference between VirtViewerSesion and
VirtViewerDisplay, since all VirtViewerDisplays are created / destroyed by
VirtViewerSession it is safe to assume that lifetime of VirtViewerSession >=
VirtViewerDisplay, so VirtViewerDisplay can take a borrowed reference
breaking the circle, and allowing proper cleanup on exit.
Note that there is no g_object_unref removed from virt-viewer-display, this
because there is no finalize / dispose and before this patch
VirtViewerDisplay never unref-ed the reference it hold to the session.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Before this patch there was a cyclic reference between VirtViewerApp and
VirtViewerWindow, since all VirtViewerWindows are created / destroyed by
VirtViewerApp it is safe to assume that lifetime of VirtViewerApp >=
VirtViewerWindow, so VirtViewerWindow can take a borrowed reference
breaking the circle, and allowing proper cleanup on exit.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This means that:
1) There is no need to explictly set its title separately
2) It is unref-ed when we do g_hash_table_unref(priv->windows), so it
should not be unref-ed separately otherwise it is unref-ed twice!
Notice that 2 was never a problem because of circular references
between VirtViewerApp and VirtViewerWindow, but once the follow
up patch to this one breaks the circle 2 becomes an issue.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
These changes match the changes already made to the spice-gtk
usb device selection widget to match the spacing advised by the Gnome HIG.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The empty string has a magic meaning for gettext, it's used to
store a translation header with all kind of information about the
po file. This is not something we want to use as a window title, so
change to _("") to "" when we want an empty string.
When doing unref() on a channel, channel-destroy signal may be emitted
during object dispose time, and it will attempt to unref() the channel
again likely leading to a crash.
It may be that spice-gtk should have a different/simpler object
life-cycle model, but it's also a good assumption to not take strong
references on the channels, but just keep a weak reference as the
session is really the channel life-cycle manager.
https://bugzilla.redhat.com/show_bug.cgi?id=797082
The use of a libtool convenience library causes some platforms to
loose the ability to use the GNU_RELRO security feature in the
resulting binary. Refactor the makefile to simply compile the
common files twice, once for virt-viewer & once for remote-viewer
If no @listen parameter is given, we must not hardcode 'localhost'
since we can't assume we are running on the same host. Instead use
the hostname from the connection URI
If auto-resize is enabled, the guest desktop size will be resized to
match current window*zoom size.
This can be a problem if the user explicitely set the desktop size to
a different resolution and want to keep it. Disabling auto-resize
sounds like a simple way to allow that.
The SpiceDisplay doesn't receive the full allocation, because
VirtViewerDisplay maintains current aspect ratio. However, the guest
display can be resize up to its container size.
This fixes going full-screen and not getting native resolution for
instance.
The standard SPICE widget guest resize implementation does not
take into account the zoom level settings in virt-viewer, because
it has no knowledge of this functionality. The guest resize can,
however, be done by calling spice_main_set_display() directly.
This allows virt-viewer to resize the guest taking into account
zoom levels.
ie, if virt-viewer is run with --zoom 50 and the window
is resized to 400x300, then the guest agent should
be told to set its resolution to 800x600
The SpiceDisplay widget has built-in support for resizing the
guest desktop, but this does not know that virt-viewer has a
zoom level setting. This makes the virt-viewer zoom completely
inoperable. Revert use of the 'resize-guest' property.
Override the grab_focus() method in the display class. Since both VNC
and Spice displays are the direct child, let's just grab the child.
It can be that this behaviour need to be overriden if Spice or VNC
display become more complex (using sub-childs or different objects)
Add a new flag --attach, which instructs virt-viewer to attach
to the target display using virDomainOpenGraphics, instead of
initiating a VNC/SPICE connection directly.
Using intltool macro only causes build issues on exotic platforms,
such as MinGW.
As long as this bug isn't fixed, we should use AM_GLIB_GNU_GETTEXT
https://bugs.launchpad.net/intltool/+bug/398571
NB this partially reverts
3473c4bb49adc0caca58dc1a8b6ce81c6870558a
The difference is the ordering of the rules. With AM_GLIB_GNU_GETTEXT
appearing after IT_PROG_INTLTOOL, the --disable-nls arg to configure
is broken. Thus AM_GLIB_GNU_GETTEXT is called first in this change.
The GLIB2 check previously removed was misleading because it in
fact checked for gmodule-export-2.0 which is needed to export
the signal handlers. Revert the previous commit, but rename the
var to GMODULE2 to make it clearer
When waiting for a VM to appear or start, set the initial window
title to the command line arg. When the VM actually appears then
update it to the real VM name
When the guest XML contains a wildcard address like 0.0.0.0 or ::,
we can't directly use connect() on it. Instead we have to use the
hostname/IP from the libvirt URI.
Ensure that all windows get a default zoom level of 100. Propagate
the primary window's zoom level to all secondary windows when
initially creating them
If 'ff' callbacks are invoked directly from the remove
callback they will likely deadlock in libvirt. They must
be invoked from a clean stack, so switch to using a
glib idle callback.
That allow positionning windows in multi-head.
Also, get rid of window_state_cb, since it's impossible to
properly catch the event to do the right thing, ie move to a different
screen before go full-screen, or disallow it in case nb physical
monitors < nb virtual monitors.
d="M 7.5809024,4.5706221 L 41.169097,4.5706221 C 42.080439,4.5706221 42.793244,5.1541039 42.835849,5.9722091 L 44.167893,31.550323 C 44.226102,32.668058 43.266837,33.570628 42.147588,33.570628 L 6.6024120,33.570628 C 5.4831629,33.570628 4.5238980,32.668058 4.5821068,31.550323 L 5.9141506,5.9722091 C 5.9544343,5.1986745 6.4616533,4.5706221 7.5809024,4.5706221 z "
id="rect2404"
sodipodi:nodetypes="cssssssss" />
<path
sodipodi:nodetypes="ccccc"
id="path2377"
d="M 8.9105350,7.1808270 L 7.6683398,29.226144 L 39.318729,29.226144 L 37.983712,7.2742560 L 8.9105350,7.1808270 z "
d="M 7.4145985,5.5813396 L 41.260101,5.5435383 C 41.543798,5.5432214 41.819403,5.7807881 41.842206,6.1960820 L 43.204098,30.999330 C 43.262137,32.056361 42.664349,32.785201 41.605727,32.785201 L 7.0817583,32.785201 C 6.0231355,32.785201 5.4887439,32.056410 5.5458869,30.999330 L 6.8699773,6.5051630 C 6.9086732,5.7893326 7.0363626,5.5817620 7.4145985,5.5813396 z "
d="M 9.2115360,7.6213630 L 8.4090070,25.491693 C 19.453645,23.091063 23.830470,14.999494 37.563039,12.344943 L 37.401567,7.6874270 L 9.2115360,7.6213630 z "
d="M 22.500000,30.192666 L 22.781716,30.192666 C 22.865481,30.192667 22.929701,30.211330 22.974376,30.248656 C 23.019345,30.285690 23.041829,30.338594 23.041830,30.407370 C 23.041829,30.476440 23.019345,30.529638 22.974376,30.566965 C 22.929701,30.603998 22.865481,30.622515 22.781716,30.622515 L 22.669735,30.622515 L 22.669735,30.850885 L 22.500000,30.850885 L 22.500000,30.192666 M 22.669735,30.315669 L 22.669735,30.499512 L 22.763640,30.499512 C 22.796558,30.499512 22.821982,30.491576 22.839911,30.475705 C 22.857839,30.459540 22.866804,30.436762 22.866804,30.407370 C 22.866804,30.377979 22.857839,30.355348 22.839911,30.339476 C 22.821982,30.323605 22.796558,30.315669 22.763640,30.315669 L 22.669735,30.315669 M 23.461979,30.303765 C 23.410250,30.303766 23.370131,30.322870 23.341621,30.361078 C 23.313112,30.399288 23.298857,30.453074 23.298857,30.522437 C 23.298857,30.591507 23.313112,30.645146 23.341621,30.683355 C 23.370131,30.721564 23.410250,30.740668 23.461979,30.740668 C 23.514001,30.740668 23.554267,30.721564 23.582778,30.683355 C 23.611287,30.645146 23.625541,30.591507 23.625542,30.522437 C 23.625541,30.453074 23.611287,30.399288 23.582778,30.361078 C 23.554267,30.322870 23.514001,30.303766 23.461979,30.303765 M 23.461979,30.180762 C 23.567787,30.180763 23.650671,30.211036 23.710630,30.271582 C 23.770588,30.332128 23.800567,30.415747 23.800568,30.522437 C 23.800567,30.628834 23.770588,30.712305 23.710630,30.772851 C 23.650671,30.833398 23.567787,30.863671 23.461979,30.863671 C 23.356464,30.863671 23.273580,30.833398 23.213328,30.772851 C 23.153370,30.712305 23.123391,30.628834 23.123391,30.522437 C 23.123391,30.415747 23.153370,30.332128 23.213328,30.271582 C 23.273580,30.211036 23.356464,30.180763 23.461979,30.180762 M 23.928420,30.192666 L 24.117994,30.192666 L 24.357387,30.644117 L 24.357387,30.192666 L 24.518305,30.192666 L 24.518305,30.850885 L 24.328730,30.850885 L 24.089338,30.399434 L 24.089338,30.850885 L 23.928420,30.850885 L 23.928420,30.192666 M 24.591489,30.192666 L 24.777095,30.192666 L 24.926991,30.427209 L 25.076887,30.192666 L 25.262935,30.192666 L 25.012079,30.573578 L 25.012079,30.850885 L 24.842344,30.850885 L 24.842344,30.573578 L 24.591489,30.192666"
style="font-size:0.90290260;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;writing-mode:lr-tb;text-anchor:start;fill:#4a4a4a;fill-opacity:1.0000000;stroke:none;stroke-width:1.0000000pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000;font-family:Bitstream Vera Sans" />
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.