Is Firestorm a pen name for viewer 3?
-
by Selby Evans (aka Thinkerer Melville)
-
Recently I complained about the morose color scheme on Viewer 2.0.
-
I got an informative response from Hitomi Tiponi:
With 2.6 skinning has finally been enabled in the the Viewer - yay! Unfortunately with 91 hard-coded colour entries, several system colours and other bugs in the viewer xml this is not easy unless LL either make quite a few changes or use the StarLight skinning base (as Firestorm does).
Back when I was working in computer science, hard coding of UI features like that was considered amateur work. I can't say I was shocked to hear that they had used hard coding there. I had begun to suspect that hard coding was the root of the color persistence in the UI. I just found it hard to believe. I wonder if they even used modular programming.
-
A few years ago the design was so far from modular that, they had to update both viewer and server software at the same time. Update Wednesdays. I remember the proud announcement of the standard message format. It certainly was an advance, but hardly the cutting edge of computer science.
-
Other changes make my complaint obsolescent:
-
-
===========================
Here is my take on developments
-
Tech: Is Snowstorm melting?-
The business case for Linden Lab to cut back on viewer development.----------------------
The Phoenix team seems to be doing a lot of things right. I pointed out some advantages they may already have in the form of the Phoenix support group. And since then they have added classes. -
Tech: Software in social development. Phoenix
-
Who would you bet on to succeed in developing software that can win user acceptance?
==========================
1 comment:
I believe we will see a greater co-operation between LL and TPV developers in the future - but the key elements will always be produced by LL. Firestorm (like all TPVs) will always be more than 95% LL's code. The Firestorm team have been doing the fancy stuff while the Snowstorm team have been doing a lot of the unglamorous stuff of bug fixing and performance tweaking, that they can then pick up.
It is important that both teams do what they are good at doing, and acknowledge each other's abilities.
Post a Comment