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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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()
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>
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>
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>
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>
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>
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>
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>
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.
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
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.
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 '-'.
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).
