| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
We are already using SPICE_CHANNEL_WEBDAV from spice/enums.h
|
|
|
|
|
|
|
|
|
| |
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 '-'.
|
|
|
|
|
| |
Since it defaults to being 0, we'll get a spurious 0 on remote-viewer
--version if we AC_DEFINE/AC_SUBST it when the user did not specify it.
|
|
|
|
| |
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1201604
|
|
|
|
| |
The following patches will only work with spice-gtk >= 0.28.
|
| |
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
This allows 12 bits to form a buildid, ex in RHEVM builds:
--with-buildid=$(release << 4 + zrelease)
https://bugzilla.redhat.com/show_bug.cgi?id=1105650
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We currently duplicate the minimum requirements for the various virt-viewer
dependencies in configure.ac, virt-viewer.spec.in and mingw-virt-viewer.spec.in
This commit uses the versions set in configure.ac in the 2 .spec.in files
so that it's easier to keep them in sync
Before/after diff of the .spec files are:
--- virt-viewer.spec.or 2013-12-18 14:14:14.304285905 +0100
+++ virt-viewer.spec 2013-12-18 14:19:20.217072678 +0100
@@ -47,14 +47,14 @@
BuildRequires: libtool
%endif
-BuildRequires: glib2-devel >= 2.22
+BuildRequires: glib2-devel >= 2.22.0
%if %{with_gtk3}
-BuildRequires: gtk3-devel >= 3.0.0
+BuildRequires: gtk3-devel >= 3.0
%else
-BuildRequires: gtk2-devel >= 2.12.0
+BuildRequires: gtk2-devel >= 2.18.0
%endif
-BuildRequires: libvirt-devel >= 0.9.7
-BuildRequires: libxml2-devel
+BuildRequires: libvirt-devel >= 0.10.0
+BuildRequires: libxml2-devel >= 2.6.0
%if %{with_gtk3}
BuildRequires: gtk-vnc2-devel >= 0.4.0
%else
--- mingw-virt-viewer.spec.or 2013-12-18 14:14:23.656401693 +0100
+++ mingw-virt-viewer.spec 2013-12-18 14:20:57.007270507 +0100
@@ -12,22 +12,22 @@
BuildRequires: mingw32-filesystem >= 23
BuildRequires: mingw64-filesystem >= 23
-BuildRequires: mingw32-glib2 >= 2.22
-BuildRequires: mingw64-glib2 >= 2.22
+BuildRequires: mingw32-glib2 >= 2.22.0
+BuildRequires: mingw64-glib2 >= 2.22.0
BuildRequires: mingw32-gstreamer-plugins-bad-free
BuildRequires: mingw64-gstreamer-plugins-bad-free
BuildRequires: mingw32-gstreamer-plugins-good
BuildRequires: mingw64-gstreamer-plugins-good
-BuildRequires: mingw32-gtk2
-BuildRequires: mingw64-gtk2
+BuildRequires: mingw32-gtk2 >= 2.18.0
+BuildRequires: mingw64-gtk2 >= 2.18.0
BuildRequires: mingw32-libusbx
BuildRequires: mingw64-libusbx
-BuildRequires: mingw32-libvirt >= 0.9.7
-BuildRequires: mingw64-libvirt >= 0.9.7
-BuildRequires: mingw32-libxml2
-BuildRequires: mingw64-libxml2
-BuildRequires: mingw32-gtk-vnc >= 0.4.3
-BuildRequires: mingw64-gtk-vnc >= 0.4.3
+BuildRequires: mingw32-libvirt >= 0.10.0
+BuildRequires: mingw64-libvirt >= 0.10.0
+BuildRequires: mingw32-libxml2 >= 2.6.0
+BuildRequires: mingw64-libxml2 >= 2.6.0
+BuildRequires: mingw32-gtk-vnc >= 0.3.8
+BuildRequires: mingw64-gtk-vnc >= 0.3.8
BuildRequires: mingw32-readline
BuildRequires: mingw64-readline
BuildRequires: mingw32-spice-glib
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Require 0.22 fro spice_uuid_to_string()
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
ovirt_proxy_fetch_vms/ovirt_proxy_lookup_vm have been deprecated
in govirt 0.3.0
|
|
|
|
|
|
|
| |
The spice_smartcard_manager_get_readers method was only added
in spice-gtk 0.20.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
This commit adds support for ovirt:// URIs. It does so by using
libgovirt to get the spice/vnc connection information through
oVirt xmlrpc API.
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Just one thing needs to be changed for virt-viewer to build with
automake 1.13, AM_CONFIG_HEADER is deprecated and should be
AC_CONFIG_HEADERS.
|
|
|
|
|
| |
Trivial change since spice-gtk now has proxy session property and
controller message, just forward it.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Since the viewer makes little sense otherwise.
|
| |
|
| |
|
|
|
|
|
| |
We use API from 2.22, and some from further version. Add
virt-glib-compat.h fallback file for those.
|