[sldev] checking how the viewer gets Event info

[Robin Cornelius]

On Mon, Sep 8, 2008 at 4:18 PM, Lawson English <lenglish5 at cox.net> wrote:

> That is something I gotta start looking at for pyogp. Working on a tentative
> design for a GUI module for it ATM.
>
> One thing I think we want (I'm sure *I* want) is to keep the GUI separate
> from the functionality. One of the GPL viewer's biggest stumbling blocks for
> modifying the GUI is how intimately connected the GUI is with the specific
> packets and functionality it deals with. There's no abstraction between the
> primitive tk-level (think the GUI is a TK port) widgets and the SL-specific
> widgets. No folder class save inventory folders, for example. I'm guessing
> that there are no chat panels that could accept a Jabber or IRC plugin
> input, eitehr, without a LOT of extra work.
>

yea for sure. In the current implementation there are packet handling
routines scattered through out the code, such as in the specific
floaters for event searches the search packets are generated and sent
from there. At least the packet receive code has *some* abstraction,
it at least comes up a common path when it gets switched to the
various functions that may deal with it but even in this case it looks
for a static instance of a LLPanelDirEvents and feeds the call back
directly in there.

This is where creating a GUI on top of libomv (libsecondlife) was a
joy. Keeping the message API out of the higher level code makes things
more readable and obvious and hopefully makes bug hunting a little
easier.  I suppose in theory this could be done with the existing
viewer almost a message group at a time so its a gradual change and
not a "refactor".

Robin