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).
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>
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.
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.
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>
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.
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
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
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".
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.
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.
