[Spice-devel] [announce] alpha glib/gtk client library + app.

[Alexander Larsson]

On Wed, 2010-09-29 at 12:07 +0200, Gerd Hoffmann wrote:
> Hi folks,
> 
> /me proudly presents some early glib/gtk bits for the client side of the 
> spice protocol.  The code is available in the gtk.v2 branch in my 
> personal spice repo @ freedesktop.org:
> 
>    http://cgit.freedesktop.org/~kraxel/spice/log/?h=gtk.v2
> 
> The README is here:
> 
>    http://cgit.freedesktop.org/~kraxel/spice/tree/gtk/README?h=gtk.v2
> 
> Good enougth to start playing with it.
> Far from being stable enougth for production use.
> Tested with winxp guest only so far.
> 
> Reviews are very welcome.  Especially looking at the design and 
> interfaces of the glib/gtk objects would be very helpful.  Looking at 
> the actual code isn't that useful (yet) as there are plenty of known 
> issues anyway.

I had a quick look at this. It seems this is a re-write of a client
implementation (based on the existing code i guess). I don't necessarily
disagree with this (as the current code isn't exactly well suited for
librarification), but this is a pretty big chunk of work that will take
a while to stabilize. Also, unless we completely replace the old client
implementation we will have to maintain two independent client
implementations. I guess if we make the gtk+ one work on windows too
then we can drop the old one. If this is the plan we need to ensure that
the APIs and implementations are not tied to tightly to unix.

A few random API comments:

"spice_watch", "spice_msg_out" etc is a pretty uncommon capitalization
for Gtk+/GObject APIs. Generally all (public) types are CamelCase.

spice_watch_put => spice_watch_free is a more typical Gtk+ naming
convention (or possibly _destroy). Or _ref/_unref for refcounted types.

Also, i don't like the audio integration, as it exposes the backend
implementation (at least by name) in the API. If we have multiple sound
implementations then each client must have code to integrate with each
one. So, I'd rather have a public SpiceAudioSink type that has different
implementations under the hood (which one gets picked might be solely a
build-time thing, or we could have an env var to choose between them).


Things like this is a bit uncommon/lowlevel in a gtk+ api (and, binds
badly to other languages):
int spice_session_get_channels(SpiceSession *session, SpiceChannel
**channels, int max);
A more typical Gtk+ style call is:
SpiceChannel ** spice_session_get_channels(SpiceSession *session);
returning a NULL-terminated array of items. Or possibly a GList *.

More later...

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl at redhat.com            alexander.larsson at gmail.com 
He's an uncontrollable guitar-strumming paranormal investigator with acid for 
blood. She's a sharp-shooting gold-digging Valkyrie from aristocratic European 
stock. They fight crime!