[sldev] Two potential plugin architectures: Inheritance across DLLs and NPAPI

[Tim Shephard]

> Client is patched to call LLFloaterAvatarList::updateAvatarList() every frame,
> which then goes over LLCharacter::sInstances and updates its internal list.

This is one of the problems with this style of architecture.. rather
than simply invalidating your widgets and asking the UI control to
redraw, you have to poll yourself very rapidly.   This isn't ideal
from a performance point of view.

>
> See line 298.
>
>
> > How does Dale's floater panel get drawn?
> > Do you have two UIFactories and loops?
> > Would it be like a flash or java plugin?
>
> It gets drawn by the UI code, I don't need to do anything to make that work.
> Simply creating the widget and then never doing anything should result in a
> window that's movable on the screen with clickable buttons, etc.

Sorry, I should have been more clear.  The questions were rhetorical,
ie: how would they be drawn with an NPAPI style architecture.


>
> My code doesn't really draw anything, it just updates what will be drawn.
>
> >
> > Possibly, we could export the widget drawing functions from an SL DLL
> > and then call those on an internal window.   Basically duplicate a
> > copy of the SL widget loop, but have it changed so that it is only
> > working on the internal window as described by the plugin.
> > Kind of a mini client inside the client.
>
> IMO, so much complication may not be necessary. Just look at the small amount
> of changes outside of llfloateravatarlist.cpp.
>
> Those are:
> registering a callback for the avatar info messages (make it so that I can do
> that from my llfloateravatarlist.cpp, and so that multiple callbacks can be
> registered (and unregistered)
>
> getting notified when a frame is drawn (add a callback system for "internal
> events", like "frame drawn", "logging out", etc). I also need to know when a
> sound is played, when somebody is typing, etc
>
> Access to internal lists of avatars
>
> My understanding is that DLL based plugins should allow the inheritance method
> of doing the UI work, so only those fairly minor changes should be needed.
>

If you mean inheritance across DLLs, that is one possibility I
mentioned..  However, the stability and cross platform suitability of
such a solution is unclear to me.