In the case where a file cannot be opened for reading, we were not
emitting a 'finished' signal to communicate the error to the client.
I was intending to further fix this issue by 'rejecting' the drop (in
SpiceDisplay) when the URI list contains invalid files (e.g.
directories). This would prevent a 'new-file-transfer' signal from even
being emitted for these invalid files. But this turns out to be not very
useful since there's no real feedback given to the user to indicate why
the drop failed. So it's probably better for client applications to get
the 'new-file-transfer' and 'finished' signals so that they can present
the error to the user to explain why the attempted transfer did not
work.
---
Changes since v1:
- include additional explanation in commit log as suggested by Fabiano on IRC
src/channel-main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/channel-main.c b/src/channel-main.c
index ffeb0ba..3a8c1dd 100644
--- a/src/channel-main.c
+++ b/src/channel-main.c
@@ -2935,7 +2935,7 @@ static void spice_file_transfer_task_completed(SpiceFileTransferTask *self,
if (!self->priv->file_stream) {
file_xfer_close_cb(NULL, NULL, self);
- return;
+ goto signal;
}
g_input_stream_close_async(G_INPUT_STREAM(self->priv->file_stream),
@@ -2944,6 +2944,7 @@ static void spice_file_transfer_task_completed(SpiceFileTransferTask *self,
file_xfer_close_cb,
self);
self->priv->pending = TRUE;
+signal:
g_signal_emit(self, task_signals[SIGNAL_FINISHED], 0, error);
}
--
2.4.3
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel