[sldev] Plugin system - first code drop

Christian Westbrook christian at electricsheepcompany.com
Wed Feb 28 12:23:03 PST 2007

> Nope!  The current First Look is just for texture pipeline  
> improvements.
> -RYaN


Thanks for the heads up on LLFloater and the mutability of the code
in general.  I can't deny this is a little alarming but is certainly
worth hearing, yet I think it sheds light on a larger issue, also
illuminated somewhat by the discussion yesterday about attempting to
protect plugin developers from changes via abstraction:  it's very
difficult (some might say impossible) to develop meaningful  code on
a codebase that is changing with only vague hints as to how it will
be changing.  I understand and appreciate that LL is not [yet?] an
organization that has completely accepted open source development,
but firmly believe that there is a happier medium between a closed,
proprietary software company and an open source platform -- happier
for LL, the community, and third party/independent developers -- to
which LL must move for any of these discussions about plugins, etc.,
to bear fruit.

It's been a full month since the last code drop of the "real" viewer
source code.  First Look has been pushed out with some regularity
throughout February, but was first done so with the caveat that it  
was an
experimental branch that should not be incorporated into our trunk.
It sure seems like all LL devs are working on FL -- when did this
change?  Without any transparency, this feels like a simple bait-and-

Please consider this a call to the LL dev team to come out and play!
Even cognizant that some features like lip sync/VoIP will remain in-
house only, there is a huge disparity between dropping code (at any
interval) and developing *with* the community.  How can we all help
push the metaversal envelope without compromising LL's business plan?



On Feb 27, 2007, at 12:58 PM, Richard Nelson 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.
> 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..
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html

More information about the SLDev mailing list