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

[Sean McNamara <smcnam gmail com>]

Hi,

On Mon, Jun 28, 2010 at 10:38 AM, Sriram Ramkrishna <sri ramkrishna me> wrote:
>
>
> On Mon, Jun 28, 2010 at 6:52 AM, Sean McNamara <smcnam gmail com> wrote:
>>
>> To elaborate: my favored method would be to keep the linkage of
>> plugins completely separate from the core. So you would have a shared
>> library, librhythmbox-plugins (or something like that), which contains
>> RBPlugin and related classes, plus a carefully determined exposure of
>> the rb-core internals. If necessary, we could bump the plugin API
>> <snip..>
>> unfortunately a case of open source laziness, where I did just enough
>> hacking on the bindings to get them to work with software I was
>> developing to consume them. Now, I'm glad I didn't bind the entire
>> rb-core, because your automatic generation probably does a better job
>> of that than I ever could.
>>
>> Auto-generation sounds like the way forward, as far as Vala bindings
>> in general. As long as everything we need is a GObject, introspection
>> should reliably give us what we need. If vapigen is not working for
>> you yet, I say give it time, and wait until it is generally useful
>> without many hacks. It is still in heavy development, so it may not be
>> an ideal tool until ptitjes or others improve it.
>>
>
> 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?

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.

Sean

>  I think
> we'll be able to add javascript to the list of plugin languages Rhythmbox
> can support.  That makes rhythmbox extensions available for gnome-shell.
> For those not familiar with libpeas, feel free to read:
> http://log.istique.net/2010-06-03/announcing-libpeas.html
> sri
>