SL Plugin APIDale Glass and I, among apparently others, are beginning the work of developing an API for writing plugins to the SL client. It should prove a challenging, interesting, fun, and immensively beneficial enterprise, espeically if LL decides to roll it into the main source.
The problem with developing for the client right now is that there is no plugin system. You can’t just write a module, include a library, and then fire up your own GUIs and functionality from within SL, because the hooks are not in place. It’s a shame LL didn’t do this yet, but obviously they have more important things to take care of.
So as we were talking about how great plugins would be, we realized we had mostly all the tools and knowledge necessary to let that very thing happen, and that was the birth of the slplugin project.
…which is technically just what I’m calling it. But see? I made a logo and everything:
- missing image -
Hah! It’s all iconic and stuff…
Well anyway, we’re in the process of hashing out all the stuff necessary to get moving. Basically, finding what we need to hook into, what our interface should look like, and how the plugin will tap into that interface.
It looks like our best bet right now is to use compiled SO/DLL plugins incorporating our plugin library that will in turn include (and thus require) the SL client headers. this shouldn’t be a problem obviously. These plugins will then be loaded and managed by a PluginManager? inside the client with which they will register events, load GUIs, and other fun stuff.
What follows is a who’s-who of what we primarily need to deal with
The GUI stuff is mostly painless, we just need to hook into the existing tools for opening floater windows and such. Modifying GUI elements that already exist would be considerably harder, since we’d have to abstract out the XML files defining the GUI and the app that creates the GUI using that file. Doesn’t sound easy.
A better route would probably be to encapsulate all the code that passes XML files in to create GUIs, then allow plugins to suppress elements and generate their own in place.
But the task of simply opening new floaters from plugins seems pretty easy.
The other major hurdle involved in making GUIs is the registration of events. We need to likewise make these dynamic, overrideable, and accessible to the plugin API.
The chat, IM, and other such interfaces should be fairly straightforward to access based on the work already done by the LibSL and OpenSL folks.
Access to the graphics layer, perhaps even the capability to swap in a custom renderer (I suspect this would require massive amounts of work mostly outside the domain of simple plugin architectures.)
Created by:last modification: Sunday 11 of February, 2007 [04:07:35 UTC] by