summaryrefslogtreecommitdiffstats
path: root/src/virt-viewer-app.c
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Ensure all windows obey initial --zoom settingJonathon Jongsma2013-11-211-6/+4
| | | | | | | | | | | | | | There are cases where multiple VirtViewerWindow objects are created before the VirtViewerApp constructor has a chance to run. Since the constructor has not yet run, priv->main_window will still be NULL, the test in virt_viewer_app_window_new() will fail, and they will not get their initial zoom level set. When the constructor finally runs, it set the zoom level of the main window to the value set on the command line, but all other windows that had already been created retained the default 100% zoom level. By creating the main_window in the instance init function, we ensure that the main window is created before we get any 'session-display-added' signals and all displays will start out with consistent zoom levels.
* Remove non-functional VIRT_VIEWER_HIDE env behaviorJonathon Jongsma2013-11-211-3/+0
| | | | | | | VIRT_VIEWER_HIDE could be set as an environment variable to (theoretically) hide displays whenever they were not ready. Unfortunately, this bit of functionality appears bitrotten and doesn't work anymore (it prevents windows from opening when you click 'view > displays > display 2', for instance).
* Add ability to define custom display->monitor mapping per vmJonathon Jongsma2013-11-201-16/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fullscreen mode generally just assigns display 1 to monitor 1, display 2 to monitor 2, etc. For custom setups, you can define a monitor mapping in the settings keyfile per-vm. This requires a vm uuid (so only works in virt-viewer or on versions of spice-server that send the uuid over the wire). The format is pretty basic: [6485b20f-e9da-614c-72b0-60a7857e7886] monitor-mapping=2;3 The group name ("6485b20f-e9da-614c-72b0-60a7857e7886") is the uuid id of the vm. This group has a single key: monitor-mapping. This key is an array of integers describing the order in which to assign the monitors to a guest display. Any monitors that are not listed in this array will not be configured at startup. For instance: monitor-mapping=2;1 will attempt to configure 2 displays on the guest and assign the first display to monitor 2 and the second display to monitor 1. monitor-mapping=2 will only configure a single display on the guest and place it on the second monitor. Any monitor numbers listed in the keyfile are greater than the number of monitors that are physically present, they will be ignored.
* Fix leak of VirtViewerApp::windows hash table keyChristophe Fergeau2013-11-201-1/+2
| | | | | | | | | | | | | The VirtViewerApp::windows hash table owns the memory for both the keys and values it stores. virt_viewer_app_remove_nth_window() uses g_hash_table_steal() which does not call the 'free' function neither for the key nor for the value. This method takes care of releasing the reference for the value it extracted from the hash table, but not for the key. This commit fixes by explicitly taking a reference on the value rather than stealing the one held by the hash table. We can then replace the use of g_hash_table_steal() with g_hash_table_remove() which will take care of freeing the removed key.
* Hide all windows on disconnectionChristophe Fergeau2013-11-131-0/+14
| | | | | | | | | | | | | | | When starting remote-viewer without argument, we are showing a window where the user can enter connection details. We then go on to try and connect to the URI the user specified, and if the connection fails, we disconnect from the remote server, and then we show again the connection window so that the user can correct the URI if he entered it wrong. However, when this happens, the window for the previous connection will still be visible even if connection failed. To avoid this, this commit makes sure we hide all windows when we get a disconnection event. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1024309
* Drop basic fullscreen modeJonathon Jongsma2013-11-131-53/+3
| | | | | | 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.
* Unify configured hotkey behaviourMarc-André Lureau2013-11-071-7/+13
| | | | | | | | | | | Whether the hotkeys are set through command line, controller or file, we should get the same keybinding result (clear unspecified, and enable global bindings) However, when started from command line arguments, without --hotkey argument, it will have basic non-global default bindings. https://bugzilla.redhat.com/show_bug.cgi?id=1023447
* Rename internal toggle-fullscreen menu accel nameMarc-André Lureau2013-11-071-3/+3
| | | | This avoid confusion with other fullscreen state property
generated by cgit (git 2.34.1) at 2025-10-01 09:22:05 +0000