Re: [Rhythmbox-devel] Rhythmbox And Vala - Questions:

[Sriram Ramkrishna <sri ramkrishna me>]

On Mon, Jun 28, 2010 at 4:03 PM, Sean McNamara <smcnam gmail com> wrote:

> The Rhythmbox plugins were a port of the gedit plugin system, couldn't we
> just not move Rhythmbox to use libpeas, like it was done for Totem?  I was
> under the assumption that libpeas can do all this stuff already.

Sounds good, but:

*libpeas does not (yet) have Vala support -- although it's in their todo list.
*This still doesn't automatically define for us an explicit plugin
API. Defining the plugin API must be done by hand, by choosing the
functions in rb-core that need to be exposed to plugins, while leaving
out the ones that don't. If the rb-core were engineered in such a way
that we could reliably determine visibility modifiers for all the
existing functions (at least: public, private, protected, as defined
in Java or Vala), we might just say "export all the public functions".
But is this really true? I haven't exhaustively checked to see if it
is this easy. Obviously, we can't export static functions; that's a
given. But do we need to expose all the non-static functions to
plugins?

Good catch.  So it looks like we need to do two things.  One, libpeas needs to support vala, and I'm not sure how to get that working myself.  The second one is picking the private/public.  It looks like we will still have to do go through the exercise on figuring what is what.  For the most part, at least in rhythmdb, the parts that are public are usually got some kind of gtk-doc tags in it.  Can't say for the ui parts.

 

It seems libpeas more or less does what I was envisioning anyway. But
we still have to do the work to support it, and I think that includes
defining (or at least *documenting*) which internal RB functions
should be available to plugins, and which not.

Yep.  libpeas is probably the way to go, just need to generate a patch and a bug.

sri