>
> From: Frediano Ziglio
>
> Until now, the same header guard was used for all generated .h files.
> Now the header guard name is based on the name of the file being
> generated so that it's different for each .h file.
> ---
> Frediano, I left you as the author of this patch but I squashed the
Users should not change the list of supported subtypes.
Signed-off-by: Frediano Ziglio
---
configure.ac| 1 +
server/reds.c | 4 ++--
server/spice-char.h | 1 +
3 files changed, 4 insertions(+), 2 deletions(-)
Changes from v1:
- do not break API;
- add some comments on API breakag
Hi Fidêncio
Thanks a lot for your information!
I solved my build error.
Best Regards
koizumi
On 2016/06/23 15:28, Fabiano Fidêncio wrote:
On Thu, Jun 23, 2016 at 7:14 AM, 小泉 wrote:
Hi all
I build virt-viewer for Windows on my fedora based on following instruction.
Building Instructio
On Thu, 2016-06-23 at 19:37 +0200, Victor Toso wrote:
> Introduced functions (private):
> * void spice_file_transfer_task_init_task_async()
> * GFileInfo *spice_file_transfer_task_init_task_finish()
>
> The init process of SpiceFileTransferTask does initialize its
> GFileInputStream (for rea
I'm not sure this is necessary. See next patch.
On Thu, 2016-06-23 at 19:37 +0200, Victor Toso wrote:
> GFileInfo is currently leaking from file_xfer_info_async_cb() so it
> should be fixed. As the GFileInfo is an interesting object to have
> for the next patch, I'm saving this object for later u
On Thu, 2016-06-23 at 19:37 +0200, Victor Toso wrote:
> We can split from file_xfer_send_start_msg_async() the logic in
> creating the SpiceFileTransferTasks; The rest of the function can be
> handled at spice_main_file_copy_async().
>
> The new function, spice_file_transfer_task_create_tasks() re
On Thu, 2016-06-23 at 19:37 +0200, Victor Toso wrote:
> In order to channel-main interact with each SpiceFileTransferTask for
> the file-transfer operation, the following functions are introduced:
Change "In order to channel-main interact" to "In order for channel-main to
interact"
> * spice_file
Acked-by: Jonathon Jongsma
On Thu, 2016-06-23 at 19:37 +0200, Victor Toso wrote:
> As this is unsigned, we can let 0 be in case of error
> ---
> src/channel-main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/channel-main.c b/src/channel-main.c
> index 3d6ac2f..
---
src/channel-main.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/src/channel-main.c b/src/channel-main.c
index 63f0b9b..2c9a6fb 100644
--- a/src/channel-main.c
+++ b/src/channel-main.c
@@ -76,6 +76,7 @@ static gssize
spice_file_transfer_ta
Rename:
* file_xfer_close_cb -> spice_file_transfer_task_close_stream_cb
As this will be private to SpiceFileTransferTask
---
src/channel-main.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/channel-main.c b/src/channel-main.c
index ef34daa..63f0b9b 100644
---
Agent only can only send error or cancel from a transfer operation
after it was initialized. From SpiceFileTransferTask point of view,
error and cancellation is an GError with different code so testing
only cancel seems enough.
---
tests/file-transfer.c | 66 +++
This only includes a simple test for file-transfer with a small
summary of the possible situations of the test.
As the test is specifically for SpiceFileTransferTask, we don't create
a SpiceMainChannel. That could cause a simple crash on CHANNEL_DEBUG
which this patch addresses.
---
tests/Makefil
There is no need to send 0 bytes of data to the agent, we should just
wait for VD_AGENT_FILE_XFER_STATUS message.
---
src/channel-main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/channel-main.c b/src/channel-main.c
index 0505687..ef34daa 100644
--- a/src/channel
Before this patch, the progress_callback is being called from
SpiceFileTransferTask each time that some data is flushed to the agent
of this given xfer-task. The progress value is computed by iterating
on all available xfer-tasks.
This patch intend to fix/change:
* The progress_callback should be
This is an intermediary step for the following patches to make the
changes more clear and easy to follow.
In file_xfer_send_progress(), I've renamed the variable self to
xfer_task as this is not SpiceFileTransferTask function.
---
src/channel-main.c | 50 ++
Another patch to rename variable and keep consistency across
channel-main. Let's avoid task which is common for GTask and self for
non SpiceMainChannel objects
---
src/channel-main.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/channel-main.c b/src/channel-mai
---
tests/file-transfer.c | 64 +++
1 file changed, 64 insertions(+)
diff --git a/tests/file-transfer.c b/tests/file-transfer.c
index 61d0dcc..018d6ad 100644
--- a/tests/file-transfer.c
+++ b/tests/file-transfer.c
@@ -172,6 +172,62 @@ test_cancel_on
This patch moves:
* GObject boilerplate
* External API related to SpiceFileTransferTask
* Internal API needed by channel-main
* Helpers that belong to this object
---
src/Makefile.am | 2 +
src/channel-main.c | 696 +--
src/spi
Each call to spice_main_file_copy_async will now create a
FileTransferOperation which groups all SpiceFileTransferTasks of the
copy operation in a GHashTable.
To ease the review process, this first patch introduces the structure
and organize the logic around the four following helpers:
* file_tra
---
tests/file-transfer.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/tests/file-transfer.c b/tests/file-transfer.c
index 6ef178b..61d0dcc 100644
--- a/tests/file-transfer.c
+++ b/tests/file-transfer.c
@@ -137,6 +137,41 @@ test_simple_transfer(F
No need to inform of a problem under
spice_file_transfer_task_completed() as the task will be finalized and
we can send the error to the agent there.
This change is related to split SpiceFileTransferTask from
channel-main.
Acked-by: Pavel Grunt
---
src/channel-main.c | 23 +-
SpiceFileTransferTask has a callback to be called when operation
ended. Til this patch, we were setting the user callback which means
that in multiple file-transfers, we were calling the user callback
several times.
Following the same logic pointed from 113093dd00a1cf10f6d3c3589b7 this
is a SpiceM
file_xfer_queue() function belongs to channel-main so it should not
access SpiceFileTransferTask private struct (self->buffer).
This patch changes:
* rename function: file_xfer_queue -> file_xfer_queue_msg_to_agent
As it makes more clear what this helper function does;
* rename variabale: self -
We can split from file_xfer_send_start_msg_async() the logic in
creating the SpiceFileTransferTasks; The rest of the function can be
handled at spice_main_file_copy_async().
The new function, spice_file_transfer_task_create_tasks() returns a
GHashTable to optimize the access to a SpiceFileTransfer
By separating SpiceFileTransferTask from channel-main, we could choose
where to put the handler for messages. With the approach based on
spice_file_transfer_task_read_async(), we cannot have it under
spice-file-transfer-task.c due the need of callback and userdata on
_read_async.
It is much easier
As this is unsigned, we can let 0 be in case of error
---
src/channel-main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/channel-main.c b/src/channel-main.c
index 3d6ac2f..1e4853e 100644
--- a/src/channel-main.c
+++ b/src/channel-main.c
@@ -3435,7 +3435,7 @@ spice_file_
In order to channel-main interact with each SpiceFileTransferTask for
the file-transfer operation, the following functions are introduced:
* spice_file_transfer_task_get_id
* spice_file_transfer_task_get_channel
* spice_file_transfer_task_get_cancellable
Note that although "id" property is public
Introduced functions (private):
* void spice_file_transfer_task_init_task_async()
* GFileInfo *spice_file_transfer_task_init_task_finish()
The init process of SpiceFileTransferTask does initialize its
GFileInputStream (for reading the file) and also its GFileInfo
(necessary to protocol in or
* spice_file_transfer_task_read_async() will call the callback with
error in case it is called on pending state
* on VD_AGENT_FILE_XFER_STATUS_SUCCESS it should not be possible to be
on pending state as spice_file_transfer_task_read_async() would
return immediately in case all file is read
-
GFileInfo is currently leaking from file_xfer_info_async_cb() so it
should be fixed. As the GFileInfo is an interesting object to have
for the next patch, I'm saving this object for later usage.
This change is related to split SpiceFileTransferTask from
channel-main.
---
src/channel-main.c | 3 ++
Hi all,
You can find the code on 'move-xfer-last' branch at
https://gitlab.com/victortoso/spice-gtk.git
There were a lot of changes based on last v3 review which makes a little bit
hard to list them all. The goal is to improve file-transfer logic/design so it
can handle per-file operations, error
file_xfer_flush_finish and file_xfer_data_flushed_cb are channel-main
function and should not check for SpiceFileTransferTask internal
errors.
---
src/channel-main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/channel-main.c b/src/channel-main.c
index be5a454..fef72cd 1
Introduced functions (private):
* void spice_file_transfer_task_read_async()
* gssize spice_file_transfer_task_read_finish()
For a better abstraction of how to read from SpiceFileTransferTask and
handle with its data, following the design of others objects like
GFile and GInputStream.
Due to th
Ping for pushing
On Thu, May 26, 2016 at 1:01 PM, Victor Toso wrote:
> Hi,
>
> On Wed, May 25, 2016 at 03:51:42PM +0200, Lukáš Venhoda wrote:
> > From: Lukas Venhoda
> >
> > Try to connect to shared folder automatically on Windows.
> >
> > On each loop of run_service(), run a GTask, that waits
Hi,
what will happen if both '--server' and '--client' are used on the commandline?
Only client's will be generated ?
Pavel
On Thu, 2016-06-23 at 12:57 +0200, Christophe Fergeau wrote:
> We currently have 2 very similar codepaths in the marshaller and
> demarshaller cases which check whether we
On Thu, 2016-06-23 at 14:25 +0200, Christophe Fergeau wrote:
> On Thu, Jun 23, 2016 at 02:03:45PM +0200, Pavel Grunt wrote:
> > Hi Christophe,
> >
> > they were patches changing spice common includes to use <> instead of "", so
> > I
> > would keep it.
>
> The generated code is in spice-common/co
On Thu, Jun 23, 2016 at 02:19:22PM +0200, Christophe Fergeau wrote:
> Actually there is a much bigger set of changes to the spice-gtk package when
> I compare http://depot.flexvdi.com/sources/spice-gtk-flexvdi-2.2.2.tgz
> with the upstream spice-gtk 0.28 tarball (see attached patch).
Here is the a
On Thu, Jun 23, 2016 at 02:03:45PM +0200, Pavel Grunt wrote:
> Hi Christophe,
>
> they were patches changing spice common includes to use <> instead of "", so I
> would keep it.
The generated code is in spice-common/common, so my understanding is
that "" should be used there for headers from the
On Thu, May 19, 2016 at 06:56:05PM +0200, Sergio L. Pascual wrote:
> On Thu, 2016-05-19 at 11:10 +0200, Christophe Fergeau wrote:
> > Is there any improvements that could be made on our side to make your
> > life easier with these clients?
>
> My colleague Javier already contributed some patches t
On Thu, 2016-06-23 at 12:57 +0200, Christophe Fergeau wrote:
Acked-by: Pavel Grunt
> ---
> python_modules/ptypes.py | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/python_modules/ptypes.py b/python_modules/ptypes.py
> index 74f3e55..eefd359 100644
> --- a/python_mo
Hi Christophe,
they were patches changing spice common includes to use <> instead of "", so I
would keep it.
Pavel
On Thu, 2016-06-23 at 12:57 +0200, Christophe Fergeau wrote:
> Includes specified on the command line are currently #included with <>
> rather than "". However, they are usually spi
We currently have 2 very similar codepaths in the marshaller and
demarshaller cases which check whether we are building client or server
code, error out if we specified neither on the command line and then
they call the same function with True or False for client/server.
We can factor this code a
This commit adds autogeneration of a generated_client_marshallers.h
header, which is then included in client_marshallers.h
This allows to remove the SpiceMessageMarshallers struct from this file,
which has to match what the generated code expects.
---
Changes since v1:
- Squashed the SPICE_{BEGIN,
From: Frediano Ziglio
Until now, the same header guard was used for all generated .h files.
Now the header guard name is based on the name of the file being
generated so that it's different for each .h file.
---
Frediano, I left you as the author of this patch but I squashed the changes I
suggest
---
python_modules/ptypes.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/python_modules/ptypes.py b/python_modules/ptypes.py
index 74f3e55..eefd359 100644
--- a/python_modules/ptypes.py
+++ b/python_modules/ptypes.py
@@ -139,7 +139,7 @@ def fix_attributes(attribute_li
Includes specified on the command line are currently #included with <>
rather than "". However, they are usually spice-common headers, so it
makes more sense to include them using ""
---
spice_codegen.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/spice_codegen.py b/spi
46 matches
Mail list logo
