GNOME Bugzilla – Bug 621246
Vala bindings incomplete
Last modified: 2018-05-24 15:20:03 UTC
Created attachment 163330 [details] [review] Autogenerated vapi files The Vala bindings present in current Rhythmbox is very basic and doesn't allow the plugin to do much. I took a stab at autogenerating the bindings, so now they're pretty complete, but to fully work they need more annotations, but this can come once the plugins actually start using them. Attached are two patches, one includes the autogenerated .vapi files and the other includes necessary changes and files that I used for the autogeneration.
Created attachment 163331 [details] [review] Patch with script to generate the bindings
*** Bug 621504 has been marked as a duplicate of this bug. ***
I did some auto-generation / hand tweaking myself too and attached mine to the bug marked duplicate above. I took a look at the patches Michal submitted (good job nice to see someone else interested in this) and have some comments based on the versions I generated (and have used to run and query rhythmdb from Vala): * Currently the auto-generation mixes classes between namespaces e.g. RBRefString (StringValueMap, MetaData ...) which should have a definition inside the RB namespace and be called RefString There are some duplicates, too (RbDragDropDest etc) * The generation for EntryType and EntryType_ are not usable in the state given I found out how to "fix" these manually (just define Vala EntryType as C RhythmDBEntryType_) but will look into automating it in Michal's script * I had to hand tweak some va_args methods too (query parse method if memory serves me correctly I think) This might be a deficiency in the introspection * Some static helper functions from the lib/rb-util.h header are very handy for starting and stopping bits and bobs e.g. debug, rb threads, ref string + file helper initialisation Will see if I can come up with something.
How does this work overlap with generation of gobject introspection data for other languages? (In reply to comment #3) > I did some auto-generation / hand tweaking myself too and attached mine to the > bug marked duplicate above. > > I took a look at the patches Michal submitted (good job nice to see someone > else interested in this) and have some comments based on the versions I > generated (and have used to run and query rhythmdb from Vala): > > * The generation for EntryType and EntryType_ are not usable in the state given > > I found out how to "fix" these manually (just define Vala EntryType as C > RhythmDBEntryType_) but will look into automating it in Michal's script I'm going to convert RhythmDBEntryType into a real GObject some time soon, partly to help with introspection and partly because it's just a mess. > * Some static helper functions from the lib/rb-util.h header are very handy for > starting and stopping bits and bobs > > e.g. debug, rb threads, ref string + file helper initialisation You shouldn't be doing that anyway. Plugins have no reason to call those functions.
> How does this work overlap with generation of gobject introspection data for > other languages? Unfortunately there is quite some overlap I expect but it seems the tools aren't mature enough at the moment. Don't take any of this as gospel, by the way, I'm still feeling my way around these things. I'm guessing that gobject introspection would be the way to go in the future for all bindings but it's still in a bit of flux. I managed to get one of the devs (of Vala) on #vala and if I understand correctly they've got a few issues that need to be fixed before Vala can make use of it. For example see: https://bugzilla.gnome.org/show_bug.cgi?id=559704 As of today, Vala includes a "snapshot" of the gobject introspection code with some changes to better support it's features and workflow (and provide less of a moving target, I imagine). They've built some tools that sit on top of that snapshot, and that's what Michal and I have been working with. The Vala toolchain internally can work with two internal descriptions of interface GIDL and GIR. GIR is intended as (again, if I get it correctly) an assumed "correct" description of the object interface. It is intended that it will be generated from source annotations. GIDL is the older gobject-introspection format but the Vala toolchain supports re-writing / re-wiring which a Vala binding for rhythmbox would need at the moment. Michal's original generation patch was using the GIR format - unfortunately that wouldn't be an approach (for now) as the Vala toolchain doesn't support re-writing of objects/interfaces using that format. Whence Rhythmbox has gobject introspection support via annotations and the gobject toolchain is there maybe that's the time to follow that. >> * Some static helper functions from the lib/rb-util.h header are very handy for >> starting and stopping bits and bobs >> >> e.g. debug, rb threads, ref string + file helper initialisation > >You shouldn't be doing that anyway. Plugins have no reason to call those >functions. Yep fair enough :-) They are quite handy for being able to test the bindings without a full rhythmbox build and start/stop etc. So, basically I've got something vaguely in the ball park using Michal's script as a starting point. I have compiled against and used the generated glue to query the rhythmdb again from Vala as a first validation. I'm afraid the generation isn't elegant - I had some issues: * Two namespaces with co-dependencies The V tools only support generating output for one namespace at a time, so I've had to bootstrap from a small set inside the RB namespace, and then generate what I can from the RHYTHMDB namespace then back once more each to get everything. * RhythmDB object either has no namespace, or is an object with no name in the RHYTHMDB namespace :-) This makes for a lot of special cases and re-writing of the output as the Vala tools and gobject code get very confused when trying to tie the re-written name up to something inside the shared object symbol table.... General info about this code: * I'm currently generating all that the tools find in the RB and RHYTHMDB namespaces It was the easiest way to check the tooling could support all of the necessary types needed. It needs someone to point it in the right direction for what _should_ be exposed via this binding. Using the re-writing in the vapi-gen toolchain means turning such things off should be relatively simple (editing the .metadata files) * That said, I've not tested and/or checked that everything is indeed there or working. * More work needed to find/verify the correct cheader files to include for particular objects / functions - I've done a first stab but without actually compiling against them it's difficult to know if they are correct. * Patch with 2 updates for rhythmbox stuff (tooling_fixups.patch) Added the <gobject.h> include to rb-refstring.h as it refers to GTYPE Included the change of Michal which updates the entry type invalid to 0 (NULL) in rhythdb.h. This is needed to allow the Vala tooling to inspect the types * New vapi_gen.patch to put the scripts under bindings/vala/generation/vapi-gen Requires ^ the above patch to rhythmbox Will need to run ./configure --enable-vala of course Must build rhythmbox before building the bindings (as the tools look in the .so) cd into the bindings/vala/vapi-gen ./generate_vapi.sh * It isn't integrated with the auto-tools stuff I'm afraid - but there aren't any hardcoded paths in there. * I haven't written any unit tests for the bindings - like the auto-tools integration this seems like something that might be after (a) thinking if you would like to go this route (b) identifying the scope of what to expose to plugins * I've also attached the currently generated rb.vapi and rhythmdb.vapi files if anyone is interested in seeing what they look like.
Created attachment 163834 [details] [review] Two Rhythmbox updates needed for Vala tools
Created attachment 163835 [details] [review] latest vapigen scripts for generating .vapi
Created attachment 163836 [details] Sample vapis from latest generation tool
@Daniel: Why is there substitution of xmlNodePtr to char? It should be 'xmlNodePtr' -> 'xmlNode*'.
Oops. Copy pasta leeks through. Thanks.
Review of attachment 163834 [details] [review]: ::: rhythmdb/rb-refstring.h @@ +28,2 @@ #include <glib.h> +#include <glib-object.h> pushed as commit b567cce ::: rhythmdb/rhythmdb.h @@ +119,3 @@ #define RHYTHMDB_ENTRY_TYPE_IMPORT_ERROR (rhythmdb_entry_import_error_get_type ()) #define RHYTHMDB_ENTRY_TYPE_IGNORE (rhythmdb_entry_ignore_get_type ()) +#define RHYTHMDB_ENTRY_TYPE_INVALID (GINT_TO_POINTER (0)) why is this change necessary? why is vala unable to handle -1?
Review of attachment 163835 [details] [review]: This patch is full of autogenerated stuff (multiple copies of it too, apparently). I'd rather not commit any generated files at all, so please remove them unless they're absolutely necessary for some reason. Is there any particular reason we're trying to generate multiple namespaces? It's not really buying us anything. ::: bindings/vala/vapi-gen/generate_vapi.sh @@ +131,3 @@ + export PKG_CONFIG_PATH=rhythmdb:rbbootstrap + + vala-gen-introspect rhythmdb rhythmdb should be using 'pkg-config --variable=vala_gen_introspect vala-1.0' to locate vala-gen-introspect, and the same for the other vala tools.
(In reply to comment #11) > #define RHYTHMDB_ENTRY_TYPE_IGNORE (rhythmdb_entry_ignore_get_type ()) > +#define RHYTHMDB_ENTRY_TYPE_INVALID (GINT_TO_POINTER (0)) > > why is this change necessary? why is vala unable to handle -1? Vala tool (gobject introspection) is calling glib's "g_module_symbol" to get a handle on the type. Snippet from vala's gobject code (scanner.c): ... if (!g_module_symbol (module, symbol_name, (gpointer *) & type_fun)) return FALSE; type_id = type_fun (); type_fundamental = g_type_fundamental (type_id); ... this results in a segfault when the "g_type_fundamental" call is made on -1 Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7595107 in IA__g_type_fundamental (type_id=18446744073709551615) at gtype.c:3682 3682 in gtype.c (gdb) where
+ Trace 222520
(gdb) printf "%d\n", type_id -1 When set to zero, the g_module_symbol call before it returns false and it skips over it. RE: Single namespace - OK good - will simplify / cleanup things a lot.
WIP latest version of the bindings generation script + support files added. Needs the aforementioned two RB updates applied to run. Still more work to do, the vapi-gen tools are still quite young.
Created attachment 164726 [details] [review] Vala bindings gen script v4
First version with autotools integration after nice 0.13.0 headers installation update. "make install" now installs a single rhythmbox.vapi and .deps in the appropriate vala locations. Notes in second attached file so I don't poop all over bugzilla again.
Created attachment 165200 [details] [review] Vapi generation + autotool integration
Created attachment 165201 [details] Notes concerning vg5 patch for vapi generation + autotools integration
*** Bug 623519 has been marked as a duplicate of this bug. ***
Created attachment 165241 [details] [review] V6 of autogeneration and auto-tools integration V6 (Hopefully) fixes issues seen when compiling the rbpitch plugin against the generated VAPI. Previous notes apply, but still needs execute permission set on generate_vapi.sh - I'm guessing this is a security feature.... Changes from v5 are: * Explicit bash usage * Exposing play/stop on RBShellPlayer * Exposing player property on RBShellPlayer to allow determining if backend is playing via Player.playing property * Stop RBShellPlayer.playing being exposed - it's a method for dbus. Making all interfaces have a GLib.Object pre-requisite
bump / +1 for having this reviewed and/or committed... this patch (V6) satisfies a need for Vala bindings that my plugin depends on.
Review of attachment 165241 [details] [review]: Don't put version history information inside version controlled files. There is no reason for generate_vapi.sh to have its own version number. ::: bindings/vala/supportfiles/rb/rb.metadata @@ +2,3 @@ +# +# Dont use single token lines in this file - there is a bug in VAPIGEN +# that provokes a GLib.CRITICAL in split - put hidden="0" on the end of a line. what is the bug number for this bug in vapigen? @@ +26,3 @@ +# all GLib.Values are rewritten as Gst.Value as they have the +# same cname for the gobject type. +# They are manually specified inside the rb-custom.vala file instead. what is the bug number for this vapigen issue? @@ +67,3 @@ +RB_METADATA_FIELD_TRACK_NUMBER hidden="0" +RB_METADATA_FIELD_TRACK_PEAK hidden="0" +RB_METADATA_FIELD_VERSION hidden="0" ugh, do we really need to list each value here? ::: bindings/vala/supportfiles/rhythmdb/rhythmdb-custom.vala @@ +21,3 @@ + public void shutdown (); + [CCode (cname = "rhythmdb_start_action_thread")] + public void start_action_thread (); these shouldn't be in here at all. ::: bindings/vala/supportfiles/rhythmdb/rhythmdb.files @@ +7,3 @@ +rhythmdb/rhythmdb-query-results.h +# Dont use the header for query model - it pulls in the RbTreeDrag stuff +# which can't be hidden for the moment by vapigen .metadata how is this going to be resolved? ::: bindings/vala/supportfiles/rhythmdb/rhythmdb.metadata @@ +21,3 @@ +RhythmDBEntry.album hidden="0" +RhythmDBEntry.album_artist hidden="0" +RhythmDBEntry.album_artist_sortname hidden="0" RhythmDBEntry is an opaque type. None of its fields should be visible. @@ +170,3 @@ +# These guys appear as const strings when visible +# they will be hidden for now until it can be +# looked into further they *are* const strings. what's the problem? @@ +238,3 @@ +# which has a bug that doesn't allow # +# hidden="1" on them and the generation # +# fails if we don't show them. # what is the bug number for this vapigen issue? @@ +241,3 @@ +# Move them to hidden="1" once vapigen # +# allows us to hide callbacks and interfaces # +############################################## er.. they have hidden="1" already?
Created attachment 165399 [details] [review] simplified generate_vapi.sh, moved some files around This does not address any of my comments from the previous version. I removed the --expose-internals flag and the metadata files for it because I don't want people doing that.
Created attachment 165410 [details] [review] a few more fixes now cleans up the partial .vapi files and includes rhythmbox-uninstalled.pc.in
Cheers for taking the time to have a look and for cleaning it up some, too. (In reply to comment #22) > Don't put version history information inside version controlled files. There > is no reason for generate_vapi.sh to have its own version number. Yep sorry about that, was just intended for while the files were not under version control. >> I made various scattered remarks regarding vapigen bugs and you said: > what is the bug number for this bug in vapigen? I'll create bugzilla bugs for the ones I haven't done so far. Would you prefer I reference them in the source or in a single specific file? Also - would you like them added as a "depends" for this bug? (I don't think any are currently blockers for the auto-generation, but you may feel differently). > +RB_METADATA_FIELD_VERSION hidden="0" > > ugh, do we really need to list each value here? > It's possible to avoid this by removing them from the hideables file. This would unfortunately stop any "auto-hide" functionality from generating a symbols file. I thought it was useful to preserve the ability to "turn off and turn on" individual symbols so I've left it like it is for the moment. >> DB.load and other utility methods > these shouldn't be in here at all. I originally intended just to put them in the .metadata.internal files for my testing but due to the naming conflicts with RhythmDB it's impossible to "hide" or "unhide" them. If your updates to the patch hasn't got rid of them entirely, I will do it for my next update. > +rhythmdb/rhythmdb-query-results.h > +# Dont use the header for query model - it pulls in the RbTreeDrag stuff > +# which can't be hidden for the moment by vapigen .metadata > > how is this going to be resolved? Good question. Don't know of a proper "fix" for the moment. I decided to define QueryResults "manually" inside the *-custom.vala. Looking at the Vala bindings for various packages, this isn't an unusual approach for problematic chunks. > > ::: bindings/vala/supportfiles/rhythmdb/rhythmdb.metadata > @@ +21,3 @@ > +RhythmDBEntry.album hidden="0" > +RhythmDBEntry.album_artist hidden="0" > +RhythmDBEntry.album_artist_sortname hidden="0" > > RhythmDBEntry is an opaque type. None of its fields should be visible. Will do. > @@ +170,3 @@ > +# These guys appear as const strings when visible > +# they will be hidden for now until it can be > +# looked into further > > they *are* const strings. what's the problem? This was kind of a reminder to myself to ask one of the Rhythmbox devs if exposing them is intentional and correct. I'll expose them in my next update. > @@ +241,3 @@ > +# Move them to hidden="1" once vapigen # > +# allows us to hide callbacks and interfaces # > +############################################## > > er.. they have hidden="1" already? Yeah, probably something that fell to the side a little. I'm afraid I've focused more on the process than individual generation details for the moment. For reference, I have also got the following outstanding issues with this tooling: * Dependency on shell/.libs/librhythmbox-core.so inside the *.metadata.in is non-portable This can be resolved by inspecting the libtool .la file and finding the dlopen line to determine the real library to pass in the "{NAMESPACE}/{NAMESPACE}.files" * hardcoded path to bash in the script is non-portable * sed usage is non-portable * sort usage is non-portable * awk usage in non-portable The above was discovered by attempting the build on OpenBSD. I haven't progressed any further than discovering these for the moment. I'm hoping most of them can be fixed by using the autotooling properly and/or reading up on proper POSIX use of them. I'll see what I can fix before the end of the week and submit it as a V8 (given your most recent cleanup as V7). As an aside, I'm in the process of moving countries end of this month, so it may go a bit quiet for a little while.
Created attachment 165571 [details] [review] V8 of generation + autotools integration. This should hopefully resolve some of the current outstanding issues list. * Portability issues fixed, build/install on OpenBSD working now * Bugzilla bugs noted in source plus in included file BUGS.txt * Issue with rhythmdb-query-results being defined in rhythmbox-custom.vala For now I've (ab)used the patching of the .gi file to "fix" the problems with RbTree and as such RhythMDBQueryModel works much like other introspected objects. * Still outstanding: (1) Running a "make dist" fails if the target vapi file has not been generated yet. (2) When the Vala version used is < 0.8.0 the error message is "Vala wasn't found"
I've just pushed my changes to convert RhythmDBEntryType into a GObject, so this will need to be updated.
Created attachment 167169 [details] [review] V9 of autotools integration that can be applied against 0_13_0 source tree Bug fix to the v8 patch - was missing bootstrap .vapis due to .gitignore fun. This patch is _only_ intended for the 0_13_0 version of Rhythmbox and will not work against HEAD (I'll look at that next). Note: To apply the patch against a source release of Rhythmbox 0_13_0 you will need to patch using: git apply vg9auto0_13_0.patch --exclude .gitignore As a source release doesn't include .gitignore files (of course) and the patch will fail otherwise.
Created attachment 167403 [details] [review] Install rhythmdb-entry.h when make install is run
Created attachment 167404 [details] [review] VG10 Vala bindings against latest rhythmdb-entry-type refactoring This patch has 167403 patch as pre-requisite. Takes into account the refactoring of the rhythmdb-entry-type to be a real GObject. Outstanding: * Make dist fails still if target not yet built due to sample-vala plugin attempting to build itself * When required valac version not met error message is inappropriate * Does not yet take into account recent changes concerning entry availability Quick compatibility test with rbpitch out-of-tree compilation successful. I'm having a play to see if I can get the sample-vala plugin to demonstrate the functionality currently listed on the developing plugins page (with the updates made since then, of course)
Comment on attachment 167403 [details] [review] Install rhythmdb-entry.h when make install is run pushed as commit 5cd556d
Created attachment 167844 [details] [review] Include podcase_entry_types during make install / dist Discovered during investigation of make dist issues with plugins/vala-sample For info, make dist fails without the source being built anyway as the gtk-doc stuff needs the built artifacts. Perhaps it can be left as-is for now? I will focus my energy on valac version message and incorporating the availability changes.
Created attachment 168142 [details] [review] Rhythmbox Vala Bindings Generation Patch V11 Includes: * Reworking of autoconf detection of Vala and related tooling Needed to support Vala 0.9.5 - vala maintainer explains projects shouldn't use pkgconfig. Changes are compatible (and tested) with 0.8.0 onwards. * Exposes more methods + objects needed for plugins I took a quick drive around the "building Rhythmbox plugins" page and have started to expose the methods and objects mentioned. I have my test plugin that exercises them, but it's a mess for the moment so haven't included it. It should probably be a separate patch, anyway. * Includes "hideables" for availability changes (not currently exposed) Outstanding bugs: * As mentioned, make dist fails if rhythmbox.vapi hasn't been built yet * rhythmbox-uninstalled.pc.in gets installed in the pkg_config directory....
Comment on attachment 167844 [details] [review] Include podcase_entry_types during make install / dist pushed as commit 828c32d, thanks
(In reply to comment #33) > Outstanding bugs: > > * As mentioned, make dist fails if rhythmbox.vapi hasn't been built yet If this means we need vala enabled for dist, that's OK. We already require gtk-doc to be enabled too. > * rhythmbox-uninstalled.pc.in gets installed in the pkg_config directory.... Just remove it from pkgconfig_DATA. This patch doesn't include rb/rhythmdb.vapi or rhythmdb/rb.vapi, so it doesn't build at all.
Created attachment 168183 [details] [review] Rhythmbox Vala Bindings Generation Patch V12 * Fix missing vapis - forgot to pull a .gitignore change * Stopped rhythmbox-uninstalled.pc being installed in pkgconfig dir * Updated generate_vapi.sh script to take advantage of vapigen with symbol generation support (see https://bugzilla.gnome.org/show_bug.cgi?id=627033) * Includes ERRORS.txt as quick start guide to tracing problems * Includes latest generated hideables.in file as a stopgap Patch applied and tested against HEAD (18 aug 2010).
Created attachment 168282 [details] [review] Remove duplicate defn for entry_get_playb_uri Actual definition exists in rhythmdb/rhythmdb-entry-type.h
Created attachment 168283 [details] [review] Rhythmbox Vala Bindings Generation Patch V14 Updated patch to build against latest HEAD updates to git vapi: All installed Rhythmbox C header files are now read in by the Vapi generation tool. The following headers are currently commented out due to vapigen being unable to hide interfaces: rb-encoder.h rb-player-gst-data-tee.h rb-player-gst-tee.h Note: I'm not sure if it's ready for mainline merge yet * I haven't performed a proper pass on the existing artifacts to check for "owned/unowned" and as such memory leaks probably exist in here. Would be nice to get some other eyes over it to help here. * I notice that the current git vapi has more features than the vapi this tool generates.
Comment on attachment 168282 [details] [review] Remove duplicate defn for entry_get_playb_uri pushed as commit 1a5afa0, thanks
Created attachment 168525 [details] [review] Give ShellError enum a typedef and name for introspection
Created attachment 168527 [details] [review] Rhythmbox Vala Bindings Generation Patch V15 Lots of object updates after looking at g-i branch and getting the signatures looking vaguely like those (with some edits). Still outstanding: * Problem with owned_get All properties containing GObjects are defaulted by vapigen to "owned get" with no way to turn it off (.metadata doesn't do it so it might have to be post-processing) * Enums RBMetadataErrorType and RBMetadataFieldType I suspect these are for DBus? I haven't included them as they duplicate the existing enums. * Rhythmbox Dev Pass Of course, it still needs a Rhythmbox Dev to perform a pass over them - there are probably lots of artifacts that shouldn't be visible.
Note: Feedback from on #vala (thanks Michal) tells me the "owned_get" is correct - g_object_get should always return an object that will need to be "free"d. This means the owned_get="0" in the .metadata.in files will dissapear.
Created attachment 168556 [details] [review] Rhythmbox Vala Bindings Generation Patch V16 Patch has attachment 168525 [details] [review] as pre-requisite. I think this might be a good version to review. Changes: * Bumped minimum vala version needed to 0.9.3 for needed type_arguments fix * Removed owned_get="0" as mentioned * Did a pass on ** arguments to check in the source if they are out parameters or arrays * Make a "full" hideables.in file when using a symbol file output vapigen (useful as a reference of symbol names) * Due to above, patch includes full symbol list in the *.hideables.in files * Removed some Rhythmbox internal methods (db.load/shutdown/startthread playlistmanager.get_playlists) * Updated with RBShellPreferences changes for widgets * Included a TODO.txt file to track any ongoing work
Comment on attachment 168525 [details] [review] Give ShellError enum a typedef and name for introspection pushed a version of this adding a GEnum type for RBShellError as commit 914080c
Created attachment 169843 [details] [review] Rhythmbox Vala Bindings Generation Patch V17 * sample-vala-plugin: correctly depend on vapi generation - modifications to the vapi cause the plugin to be re-compiled * sample-vala-plugin: added in necessary makefile magic to allow vala intltool bits inside the vala code (not added but tested in plugin not included in this patch) * rhythmdb.vapi: post-process the vapi to add back the correct cprefix - is needed due to the attribute not being passed through from the rhythmdb-custom.vala definition and setting it in the .metadata.in breaks the generation * RBSourceGroup: fix methods to return unowned variables as class is compact * RBShell.set_notebook_page: let page param be nullable to reset back to default page
Hi, What is the status of this work currently? What is required to move it forward? I am very interested in seeing this pulled into an official release of Rhythmbox, and will help out as needed/able. We currently have a few months-old (possibly stale vs. latest git) patch, that has not been reviewed by a committer (e.g. Jonathan). While this solution may not be the *tidiest* in the world, it gets the job done, and works fabulously for my (external) plugin. Are there stylistic / political reasons holding it back, or are there outstanding technical issues that are actually tractable without throwing out the whole work and starting over from scratch? If the latter, please list the remaining technical issues as precisely as is practical, to make it easier for me to understand what I have to do to get this committed to master and thus on track for a release. Why do I care so much about getting it into a release? Easy: distros that pick up that release will (hopefully, if they package things right) ship with built-in support for external Vala plugins for Rhythmbox, maybe just requiring the install of an optional package. But since very few distros maintain or are willing to maintain a significant patch set against the core of Rhythmbox (plugins are a different story), this won't happen until it is in a tagged release. Having a version of Rhythmbox with this support out in the wild will, in time, make it as casual for end-users to install external Vala plugins as it currently is for installing external Python plugins (i.e., no need to rebuild all of Rhythmbox and any other custom plugins they may have). Thanks for your time.
I find vala annoying and tedious to work with, so when I'm deciding what to do with what little time I have to work on rhythmbox, it's not a high priority. It also means I'm not very interested in adding language specific bindings code when we're pretty close to having gobject introspection working.
@46 - Hi Sean, Sorry I've let the patch slide into staleness. I figured due to the lack of interest that the devs were heading in the gobject direction. Such is life. When I get some time I'll try and update the patch to apply against a recent static snapshot. Sadly that will be all the time I'll get to work on this, as I've moved my personal development target elsewhere.
Created attachment 177147 [details] [review] Rhythmbox Vala Bindings Generation Patch V18 My last vapigen based Vala bindings generation patch. Should be applied to the git tag v0.13.2. e.g. # git checkout v0.13.2 # git checkout -b valabindings0.13.2 # git apply vg18autotools_allrb.patch # ./autogen.sh --enable-uninstalled-build --enable-vala Generates bindings for a big chunk of Rhythmbox artifacts (some internal stuff too for which C header files are not installed with "make install".) Putting it up just in case anyone wants to play with it.
Comment on attachment 177147 [details] [review] Rhythmbox Vala Bindings Generation Patch V18 Marked obsolete - rhythmbox has moved to GI for plugin bindings. Maybe you want to mark the whole bug obsolete too?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/935.