[Spice-devel] Spice-server gobject bindings

[Christophe Fergeau]

Hey Matthew,

I've finally taken a quick look at these bindings. For some reason I
could not build it:

ssg-server.c: In function 'ssg_server_class_init':
ssg-server.c:630:21: error: 'SSG_TYPE_SPICE_COMPAT_VERSION_T' undeclared (first use in this function); did you mean 'SSG_TYPE_SPICE_PORT_EVENT_T'?
                     SSG_TYPE_SPICE_COMPAT_VERSION_T,
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                     SSG_TYPE_SPICE_PORT_EVENT_T
ssg-server.c:630:21: note: each undeclared identifier is reported only once for each function it appears in
ssg-server.c:773:21: error: 'SSG_TYPE_SPICE_IMAGE_COMPRESSION_T' undeclared (first use in this function); did you mean 'SSG_TYPE_SPICE_COMPAT_VERSION_T'?
                     SSG_TYPE_SPICE_IMAGE_COMPRESSION_T,
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                     SSG_TYPE_SPICE_COMPAT_VERSION_T
ssg-server.c:782:21: error: 'SSG_TYPE_SPICE_WAN_COMPRESSION_T' undeclared (first use in this function); did you mean 'SSG_TYPE_SPICE_IMAGE_COMPRESSION_T'?
                     SSG_TYPE_SPICE_WAN_COMPRESSION_T,
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                     SSG_TYPE_SPICE_IMAGE_COMPRESSION_T
I guess an issue with the GEnum generation?

What these bindings achieve is replace the creation/initialization of
various structures with GObject wrapping this, and emitting signals when
a callback would be invoked by spice-server.
(note, while at it, I would not expose the attache-worker typo in the
higher level-API).
While this makes interacting with spice-server using these bindings
easier, I feel like some of these would make more sense as vfuncs on the
corresponding SsgXxxxInstanceClass that would get implemented through
inheritance. But at this point that's mostly a design decision.

I don't think at this point we should carry this upstream in
spice-server, as there are no users for it yet, so we would not be using
it/testing it as part of working on spice-server. We'd also want
something API/ABI stable before we ship it this way.

What we can do however to give it more visibility is link to it from
spice-space.org website, and/or add it to our it upstream gitlab
instance (hard to get new repositories/accounts) on freedesktop)

Christophe

On Fri, Sep 15, 2017 at 08:42:05PM +0800, Matthew Francis wrote:
> Hi,
> 
> I've recently developed a set of gobject bindings for spice-server. The
> code is available here:
> 
>   https://github.com/mjayfrancis/SpiceServerGLib
> 
> This parallels SpiceClientGLib to allow language bindings to easily control
> server instances.
> 
> The API coverage is by no means yet complete, but what is there is
> sufficient to implement a proxy
> (included) that chains from SpiceClientGLib to pass through a basic screen,
> keyboard and mouse.
> 
> 
> Would there be any interest in adopting this into the core code? If so, how
> and where would it fit?
> If at all possible, I would like to see this upstream - the present code is
> close to meeting my
> immediate needs, but I have a certain amount of time available to round out
> the API coverage
> and adapt the code as needed for inclusion, if it is possible to do so.
> 
> 
> (The end use I have in mind involves a proxy that modifies screen data to
> add transparent
> overlays, etc. - but this could equally be used for any other sort of
> application to easily present
> an interface over Spice)
> 
> Best regards
> Matthew Francis

> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20171129/8df161a7/attachment.sig>