The biggest blockers seem to be int ca_proplist_create and ca_context_create.  Perhaps a ca_proplist_new, _ref, _unref could be added?

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?

I don't know what the state of introspection is for non-GObject...

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?

Jean-François, sorry I don't know but asking on IRC is probably the best way of finding out.

Well we have cairo, libxml, sqlite, cogl, freetype, fontconfig, JSCore, XLib, ... People will cry if it's not yet stable.

Is Robert's patch up-to-date? I am kinda relying on patches from you guys, as my experience with GI is rather minimal...

Patch is unfinished and probably out of date.

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.

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.

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.

I know that this bug is blocking GNOME Clocks right now, and they're considering a Vala rewrite to get around the problem.

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

(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?

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.

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?

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.)

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?

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" :-) ).

Argh, accidentally posted a half-finished comment, please ignore comment 18

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>