| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
| |
remote_viewer_connect_dialog now returns TRUE and FALSE, instead of 0 and -1.
Added a doxygen style comment to document this in code also.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1201604
|
|
|
|
|
|
|
| |
Remove the dialog used to report errors when create_session() fails,
propagating the error is enough and it is already done.
Related: rhbz#1085216
|
|
|
|
|
|
|
| |
By convention functions that take GError parameters should return FALSE
(or NULL) or error.
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
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Silence the Gtk 3.14 message:
"GtkDialog mapped without a transient parent. This is discouraged."
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
The 'free()' function accepts NULL, so you should not
check for NULL before calling it.
|
|
|
|
|
| |
Lets prefill the username entry using the user name of the
current user.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Use a list to store the application's windows. This is another step
towards separating the window from the guest display ID.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Instead of returning 0 for success and -1 for failure, change to a
boolean success value to be more consistent with the rest of the
virt-viewer code.
|
|
|
|
|
| |
When collect_credentials() returns a failure status, 'username' was
potentially leaked.
|
|
|
|
|
|
| |
Minor fixes from patch review
rhbz#1061826
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
After the previous commit which introduced the OvirtForeignMenu
class, we can now make use of it in the remote-viewer UI code.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
The 'app' parameter is used in the function.
|
|
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=1107518
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Based on the new design for the 'connect to server' dialog from Nautilus.
|
|
|
|
|
|
| |
This flag is always set when using the rhevm user portal. Best is
probably to ignore it, now that fullscreen has simplified unique
behaviour.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
We currently reuse the oVirt CA cert for SPICE connection as well,
but it may not be set. When this happens, we don't want to try to use
it.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
ovirt_proxy_fetch_vms/ovirt_proxy_lookup_vm have been deprecated
in govirt 0.3.0
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|