After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 621246 - Vala bindings incomplete
Vala bindings incomplete
Status: RESOLVED OBSOLETE
Product: rhythmbox
Classification: Other
Component: Plugins (other)
unspecified
Other Linux
: Normal normal
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
: 621504 623519 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-06-10 20:44 UTC by Michal Hruby
Modified: 2018-05-24 15:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Autogenerated vapi files (80.08 KB, patch)
2010-06-10 20:44 UTC, Michal Hruby
none Details | Review
Patch with script to generate the bindings (5.22 KB, patch)
2010-06-10 20:45 UTC, Michal Hruby
none Details | Review
Two Rhythmbox updates needed for Vala tools (1.15 KB, patch)
2010-06-16 15:09 UTC, Daniel Hams
reviewed Details | Review
latest vapigen scripts for generating .vapi (498.80 KB, patch)
2010-06-16 15:10 UTC, Daniel Hams
needs-work Details | Review
Sample vapis from latest generation tool (10.19 KB, application/x-bzip)
2010-06-16 15:12 UTC, Daniel Hams
  Details
Vala bindings gen script v4 (102.36 KB, patch)
2010-06-27 02:33 UTC, Daniel Hams
none Details | Review
Vapi generation + autotool integration (108.10 KB, patch)
2010-07-03 22:37 UTC, Daniel Hams
none Details | Review
Notes concerning vg5 patch for vapi generation + autotools integration (2.83 KB, text/plain)
2010-07-03 22:38 UTC, Daniel Hams
  Details
V6 of autogeneration and auto-tools integration (108.78 KB, patch)
2010-07-04 20:09 UTC, Daniel Hams
needs-work Details | Review
simplified generate_vapi.sh, moved some files around (100.07 KB, patch)
2010-07-07 06:23 UTC, Jonathan Matthew
needs-work Details | Review
a few more fixes (100.82 KB, patch)
2010-07-07 09:14 UTC, Jonathan Matthew
needs-work Details | Review
V8 of generation + autotools integration. (102.71 KB, patch)
2010-07-09 17:48 UTC, Daniel Hams
none Details | Review
V9 of autotools integration that can be applied against 0_13_0 source tree (104.89 KB, patch)
2010-08-05 09:19 UTC, Daniel Hams
none Details | Review
Install rhythmdb-entry.h when make install is run (709 bytes, patch)
2010-08-09 08:10 UTC, Daniel Hams
committed Details | Review
VG10 Vala bindings against latest rhythmdb-entry-type refactoring (104.56 KB, patch)
2010-08-09 08:15 UTC, Daniel Hams
none Details | Review
Include podcase_entry_types during make install / dist (704 bytes, patch)
2010-08-13 21:09 UTC, Daniel Hams
committed Details | Review
Rhythmbox Vala Bindings Generation Patch V11 (90.20 KB, patch)
2010-08-17 21:44 UTC, Daniel Hams
none Details | Review
Rhythmbox Vala Bindings Generation Patch V12 (96.10 KB, patch)
2010-08-18 09:52 UTC, Daniel Hams
none Details | Review
Remove duplicate defn for entry_get_playb_uri (887 bytes, patch)
2010-08-19 11:55 UTC, Daniel Hams
committed Details | Review
Rhythmbox Vala Bindings Generation Patch V14 (110.04 KB, patch)
2010-08-19 12:03 UTC, Daniel Hams
none Details | Review
Give ShellError enum a typedef and name for introspection (928 bytes, patch)
2010-08-22 22:04 UTC, Daniel Hams
committed Details | Review
Rhythmbox Vala Bindings Generation Patch V15 (129.43 KB, patch)
2010-08-22 22:09 UTC, Daniel Hams
none Details | Review
Rhythmbox Vala Bindings Generation Patch V16 (169.27 KB, patch)
2010-08-23 12:37 UTC, Daniel Hams
none Details | Review
Rhythmbox Vala Bindings Generation Patch V17 (173.54 KB, patch)
2010-09-09 12:03 UTC, Daniel Hams
none Details | Review
Rhythmbox Vala Bindings Generation Patch V18 (207.68 KB, patch)
2010-12-28 16:47 UTC, Daniel Hams
none Details | Review

Description Michal Hruby 2010-06-10 20:44:19 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.
Comment 1 Michal Hruby 2010-06-10 20:45:21 UTC
Created attachment 163331 [details] [review]
Patch with script to generate the bindings
Comment 2 Daniel Hams 2010-06-14 07:41:08 UTC
*** Bug 621504 has been marked as a duplicate of this bug. ***
Comment 3 Daniel Hams 2010-06-14 08:23:16 UTC
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.
Comment 4 Jonathan Matthew 2010-06-14 08:35:29 UTC
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.
Comment 5 Daniel Hams 2010-06-16 15:07:20 UTC
> 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.
Comment 6 Daniel Hams 2010-06-16 15:09:28 UTC
Created attachment 163834 [details] [review]
Two Rhythmbox updates needed for Vala tools
Comment 7 Daniel Hams 2010-06-16 15:10:41 UTC
Created attachment 163835 [details] [review]
latest vapigen scripts for generating .vapi
Comment 8 Daniel Hams 2010-06-16 15:12:41 UTC
Created attachment 163836 [details]
Sample vapis from latest generation tool
Comment 9 Michal Hruby 2010-06-16 18:09:00 UTC
@Daniel: Why is there substitution of xmlNodePtr to char? It should be 'xmlNodePtr' -> 'xmlNode*'.
Comment 10 Daniel Hams 2010-06-16 20:01:57 UTC
Oops. Copy pasta leeks through.

Thanks.
Comment 11 Jonathan Matthew 2010-06-22 04:47:26 UTC
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?
Comment 12 Jonathan Matthew 2010-06-22 04:54:29 UTC
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.
Comment 13 Daniel Hams 2010-06-22 08:07:39 UTC
(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
  • #0 IA__g_type_fundamental
    at gtype.c line 3682
  • #1 g_igenerator_process_module_symbol
    at scanner.c line 562

(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.
Comment 14 Daniel Hams 2010-06-27 02:32:00 UTC
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.
Comment 15 Daniel Hams 2010-06-27 02:33:20 UTC
Created attachment 164726 [details] [review]
Vala bindings gen script v4
Comment 16 Daniel Hams 2010-07-03 22:36:08 UTC
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.
Comment 17 Daniel Hams 2010-07-03 22:37:15 UTC
Created attachment 165200 [details] [review]
Vapi generation + autotool integration
Comment 18 Daniel Hams 2010-07-03 22:38:28 UTC
Created attachment 165201 [details]
Notes concerning vg5 patch for vapi generation + autotools integration
Comment 19 Jonathan Matthew 2010-07-04 12:14:33 UTC
*** Bug 623519 has been marked as a duplicate of this bug. ***
Comment 20 Daniel Hams 2010-07-04 20:09:41 UTC
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
Comment 21 Sean McNamara 2010-07-06 07:25:45 UTC
bump / +1 for having this reviewed and/or committed... this patch (V6) satisfies a need for Vala bindings that my plugin depends on.
Comment 22 Jonathan Matthew 2010-07-07 06:18:55 UTC
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?
Comment 23 Jonathan Matthew 2010-07-07 06:23:12 UTC
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.
Comment 24 Jonathan Matthew 2010-07-07 09:14:52 UTC
Created attachment 165410 [details] [review]
a few more fixes

now cleans up the partial .vapi files and includes rhythmbox-uninstalled.pc.in
Comment 25 Daniel Hams 2010-07-07 09:40:16 UTC
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.
Comment 26 Daniel Hams 2010-07-09 17:48:07 UTC
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"
Comment 27 Jonathan Matthew 2010-08-03 06:00:45 UTC
I've just pushed my changes to convert RhythmDBEntryType into a GObject, so this will need to be updated.
Comment 28 Daniel Hams 2010-08-05 09:19:47 UTC
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.
Comment 29 Daniel Hams 2010-08-09 08:10:00 UTC
Created attachment 167403 [details] [review]
Install rhythmdb-entry.h when make install is run
Comment 30 Daniel Hams 2010-08-09 08:15:29 UTC
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 31 Jonathan Matthew 2010-08-09 08:31:26 UTC
Comment on attachment 167403 [details] [review]
Install rhythmdb-entry.h when make install is run

pushed as commit 5cd556d
Comment 32 Daniel Hams 2010-08-13 21:09:31 UTC
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.
Comment 33 Daniel Hams 2010-08-17 21:44:00 UTC
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 34 Jonathan Matthew 2010-08-18 05:28:29 UTC
Comment on attachment 167844 [details] [review]
Include podcase_entry_types during make install / dist

pushed as commit 828c32d, thanks
Comment 35 Jonathan Matthew 2010-08-18 05:41:39 UTC
(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.
Comment 36 Daniel Hams 2010-08-18 09:52:45 UTC
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).
Comment 37 Daniel Hams 2010-08-19 11:55:57 UTC
Created attachment 168282 [details] [review]
Remove duplicate defn for entry_get_playb_uri

Actual definition exists in rhythmdb/rhythmdb-entry-type.h
Comment 38 Daniel Hams 2010-08-19 12:03:14 UTC
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 39 Jonathan Matthew 2010-08-22 03:16:33 UTC
Comment on attachment 168282 [details] [review]
Remove duplicate defn for entry_get_playb_uri

pushed as commit 1a5afa0, thanks
Comment 40 Daniel Hams 2010-08-22 22:04:56 UTC
Created attachment 168525 [details] [review]
Give ShellError enum a typedef and name for introspection
Comment 41 Daniel Hams 2010-08-22 22:09:43 UTC
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.
Comment 42 Daniel Hams 2010-08-22 22:21:46 UTC
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.
Comment 43 Daniel Hams 2010-08-23 12:37:12 UTC
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 44 Jonathan Matthew 2010-08-28 08:38:19 UTC
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
Comment 45 Daniel Hams 2010-09-09 12:03:23 UTC
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
Comment 46 Sean McNamara 2010-12-27 03:08:42 UTC
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.
Comment 47 Jonathan Matthew 2010-12-27 07:07:58 UTC
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.
Comment 48 Daniel Hams 2010-12-27 15:57:08 UTC
@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.
Comment 49 Daniel Hams 2010-12-28 16:47:04 UTC
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 50 Daniel Hams 2013-07-01 07:32:32 UTC
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?
Comment 51 GNOME Infrastructure Team 2018-05-24 15:20:03 UTC
-- 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.