summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Drop support to gtk2wip/gapplicationFabiano Fidêncio2015-10-145-173/+0
| | | | | | 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.
* Use the display ID to configure fullscreen monitorsJonathon Jongsma2015-10-095-62/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | When starting virt-viewer in fullscreen mode, we generally try to arrange guest displays exactly the same as client monitors. So if a client machine has two monitors, we'll try to enable display 0 and 1 on the guest (in that order). However, when using the configuration file to map fullscreen displays to different monitors, the guest displays may not be sequential, or there may be displays missing. For example, consider the following configuration: monitor-mapping=1:2;2:1 In virt_viewer_session_spice_fullscreen_auto_conf(), we were building an array of GdkRectangles for the initial monitors that we want to enable on the guest. We then configured the guest displays using the index of the array for the as the id of the guest display. But when displays are sparse or are out-of-sequence, the array index will not match the >ntended display ID. This created problems where displays were arranged incorrectly. By changing the simple array into a GHashTable, we can keep the display ID together with the GdkRectangle until we need to use it, and things will be configured correctly. This regression was introduced by c586dc8c. Fixes: rhbz#1267184
* SessionSpice: make main-window a propertyJonathon Jongsma2015-10-091-45/+77
| | | | | | | Make "main-window" a construct-only property of VirtViewerSessionSpice. This allows us to set it in the constructor and encapsulate all of the setup within the gobject constructor rather than doing extra work in the _new() function.
* Add new functions to enable/disable a displayJonathon Jongsma2015-09-104-7/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Set enabled status of all displays when we get a monitor updateJonathon Jongsma2015-09-081-2/+4
| | | | | | | | | | Previously, when we received a new monitors update from the server, we only called virt_viewer_display_set_enabled() for the displays that were enabled. We simply assumed that those that were not enabled were already set to disabled. This assumption is currently valid, but I have some changes in the pipeline where this is not true. This change ensures that we update the enabled state of all monitors when we get an updated monitors conifguration.
* Don't emit 'monitor-geometry-changed' for disabled displaysJonathon Jongsma2015-09-081-20/+19
| | | | | | | | | When a display widget receives a new size allocation, we generally emit a monitor-geometry-changed signal so that we can reconfigure the displays. But if the widget for a *disabled* display is allocated, there's no reason to send down a new configuration. We don't need to emit this signal. This doesn't currently cause any problems, but I ran into issues while testing some other uncommitted changes.
* coverity: result is not floating-pointFabiano Fidêncio2015-08-171-2/+2
| | | | | | | | Coverity says: Result is not floating-point (UNINTENDED_INTEGER_DIVISION) interger_division: Dividing integer expressions "preferred->width * 100" and "zoom", and then converting the integer quotient to type double. Any remainder, or fractional part of the quotient, is ignored.
* coverity: Copy into fixed sized bufferFabiano Fidêncio2015-08-131-0/+5
| | | | | | | | Coverity says: You might overrun the 108 byte fixed-size string "addr.sun_path" by copying "unixsock" without checking the lenght. Note: This detect has an elevated risk because the source argument is a paramenter of the current function.
* session-spice: Use display id instead of monitor id in debug logPavel Grunt2015-07-291-1/+2
| | | | | Windows guests have monitor id = 0, so the debug log is always the same: "creating spice display (#:0)" for all the displays.
* virt-viewer-window: Change zoom with respect to real zoomPavel Grunt2015-07-291-3/+17
| | | | | | | | | The zoom can be changed by resizing the window (VNC / Spice without the agent). It is necessary to recalculate the zoom level before changing it, otherwise zoom operations will not work correctly. Resolves: https://bugs.freedesktop.org/show_bug.cgi?id=90582
* Show window after its default and preferred sizes are setPavel Grunt2015-07-291-2/+2
| | | | | | | | | | | | | Under some circumstances (Xfce desktop environment, gtk3 client, RHEL6 guest having two monitors running locally) it is possible to create a loop of resizing windows. It is caused by size request like 1x1 sent to the guest. These request are created because _window_queue_resize() is called when the window is being shown. To avoid the problem, call gtk_widget_show() after its preferred and default sizes are set. Resolves: https://bugs.freedesktop.org/show_bug.cgi?id=91405
* events: don't leak GIOChannel when destroying IO handleFabiano Fidêncio2015-07-221-0/+4
| | | | | | | | | | | | | | virt_viewer_events_add_handle() creates a GIOChannel in order to watch the fd it was given for changes. virt_viewer_events_remove_handle() is freeing all the resources allocated by virt_viewer_events_add_handle() except for this GIOChannel. This commit adds the needed g_io_channel_unref() call to virt_viewer_events_remove_handle() Based on commit 8e95b8d25a3eee6316aff2f83b0c449aaf10984a from libvirt-glib. Original author: Christophe Fergeau <cfergeau@redhat.com> Related to: rhbz#1243228
* events: allow to remove disabled timers and handlesFabiano Fidêncio2015-07-221-11/+9
| | | | | | | | | | | | Trying to remove a disabled timer or handle will cause virt_viewer_events_remove_{handle,timeout}() to return an error rather than removing it. Based on commit 79699d73e6e1b7218e3bd8349d176752f86128b9 from libvirt-glib. Original author: Christophe Fergeau <cfergeau@redhat.com> Related to: rhbz#1243228
* events: don't create glib IO watch for disabled handlesFabiano Fidêncio2015-07-221-4/+6
| | | | | | | | | | | | | | | | | | | | | | It's possible to create a handle to watch for file events which do not watch for any file event. Such a handle can be enabled later with virt_viewer_events_update_handle() by setting some conditions to watch for. When a handle is disabled after it has been created, virt_viewer_events_update_handle() makes sure it removes the corresponding virt_viewer_events_handle::source IO watch if any was set. virt_viewer_events_add_handle() will always create a virt_viewer_events_handle::source IO watch even if the handle is not watching for any events. This commit makes consistent by only creating a watch with g_io_add_watch() when the caller asked to watch for some events. Based on commit d71c143936a35cd6c3f23ae0cbf7f3215d944051 from libvirt-glib. Original author: Christophe Fergeau <cfergeau@redhat.com> Related to: rhbz#1243228
* events: don't hold events lock when dispatching free callbacksFabiano Fidêncio2015-07-221-6/+2
| | | | | | | | | | | | | | The _event_timeout_remove and _event_handle_remove methods were holding onto the global lock when invoking the free callback. This is a violation of the libvirt events API contract which requires free callbacks to be invoked in a re-entrant safe context. Based on commit dd17c3cc587c73a8c915238f9d9a3e200e89c93f from libvirt-glib. Original author: Daniel P. Berrange <berrange@redhat.com> Related to: rhbz#1243228
* events: don't reschedule deleted timeouts/watchesFabiano Fidêncio2015-07-221-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The deletion of libvirt timeouts/watches is done in 2 steps: - the first step is synchronous and unregisters the timeout/watch from glib mainloop - the second step is asynchronous and triggered from the first step. It releases the memory used for bookkeeping for the timeout/watch being deleted This is done this way to avoid some possible deadlocks when reentering the sync callback while freeing the memory associated with the timeout/watch. However, it's possible to call gvir_event_update_handle after gvir_event_remove_handle but before _event_handle_remove does the final cleanup. When this happen, _update_handle will reregister the handle with glib mainloop, and bad things will happen when a glib callback is triggered for this event after _event_handle_remove has freed the memory associated with this handle watch. This commit marks the timeouts and watches as removed in the synchronous _remove callback and makes sure removed timeouts/watches are ignored in _update callbacks. Based on commit 3e73e0cee977fb20dd29db3ccfe85b00cc386c43 from libvirt-glib. Original author: Christophe Fergeau <cfergeau@redhat.com> Related to: rhbz#1243228
* events: protect 'handles' and 'timeouts' against concurrent accessesFabiano Fidêncio2015-07-221-0/+10
| | | | | | | | | | | | | | | | | Timeout and watch deletion is done from an idle callback. However, we cannot assume that all libvirt event calls (the callbacks passed to virEventRegisterImpl) will be done from the mainloop thread. It's thus possible that a libvirt event call will run a thread while one of the idle deletion callbacks runs. Given that the 'handles' and 'timeouts' arrays are shared among all threads, we need to make sure we hold the 'eventlock' mutex before modifying them. Based on commit 924178f6b35735458b37d30303fe7bc753dde0b1 from libvirt-glib. Original author: Christophe Fergeau <cfergeau@redhat.com> Related to: rhbz#1243228
* events: remove unused virt_viewer_events_find_{handle,timeout} argFabiano Fidêncio2015-07-221-12/+6
| | | | | | | | Based on commit 1fb34633ef3b318ea678b775d5e47debc98d2184 from libvirt-glib. Original author: Christophe Fergeau <cfergeau@redhat.com> Related to: rhbz#1243228
* events: allow zero timeouts for timerFabiano Fidêncio2015-07-221-1/+1
| | | | | | | | | | | | | In libvirt, it's perfectly possible and widely used to have disabled timers (timeout=-1) and fire them up 'randomly' with timeout=0. However, with current mapping into glib mainloop it's not possible and causing troubles. Based on commit a40a1732e0d53fcc44b8d348cec97152dafd2b88 from libvirt-glib. Original author: Michal Privoznik <mprivozn@redhat.com> Related to: rhbz#1243228
* glib-compat: Use g_new0(GMutex, 1) if GLib >= 2.31Fabiano Fidêncio2015-07-222-0/+5
| | | | | | | | | | Since 2.31, g_mutex_new() is deprecated. Based on commit 2dc7476d32a9e158e688486e8f184c719c53bb4c from libvirt-glib. Original author: Daniel P. Berrange <berrange@redhat.com> Related to: rhbz#1243228
* glib-compat: group definitions and functionsFabiano Fidêncio2015-07-221-2/+0
| | | | | There is no need to have more than one glib version checking for the same version, in the same file. Let's just group them all.
* events: remove timeout and handle from arraysFabiano Fidêncio2015-07-221-28/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise, it will crash next time it goes find() Backtrace: (gdb) where #0 0x00007efcae715095 in g_io_create_watch () from /lib64/libglib-2.0.so.0 #1 0x00007efcae7150ef in g_io_add_watch_full () from /lib64/libglib-2.0.so.0 #2 0x00000000004275ba in virt_viewer_events_update_handle (watch=<optimized out>, events=1) at virt-viewer-events.c:158 #3 0x00007efcb1a62dce in virNetSocketUpdateIOCallback (sock=0x1e75c00, events=1) at rpc/virnetsocket.c:1981 #4 0x00007efcb1a50113 in virNetClientIOUpdateCallback (client=<optimized out>, enableCallback=<optimized out>) at rpc/virnetclient.c:1639 #5 0x00007efcb1a50f82 in virNetClientIO (thiscall=0x20e0170, client=0x1f2e060) at rpc/virnetclient.c:1793 #6 virNetClientSendInternal (client=client@entry=0x1f2e060, msg=msg@entry=0x20e0100, expectReply=expectReply@entry=false, nonBlock=nonBlock@entry=true) at rpc/virnetclient.c:1962 #7 0x00007efcb1a52413 in virNetClientSendNonBlock (client=0x1f2e060, msg=msg@entry=0x20e0100) at rpc/virnetclient.c:2036 #8 0x00007efcb1a5243d in virNetClientKeepAliveSendCB (opaque=<optimized out>, msg=0x20e0100) at rpc/virnetclient.c:293 #9 0x00007efcb1a5ba02 in virKeepAliveTimer (timer=<optimized out>, opaque=0x20d3d00) at rpc/virkeepalive.c:176 #10 0x00000000004272e9 in virt_viewer_events_dispatch_timeout (opaque=0x1e6cd30) at virt-viewer-events.c:233 #11 0x00007efcae7231b3 in g_timeout_dispatch () from /lib64/libglib-2.0.so.0 #12 0x00007efcae72279a in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #13 0x00007efcae722ae8 in g_main_context_iterate.isra.24 () from /lib64/libglib-2.0.so.0 #14 0x00007efcae722dba in g_main_loop_run () from /lib64/libglib-2.0.so.0 #15 0x00007efcb054a045 in gtk_main () from /lib64/libgtk-3.so.0 #16 0x0000000000410a9c in main (argc=1, argv=0x7ffde58a7978) at virt-viewer-main.c:124 Based on commit cff5f1c46f4b9661e112b85159fb58ae473a9a89 from libvirt-glib. Original author: Marc-André Lureau <marcandre.lureau@redhat.com> Related to: rhbz#1243228
* events: register event using GOnce to avoid multiple initializationsFabiano Fidêncio2015-07-221-2/+10
| | | | | | | | Based on commit 8f8d9ce5238dbcbce40aa04ba55b8c55f97c79c0 from libvirt-glib. Original author: Marc-André Lureau <marcandre.lureau@redhat.com> Related to: rhbz#1243228
* events: ensure event callbacks are threadsafeFabiano Fidêncio2015-07-221-18/+65
| | | | | | | | | | | Take a global lock whenever changing any event callbacks to ensure thread safety. Based on commit f1fe67da2dac6a249f796535b8dbd155d5741ad7 from libvirt-glib. Original author: Daniel P. Berrange <berrange@redhat.com> Related to: rhbz#1243228
* virt-viewer-window: Allow to resize window to any sizePavel Grunt2015-07-221-76/+3
| | | | | | | | | | | | | | | The function virt_viewer_window_resize restricts window to be bigger than a client's screen. It avoids extending the window to more client's screens, it causes changes of the zoom level if the guest does not fit into a screen. Lets remove virt_viewer_window_resize (its behaviour was introduced by the commit 6acb3856b6d8007752388f22f97aa8aaffdb7a5e). It will let the window managers to handle resizing of the window. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1221501 https://bugzilla.redhat.com/show_bug.cgi?id=1205804
* Remove unnecessary parameter from virt_viewer_window_resize()Pavel Grunt2015-07-221-6/+5
| | | | | Since c3cbdef888cc823e92140027d38378f40ccd4174 virt_viewer_window_resize is always called with keep_win_size = FALSE.
* virt-viewer: set keepAlive on libvirt connectionPavel Hrdina2015-07-091-0/+4
| | | | | | | Setting the keepAlive on libvirt connection is needed in order to receive the CloseCallback event. Resolves: rhbz#1164052
* Build an intermediate convenience libraryJonathon Jongsma2015-06-301-38/+47
| | | | | | | | | | Instead of building every single source file twice (once for virt-viewer, and once for remote-viewer), just build them into a temporary library and link the final executables against that. The one possible drawback to this approach is that we now use the same log domain for both executables: 'virt-viewer'. Previously, the remote-viewer executable used 'remote-viewer' for its log domain.
* Build: put one file on a lineJonathon Jongsma2015-06-301-17/+35
| | | | | For easier maintenance, put a single source file per-line in the makefile
* Remove spice-controller flags from virt-viewer buildJonathon Jongsma2015-06-301-1/+0
| | | | | Virt-viewer does not use spice-controller, only remote-viewer does. So there's no need to ad SPICE_CONTROLLER_CFLAGS to the virt-viewer build.
* Don't wait for reconnect when user cancels authJonathon Jongsma2015-06-193-1/+7
| | | | | | | | | | | When starting virt-viewer with the --reconnect switch to a guest that has a password, if the user cancels the authentication dialog (e.g. pressing 'Esc'), the window will display "Waiting for guest domain to restart". Obviously, the domain will never restart because it's already running. After this fix, the application will simply exit when the user cancels authentication, even if the --reconnect switch is used.
* Automatically retry auth failures for VNCJonathon Jongsma2015-06-191-25/+4
| | | | | | | There's no reason that we need to ask if the user wants to retry auth failures for VNC sessions but not ask for spice sessions. If the user doesn't want to retry, she can simply click 'cancel' when the auth dialog pops up, just as they do with spice.
* VNC session: emit session-cancelled signalJonathon Jongsma2015-06-191-0/+1
| | | | | | When the user cancells an authentication dialog (e.g. by pressing 'Esc', emit the session-cancelled signal to be consistent with the spice session implementation.
* Rename session-auth-failed to session-auth-unsupportedJonathon Jongsma2015-06-194-9/+9
| | | | | | | | Now that VNC and Spice both return the same signal on normal authentication failures ('session-auth-refused'), the 'session-auth-failed' signal is too confusingly similar. Rename it to -unsupported to make it obvious that it's a different type of (unrecoverable) error.
* Fix inconsistencies in session auth failuresJonathon Jongsma2015-06-192-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | The spice session implementation can retry authentication on its own, whereas the vnc session needs to tear down the session and re-connect in order to retry a failed authentication. This results in the following inconsistent behavior: VNC session: - emits a 'session-auth-failed' signal when the client does not support a particular authentication type (i.e.: a non-recoverable error) Spice session: - emits a 'session-auth-failed' signal when user enters an incorrect password, and immediately retries auth internally VNC session: - emits a 'session-auth-refused' error when user enters an invalid password (i.e.: a recoverable error) Spice Session: - never emits a 'session-auth-refused' signal Because of these differences, the VirtViewerApp code to handle authentication failures is a bit confusing and difficult to maintain. To fix this issue, make both the spice and VNC sessions emit the same signal when similar errors occur. We use the new session API added in the last commit to determine whether the session supports automatic retries so we know how to handle the signal.
* Session: add vfunc to check auth retry capabilityJonathon Jongsma2015-06-193-0/+20
| | | | | | | The spice session implementation can retry authentication on its own, whereas the vnc session needs to tear down the session and re-connect in order to retry a failed authentication. Add API to determine this so that we can clean up some code related to authentication failures.
* Move SpiceSession setup to create_spice_session()Jonathon Jongsma2015-06-191-58/+60
| | | | | | | | | | | | | Most of the setup (connecting to signals, etc) for the SpiceSession was done in create_spice_session(), but some was done afterwards in virt_viewer_session_spice_new(). Consolidate all session configuration in one place. In addition to making it easier to maintain, create_spice_session() is also called in virt_viewer_session_spice_close(). which results in a spice session that is configured slightly differently than the first session created in _new(). Consolidating everything in create_spice_session() avoids that inconsistency.
* Add config.h include to remote-viewer-connect.c fileDaniel P. Berrange2015-06-191-0/+2
|
* remote-viewer-connect: Address entry is now requiredLukas Venhoda2015-06-161-6/+21
| | | | | Connect button is now non-sensitive when address entry is empty. Pressing enter will now also NOT connect, when address entry is empty.
* remote-viewer-connect: Fixed reselecting in recent chooserLukas Venhoda2015-06-161-0/+10
| | | | | | | | | | | Recent chooser didn't unselect on loosing focus. Selecting recent connection, then modifying address in entry and doubleclicking on the same recent connection caused remote-viewer to connect to address in the entry, Recent chooser now unselects on loosing focus, forcing to re-select when doubleclicking the recent connection, which will now properly set the address to connect to.
* remote-viewer-connect: Changed hardcoded UI into XMLLukas Venhoda2015-06-163-71/+170
| | | | | Hardcoded UI removed in favor of XML. Added the new XML file for translation.
* remote-viewer-connect: Changed dialog into a windowLukas Venhoda2015-06-163-28/+113
| | | | | | 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: Check if uri is NULLLukas Venhoda2015-06-161-1/+3
| | | | URI should be NULL before passing it to remote_viewer_connect_dialog.
* remote-viewer-connect: Changed response to gbooleanLukas Venhoda2015-06-163-6/+17
| | | | | | 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.
* remote-viewer: Connect dialog moved to its own fileLukas Venhoda2015-06-164-158/+229
| | | | | | | | 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.
* Enable hotkeys after setting them in virt_viewer_app_set_hotkeysChristophe Fergeau2015-06-151-1/+1
| | | | | | | | | | | Enabling hotkeys will trigger a rebuild of the 'send keys' menu containing the new hotkeys. virt_viewer_app_set_hotkeys() was clearing and then enabling the hotkeys before parsing the string containing the new hotkeys. This was causing these hotkeys to be missing from the 'Send keys' menu when they are set through the spice controller because the 'send keys' menu was rebuilt before the new hotkeys are set. Resolves: rhbz#1055600
* Add missing config.h header fileDaniel P. Berrange2015-06-101-0/+2
|
* vv-file: Show 'newer-version-url' when version check failsChristophe Fergeau2015-06-091-5/+17
| | | | | | | We currently display a generic error message when the current binary is older than the minimum version specified in the vv file. The previous commit added a 'newer-version-url' field to these .vv file. This commit adds that URL to the error message if it's set.
* vv-file: Add 'newer-version-url' key to .vv filesChristophe Fergeau2015-06-092-0/+29
| | | | | | If set, this URL will be displayed when one of the version checks ('version' of 'versions' key fail). This URL should contain explanations about how to get an updated remote-viewer version.
* test: Add test case for virt_viewer_compare_buildidChristophe Fergeau2015-06-092-0/+79
|
generated by cgit (git 2.34.1) at 2025-09-29 20:15:23 +0000