Category: SL Tech

Viewer 2: Getting the message

Posted on by Inara Pey

Esbee Linden posts about the forthcoming Viewer 2.1, and makes something of a ballyhoo over it. 400,000 downloads is a surprising figure. Emerald has been around a while and yet people question the Modular Systems’ claim that in excess of 70,000 have downloaded it. Given Viewer 2 has been with us less than three months, 400K is a very surprising figure. Nevertheless I expect at least one fanboi will be looking through Hubble and praising the figure for all its worth and using it as further “proof” that there is nothing wrong with Viewer 2.0….

Beyond the hype, however, there are some telling statements from Esbee. Most interesting is her list of forthcoming attractions, namely:

  • Adding individual volume controls for Shared Media objects.
  • Customization of the bottom bar, so that you can quickly access the features and functionality that you use most often.
  • Updates to the camera and movement controls, so we can allow you to pan and orbit your view of Second Life at the same time.
  • Adding the ‘Build’ option back to the right-click context menu.
  • Fixing the bug where CTL-ALT-F1 does not hide all the Viewer UI as it should. This fix should solve a lot of problems for our machinimists and photographers.
  • Adding a preference that allows users to control whether the Side Bar opening resizes the world or slides over it.

Frankly, while it is good news that the above are all being added to Viewer 2.0 – the fact remains that they should have been there from Day One. Period. While Viewer 2.0 is primarily aimed at new users who, granted, come into SL with a raft of different expectations than the rest of us, the fact remains that Viewer 2.0 also has to service those of us who have been here a while – and things like the irritating camera controls, restricted build functionality, lack of cohesive access to functions via the taskbar, etc., simply fail to consider, much less address the needs of the experienced user.

Similarly fundamental bugs such as the Sidebar jarring the in-world view to the left, the failure of CTRL-ALT-F1 should have been picked up and addressed long before the Viewer went to public Beta (and I have it on good authority that both of these issues were repeatedly raised during the closed beta testing, so absolutely no excuses here).

Performance issues are something I’m not going to comment on – they’re an accepted pitfall in an environment as dynamic as SL, and something somewhere is likely going to cause issues and problems along the way; as long as LL stay on top of them, that’s all that matters.

The Avatar customisation is also interesting, although potentially it will push Viewer 2.0 further from those wishing to stay with a 1.2x code base for their Viewer and put more of a load on TPV developers as they try to maintain and fix establish 1.2x code and integrate / back-engineer the newer code into their products. Even so, a greater flexibility for clothing layer use is to be welcomed.

Now, if they really could get the new search tool sorted out, then we might be approaching a waypoint to celebrate; but I’ll let Ciaran Laval give you the low-down on the situation there.

Imprudence returns

Posted on by Inara Pey

Following the recent discussions on the TPVP which led to some needed rewording, Imprudence have announced they will continue to support Second Life.

While SL may no longer be the primary “market” for Imprudence (and Lord knows the OS environment needs a viewer with Imprudence’s strengths), that they have reversed their earlier, and somewhat irrational action is to be strongly commended. So to is their willingness to engage in the issue of clarifying concerns around the TPVP’s ill-considered wording.

Kudos, Imprudence!

TPV: a further re-wording

Posted on by Inara Pey

Following last week’s meeting between Joe (Miller) Linden and some third-party viewer devs, it appear that concerns have now been addressed.

At the heart of last week’s meeting were concerns over the wording of Clauses 7a and 7d, both of which related to liability, and which have now been re-worded, vis:

Clause 7a:

Original: You are responsible for all uses you make of Third-Party Viewers. If you are a Developer, you are responsible for all features, functionality, code, and content of Third-Party Viewers that you develop or distribute.

Update: You are responsible for all uses you make of Third-Party Viewers.

Clause 7d:

Original: You assume all risks, expenses, and defects of any Third-Party Viewers that you use, develop, or distribute. Linden Lab shall not be responsible or liable for any Third-Party Viewers.

Update: You assume all risks, expenses, and defects of any Third-Party Viewers that you use. Linden Lab shall not be responsible or liable for any Third-Party Viewers

Both re-wordings seem fair and concise and do not rob the TPVP of any teeth.

Elsewhere, LL has further reinforced their position that that are not in any way attempting to infringe upon the GPL (possibly for those who missed the various statements at the top of TPVP), by adding a new Clause 8f: Nothing in this Policy is intended to modify the terms of the GPL.

All of this should go a long way to reassuring TPV devs that Linden Lab isn’t out to “shut them down” as well as alleviating tensions. Doubtless, some still won’t be satisfied – but that is their choice rather than anything to do with LL trying to hound them out of the playground. The full TPVP can still be read here.

TPV: brown bag and changes?

Posted on by Inara Pey

On the 13th, Joe (Miller) Linden held the first of his brown bag meetings with TPV developers to discuss the Third Party Viewer Policy. The various transcripts and audio recordings make interesting (if headache inducing) reading / listening.

While it was unfortunate that LL decreed the meeting would be in Voice – thereby potentially limiting input and participation (specifics raised in chat seemed to be somewhat ignored) – the meeting wasn’t as fractious as might have been the case, given the amount of ire the TPVP has created. Certainly, despite the efforts of some to try an disrupt proceedings by crashing sims, etc., progress seemed to be made in the key areas of contention – notably Section 7 of the policy.

This section has caused contention largely due to the wording. If taken 100% literally, it would appear to be shifting all responsibility for TPV code onto the shoulders of TPV developers. While this was not LL’s intent – as I’ve said elsewhere, they are not malicious – the wording did leave a lot to be desired. And while some may disagree, part of the problem does stem from the fact Section 7 mixes the development of a viewer with its use by others. Beyond this, there is the problem that a literal reading of some of the clauses – 7a, for example, appears to give the impression TPVs take responsibility for LL’s code when LL absolve themselves of all blame.

Whether one agrees with this standpoint or not (I personally don’t – and I sincerely doubt the law would interpret the language in the manner some TPV devs fear) – the the wording does cause angst and could be reworded without compromising the TPVP rather suggests that there would be no damage done were minor adjustments to be made to the phrasing of the clause – and this was indeed suggested.

A similar discussion was had around clause 7d, where again, it was apparent that much angst could be resolved by simply striking the first sentence in the clause; what was more, doing so could clarify LL’s position on matters of liability.

Elsewhere, people were more receptive to the fact that the TPVP is concerned with connecting to a service, and therefore stands aside from GPL requirements – something that seemed clear to many “outside” observers on the matter, including myself. Most interestingly, Lance Corrimal indicated that the Free Software Foundation’d licensing expert did not find the TPV to be in conflict with the GPL. That it would be is something I’ve had a hard time getting my head around; again, LL are not stupid. They did blunder with the original draft of the TPV – but they also stated the re-draft would be passed in front of experts in licensing and the GPL. I doubt that they  would subsequently go ahead and release the re-draft without following through on their intent to do so; ergo, it was hard to see how the experts they potentially used to review the TPVP got it so badly “wrong”, while those (with the greatest of respect) not versed in licensing and law were so adamant it is “wrong”.

What remains to be seen for the moment is how much fruit this first discussion bears between now and the next (set, I believe, for next week). When one puts aside all the angst and subjectivity surrounding clauses 7a and 7d, both could be more clearly worded without, as I’ve stated, impinging on the TPVP’s overall intent. As such, I would hope LL will take the suggested re-wording of both to heart and update the clauses.

It would still be nice to see the TPVP more clearly focused on the development of such viewers, with anything relating to the use of the same moved to the ToS. This would not only make the TPVP more focused for both LL and TPV developers – it would ensure the limitations on the use of such viewers are placed where they have a chance of being read by the majority.

Viewer 2.0 gets Starlight & I tweak KLee’s sidebar

Posted on by Inara Pey

Not too long ago, Tom (T Linden) Hale passed a comment in one of the multitudinous Viewer 2.0 threads to the effect that the skin of the Viewer itself can’t really be that radically changed because it is too much a part of the of overall viewer (and had I the patience to wade through the blasted flog, but patience and the official flogs don’t seem to go hand-in-hand).

At the time he mentioned this – back when the “beta” had just started – the comment struck me as odd. The majority of the Viewer files are XML…the folder structure of Viewer 2.0 isn’t that different from 1.2x – so wher’s the problem? However, I’m also not a programmer, so what on Earth do I know?

Now, Hitomi Tiponi has issued “Starlight”, a new skin specifically for Viewer 2.0, and what is likely to be the first of many such efforts.

Starlight brings together several of the tweaks developed by Alexandrea Fride and others, and presents them in a skin design that – while keeping to the overall 80’s approach LL opted for with the Viewer – lightens the basic colour scheme up somewhat. Avi Arrow has further tweaked Hitomi’s design to make the Sidebar somewhat less intrusive  so it doesn’t block the top and bottom right HUD attachment points (or the mini-map, if you prefer having that open on the top right of the screen). I’m borrowing the following screen shot from Avi to demonstrate both Hitomi’s skin and the sidebar revision.

V2.0 “Starlight” Skin with Avi Arrow’s modified Sidebar (Credit: Avi Arrow)

Notice the additional buttons and other tweaks to the interface in the image above.

The Starlight skin can be downloaded here, and Hitomi provides full installation instructions for Windows, while Mac instructions and Avi’s sidebar mod can be found in the flog thread on the skin.

Elsehwere, KirstenLee Cinquetti continues to revise and improve her take on Viewer 2.0, and the latest – S20.12 removes the sidebar completely from the screen until such time as it is need. Instead, there is an additional button in the toolbar area, which opens a mini-selection bar when clicked, which can be used in turn to display elements of the sidebar in their usual place. It is not elegant – but it does reduce the intrusiveness of the sidebar considerably.

In a tip of the hat to Avi’s idea, I’ve further tweaked KirstenLee’s sidebar so that it no longer blocks access to the top / bottom right HUD attach points, both of which I use.

My revision to KLee’s Viewer 2.0 variant

To make the changes to the Sidebar’s appearance (Klee S20, v16 or lower):

  • Close the Viewer, if running.
  • Use a text editor (such as Notepad) to open main_view.xml contained in the skins\default\xui\en folder of your KLee Viewer installation)
  • Find the section commencing <!– side tray –>
  • Within the < panel block, change the following:
    • Height=”450″
    • Top=”195″
  • Save the changes.
  • Start the Viewer – your sidebar should now be suitably resized when opened.

Klee S20 v17 and later:

  • Close the Viewer, if running.
  • Use a text editor (such as Notepad) to open main_view.xml contained in the skins\default\xui\en folder of your KLee Viewer installation)
  • Find the section commencing: <!– side panel now scales to top n bottom KL –>
  • Within the < panel block, change the following:
    • Top=”195″
  • Save the changes.
  • Start the Viewer – your sidebar should now be suitably resized when opened.

Viewer 2.0 goes “live”

Posted on by Inara Pey

Tom (Hale) Linden bullishly pushes through Viewer 2.0 as the new default Viewer for Second Life today. In a post about an improved New User Experience, Hale lets slip that Viewer 2.0 is now released, stating that the new  viewer is now a part of the default download for new users when they create a new account. Viewer 2 is now out of beta and joins Viewer 1.23 and other approved third-party viewers as an option for all Residents.

While this move isn’t entirely unexpected – the Lab did state back when the released of Viewer 2.0 into open Beta was being announced that they planned to make it “official” “by the end of Q1” (which is today), the “announcement” that this is now the case is nevertheless liable to cause much outrage and upset – especially for those heavily engaged in new user orientation and who a) have been given next to no time in which to re-generate their notecards and other information to reflect the new Viewer and b) haven’t even been given the luxury of a formal open announcement that Viewer 2.0 is now “out of Beta”.

One might also point out that those still attempting to Beta Viewer 2.0 have probably been taken by surprise by this announcement.

So… here it is – and note that official support for Viewer 1.22 now ends, and support for Viewer 1.23 will terminate at the end of June 2010.