[sldev] sljirastats.com Linden Metrics Report

[Lawson English]

Aimee Walton wrote:
>
> I guess you haven't been following the Dazzle debate then; people are 
> desperate for proper user skinning to happen before the new colour 
> scheme goes live. It causes eyestrain and migraines for a significant 
> number of people, and breaks some fundamental principles of good GUI 
> design. Packaged skins would at least allow those people that aren't 
> happy messing around with the files directly some choice, with a 
> little security that the changes aren't going to get broken with each 
> update.
>
> https://wiki.secondlife.com/wiki/Skinning - note Dazzle and the new 
> skin in Phase 0, skinning not till Phase 1. A completely avoidable PR 
> issue, why upset people introducing Phase 0 when it's all going to be 
> moot anyway once Phase 1 is ready? It makes no sense; it's like 
> standing by and watching a friend walk off a cliff.

It's an issue with the number of beta testers. More people are willing 
to try a first look client than a beta test. More people are willing to 
try an RC than a first look.

And for something like this they need huge numbers of beta testers and 
they just don't get them.

Maybe it would be possible to roll Dazzle back to "first look" or even 
"second look" and explain this is a test of features, tell us what you 
like and don't like....

But it still needs to be on the main grid or they don't' get enough 
feedback.

Personally, (horns blaring) I think the GUI needs to be refactored from 
the ground up, as I have said. The crazy patchwork of classes that is 
the viewer GUI is virtually unmanageable, so all these changes are 
overly risky as far as introducing side-effect bugs. The hierarchy of 
the classes--even how they are grouped in files--makes it extremely 
difficult to modify, letalone rationally "extend" behavior. The GUI 
itself is dependent on global variables that are poorly documented, and 
often have nothing to do with a normal GUI at all. Folders and their 
helper classes are intertwined quite tightly with server interactions. 
Inventory folders are the only type of folder available. There's no 
possibility of creating a window with a simple hierarchical view of 
non-inventory data stored on the client's hard drive without having an 
extensive understanding of how the folder classes interrelate so you can 
grab that one relevant class and rewrite it for your own use. Skins, we 
know about. User-extensible GUI elements are impossible, at least at the 
level a game-like client should allow for. Programmer-extensibility is 
slightly less impossible, but still not-doable unless you spend a 
ludicrous amount of time analyzing the code. Rearranging existing 
elements is doable, but only in a very contrived fashion....

If anyone looks at the roadmap for GUI revision

http://wiki.secondlife.com/wiki/User_Interface_Roadmap

They will notice that the very bottom of the page of "future projects," 
what used to be called "step four," is:

Create a sample UI only client


In a normal system, that would be the first thing you would expect to 
see, but in fact,  the GUI, as it stands now, needs so much reworking 
that a standalone GUI window ("a sample UI-only client") can only be 
done after the entire mess has been cleaned up. THAT is how messy and 
intertwined the GUI is. Why anyone seriously thinks that de-bugging the 
client at some higher level, while leaving the foundational mess of the 
GUI untouched (and the GUI IS the foundation here--there's no clear MVC 
divisions that make the GUI-bugs relatively separate from the rest of 
the system, interaction-wise), will yield a truly stable, extensible 
system, is beyond me.

I can understand LL's reluctance to tackle the job. I can understand any 
individual developer's reluctance to try to do it (HELL, I have no idea 
where to begin), but that the development community remains almost mute 
on this topic while squabbling over the superficial stuff, just reveals 
that the SL developers community really is clueless about the 
fundamental issue here--or is being hypocritical in their condemnation 
of LL.

Why are only a handful of us screaming about this issue? Why isn't it 
the number one priority raised over and over again in Open Source 
meetings, SLDEV messages, etc? It impacts everything from frame rate, to 
memory leaks, to GUI extensibility, to who-knows-what.

I mean really, guys. Refactoring the GUI is Job Number 1. The Lindens 
are afraid to tackle it. You guys bury your heads in the sand. If 
nothing is done, the situation will only get worse and the list of 
bug-fixes awaiting integration will grow ever longer because 
dependencies on the GUI and other subsystems will continue to bite every 
bug-fix attempt.




Lawson