[sldev] Plugin system - first code drop
tshephard at gmail.com
Tue Feb 27 11:52:12 PST 2007
That was a real eye opener, especially the bit about "large
architectural decisions to be made".
Can you shed some light on that? Are these decisions strictly GUI
hierarchy related? Timelines?
My main concern here would be developing a contract of Ansi C function
pointers across DLLs and then after the architecture upgrade is done a
significant impedance mismatch occurs, and everyone needs to rewrite
their plugins. Or, worse, we keep you guys from doing the upgrades
you need to do because you have to support a bunch of legacy
Heh. I hope I'm not the only one that doesn't see the curious
challenge trying to architect when you have no clue what the over all
technical roadmap looks like...
I am beginning to think whatever we come up with in this environment
is going to be sub-optimal at best.
Though I can imagine that we can probably come up with something that works...
On 2/27/07, Richard Nelson <richard at lindenlab.com> wrote:
> Just jumping in here to comment on LLFloater stability. In general, we can't guarantee that our UI class interfaces will remain stable. For example, we recently changed LLFloaters and LLPanels to implement LLUICtrl in order to sanitize our keyboard focus model and let them participate fully in focus management (LLView's can't delegate keyboard focus, they can only contain LLUICtrls, or widgets). We've also made many changes in the move over to XML-driven UI. These changes are not complete, and we will continue to tease out architectural abstractions and refactor our UI code based on use cases as they arise.
> That said, most changes can be considered extensions to existing functionality, implemented in the base class, with no extra burden on derived classes. There are still large architectural decisions to be made, though.
> On Tue, 27 Feb 2007 09:32:17 -0800, Rob Lanphier <robla at lindenlab.com> wrote:
> >> > Basically there would be an instance of LLFloaterPluginProxy for every
> >> > plugin floater created.
> >> I initially rejected the derivation idea, as a class derived from the
> >> floater class meant that this class would change any time the floater did.
> > OK, that concern makes sense. However, looking through the code,
> > llFloater seems likely to be very resistant to change. If it does
> > change, it would likely impact a very significant amount of code and
> > therefore would only occur when absolutely necessary.
> > Perhaps a linden can comment..
> Click here to unsubscribe or manage your list subscription:
More information about the SLDev