Jump to content

Tools and Technology

  • entries
    80
  • comments
    3,233
  • views
    81,416

Contributors to this blog

About this blog

Entries in this blog

Esbee Linden

Today, we’re releasing Viewer 2 (Version 2.2.0 Beta) on our Beta release channel. This is an exciting release for us for two reasons. First, this release marks the first Viewer download since we announced the Snowstorm Team at SLCC in August. The Snowstorm Team has been working in the open to share our design and development process and directly engage with open source developers. Second, this beta release also marks the beginning of a new approach to our release process. Since we kicked off Project Snowstorm, we’ve made the latest Development Viewer available to Residents nightly so they can see our day to day progress and try out new things as soon as they’re in a build.

In our Beta and Release channels, we will make Viewers available to you more frequently. Our plan is to update Betas weekly with new official releases happening every 3-4 weeks. This lets us get new ideas and features into your hands faster and it gives us the ability to react to your feedback more quickly.

This latest beta release of Viewer 2 (Version 2.2.0 Beta), is mostly focused on bug fixes, but also includes some great user interface customization options. Here’s a quick run-down of what you’ll find in this release:

  • Sidebar Tabs can now be undocked and turned into regular floating windows.
  • The buttons on the Bottom Bar can be reordered.
  • Right-click on your avatar and select “Sit Down” to sit anywhere.
  • Parcel property icons (found in the Location Bar) are now on by default.
  • Selection beams are working again.
  • Language translations in local chat (via Google Translate API).
  • Group permissions now work via the Snapshot tool.
  • Turn off scripted particles and lights.
  • Builders can more easily align textures across linked prims using planar mapping.
  • View profile inspectors via the Mini-map.
  • Pan the mini-map with shift-drag.

Many of these features came to the official Viewer through resident contributions, both directly by way of the Snowstorm team, as well as indirectly through past contributions to the Snowglobe project. Thank you to all of you who have contributed code, testing, and commentary. Please keep it up!

To view a full list of changes, see the Release Notes.

Download the Beta Viewer : Windows | Mac | Linux

Please note that, as always on the beta channel, we only support one beta viewer at a time. If you’re using an older Beta Viewer, then you will be asked to upgrade on your next login.

Thank you!

Yoz Linden

As we described a little while ago, we're taking some major steps to improve our bug-tracker, jira.secondlife.com. We're making it faster and easier to use, more revealing of our ongoing engineering work, and - most importantly - better at helping us find and fix bugs.

Today we completed the largest single milestone on our bug-tracking roadmap: the upgrade to JIRA 4.1. This was more than just a simple upgrade: as well as all the improvements that JIRA 4.1 brings, we've moved to new, more powerful hosting infrastructure. We've integrated the same login system used by the rest of secondlife.com. And we've installed the Greenhopper project management plugin so that open projects, such as Snowstorm, can expose far more of their roadmaps and schedules. It'll take a few days for the first projects to make their Greenhopper pages available, but once a project has one, you can get to it through the "Agile" item on the navigation bar.

If you're interested in our bug-tracking process or already contribute to it, please go take a look. We hope you'll find it significantly better than what we had before. However, there are still tweaks to be done and problems to be fixed. If you find anything in the new setup that doesn't work as it should, you can file an issue about the bug-tracker in the bug-tracker, specifically in the WEB project, jira.secondlife.com component. (Using the bug-tracker to report on itself may seem dangerously recursive, but don't worry; we've hardly ever caused any wormholes in the space-time continuum.)

One more thing, for JIRA regulars: As mentioned previously, we're also making changes to some of the workflows with which we categorise and process issues. Some of those changes were made two weeks ago. With this upgrade, we're moving towards another little tweak: renaming the Priority field to Severity and using it to describe the seriousness of effect that an issue has. This is for a couple of reasons: firstly, to reduce edit-war arguments by making the field topic a little more objective. (You can read the descriptions and criteria for the Severity field values on this wiki page.)  Secondly, because Priority is meaningless as an attribute of a single issue; rather, an issue's Priority is its relative position amongst its peers, which is decided during project backlog review. The renaming of the field hasn't happened yet, since it requires tweaking of the underpinnings to be done after dust has settled on the upgrade, but in the meantime we've renamed the values that the field takes.

Once again, we'd like to thank everyone who works with us through the bug-tracker to report and fix problems. With these and future JIRA improvements, we aim to give you a clearer view of how your contributions make Second Life better for everyone.

Edited to add: Our screencast wizard, Torley, has created a couple of video tutorials which show off some new features that make JIRA use considerably quicker. Check out How to search the bug tracker and How to report a bug.

Oz Linden

As part of launching our new more open viewer development process, we changed the open source license for the new viewer code base from the GPL with an exception to allow use with certain other open source licenses (the "FLOSS Exception") to the LGPL.  Some people have been asking about what this change means, and what our intentions are in making it.  In particular, the LGPL requires that the code first be compiled into a library and then may be used in an application.  Since the open source we make available does not directly provide for building this way, some people have speculated that the new license may actually be a barrier to other viewer developers.  I'll try to answer this as clearly as I can.

At Linden Lab, our intent is to enable the development of third party viewers and the improvement of our own viewer through mutual sharing of the requisite common technology.  We think that LGPL is a better license to accomplish that sharing. Even though it was originally written to apply only to libraries, there is significant room for interpretation when using it.

Our interpretation is this: modifying the build procedures provided in the source code to produce a library containing a subset of the licensed code is a minor programming exercise.  The result of linking that library (which may be either a static library or a shared one, and either is allowed) with whatever other code is used to build a viewer is again a minor problem. The results are essentially indistinguishable from those in which the developer just modified the build procedures in place to produce an executable application.  Essentially, the details of the linkage procedures used are a matter of packaging and have no end user effect.  In practical programming terms, a library is just a convenient package - the requirement in the LGPL is like requiring that a grocery store sell a product only if it is first placed into a shopping cart while inside the store.  Essentially a library is just that - a shopping cart full of individually compiled modules, so there's no real difference between using a library and just using the modules separately (one could build a library containing exactly one module, or build an application that had only one module and one library).

It is our intent that developers be able to use the components that we have licensed under the LGPL to produce viewer applications, regardless of the linkage procedures used, so long as they make available any changes to those components as specified in the license.

Q Linden

In the Snowstorm Product Backlog Office Hour Wednesday, I commented that "I think options are bad for users and bad for code quality". If you read that whole transcript, you can probably see that it was interpreted badly. The most extreme variant, reported by someone who was watching in-world chat afterward, held that Linden Lab wanted to remove all options from the Viewer. Let me start by saying that is not the case and never would be, nor is it something that I or anyone at Linden Lab has ever seriously contemplated.

However, I still stand by my original comment -- options are problematic for lots of reasons.

Let's see why:

First, every option has to have a way to control it. In many cases, you have to have multiple ways to control it. From a user interface design point of view, that means creating option interfaces. For the SL Viewer, those are a) the preferences dialog, b) the debug settings, c) checkable menu items, and d) options within dialogs that control other features.

You'd normally like to put options with the things they affect, but screen space is always at a premium and many options are only changed infrequently. So instead, we group options together in a preferences dialog. But there are enough of them that it becomes necessary to create some means of organizing prefs into a hierarchical structure, such as tabs.

But as soon as you do that, you find that you have trouble because not everyone agrees on what the hierarchy should be. What tabs should you have? Where does each option go? When you get too many options for one tab, how should you split them up?

There's no one answer and there's rarely a right answer.

And then, once you have a place to put them, you have to decide what to call each option and what the default is. And if those decisions were easy there wouldn't be a need for an option!

Second, options add complexity to the interface. Every time you add an option, you add a decision for the user to make. In many cases, someone might not even know what the option controls or whether it's important. Too many options might leave someone feeling that the product is too complex to use.

Third, options add complexity to the code. Every option requires code to support all of the branches of the decision tree. If there are multiple options affecting the same feature, all of the combinations must be supported, and tested. Option code is often one of the biggest sources of bugs in a product. The number of options in the Second Life Viewer renderer, which interact not only with each other but with device drivers and different computers, make it literally impossible for us to exhaustively test the renderer. We have to do a probability-based sampling test.

You could say that it's our problem to deal with that complexity, and you'd be right, but every additional bit of complexity slows down development and testing and makes it harder for us to deliver meaningful functionality.

Fourth, options that are 50-50 probably do need to exist. Options that are 90-10 are addressing an advanced (and possibly important) use case. Having them in the preferences interface promotes them to a primacy they probably don't deserve.

Finally, adding options has a snowball effect. Having a small number of options is good, but having too many options is definitely bad for the product and for the customers trying to use it. Sure, advanced uses need advanced features, but we don't have to make everyone confront all of the complexity.

Add all of this up, and I think it becomes clearer why I said I didn't like options and would prefer to find alternatives.

So why have options at all, then? Because different people legitimately have different needs. Advanced users vs novices, or landowners vs shoppers. We get it. But it's also often an indication of a design that needs work.

There are alternatives to putting more checkboxes on the preferences screen:

a) Allow entire user interfaces to be "plugged in". This requires a major architectural change to the software. Although we've talked about it, it's going to be a while yet before we get there.
b) Allow options to be controlled close to the point of use. As I said above, this can clutter the interface but can be effective.
c) Make an interface that covers all use cases. This is the hardest of all, requiring real understanding and design, but is usually the right answer.

In short, I often consider adding a preference to the prefs panel to be the wrong answer to a real question. It's not that we don't consider different use cases, it's that we're trying to cover them in a better way.

So this has been my attempt to explain the thinking behind a statement like "options bad". I hope it's helped -- has it? Tell me in the comments.

×
×
  • Create New...