IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
It's currently not possible to configure guest with higher resolution
than native, as it will switch back to native, since the gtk widget
allocation will always end up being the size of the screen. We
special-case fullscreen mode, and only resize when entering
fullscreen. Furthermore, it avoids sending extra unnecessary resize
events to the guest whenever gtk+ call size allocate in various
stages, with different values.
https://bugzilla.redhat.com/show_bug.cgi?id=864929
Fix some unwanted guest resize due to rounding issues (at least when
scaling up)
We may want to save the original remote desktop size, instead of
always checking widget requisition. That way zooming shouldn't resize
guest at all, but it seems tricky to handle that special case vs user
window resize that should trigger guest resize.
https://bugzilla.redhat.com/show_bug.cgi?id=856678
The virt_viewer_display_idle() will queue a resize event that will
result in display size requisition of 50x50. If we later resize the
window to 1x1 in virt_viewer_window_resize() we end up with a tiny
window.
It is legitimate not to force that 1x1 window resize when toggling the
option. After the rest of the logic in virt_viewer_window_resize(), if
the remote desktop ends up being resize, that will trigger another
virt_viewer_set_desktop_size() and finally change the window size
appropriately.
https://bugzilla.redhat.com/show_bug.cgi?id=856610
The string '::' is just one of many possible ways to express
the IPv6 "any" address. Others include '::0', '0:0:0:0:0:0:0:0',
'0::0' and more. Instead of trying to do strcmp, actually try
parsing the address with GInetAddress and then simply use an
accessor to check what type it is
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Currently the remote viewer windows get the URI as their
title. Provide a --title STRING arg to remote-viewer to
let the user override the title with something more
meaningful to them.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Commit 2201a5a was supposed to free a SPICE ticket leak, but it's
actually introducing a double-free as the SPICE ticket is
unconditionally freed at the end of
virt_viewer_session_spice_main_channel_event
Callers manually add a trailing \n when they call virt_viewer_app_trace,
but it's sometimes forgotten, leading to rhbz#822794. This commit
removes the \n from all callers (it was missing in a few of them)
and adds it in virt_viewer_app_trace.
Now that we have 2 distinct binaries, remote-viewer and virt-viewer,
'PACKAGE' can no longer be used in error messages as the name of the
binary. This causes a small inconsistency when running
'remote-viewer --foobar' as the error message would be:
'Unknown option --foobar
Run 'virt-viewer --help' to see a full list of available command line options'
This commit makes sure we use argv[0] for this message.
Fixes rhbz#814150
GtkNotebook will use the currently visible widget as default page.
If we don't show status widget before we append the display, the
current page will be on display. Quoting Gtk+ documentation:
"Note that due to historical reasons, GtkNotebook refuses to switch to
a page unless the child widget is visible. Therefore, it is
recommended to show child widgets before adding them to a notebook."
This property will be set when the display can be selected to be
"enabled" and shown (this can involve creating/connecting an
additional guest monitor, and may need guest agent cooperation for
example).
Rely on spice-gtk display channel monitors property to manage
displays. The same display channel may now provide several monitors,
the SpiceDisplay widget must be told which monitor to display
This flag will help to track whether the display has been
removed/closed and whether it really has a valid display.
Ready in contrast, is used to "hide" temporarily the display (when
starting or redrawing the display, to avoid artifacts)
When display is released, detach signal automatically.
Fix various crash related to not cleaning up signal handlers properly,
due to no longer 1-1 only relation between display widget and channel.
Use virt_viewer_signal_connect_object(), a copy of telepathy
utility function tp_g_signal_connect_object(). This function
will take care of removing signal handler if any of emitter or
attached object are destroyed.
The following patches will have this condition met, since there is no
longer 1-1 relation between channel and display. The channels can
continue to be around when some of the display are removed.
Fix copied from libvirt, commit by Eric Blake.
glibc 2.15 (on Fedora 17) coupled with explicit disabling of
optimization during development dies a painful death:
/usr/include/features.h:314:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
Work around this by only conditionally defining _FORTIFY_SOURCE,
in the case where glibc can actually use it. The trick is using
AH_VERBATIM instead of AC_DEFINE.
This reverts commit 3ce6df7c309068f36e2602692da809a153ed5688. This
commit broke virt-viewer which expects this function to return -1
or 0 on error, and a positive value on success in
virt_viewer_initial_connect.
VirtViewerApp::activate is expected to return -1 on errors.
It calls the VirtViewerSession::open_* methods, which return FALSE
on error. However, VirtViewerApp::activate directly returns these
boolean instead of testing the returned value and properly returning
-1 on errors. This caused errors in these open methodes to be ignored.
==25063== 59 bytes in 1 blocks are definitely lost in loss record 5,163 of 9,502
==25063== at 0x4A0884D: malloc (vg_replace_malloc.c:263)
==25063== by 0x3DE384D2BE: g_malloc (gmem.c:159)
==25063== by 0x3DE3862D0B: g_strdup (gstrfuncs.c:356)
==25063== by 0x41F40A: connected (remote-viewer-main.c:186)
==25063== by 0x3DE400F663: g_closure_invoke (gclosure.c:777)
==25063== by 0x3DE40206D7: signal_emit_unlocked_R (gsignal.c:3547)
==25063== by 0x3DE402866C: g_signal_emit_valist (gsignal.c:3296)
==25063== by 0x3DE4028CCF: g_signal_emit_by_name (gsignal.c:3389)
==25063== by 0x41AA53: reemit_signal_VOID (virt-viewer-session-ovirt.c:211)
==25063== by 0x3DE400F942: _g_closure_invoke_va (gclosure.c:840)
==25063== by 0x3DE4027D87: g_signal_emit_valist (gsignal.c:3207)
==25063== by 0x3DE4028CCF: g_signal_emit_by_name (gsignal.c:3389)
==25063== 14 bytes in 1 blocks are definitely lost in loss record 623 of 9,502
==25063== at 0x4A0884D: malloc (vg_replace_malloc.c:263)
==25063== by 0x34561092F7: __vasprintf_chk (vasprintf_chk.c:82)
==25063== by 0x3DE3882F1A: g_vasprintf (stdio2.h:199)
==25063== by 0x3DE3862EDC: g_strdup_vprintf (gstrfuncs.c:509)
==25063== by 0x3DE3862F7B: g_strdup_printf (gstrfuncs.c:535)
==25063== by 0x40CBAE: virt_viewer_app_update_pretty_address (virt-viewer-app.c:1538)
==25063== by 0x40FB55: virt_viewer_app_free_connect_info (virt-viewer-app.c:1707)
==25063== by 0x40FBE9: virt_viewer_app_dispose (virt-viewer-app.c:1291)
==25063== by 0x3DE40144F7: g_object_unref (gobject.c:2981)
==25063== by 0x40C31A: main (remote-viewer-main.c:336)
==25063== 10 bytes in 1 blocks are definitely lost in loss record 491 of 9,502
==25063== at 0x4A0884D: malloc (vg_replace_malloc.c:263)
==25063== by 0x34561092F7: __vasprintf_chk (vasprintf_chk.c:82)
==25063== by 0x3DE3882F1A: g_vasprintf (stdio2.h:199)
==25063== by 0x3DE3862EDC: g_strdup_vprintf (gstrfuncs.c:509)
==25063== by 0x3DE3862F7B: g_strdup_printf (gstrfuncs.c:535)
==25063== by 0x40DE36: window_update_menu_displays_cb (virt-viewer-app.c:1640)
==25063== by 0x3DE383833F: g_hash_table_foreach (ghash.c:1524)
==25063== by 0x3DE400F663: g_closure_invoke (gclosure.c:777)
==25063== by 0x3DE40206D7: signal_emit_unlocked_R (gsignal.c:3547)
==25063== by 0x3DE402866C: g_signal_emit_valist (gsignal.c:3296)
==25063== by 0x3DE40287C1: g_signal_emit (gsignal.c:3352)
==25063== by 0x5772F95: gtk_widget_show (gtkwidget.c:3225)
==25063== 8,431 (72 direct, 8,359 indirect) bytes in 1 blocks are definitely lost in loss record 9,468 of 9,502
==25063== at 0x4A0884D: malloc (vg_replace_malloc.c:263)
==25063== by 0x3DE384D2BE: g_malloc (gmem.c:159)
==25063== by 0x3DE38616B1: g_slice_alloc (gslice.c:1003)
==25063== by 0x3DE3861C05: g_slice_alloc0 (gslice.c:1029)
==25063== by 0x3DE402F96F: g_type_create_instance (gtype.c:1872)
==25063== by 0x3DE40147A7: g_object_constructor (gobject.c:1849)
==25063== by 0x3DE4016260: g_object_newv (gobject.c:1632)
==25063== by 0x3DE40168AB: g_object_new (gobject.c:1542)
==25063== by 0x40C4BD: virt_viewer_util_load_ui (virt-viewer-util.c:41)
==25063== by 0x40C7EB: virt_viewer_auth_collect_credentials (virt-viewer-auth.c:43)
==25063== by 0x41B391: authenticate_cb (virt-viewer-session-ovirt.c:430)
==25063== by 0x3458C05E8F: ffi_call_unix64 (unix64.S:75)
==25063== 32 (16 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 3,962 of 9,502
==25063== at 0x4A0884D: malloc (vg_replace_malloc.c:263)
==25063== by 0x3DE384D2BE: g_malloc (gmem.c:159)
==25063== by 0x3DE38616B1: g_slice_alloc (gslice.c:1003)
==25063== by 0x3DE38629F2: g_slist_append (gslist.c:222)
==25063== by 0x41483C: virt_viewer_window_init (virt-viewer-window.c:323)
==25063== by 0x3DE402FA05: g_type_create_instance (gtype.c:1892)
==25063== by 0x3DE40147A7: g_object_constructor (gobject.c:1849)
==25063== by 0x3DE4015D70: g_object_newv (gobject.c:1713)
==25063== by 0x3DE401655F: g_object_new_valist (gobject.c:1830)
==25063== by 0x3DE4016893: g_object_new (gobject.c:1545)
==25063== by 0x40DA34: virt_viewer_app_window_new (virt-viewer-app.c:590)
==25063== by 0x40E300: virt_viewer_app_constructor (virt-viewer-app.c:1336)
==30355== 4 bytes in 1 blocks are definitely lost in loss record 53 of 9,267
==30355== at 0x4A0884D: malloc (vg_replace_malloc.c:263)
==30355== by 0x3DE384D2BE: g_malloc (gmem.c:159)
==30355== by 0x3DE3862D0B: g_strdup (gstrfuncs.c:356)
==30355== by 0x3DE40360FC: value_copy_string (gvaluetypes.c:276)
==30355== by 0x3DE40340CA: g_value_transform (gvalue.c:535)
==30355== by 0x3FDAE621DD: gdk_screen_get_setting (gdkevents-x11.c:3022)
==30355== by 0x3FDB3C7415: gtk_settings_get_property (gtksettings.c:1152)
==30355== by 0x3DE4017A74: g_object_get_property (gobject.c:1289)
==30355== by 0x414991: virt_viewer_window_disable_modifiers (virt-viewer-window.c:616)
==30355== by 0x415922: virt_viewer_window_keyboard_grab (virt-viewer-window.c:931)
==30355== by 0x3DE400F942: _g_closure_invoke_va (gclosure.c:840)
==30355== by 0x3DE4027D87: g_signal_emit_valist (gsignal.c:3207)
Fix switch-host migration with Spice.
spice-gtk doesn't like channels staying around when they should be
destroyed/finalized, ie removed from session.
spice-gtk should probably learned to handle better the case of non
cooperating clients, and be able to dissociate a channel from a
session without waiting for it to be disposed, but for now, the
relation is quite tight.
The gtk_widget_get_pointer() API is deprecated in GTK3 since it
is not aware of multiple pointers. Replace its usage in autoDrawer.c
with GdkDeviceManager and friends
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The GtkStyle API has been deprecated in favour of GtkStyleContext.
Update ovBox.c to use the latter if building with GtK3. Also replace
use of the gtk_widget_size_request API with gtk_widget_get_preferred_size.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
