[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