summaryrefslogtreecommitdiffstats
path: root/src/virt-viewer-app.c
Commit message (Collapse)AuthorAgeFilesLines
* virt-viewer-app: create_session() should return a booleanFabiano Fidêncio2015-03-271-6/+6
| | | | | | | By convention functions that take GError parameters should return FALSE (or NULL) or error. Related: rhbz#1085216
* virt-viewer-app: Add a GError arg to create_session()Fabiano Fidêncio2015-03-271-1/+5
| | | | | | | | | | | 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
* Exit normally when canceling dialogPavel Grunt2015-03-231-3/+3
| | | | | | | | | 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.
* Monitor config at sometimes leaves additional monitors enabledJonathon Jongsma2015-03-231-10/+16
| | | | | | | | | | | | | | | | | | | | | | | 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
* Use 'constructed' vfunc instead of 'constructor'Jonathon Jongsma2015-03-231-12/+4
| | | | | | 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'.
* VirtViewerApp: create main window after constructorJonathon Jongsma2015-03-231-5/+22
| | | | | | | | | | | | | | | | | 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 geometry when enabling/disabling displaysFabiano Fidêncio2015-03-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | _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
* Deal with NULL gport in virt_viewer_app_set_connect_info()Christophe Fergeau2015-03-131-1/+1
| | | | | | | | 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.
* Enable share folder widgets if supported by sessionMarc-André Lureau2015-03-051-22/+43
|
* Sync preferences widgets with session propertiesMarc-André Lureau2015-03-051-0/+41
|
* Show preferences dialogMarc-André Lureau2015-03-051-1/+27
| | | | Add a menu item Preferences under File and show the preferences dialog
* Report error on attach-only displayMarc-André Lureau2014-11-251-2/+5
| | | | | Provide error details if the display can only be access through libvirt --attach method.
* Move libvirt reconnect polling to VirtViewerMarc-André Lureau2014-11-251-35/+0
| | | | | This is libvirt specific, no need to share it in the VirtViewerApp base class.
* VirtViewerApp: Never remove main windowChristophe Fergeau2014-11-181-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix check of virt_viewer_app_initial_connect return valueChristophe Fergeau2014-11-141-1/+1
| | | | | | | 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.
* Avoid log message warning messages due to incorrect int formatDaniel P. Berrange2014-10-271-1/+3
| | | | | | | 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.
* Fix bug with initial placement of fullscreen windowsJonathon Jongsma2014-10-151-2/+1
| | | | | | | | | 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
* Use socat instead of nc if possibleMarc-André Lureau2014-10-101-9/+23
| | | | | | | | | | | 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
* Initialize fullscreen display map to fallbackJonathon Jongsma2014-09-261-0/+1
| | | | | | | 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.
* Create windows on demand, not at startupJonathon Jongsma2014-09-241-43/+70
| | | | | | | | | | | | | | | 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
* VirtViewerApp: store windows in a listJonathon Jongsma2014-09-241-109/+94
| | | | | Use a list to store the application's windows. This is another step towards separating the window from the guest display ID.
* App: keep hash table of displaysJonathon Jongsma2014-09-241-0/+16
| | | | | This is part of a re-factoring that will de-couple the client window from the remote display id.
* Don't show extra screens in fullscreen modeJonathon Jongsma2014-09-241-2/+5
| | | | | | | | | | | | | | 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
* Move monitor mapping into app_window_try_fullscreen()Jonathon Jongsma2014-09-241-9/+7
| | | | | | | | 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.
* Revert changes related to numpad acceleratorsFabiano Fidêncio2014-09-231-6/+0
| | | | | | | | | | | | | | | | | | | | 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.
* Don't print warning for missing comment in config fileJonathon Jongsma2014-09-051-1/+1
| | | | Change g_warning to g_debug as suggested by Marc-Andre
* Add support to use numpad accelarators for zoom-{in.out,reset}Fabiano Fidêncio2014-08-191-0/+6
| | | | | | | | 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
* Write vm name to config file as commentJonathon Jongsma2014-08-071-0/+14
|
* Change per-guest fullscreen config formatJonathon Jongsma2014-08-071-35/+98
| | | | | | | | | | | 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
* Add a dialog showing details of the current guestJonathon Jongsma2014-08-071-0/+25
| | | | | | 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)
* Always set ask-quit settingMarc-André Lureau2014-07-211-3/+2
| | | | | | Avoid creating empty settings files, always set the ask-quit key. https://bugzilla.redhat.com/show_bug.cgi?id=1006737
* Make ctrl-[+-] zoom in/out in fullscreenMarc-André Lureau2014-07-081-0/+4
| | | | | | | Make ctrl-[+-] zoom in/out in fullscreen with mouse over the control bar. https://bugzilla.redhat.com/show_bug.cgi?id=987549
* app: report disconnection error detailsMarc-André Lureau2014-07-081-2/+4
| | | | | | It may be useful to provide more detailed reason for disconnection. https://bugzilla.redhat.com/show_bug.cgi?id=1115986
* app: add virt_viewer_app_make_dialog()Marc-André Lureau2014-07-081-10/+27
| | | | | Add a function to create an application dialog. In the following commit, we will add more details for connection failures.
* Use GOptionGroup for VirtViewerApp optionsJonathon Jongsma2014-07-021-3/+6
| | | | | | | | 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.
* kiosk: remove invalid unrefMarc-André Lureau2014-06-161-1/+0
| | | | | | 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.
* kiosk: don't attempt to hide windows when disconnectingMarc-André Lureau2014-06-101-1/+3
| | | | | | | Get rid of the following warning: (virt-viewer:7262): virt-viewer-WARNING **: Can't hide windows in kiosk mode https://bugzilla.redhat.com/show_bug.cgi?id=1107518
* Replace DEBUG_LOG with g_debugMarc-André Lureau2014-06-101-11/+11
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1107518
* Remove warning when removing displayMarc-André Lureau2014-06-101-1/+3
| | | | | | | | | | | 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
* Don't connect to localhost when using --directChristophe Fergeau2014-06-101-0/+7
| | | | | | | | | | | | | | | | | | 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
* Don't show 'do you want to quit' dialog in kiosk modeChristophe Fergeau2014-03-141-5/+6
| | | | | | | | 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.
* Don't create new windows at startup when kiosk mode is falseJonathon Jongsma2014-03-131-5/+5
| | | | | | 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.
* Remove special-case for getting window n=0Jonathon Jongsma2014-03-131-13/+9
| | | | | | 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.
* Silence a message about missing configuration fileMarc-André Lureau2014-03-131-2/+5
| | | | | | | Do not print a g_debug() error when the configuration file is missing, unless given the --debug option. https://bugzilla.redhat.com/show_bug.cgi?id=1006737
* rhbz#1007306 - Don't free session if we're re-trying authJonathon Jongsma2014-02-131-2/+3
| | | | | | | 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.
* Don't hide the main window when disconnectingJonathon Jongsma2014-02-131-2/+4
| | | | | | | | | | | | | | | | | | | | | | 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.
* Improve window title when connected to newer spice-serverJonathon Jongsma2014-02-111-22/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Clear global zoom-reset hotkey tooMarc-André Lureau2014-01-071-0/+1
|
* Fix rebuild of accelerators menu when loading from fileMarc-André Lureau2014-01-071-3/+10
| | | | | | | | | 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.
* app: remove useless warningMarc-André Lureau2013-12-111-1/+0
| | | | | | This warning should have been removed with 20eb200c. https://bugzilla.redhat.com/show_bug.cgi?id=1021350
generated by cgit (git 2.34.1) at 2025-09-27 06:45:18 +0000