[sldev] sljirastats.com Linden Metrics Report

Felix Duesenburg kfa at gmx.net
Fri Apr 18 04:07:21 PDT 2008


Lawson English wrote:
> I've said it before (and I'm saying it again): the single most 
> important thing that can be done to reduce client-bugs in the long-run 
> is to refactor the GUI away from the rest of the client code-base.  
> The GUI kinda seeps into everything and it's virtually impossible to 
> change the GUI in substantial ways without impacting the rest of the 
> code, and whenever you touch most of the non-GUI code, you must take 
> into account the interactions of the GUI with that section of code 
> during your analysis--even at the highest and lowest levels of the 
> analysis.

Not sure how closely this is related, maybe this needs a different 
subject line. But here is what I keep thinking when pouring over the source:

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 always thought this is awkward. Shouldn't we do it e.g. in the fashion 
the Qt toolkit works: with a preprocessor that turns the xml gui 
definitions into code at compile time, with the language being a 
configurable parameter. These things are not dynamic anyway, so why 
aren't they part of the main app? This would save us having to 
distribute all those files with the release viewer, and make the GUI 
elements display faster. Language overlays or custom skins could still 
be made dynamic by placing such things in user's overlay directory, in 
case it's not feasible to provide a compiled viewer for a specific 
configuration. If no overlay file for a floater or panel exists, nothing 
needs to be parsed.

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?

Felix


More information about the SLDev mailing list