[sldev] sljirastats.com Linden Metrics Report

[Kent Quirk (Q Linden)]

On Apr 18, 2008, at 8:01 PM, Felix Duesenburg wrote:
> 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.

I'm sorry, but I really think this is highly unlikely to ever happen.

You're proposing the creation of an additional step to the build  
process, to take something out of data and put it into code. We're  
moving much more in the direction of moving things out of code and  
into data. I see that you're trying to draw a bright line between the  
model and view parts of the UI, and there's a certain argument for  
your position -- in stable code. But high quality UI development  
requires lots of iterations. The cycle time for edit/build/test is  
critical to controlling how many shots you get at making it good. In  
that scenario, the more you can do in data without a rebuild, the  
better off you are.

To tie in the other discussion going on right now, we're fully aware  
that the viewer isn't as modular as anyone would like, and that  
there's too much coupling between the various pieces. Some of us are  
working very hard on taking some of that apart right now. I, for  
example, am one of three developers who have been working on  
refactoring the notifications and alerts systems, with the help of our  
UI team and some excellent feedback I got earlier from this list.

We're also doing a lot of work toward making the viewer more and more  
data-driven. For example, the Notifications system is quite a bit more  
flexible now, because we're adding capabilities to the XML file we use  
for localization.

I'm not being authoritarian about this, just trying to express the  
reality of our goals and that I think they're incompatible with what  
you're proposing. As far as I can tell, there's little chance that  
we'll move in favor of moving things into compiled code, especially if  
doing so also requires adding to build time and complexity.

	Q