|Summary:||Add introspection support|
|Product:||libcanberra||Reporter:||Robert Ancell <robert.ancell>|
|Component:||Unspecified||Assignee:||Lennart Poettering <lennart>|
|Status:||NEW ---||QA Contact:|
|Priority:||medium||CC:||jstpierre, mitya57, nekohayo, pborelli, reklov, t.c.brindle|
|i915 platform:||i915 features:|
|Attachments:||Some work on a patch to add introspection support|
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
Comment 19 Tristan Brindle 2013-08-07 05:22:35 UTC
Comment 20 Tristan Brindle 2013-08-07 05:24:21 UTC
Argh, accidentally posted a half-finished comment, please ignore comment 18