This avoid keep sending modifiers changes if guest is not
synchronising the changes.
I consider this as an improving as this avoids client to try again
and again to force synchronisation however this does not prevent
every unwanted keystroke insertion which possibly can be a real
problem on some configurations.
For instance if guest do not handle caps lock as the client do
if client uses another modifiers (as num lock) this can force
inserting virtual caps keypress.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Marc-André Lureau <mlureau@redhat.com>
b0a2ff4 "clipboard: Add fixup_clipboard_text helper"
mistakenly removed some early returns when text conversion fails for
some reason. This commit readds it.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Signed-off-by: Pavel Grunt <pgrunt@redhat.com>
The parameter is removed from functions:
get_line
spice_convert_newlines
spice_unix2dos
spice_dos2unix
It was introduced in 75f1ea3ee9
but never used
Acked-by: Marc-André Lureau <mlureau@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
If we are to ever display error messages to a user in a UI, they need to
be translated.
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Currently, when the agent asks us for VD_AGENT_CLIPBOARD_UTF8_TEXT data,
spice-gtk looks up for the first X11 target which would provide it with
UTF8_TEXT data, and uses that for the clipboard request. This means we
will use UTF8_STRING as the target for gtk_clipboard_request_contents().
However, some applications who can copy and paste text do not
necessarily support the UTF8_STRING target. This is the case for Motif
applications which support the STRING target however. It turns out gtk+
also provides a gtk_clipboard_request_text() method which will try
several targets (UTF8_TEXT, COMPOUND_TEXT, TEXT), and will ensure the
returned string is UTF-8, so we can use that when the agent asks us for
some text data.
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1348624
If a client is handling multiple SpiceFileTransferTasks at one time,
it's not currently possible to provide a single overall progress to the
user. The only information that the client can get is the percentage
progress. This patch adds two new properties:
- total-bytes: the size of the file transfer task in bytes
- transferred-bytes: the number of bytes already transferred
This allows a client UI to calculate the combined progress for all
ongoing transfer tasks and present it to the user. Two convenience
functions were added to retrieve these values:
- spice_file_transfer_task_get_total_bytes()
- spice_file_transfer_task_get_transferred_bytes()
I added it to make sure AC_SUBST happened, but apparently AC_SUBST
happens with very old pkg-config versions too, no need to check
pkg-config pkg.m4 version.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Trying to click on spice-gtk window while in server mode should result
in a pointer grab. This is currently failing, with the cursor wrapping
to the top left corner of the window instead without being grabbed.
This is caused by our use of gtk_event_box_set_above_child(),
when clicking on the SpiceWidget, the grab is implicitly taken by
the window which is above the event box (which is an internal
GtkEventBox input-only GdkWindow). Then when we call gdk_pointer_grab()
on the GtkEventBox::window, we get a grab-broken event indicating the
grab was transferred from the internal input-only window to
GtkEventBox::window (see gtk+ bug
https://bugzilla.gnome.org/show_bug.cgi?id=769635#c2 for a detailed
explanation).
This commit ignores grab-broken events when the GdkWindow who got the
grab corresponds to the one we called gdk_pointer_grab() on.
An alternative would be to call gdk_pointer_grab() on the GdkWindow
which received the button-press-event, but the call chain between
button_event() and the eventual gdk_pointer_grab() call, so it would be
not so elegant to pass the correct GdkWindow all the way.
There is no strong need for keypress-delay on local connection (not
verified: unless the system is heavily loaded, in which case the VM will
probably be stuck too and may or not repeat the key when running).
The benefit of removing keypress-delay is that games or interfaces that
require "realtime" responses, such as FPS, are slightly better without
the 100ms input delay.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
So the widget can call it without going through g_object_set().
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Channel users (such as spice widget) may want to know some connection
details. Instead of exposing various connection properties, we may as
well just have a GSocket property, with a strong warning on usage.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
We no longer need the gtk+-quartz/win32 check, however we can simplify
the x11 check if building gtk+-x11
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
So we can drop the AC_SUBST for _CFLAGS & _LIBS variable (since 0.24
but there is no clean way to check that before PKG_PREREQ in 0.29,
released last year)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
GTK on its own is not enough to ensure libX11 is properly linked with
libspice-client-gtk. This patch adds X11_LIBS to SPICE_GTK_LIBADD_COMMON
(and X11_CFLAGS to a relevant section as well) in src/Makefile.am, and
performs an approriate pkg-config based check to determine the correct
values in configure.ac when not building for win32 or quartz.
For more info see http://bugs.gentoo.org/585118
This will allow internationalisation to work correctly.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Marc-André Lureau <mlureau@redhat.com>
Replace GDK_WINDOW_HWND by gdk_win32_window_get_impl_hwnd() which gets
the HWND directly, without any side effects.
Related:
https://bugzilla.redhat.com/show_bug.cgi?id=1352216
Acked-by: Fabiano Fidêncio <fabiano@fidencio.org>
This lets create_gstreamer_decoder() fail if it cannot create the
pipeline it needs, allowing the caller to try fallbacks.
This also means the pipeline has the same lifetime as the decoder which
makes it possible to remove a check in queue_frame().
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Note that this implies closing the stream before receiving any frame.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Victor Toso <victortoso@redhat.com>
In preparation for potentially displaying error messages to a user in a
UI, I thought I'd improve the messages slightly.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
It's safer and more consistent than assuming the caller has done the
check already.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
It is disconnected when spice_vmc_input_stream_read_all_finish()
is called.
Silence many warnings appearing with webdav:
GLib-GObject-WARNING **: gsignal.c:2635: instance '0x7fe658015c40' has no handler with id '13555'
Acked-by: Victor Toso <victortoso@redhat.com>
By using g_hash_table_new_full() we can unref its value which is the
SpiceFileTransferTask. This makes the code a little bit simpler as
nowhere we use the xfer-task after removing it from hash table.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
SpiceMainChannel uses the SpiceFileTransferTask reference given in the
hash table provided by spice_file_transfer_task_create_tasks(). That
means SpiceFileTransferTask is not holding a reference for itself but
it relies on it due the async calls it provides.
This patch increases the reference of each SpiceFileTransferTask for
the hash table which will be unref'ed by channel-main in
file_transfer_operation_task_finished(); the original reference is
kept to SpiceFileTransferTask to be freed after the finish signal is
emitted on spice_file_transfer_task_close_stream_cb().
This patch fixes some critical warnings as we have two g_object_unref
but only one reference.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Since commit b26818d0e0 we are grouping all transferred files per
operation (drag and drop); That leaded to some design flaws in the
code. The changes suggested in this patch are (in execution order):
* On spice_file_transfer_task_read_async()
- Passing FileTransferOperation data so in the callback and in further
function calls, we don't need to look for this;
Note that FileTransferOperation is not freed while any of its
SpiceFileTransferTask exists and by design they are never finished
while on pending state, so file_xfer_read_async_cb() should have a
valid FileTransferOperation pointer.
* On file_xfer_read_async_cb()
- Removed unnecessary variables;
* On file_xfer_flush_async()
- Using SpiceFileTransferTask as parameter which can retrieve the
SpiceMainChannel and the GCancellable;
- Using SpiceFileTransferTask as source_object for GTask with
FileTransferOperation as user_data which is helpful for its
callback;
* On file_xfer_flush_finish() and file_xfer_data_flushed_cb()
- Using SpiceFileTransferTask as parameter and source_object check for
GTask
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This was a request introduced at f6b3b69709 to be done after
moving the SpiceFileTransferTask code to its own file.
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Now that the ConnectAsyncData we need is set as GTask data, we can pass
around the GTask rather than the ConnectAsyncData instance, and remove
the GTask pointer from it. We can get the ConnectAsyncData from the
GTask when needed using g_task_get_task_data().
Currently, the ConnectAsyncData instance is leaked if for example
we trigger one codepath calling g_task_return_error(). If we
associate it with the GTask with g_task_set_task_data(),
this kind of leak will be avoided.
Rather than returning the whole ConnectAsyncData struct with
g_task_return_pointer(), we can return only the GIOStream object as this
is what we are interested in.
This has the side-effect of fixing a ConnectAsyncData leak as after
calling g_task_propagate_pointer() the old code had ownership of the
ConnectAsyncData instance but was never freeing it.
The leak is:
==20010== 4,348 (56 direct, 4,292 indirect) bytes in 1 blocks are definitely lost in loss record 20,762 of 20,999
==20010== at 0x4C2DA60: calloc (vg_replace_malloc.c:711)
==20010== by 0xD0F6EB0: g_malloc0 (gmem.c:124)
==20010== by 0x75C0978: wocky_http_proxy_connect_async (wocky-http-proxy.c:359)
==20010== by 0xCB4E22C: g_socket_client_connected_callback (gsocketclient.c:1548)
==20010== by 0xCB57342: g_task_return_now (gtask.c:1107)
==20010== by 0xCB579E5: g_task_return (gtask.c:1165)
==20010== by 0xCB4FB1C: g_socket_connection_connect_callback (gsocketconnection.c:236)
==20010== by 0xCB47160: socket_source_dispatch (gsocket.c:3543)
==20010== by 0xD0F1702: g_main_dispatch (gmain.c:3154)
==20010== by 0xD0F1702: g_main_context_dispatch (gmain.c:3769)
==20010== by 0xD0F1AAF: g_main_context_iterate.isra.29 (gmain.c:3840)
==20010== by 0xD0F1B5B: g_main_context_iteration (gmain.c:3901)
==20010== by 0xCB7D58C: g_application_run (gapplication.c:2381)
==20010== by 0x41571C: main (remote-viewer-main.c:42)
It was wrongly annotated as (transfer none)
An alternative would be to store what is returned by
g_file_get_basename() in SpiceFileTransferTask and return that, this
would allow to make spice_file_transfer_task_get_filename() (transfer
none) without leaking memory.
Acked-by: Victor Toso <victortoso@redhat.com>
This patch avoids a race condition. The race happens when we mark the
xfer-task as completed by receiving VD_AGENT_FILE_XFER_STATUS_SUCCESS
message while the flush callback was not yet called.
The flush callback is file_xfer_data_flushed_cb() and it might not be
called immediately after data is flushed.
The race can be verified while transferring several small files at
once. I can see it often with more then 50 files in one transfer
operation.
This fix implies that SpiceMainChannel should check in its async
callbacks if given SpiceFileTransferTask is completed.
This patch introduces spice_file_transfer_task_is_completed (internal)
to help check if spice_file_transfer_task_completed() was called or
not.
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
The self->error is the error set for the file-transfer and it will be
propagated with the "finish" signal. As this is transfer none pointer,
we should not lose its reference on g_task_return_error and we should
clear it out afterwards.
40 (16 direct, 24 indirect) bytes in 1 blocks are definitely lost in
loss record 7,489 of 14,298
at 0x4C2BBAD: malloc (vg_replace_malloc.c:299)
by 0xB5090E8: g_malloc (gmem.c:94)
by 0xB51F8A2: g_slice_alloc (gslice.c:1025)
by 0xB4EFCC5: g_error_new_literal (gerror.c:471)
by 0xB4EFFAD: g_set_error_literal (gerror.c:619)
by 0xAF13397: g_cancellable_set_error_if_cancelled (gcancellable.c:314)
by 0xAF630C8: g_task_propagate_error (gtask.c:1519)
by 0xAF63CD8: g_task_propagate_int (gtask.c:1652)
by 0x50863F5: spice_file_transfer_task_read_finish (spice-file-transfer-task.c:477)
by 0x5093239: file_xfer_read_async_cb (channel-main.c:1811)
by 0xAF62F38: g_task_return_now (gtask.c:1121)
by 0xAF63775: g_task_return (gtask.c:1179)
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
g_file_read_finish() is (transfer full) so we must release the ref
we got in _dispose() as it's not done anywhere else in the code.
Acked-by: Victor Toso <victortoso@redhat.com>
The file transfer code calls g_*_async() methods with a GTask as the
user_data argument. It needs to own a reference to the GTask for the
duration of the async call to keep the GTask alive, however it was never
releasing it when it no longer needs it (that is, after calling
g_task_return_*).
Some of the leaks fixed by this patch are:
* GTask leak after flush
11,232 bytes in 54 blocks are definitely lost in
loss record 14,018 of 14,071
at 0x4C2BBAD: malloc (vg_replace_malloc.c:299)
by 0xC14A0E8: g_malloc (gmem.c:94)
by 0xC1608A2: g_slice_alloc (gslice.c:1025)
by 0xC160ECD: g_slice_alloc0 (gslice.c:1051)
by 0xBEDBD11: g_type_create_instance (gtype.c:1857)
by 0xBEBD7DA: g_object_new_internal (gobject.c:1781)
by 0xBEBF11C: g_object_newv (gobject.c:1928)
by 0xBEBF89B: g_object_new (gobject.c:1621)
by 0xBBA4424: g_task_new (gtask.c:693)
by 0x6F8C3C0: file_xfer_flush_async (channel-main.c:899)
by 0x6F8C3C0: file_xfer_read_async_cb (channel-main.c:1826)
by 0xBBA3F38: g_task_return_now (gtask.c:1121)
by 0xBBA4775: g_task_return (gtask.c:1179)
* GTask leak from spice_main_file_copy_async()
208 bytes in 1 blocks are definitely lost in
loss record 13,708 of 15,093
at 0x4C2BBAD: malloc (vg_replace_malloc.c:299)
by 0xC14A0E8: g_malloc (gmem.c:94)
by 0xC1608A2: g_slice_alloc (gslice.c:1025)
by 0xC160ECD: g_slice_alloc0 (gslice.c:1051)
by 0xBEDBD11: g_type_create_instance (gtype.c:1857)
by 0xBEBD7DA: g_object_new_internal (gobject.c:1781)
by 0xBEBF11C: g_object_newv (gobject.c:1928)
by 0xBEBF89B: g_object_new (gobject.c:1621)
by 0xBBA4424: g_task_new (gtask.c:693)
by 0x6F8EF55: spice_main_file_copy_async (channel-main.c:3084)
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
The GFileInfo returned by spice_file_transfer_task_init_task_finish()
must be unref'ed when no longer needed.
Acked-by: Victor Toso <victortoso@redhat.com>
