summaryrefslogtreecommitdiffstats
path: root/src/virt-viewer-app.c
Commit message (Collapse)AuthorAgeFilesLines
* app, cosmetic: remove one unneeded level of identationHEADmasterFabiano Fidêncio2016-03-071-14/+14
| | | | | Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com> Acked-by: Pavel Grunt <pgrunt@redhat.com>
* app: monitor-config - do it all or nothingFabiano Fidêncio2016-03-071-3/+4
| | | | | | | | | | | | | Don't keep trying to use a monitor config when it already failed for one monitor, otherwise virt-viewer can end up in a situation where none of the displays are enabled but the program is still running. So, in case of any failure, let's skip the whole monitor config, forcing virt-viewer to use the "fallback" one instead. Resolves: rhbz#1315206 Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com> Acked-by: Pavel Grunt <pgrunt@redhat.com>
* Use GResource for loading ui filesFabiano Fidêncio2016-03-031-0/+5
| | | | | | | | | | Let's take advantage of GResource for loading ui files in a better and cleaner way than virt_viewer_util_load_ui() was doing. It also brings the benefit, at least for developers, of being able to test ui changes without having to "make install" virt-viewer. Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com> Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
* app: Remove useless libxml includesFabiano Fidêncio2016-03-031-3/+0
| | | | Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
* Don't open the default display while parsing command lineEduardo Lima (Etrunko)2016-02-261-1/+1
| | | | | | | | | Since commit a9ce19f it has not been possible to check app version from a tty without X session running. The issue is that gtk_get_option_group function opens the default display if passed TRUE as argument. Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com> Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
* cleanup: Drop old compatibilty codeFabiano Fidêncio2016-02-241-2/+0
| | | | | | | | A few more pieces of old compatibility code can be dropped, as we already depend on GLib 2.38. Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com> Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
* app: Don't leave a window opened in case of connection errorFabiano Fidêncio2016-02-241-1/+4
| | | | | | | | | | | | | | | | | | | | Since commit ed9b3f3 the main window is not hidden when disconnecting. But it also is not hidden when a connection error occurs, leaving a black display with a not so accurate message to the users in case they try to connect to a non-valid address from the remote-viewer connection window and in this case the main window (display #1) shuldn't be shown. The impetus for this chance is the following: - user runs remote-viewer without any argument - the remote-viewer connection window shows up - user attempts to connect to a non-valid address - a dialog pops up indicating a failure connecting to the graphic server - the main window shows up saying "Connecting to the graphic server" - user clicks 'Ok' - the main window stays there with the same message As a user, I expect the program to not show the main window in connecting failure cases. This patch accomplishes that.
* Port to GtkApplication API'sEduardo Lima (Etrunko)2016-02-181-56/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Drop support to gtk2Fabiano Fidêncio2016-02-151-9/+8
| | | | | | | | 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. Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
* app: Compute monitor mapping only in fullscreenPavel Grunt2016-02-151-6/+20
|
* app: Do not show usbredir button without sessionPavel Grunt2016-02-151-4/+8
| | | | | | The button is visible in the fullscreen toolbar when waiting for a guest. Clicking on it causes the runtime warning: virt-viewer-CRITICAL **: virt_viewer_session_usb_device_selection: assertion 'VIRT_VIEWER_IS_SESSION(self)' failed
* app: Add comment only when config file has VM groupPavel Grunt2016-02-151-1/+1
| | | | | Avoid the debug message on close: virt-viewer-DEBUG: Unable to get comment from key file: Key file does not have group '39cd210d-5d45-478a-91fe-b3680307f2df'
* app: Return early on empty monitor mappingPavel Grunt2016-02-151-0/+5
| | | | | Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1304648
* app: Do not map display to non-existent monitorPavel Grunt2015-11-041-1/+5
|
* app: Add helper for number of client monitorsPavel Grunt2015-11-041-6/+11
|
* app: Use display id instead of 'this' in debugPavel Grunt2015-10-211-1/+1
|
* 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.
* Don't wait for reconnect when user cancels authJonathon Jongsma2015-06-191-0/+5
| | | | | | | | | | | 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.
* Rename session-auth-failed to session-auth-unsupportedJonathon Jongsma2015-06-191-5/+5
| | | | | | | | 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-191-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* 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
* monitor-mapping: Do not allow to skip a displayPavel Grunt2015-06-041-0/+9
| | | | | | | | | | Skipping a display does not have an effect because displays will be reconfigured and shifted on the guest side anyway. these monitor mappings are not valid: 'monitor-mapping=1:2;3:1' - display #2 is not specified 'monitor-mapping=4:2;2:1' - displays #1, #3 are not specified 'monitor-mapping=3:3' - displays #1, #2 are not specified
* virt-viewer: Set toolbar buttons not sensitive when neededLukas Venhoda2015-04-221-0/+13
| | | | | | | | | | | | | | File->Screenshot, File->Preferences, View->Zoom and Send keys are now sensitive only while quest is connected. Changed behaviour of zoom: Previously, zoom could be set while quest wasn't connected. The zoom would then be set on connection. There was no indication of current zoom level while not connected to guest. Now, the menu is not sensitive while not connected to guest. Zoom can now be only modified while connected to guest, or from the command line.
* app/window: Set display menu not sensitive when neededLukas Venhoda2015-04-221-1/+5
| | | | | Displays menu must be sensitive only when at least one display is enabled.
* virt-viewer-app: Do not show error dialog twice for unknown graphicPavel Grunt2015-04-091-2/+0
| | | | Related: rhbz#1085216
* Fix crash when disabling last enabled displayFabiano Fidêncio2015-04-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using virt_viewer_signal_connect_object() instead of g_signal_connect() ensures that menu_display_visible_toggled_cb() won't be executed after the display object be disposed. Backtrace for the crash: #0 0x00007ffff070592b in g_type_check_instance_is_a (type_instance=0x8851f0, iface_type=<optimized out>) at gtype.c:4016 #1 0x000000000041ee06 in virt_viewer_display_get_session (self=0x8851f0) at ../../src/virt-viewer-display.c:702 #2 0x0000000000417be7 in menu_display_visible_toggled_cb (checkmenuitem=0x93f790 [GtkCheckMenuItem], display=0x8851f0) at ../../src/virt-viewer-app.c:2187 #6 0x00007ffff06fe29f in <emit signal ??? on instance 0x93f790 [GtkCheckMenuItem]> (instance=instance@entry=0x93f790, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3361 #3 0x00007ffff06e3b9f in g_closure_invoke (closure=0x93faa0, return_value=return_value@entry=0x0, n_param_values=1, param_values=param_values@entry=0x7fffffffc230, invocation_hint=invocation_hint@entry=0x7fffffffc1b0) at gclosure.c:768 #4 0x00007ffff06f54c9 in signal_emit_unlocked_R (node=node@entry=0x6d73e0, detail=detail@entry=0, instance=instance@entry=0x93f790, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffc230) at gsignal.c:3549 #5 0x00007ffff06fded0 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffc3f0) at gsignal.c:3305 #7 0x00007ffff5eb6158 in gtk_check_menu_item_activate (check_menu_item=0x93f790 [GtkCheckMenuItem]) at gtkcheckmenuitem.c:299 #8 0x00007ffff5eb6158 in gtk_check_menu_item_activate (menu_item=0x93f790 [GtkCheckMenuItem]) at gtkcheckmenuitem.c:419 #12 0x00007ffff06fe29f in <emit signal ??? on instance 0x93f790 [GtkCheckMenuItem]> (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3361 #9 0x00007ffff06e3b9f in g_closure_invoke (closure=closure@entry=0x6d5aa0, return_value=return_value@entry=0x0, n_param_values=1, param_values=param_values@entry=0x7fffffffc6b0, invocation_hint=invocation_hint@entry=0x7fffffffc630) at gclosure.c:768 #10 0x00007ffff06f51bd in signal_emit_unlocked_R (node=node@entry=0x6d5ba0, detail=detail@entry=0, instance=instance@entry=0x93f790, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffc6b0) at gsignal.c:3479 #11 0x00007ffff06fded0 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffc870) at gsignal.c:3305 #13 0x0000000000417c5e in menu_display_visible_toggled_cb (checkmenuitem=0x93f790 [GtkCheckMenuItem], display=0x8851f0) at ../../src/virt-viewer-app.c:2200 #17 0x00007ffff06fe29f in <emit signal ??? on instance 0x93f790 [GtkCheckMenuItem]> (instance=instance@entry=0x93f790, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3361 #14 0x00007ffff06e3c45 in g_closure_invoke (closure=0x93faa0, return_value=return_value@entry=0x0, n_param_values=1, param_values=param_values@entry=0x7fffffffcb50, invocation_hint=invocation_hint@entry=0x7fffffffcad0) at gclosure.c:768 #15 0x00007ffff06f54c9 in signal_emit_unlocked_R (node=node@entry=0x6d73e0, detail=detail@entry=0, instance=instance@entry=0x93f790, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffcb50) at gsignal.c:3549 #16 0x00007ffff06fded0 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffcd10) at gsignal.c:3305 #18 0x00007ffff5eb6158 in gtk_check_menu_item_activate (check_menu_item=0x93f790 [GtkCheckMenuItem]) at gtkcheckmenuitem.c:299 #19 0x00007ffff5eb6158 in gtk_check_menu_item_activate (menu_item=0x93f790 [GtkCheckMenuItem]) at gtkcheckmenuitem.c:419 #23 0x00007ffff06fe29f in <emit signal ??? on instance 0x93f790 [GtkCheckMenuItem]> (instance=instance@entry=0x93f790, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3361 #20 0x00007ffff06e3c45 in g_closure_invoke (closure=closure@entry=0x6d5aa0, return_value=return_value@entry=0x0, n_param_values=1, param_values=param_values@entry=0x7fffffffcfd0, invocation_hint=invocation_hint@entry=0x7fffffffcf50) at gclosure.c:768 #21 0x00007ffff06f51bd in signal_emit_unlocked_R (node=node@entry=0x6d5ba0, detail=detail@entry=0, instance=instance@entry=0x93f790, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffcfd0) at gsignal.c:3479 #22 0x00007ffff06fded0 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffd190) at gsignal.c:3305 #24 0x00007ffff608648e in IA__gtk_widget_activate (widget=widget@entry=0x93f790 [GtkCheckMenuItem]) at gtkwidget.c:5048 #25 0x00007ffff5f6cacd in IA__gtk_menu_shell_activate_item (menu_shell=0x70ece0 [GtkMenu], menu_item=0x93f790 [GtkCheckMenuItem], force_deactivate=<optimized out>) at gtkmenushell.c:1303 #26 0x00007ffff5f6ce96 in gtk_menu_shell_button_release (widget=0x70ece0 [GtkMenu], event=<optimized out>) at gtkmenushell.c:730 #31 0x00007ffff06fe29f in <emit signal ??? on instance 0x70ece0 [GtkMenu]> (instance=instance@entry=0x70ece0, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3361 #27 0x00007ffff5f578ad in _gtk_marshal_BOOLEAN__BOXED (closure=0x6c7180, return_value=0x7fffffffd4e0, n_param_values=<optimized out>, param_values=0x7fffffffd540, invocation_hint=<optimized out>, marshal_data=<optimized out>) at gtkmarshalers.c:86 #28 0x00007ffff06e3c45 in g_closure_invoke (closure=closure@entry=0x6c7180, return_value=return_value@entry=0x7fffffffd4e0, n_param_values=2, param_values=param_values@entry=0x7fffffffd540, invocation_hint=invocation_hint@entry=0x7fffffffd4c0) at gclosure.c:768 #29 0x00007ffff06f5cef in signal_emit_unlocked_R (node=node@entry=0x6c73f0, detail=detail@entry=0, instance=instance@entry=0x70ece0, emission_return=emission_return@entry=0x7fffffffd660, instance_and_params=instance_and_params@entry=0x7fffffffd540) at gsignal.c:3587 #30 0x00007ffff06fdac2 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffd710) at gsignal.c:3315 #32 0x00007ffff608790c in gtk_widget_event_internal (widget=widget@entry=0x70ece0 [GtkMenu], event=event@entry=0x944f90) at gtkwidget.c:5017 #33 0x00007ffff6087be7 in IA__gtk_widget_event (widget=widget@entry=0x70ece0 [GtkMenu], event=event@entry=0x944f90) at gtkwidget.c:4814 #34 0x00007ffff5f55b94 in IA__gtk_propagate_event (widget=0x70ece0 [GtkMenu], event=0x944f90) at gtkmain.c:2501 #35 0x00007ffff5f55f5b in IA__gtk_main_do_event (event=0x944f90) at gtkmain.c:1696 #36 0x00007ffff5bae7dc in gdk_event_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at gdkevents-x11.c:2425 #37 0x00007ffff03e40ba in g_main_context_dispatch (context=0x693d50) at gmain.c:3122 #38 0x00007ffff03e40ba in g_main_context_dispatch (context=context@entry=0x693d50) at gmain.c:3737 #39 0x00007ffff03e4450 in g_main_context_iterate (context=0x693d50, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3808 #40 0x00007ffff03e4772 in g_main_loop_run (loop=0x748980) at gmain.c:4002
* virt-viewer-app: Set hotkeys when app is constructedPavel Grunt2015-04-021-1/+1
| | | | | | | | virt_viewer_app_set_hotkeys() calls virt_viewer_app_set_enable_accel() which notify the display about "enable-accel". However the display begins to exist after the virt_viewer_app initialization. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1206106
* Use ZOOM constants instead of numbersPavel Grunt2015-04-021-2/+2
|
* 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.
generated by cgit (git 2.34.1) at 2024-05-09 10:19:51 +0000