Re: Plugin System



On Mon, Sep 22, 2003 at 02:08:51PM -0700, Bob Smith wrote:
> 
> Something like, I copy my foo.dll mono plugin into the plugin directory,
> then I must execute something like "go_mono_register foo.dll" to
> register the plugin with the plugin system. In the current
> implementation, go_mono_register would generate a plugin description xml
> file from the dll.

This seems like the best course of action for the 'self describing'
use case you've mentioned.  Its tempting to take things one step
beyond that and have a
    gdk-pixbuf-query-loaders
type file for a set of directories that might contain plugins.  That
would remove the need to both searching for files at startup.
However, that might be gilding the lily.

> Its basically a ghost object for a service. It looks and works just like
> the service, but doesn't actually load the plugin that its ghosting
> until its actually used. This would require one proxy object per service
> type. Since apps are free to implement their own service types, I don't
> think we should make it a requirement for them to provide proxy object
> implementations since most apps wont ever use them.

Agreed.  The use of proxies should be entirely optional.

> I've still got to explore your idea of using the accessibility api for
> scripting though. I've played a bit with it, and I think it might work.
> The one thing that I saw though, is that it appears that it makes things
> very dependent on the layout of the app. If you change the GUI then the
> scripts wont work any more. Also, while not as important for GNOME, it
> wouldn't work nicely with nongui apps.

I reached pretty much the same conclusion.  We'll be able to hook
into the gtkUIManager actions for some of the raw 'make menu do foo'
operations.  However, a real scripting api will involve more
application specific objects the decent methods, atk and gtk are not
going to operate on that level.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]