[sldev] Rewriting the viewer (Re: sljirastats.com Linden Metrics Report)

[Lawson English]

Rob Lanphier wrote:
> On 4/18/08 1:30 PM, Jesse Barnett wrote:
>> Actually it was discussed extensively the first few weeks of SLDev & 
>> Rob coming on board in iirc and meetings under the umbrella of plugin 
>> architecture. I would imagine that the concensus has'nt changed from 
>> that time. Yes, it is a serious problem and yes, it should be done, 
>> but no, no one wants to tackle that beast and it is more expidient to 
>> just create sockets that interface the jumbled mess in the backend 
>> for the plugins to go. You hit the nail on the head with this : "I 
>> can understand any individual developer's reluctance to try to do it 
>> (HELL, I have no idea where to begin),"  It isn't just a matter of 
>> refactoring the GUI, the GUI is everywhere and would involve a major 
>> rewrite of ALL the code. The code sucks and everyone in the community 
>> and the Lindens know it sucks but continually hammering to get 
>> someone, anyone to rewrite it isn't going to be very productive.
>
> I'll restate what I stated last year on this topic, pointing to this 
> article from Joel Spolsky about Netscape:
> http://www.joelonsoftware.com/articles/fog0000000069.html
>
> I'm glad Firefox and Thunderbird are around, and I use both of them as 
> my primary apps for their respective functions.  However, while the 
> approach was eventually successful in producing some really important 
> software, it completely failed to achieve the desired result for 
> Netscape Corporation (and for that matter, AOL after that).  We intend 
> to survive the release of our source code ;-)
>
> The viewer architecture is in much better shape than it was this time 
> last year, and I think we have every reason to believe it will be much 
> better next year.

I meant to say refactoring. If I said throw everything out and start 
from scratch, well, I said it wrong.

Here are the problems I am aware of with the GUI:

*It uses global variables that aren't documented, and apparently are 
tied to other subsystems in complicated, undocumented ways, which make 
creating standalone test-viewers impossible unless they drag substantial 
portions of other subsystems with them. Not only can't you test GUI's 
separately, you can't test the other subsystems separately either.

*Certain important functionality, e.g., hierarchical folders, are tied 
to server communications in ways that make it very difficult, or at 
least, unintuitive, to create new hierarchical lists in the GUI that 
don't use inventory items. I threw up my hands and bypassed the whole thing:

http://www.youtube.com/watch?v=kvEKiGSYm0k

Dale Glass told me he figured out how to do it using the existing folder 
classes, but it wasn't obvious to me how he did it. GUIs are supposed to 
make life easier for developers, not harder, so my point stands.

*Text-handling is extremely... odd. True-type fonts are used to simulate 
bitmapped fonts and different truetype fonts are required to simulate 
different text-sizes. Changing fontsizes in existing classes is a chore. 
For example, I wrote a simple patch to link font-sizes specified in 
preferences to the font size of all multi-line text except the LSL 
editor. It wasn't that hard to do, but required a bit of analysis of the 
internals of the various text-handling classes because there was no easy 
way to do it from outside the existing classes. I would have to rename 
classes and write simple interface classes to intercept the calls from 
other parts of the viewer, such as the XML handlers, or add a tiny 
snippet of code to test the status of the font-size flag set in the 
preferences inside the existing multi-line text editor. I chose the 
latter as the most easy to maintain. Just delete/comment out my 10 lines 
of code if a better solution is devised.

*event handling is (or was, haven't looked lately) a bit odd as well.

*skinning is possible only at the most superficial level. More complex 
customization is difficult or impossible. Customizing the behavior of 
the GUI elements, such as adding different kinds of sliders, wasn't even 
a design consideration originally (nuf said).

* and likely other issues I can't recall off the top of my head.

* and certainly other issues I never encountered when working on my two 
minor patches.



Lawson