Re: plugin hook xml format proposal

>From: msevior@physics.unimelb.edu.au
>To: abiword-dev@abisource.com
>Subject: Re: plugin hook xml format proposal
>Date: Thu, 10 Feb 2005 22:55:27 +1100 (EST)

> Hi Robert,
> Sorry for the delay. This is pretty much my vision except a
> point I address below. Go for it :-)
>
> There was similar proposal for the gnome-office plugin system
> but I don;t know if it ever got implemented.

Jody said it would be pretty close, maybe even in cvs now. The problem
is the dependencies (glib, libgoffice) for win32, cocoa. I think i can
come up with a working solution within abi in a few hundred lines of xp
code plus a (very) few dozen lines of platform code.
With the new infrastructure we can implement a loader for gnome-office
plugins anyways. Volunteers?

> This should not happen. Upon creation the fp_MathRun will
> request fl_DocLayout for an EmbedManager to provie it with a
> mathview. The initally loaed plugin (call it fl_DummyMath) would
> then load the full gr_MathManager plugin which in turn would
> create a copy of itself and return that to fl_DocLayout.
>
> (see my little example code earlier.)
> This would only happen if there was Maths in the document
> though. Without maths the full MathManager is never loaed, just
> the lightweight dummy class.

Hi Martin,

now i understand better what you want to do (i hope :). You will
probably like to have 2 .so modules which implement the existing abi
plugin interface. The dummy should go into abi's standard plugin dir and
the gtkmathview-linked one in a subdir probably (as described before
for .xml and .so).

When your dummy needs to load the real math plugin you call
XAP_ModuleManager::instance().loadModule ("path/plugin.so");
but you've probably figured that out already ;-)

For your kind of functionality i'm currently not coding support. But as
soon as my simple stuff works (don't hold your breath) we can talk about
that. Now i'm focused on hacking the "usual" plugin stuff like menu
entries and config dialogs.

I also pasted a commented sample xml description to show what will be
possible after the commit of my stuff. This is the target for now. BTW,
i now have support for multiple builtin as well as plugged loaders. So
everything will stay 100% backwards compatible (i made the existing
loader just another one among the builtin loaders). The lazy loader
should go into abiword itself IMO.

Best,
- Rob

<?xml version="1.0" ?>
<!-- Args of root node are optional
         preload ... shlib is loaded immediately
         factory ... plugin wants to be loaded by an explicitely
                                 named factory
         version ... xml description format version
-->
<abiplugin preload="true" factory="libAbiTestLoader" version="1.0">

        <!-- Metadata, same as XAP_ModuleInfo -->
        <meta name="name" value="Super Module" />
        <meta name="author" value="Foo Bar" />
        <meta name="description" value="No description" />
        <meta name="usage" value="No usage" />
        <meta name="version" value="0.0" />

        <!-- Custom config dialog (optional)
                 only one entry is allowed;
                 title, icon are not used
        -->
        <hook type="config">
                <entry id="1" />
        </hook>

        <!-- Add entries to the "Tools" menu
                 Extensible Menus for now:
                 Edit View Insert Format Tools
        -->
        <hook type="menu" object="Tools">
                <entry id="2" title="Google Search" icon="google.png" />
                <!-- more entries here -->
        </hook>
</abiplugin>
Received on Thu Feb 10 15:13:26 2005