[sldev] sljirastats.com Linden Metrics Report

[Felix Duesenburg]

Argent Stonecutter wrote:
> On 2008-04-18, at 06:48, Felix Duesenburg wrote:
>> Argent Stonecutter wrote:
>>> On 2008-04-18, at 06:07, Felix Duesenburg wrote:
>>>> 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?
>>>
>
>>> Because then they wouldn't be skinnable or editable and you wouldn't 
>>> be able to go in and say "if you remove this section from your 
>>> overlay panel xml file you can get rid of the damned release keys 
>>> button".
>>
>
>> It doesn't occur to me that this is a feature people really want. Is it?
>
> It's a feature that most people don't care about most of the time, but 
> when they do need it they REALLY need it. I have provided patches for 
> these files on Jira and on the blog and in-world and people have been 
> VERY grateful for them.
>
>> If those who like to edit their gui files happen to be mostly 
>> developers (which I cannot verify), wouldn't it suffice that they can 
>> compile their own?
>
> I'm a developer, but I don't want to have to maintain a development 
> environment on Windows as well as OS X to tweak the viewer. And every 
> time I read this list and see more questions about compatibility 
> problems with this or that version of visual studio that gets reinforced.
>
>> The whole thing would run faster and more reliable.
>
> It wouldn't be significantly faster... these files are only read at 
> startup and they're not a significant part of the startup process.
>
> It wouldn't be significantly more reliable. I don't think I have have 
> EVER had a problem caused by these files, except where I caused it by 
> editing them... and whether I was rebuilding the client after editing 
> them or not wouldn't make much difference there.
>
> As for language translations... you want to require translators to be 
> translators as well?
>

Thank you for the clarification, I see the point. I remember now one 
more aspect that led me to raising this, which is a security concern. 
Something could overwrite these files and do things like swapping the 
'yes' and 'no' labels on the payment permission dialog. See the recent 
thread titled "Handling open source translations".