[sldev] Plugin system - first code drop

[Tim Shephard]

Ahh, not so much looking for a full patch.. just perhaps an example of
how you're doing this and what your thoughts are.

The key, I think, is to make sure that the plugin developer has to do
as little work as possible and that we add minimal technical risk to
the client in use today.   APIs are successful when they're clear,
well documented, simple to use, and don't add to general system
complexity.

When I mentioned the floater proxy, I didn't mean inheritance across
DLLs.  Inheritance across DLLs would be the exactly the same as what
you find in the wiki or in Dale's code.

What I'm thinking is something along these lines (rough example):

Basically we extend llFloater with a class called
LLFloaterPluginProxy.   It would roughly be implemented as follows:

LLFloaterPluginProxy::LLFloaterPluginProxy()
:   LLFloater("floater_plugin")
   gUICtrlFactory->buildFloater(this, pluginTable->getXMLSpec());

    listOfCommitCallBacks = pluginTable->getListOfCommitCallBacks();
    loop through listOfEvents
       childSetCommitCallback(list.name, list.function, this);

   .. do for setAction, etc
}

void LLFloaterPluginProxy::show(void*)
{
    sInstance = new LLFloaterProxy();
    sInstance->open();
    pluginTable->plugInProxy();
}

LLFloaterPluginProxy::~LLFloaterPluginProxy()
{
    pluginTable->destruct();
    sInstance=NULL;
}

Basically there would be an instance of LLFloaterPluginProxy for every
plugin floater created.

The advantage of this approach is we don't touch core code, which I
personally think is critical.  Not just for getting merged, but also
to ensure we minimize risk to the client that are not using plugins.

Let me know what you think, Soft.

Cheers,

Tim.

On 2/26/07, Soft Noel <soft at softnoel.org> wrote:
> On Mon, February 26, 2007 4:59 pm, Tim Shephard wrote:
> > Can you post a couple of sample hooks?
> >
> > Are you doing it via a proxy llFloater class?
>
> I'm not ready to drop this code yet. It's still in a gross hack state
> while I'm proving out an approach for myself. I'm also hoping someone will
> try out the class inheritance model (I think that's what you mean by the
> proxy llFloater class), and if I put the hook stuff out there that's less
> likely.
>
> Right now, the hooks are all into viewer-side code that's a regular client
> to the UI classes, creating subscribers as needed. I'm experimenting with
> seeing how much I can make the client-side plugin code self-contained, as
> a huge third-party patch set spidering into every last system will make LL
> balk.
>
>
> > Great energy.  Let me know your secret on how you can afford to spend the
> > time.
>
> Evenings at home with a Costco pallet of Diet Mountain Dew: It actually
> ends up being cheaper than going out or SL clothes-shopping. :)
>
>
>