Re: Patch: Pluggable module loaders and demo loader

Hi Martin,

i looked at your code briefly and try to answer to the best of my
knowledge. Don't do me any harm if i'm way off.

Am Donnerstag, den 03.02.2005, 15:48 +1100 schrieb Martin Sevior:
[...]
> Hi Robert,
> This sound like it is just what I wanted for the GtkMathView
> but let me see if I understand....
>
> What I want is a way register a plugin that can then create a new class
> linked to gtkMathView, without gtkmathview being linked to the plugin.

Why should the plugin /not/ be linked to gtkmathview? I thought the goal
was to not link abi itself but the plugin.

> GtkMathView is quite a large program and I would really rather only load
> it, if it is actually needed for some maths.
>
> Right now I have a method..
>
> GR_EmbedManager * GR_MathManager::create(GR_Graphics * pG)
> {
> return static_cast<GR_EmbedManager *>(new GR_MathManager(pG));
> }
>
> GR_MathManager is linked against GtkMathView.
>
> With this new code is it possible to have a method..
>
> GR_Embedmanager * GR_DummyMathManager::create(GR_Graphics * pG)
> {
> if(mathManagerUnloaded())
> {
> loadMathManager();
> return static_cast<GR_EmbedManager *>(getMthManager()-
> >create(pG));
> }
> return static_cast<GR_EmbedManager *>(getMathManager()->create(pG));
> }
>
> What would loadMathManager() look like?
> My vision is that getMathManager() would return a GR_MathManager *
> pointer cast to GR_EmbedManager.

I would offhand suggest a somewhat different approach but i must admit
that the code snippet you posted doesn't mean much to me (i'm missing
the context probably). I do however think that there are similarities in
terms of "architecture" between rendering plugins and plugin factories.

GR_EmbedManager seems to be the Singleton that manages "renderers" (like
the mathml one). If so it would be very similar to XAP_ModuleManager and
could offer
    GR_EmbedManager {
        bool registerRenderer (RenderPluginHook*);
        bool unregisterRenderer (RenderPluginHook*);
    };
for plugins to hook in (uninitialized) renderers.

class RenderPluginHook {
    const char * getMimeType (); // so GR_EmbedManager can decide
which plugin to use
    RenderPluginBase * getRenderer (); // costly instantiation of
renderer only if needed
};

RenderPluginInterface could be the the common base class for all
renderers and declare a common interface.

class RenderPluginInterface {
    // all virtual interface methods
};

Your mathml renderer would be a subclass of RenderPluginBase.

class RenderPluginDefault {
    // implements common snapshot functionality
};

I'm aware that such an approach would require quite some refactoring.
Maybe it is however noteworthy that my first attempt at plugin factories
also mixed "manager functionality" and "managed functionality" in
XAP_ModuleManager. Now i'm working towards splitting the default plugin
loader out of the Manager and make it behave exactly like a plugin. The
only difference is that "for some reason" it is instantiated with the
Manager and used as a fallback if none of the hooked factories "bites".

Maybe you would like to try a similar approach for your rendering
plugins, where the default renderer (which only shows snapshots) has
some wildcard mimetype and therefore renders all the snapshots if there
was no plugin before in the chain that rendered the content.

If you would like to discuss further, i'm in #abiword today.
Best,
- Rob
Received on Thu Feb 3 11:07:13 2005