[sldev] Plugin system - first code drop

[Richard Nelson]

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.

Richard


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..
>