Bug 32587 - Add introspection support
Add introspection support
Status: NEW
Product: libcanberra
Classification: Unclassified
Component: Unspecified
unspecified
Other All
: medium enhancement
Assigned To: Lennart Poettering
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-22 16:53 UTC by Robert Ancell
Modified: 2013-08-07 05:44 UTC (History)
6 users (show)

See Also:


Attachments
Some work on a patch to add introspection support (2.86 KB, patch)
2010-12-22 16:53 UTC, Robert Ancell
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Ancell 2010-12-22 16:53:17 UTC
Created attachment 41386 [details] [review]
Some work on a patch to add introspection support

It would be nice to have introspection support so libcanberra could be easily accessible to other languages (e.g. Python).
Comment 1 Robert Ancell 2010-12-22 16:55:50 UTC
The biggest blockers seem to be int ca_proplist_create and ca_context_create.  Perhaps a ca_proplist_new, _ref, _unref could be added?
Comment 2 Lennart Poettering 2010-12-23 06:32:21 UTC
Hmm, when I added introspection support to the APIs of Avahi I was subsequently asked to disable it again since the introspection formats for non-GObject libraries has not been declared stable yet. Has this changed by now?
Comment 3 Robert Ancell 2011-01-05 19:18:15 UTC
I don't know what the state of introspection is for non-GObject...
Comment 4 Jean-François Fortin Tam 2012-03-24 19:37:30 UTC
Lennart/Robert: who should we ask about the current state of introspection formats for non-gobject libraries, so that this bug can move forward? Shouldn't it work by now?
Comment 5 Robert Ancell 2012-04-04 00:07:36 UTC
Jean-François, sorry I don't know but asking on IRC is probably the best way of finding out.
Comment 6 Nicolas Dufresne 2012-09-10 15:33:41 UTC
Well we have cairo, libxml, sqlite, cogl, freetype, fontconfig, JSCore, XLib, ... People will cry if it's not yet stable.
Comment 7 Lennart Poettering 2012-09-24 23:47:49 UTC
Is Robert's patch up-to-date? I am kinda relying on patches from you guys, as my experience with GI is rather minimal...
Comment 8 Robert Ancell 2012-09-25 00:11:27 UTC
Patch is unfinished and probably out of date.
Comment 9 Jasper St. Pierre 2012-11-15 15:32:23 UTC
Is porting libcanberra to GObject out of the question? It's the GNOME audio playback library, so it seems like it should use GNOME platform libraries.
Comment 10 Lennart Poettering 2012-11-15 16:32:10 UTC
It's not out of the question, but I must admit that I'd prefer to add GObject intrsopection without moving it fully to GObject if that's possible, simply to keep things simply and the way they already work.
Comment 11 Jasper St. Pierre 2012-11-15 17:55:15 UTC
It's certainly possible, but at the very least, we require boxed types for introspection. To make your system efficient, you'd require a ref-counting struct.
Comment 12 Allan Day 2013-02-08 09:46:02 UTC
I know that this bug is blocking GNOME Clocks right now, and they're considering a Vala rewrite to get around the problem.
Comment 13 Tristan Brindle 2013-03-02 18:46:36 UTC
Hi all,

To get around the problem of libcanberra not being introspectable, I've written small library called GSound (remarkably, a name that doesn't seem to have ever been used in the GLib stack), which is a GObject wrapper around libcanberra.

The API is largely identical, just translated into a "GObject-y" style for use with GI. So to go for the most complicated example straight away, instead of

int ca_context_play_full(ca_context *context,
                         uint32_t id,
                         ca_proplist *p,
                         ca_finish_callback_t cb,
                         void *userdata)

the GSound wrapper is:

void gsound_context_play_full(GSoundContext *context,
                              GCancellable *cancellable,
                              GHashTable *attributes,
                              GAsyncReadyCallback callback,
                              gpointer user_data)

with

gboolean gsound_context_play_full_finish(GSoundContext *context,
                                         GAsyncResult *result,
                                         GError **error)

matching the usual GIO async pattern. Properties are passed as GHashTables rather than ca_proplists, in order to take advantage of automatic conversion from native hashes/dicts.


All the code (and a README with a bit more info) can be found at

https://github.com/tcbrindle/gsound

(I don't have a Gnome account). It's licenced under the LGPL 2.1+.

This seems like the right solution to keep libcanberra relatively desktop-agnostic whilst still having an audio playback library that's easy to use from GI.

Any patches or feedback will be gratefully received.

Cheers,

Tristan
Comment 14 Mathieu Bridon 2013-03-24 03:50:50 UTC
(In reply to comment #12)
> I know that this bug is blocking GNOME Clocks right now, and they're
> considering a Vala rewrite to get around the problem.

They did switch to Vala, so they are not blocked any more.

However, I'm writing an IBus input method engine in Python, and this is blocking me (I need to play an error sound when the user types a wrong input).

(In reply to comment #13)
> Hi all,
> 
> To get around the problem of libcanberra not being introspectable, I've
> written small library called GSound (remarkably, a name that doesn't seem to
> have ever been used in the GLib stack), which is a GObject wrapper around
> libcanberra.

I think at this point, application authors (like me) would really benefit from knowing what is the long-term plan: will libcanberra eventually support GObject-Introspection, or should we use GSound?

In other words, could GSound eventually become "blessed" in GNOME, and become the proper fix for this bug?
Comment 15 Lennart Poettering 2013-03-25 17:07:33 UTC
I am happy to make it introspectable, but I am kinda relying on a patch for that.

If somebody cooks something up I am happy to merge it and release it. I think it's the right way if lc is introspectable.
Comment 16 Jasper St. Pierre 2013-03-25 17:18:29 UTC
Non-GObject introspection is indeed unstable, unless you provide boxed objects, which come with their own set of drawbacks. Do you have anything more complicated than simple objects with methods, like a custom form of inheritance?
Comment 17 Lennart Poettering 2013-03-25 17:28:50 UTC
It should be normal object-oriented C, i.e. all methods take the objects as first arg and so on.

I don't know GObject too well, but here's where I might see problems:

- instantiation is done like this:

  int ca_context_create(ca_context **c);

  i.e. we return the newly created object via an argument, rather then as function return.

- we have a callback function:

  void (*ca_finish_callback_t)(ca_context *c, uint32_t id, int error_code, void *userdata);

- we have four static calls that are not methods of our own objects:

  ca_context *ca_gtk_context_get(void);
  int ca_gtk_play_for_widget(GtkWidget *w, uint32_t id, ...);
  int ca_gtk_play_for_event(GdkEvent *e, uint32_t id, ...);
  void ca_gtk_widget_disable_sounds(GtkWidget *w, gboolean enable);

- there are no va_arg versions of two of the calls above (that's because they are easily built from three other calls, so doing the va_arg thing appeared unnecessary.)
Comment 18 Tristan Brindle 2013-08-07 04:57:58 UTC
My personal feeling is that even if libcanberra gains introspection support, it would end up with an API which isn't necessarily optimal in JavaScript or Python. 

For example, since varargs aren't supported in g-i, you'd need to add support for ca_proplists, and then your call sequence in Python would look something like:

def on_playback_finished(args...):


ctx = ca_context()
pl = ca_proplist()
pl.add("media.filename", "/my/sound/file")
pl.add(...)
ctx.play(1, pl)





(In reply to comment #14)
> I think at this point, application authors (like me) would really benefit
> from knowing what is the long-term plan: will libcanberra eventually support
> GObject-Introspection, or should we use GSound?
> 
> In other words, could GSound eventually become "blessed" in GNOME, and
> become the proper fix for this bug?
Comment 19 Tristan Brindle 2013-08-07 05:22:35 UTC
My personal feeling is that even if libcanberra gains introspection support, it would end up with an API which isn't necessarily optimal in JavaScript or Python, and rather different to other g-i libraries like GIO.

For example, since varargs aren't supported in g-i, you'd need to add support for ca_proplists, and then your call sequence in Python would look something like:

def on_playback_finished(ctx, id, error_code):
    if (error_code != canberra.SUCCESS):
        # do something

ctx = canberra.context()
pl = canberra.proplist()
pl.add("media.filename", "/my/sound/file")
pl.add(...)
ctx.play_full(1, pl, on_playback_finished)

However, a much nicer way to come up with a list of properties would be to use native Python dicts (or hashes in JavaScript). Automatic conversion from these native types to GHashTables already exists, so it makes sense to use this if possible.

Likewise, it's usual in Python or JS to use exceptions rather than C-style integer return codes for errors. Again, the g-i runtimes have automatic conversion from GErrors to native exceptions, so it makes sense to use GError if we can.

GSound was my attempt to use these features (and the familiar GIO async machinery rather than a custom callback) to make libcanberra easy to use from introspected languages. Of course, having two layers is less than ideal in some ways, but then again, the pattern of a low-level C library + GObject wrapper is already used in many places in the GLib stack, and seems to work pretty well.

(In reply to comment #14)
> I think at this point, application authors (like me) would really benefit
> from knowing what is the long-term plan: will libcanberra eventually support
> GObject-Introspection, or should we use GSound?
> 
> In other words, could GSound eventually become "blessed" in GNOME, and
> become the proper fix for this bug?

I'm not a Gnome hacker (yet?), but I'd be delighted for this to happen eventually if people think it merits inclusion. I'm more than happy to take feedback and patches if people want to take a look at it (even if the feedback is "don't waste your time" :-) ).
Comment 20 Tristan Brindle 2013-08-07 05:24:21 UTC
Argh, accidentally posted a half-finished comment, please ignore comment 18
Comment 21 Tristan Brindle 2013-08-07 05:44:43 UTC
For the record, all the relevant info about GSound (including simple usage examples in JS, Python and Vala) can be found at

https://github.com/tcbrindle/gsound

<end promotion>