On Tue, 2003-09-30 at 13:29, Rodrigo Moya wrote: > On Tue, 2003-09-23 at 22:10 -0700, Bob Smith wrote: > > Rodrigo mentioned scripting plugins. Having embeded a lot of languages > > into my apps over time, I tend to agree with Jody. The scripting engine > > is an insignificant part of code. > > > well, that's what I mean, to just share the scripting service types, and > the implementations based on a given language. If you look at the code > in gnome-office, I was trying to keep the scripting service as generic > as possible, with just a few methods to execute code. Scenario. Say I write a plugin loader written using R. An R plugin for the GO plugin system would need to be written. At the same time, say the application wanted to support plugins written in R. If it had a separate implementation, there would be a problem with Rf_initEmbeddedR. It should always be called before using R, but only called once. Same with finalizing R. So I guess some types of plugins will have to be shared. Hmm... Say you wanted to have a library that supported its own plugins. Say, libgda. Libgda would need to add its plugin dirs to the plugin manager. Gnumeric might not want to know directly about libgda's plugins, so we need to either support querying by plugin types, or maybe something simpler... Should we do something like, associate a set of dirs with a name, and then query for plugins by that name? Like, "gnumeric" looks for plugins in "/usr/lib/gnumeric/plugins" and "~/.gnumeric/plugins". On the other hand, this would be very similar to having multiple plugin managers in an app. > > That's what we can share, since I can't find a reason for having the > embedded interpreter for, say, Mono, Perl, Python, etc re-implemented in > each app. Providing the basics of the scripting engine in a common place > gives scripting support to all apps. > > > Unless I can see good evidence that > > you can do most of the stuff you want from the accessibility api, this > > is not enough to make me believe that the plugin library should be > > oriented around a global plugin dir. > > > why not have a common place for looking for plugins, but give users the > choice to disable looking in that dir? > Yeah. We could have something like "/usr/lib/gnome-office/plugins/" where such plugins are stored. That would make sharing plugins easy. > cheers > cheers > _______________________________________________ > gnome-office-list mailing list > gnome-office-list gnome org > http://mail.gnome.org/mailman/listinfo/gnome-office-list -- Bob Smith <bob thestuff net>
Attachment:
signature.asc
Description: This is a digitally signed message part