[sldev] sljirastats.com Linden Metrics Report

[Felix Duesenburg]

Callum Lerwick wrote:
> On Fri, 2008-04-18 at 07:07 -0400, Felix Duesenburg wrote:
>   
>> There is quite a heavy dependency of the viewer application on the 
>> correctness of added resources. In other words, hard coded parts of the 
>> program need outside resources to be correctly structured or they would 
>> fail. I really mean structure, not just language dependent snipplets of 
>> text, or colors or the like. Examples of that are keywords.ini and the 
>> entire GUI skin files collection, and certainly some more parts of the 
>> viewer which I'm not yet too familiar with.
>>     
>
>   
>> I may be totally off with this, missing out a mention of the reasons for 
>> why the current structure is the way it is. Can someone help with a 
>> pointer if that is the case?
>>     
>
> How about:
>
> Rule of Representation: Fold knowledge into data, so program logic can
> be stupid and robust.
> http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2878263
>
> At the same time:
>
> Rule of Generation: Avoid hand-hacking; write programs to write programs
> when you can.
> http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2878742
>
> So arguably *automatically generated* code is acceptable. But you need
> to strictly disallow hand-hacking of generated code. Don't even put it
> in the SCM, make the build system generate it for you.
>
>   

I'm afraid I didn't present it too well, maybe lacking some background 
to cite excellent sources such as this. But we're not at all on 
different sides here. That's why I was drawing the comparison with the 
Qt toolkit, which has these rules implemented well. (Only been given to 
understand that compiling all of it into a monolithic executable is not 
wanted for the SL viewer.)

Ok, being told that the goal is to have loadable skin packs, I want to 
ask back: What's in a skin? To me that is colors, text and labels that 
are language dependent, style descriptions of widget decorations, and 
icons or other graphical elements. But not the entire structure with 
functional elements on whose presence hard coded parts of the program 
are relying.

IMHO this is a starting point where refactoring would make sense and be 
fairly easy to do as well: Have the functionality part taken into the 
source on compile time by a preprocessor, and reduce the 'loadFromXML' 
function to add the parts that are really just style elements. The much 
desired function to enable/disable certain elements without having to 
recompile the viewer (s. Argent's earlier post in this thread) is 
provided by show/hide flags in the GUI XML.

If 'preprocessor' sounds high-flying or complicated, it's really just a 
rewrite of the current load function in Python that hooks up in the 
custom build steps. We may even keep the XML files as they are and leave 
it to the preprocessor to sort out which is which. This would avoid 
creating a gigantic patch, and avoid undoing any work that has already 
been put into creating tools for editing the GUI. Hope I'm making sense, 
trying to think practical.

> But I think the real issue here is:
>
> Rule of Repair: Repair what you can — but when you must fail, fail
> noisily and as soon as possible.
> http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2878538
>
> The viewer has the "failing" part down, but fails at the graceful and
> noisy part. It crashes and gives you no useful diagnostic output as to
> what the problem is.
>   
>   
YES.