Hi, On Mon, Jun 28, 2010 at 10:38 AM, Sriram Ramkrishna <s...@ramkrishna.me> wrote: > > > On Mon, Jun 28, 2010 at 6:52 AM, Sean McNamara <smc...@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 > _______________________________________________ rhythmbox-devel mailing list rhythmbox-devel@gnome.org http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
