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@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel