SL projects update 23/4: TPV developer meeting, Friday June 6th

A TPV developer meeting took place on Friday June 6th. The core items discussed in the meeting are reported below, with timestamps in the relevant paragraphs indicating the point at they are discussed in the video embedded here.

Note that the timestamps are not necessarily chronological; some subjects have been grouped together for ease of reading. Also, the last 8-10 minutes of the meeting is taken-up with general conversation (Oz’s vacation, trying-out the Oculus Rift, etc.), which is not reported upon here.

My thanks as always to North for the video.

SL Viewer Status

[0:18] Other than the release of the MemShine RC viewer, version 3.7.9.290582, reported upon in part 1 of this week’s report, there have been no significant SL viewer updates. If the stats on this viewer remain good, it is likely that the individual MemPlug and Sunshine AIS v3 release candidates also still in the release channel will be closed-out, leaving just the MemShine version. As the overall stats between the RCs, which apparent include the SL Zipper RC which is currently absent from the Alternate Viewers wiki page,  are all so close, it is not clear which is most likely to be promoted as  the next de facto release viewer.

Oculus Rift Project Viewer

[1:33] Alongside the release of the Oculus Rift project viewer, the Lab also made the code repository available to the public as well. However, TPVs are warned against integrating the code for release purposes at this time, as it is anticipated there will be significant changes to the viewer once the new version of the Oculus Rift Development Kit is available. However, the Lab is not opposed to TPVs producing experimental versions of their viewers using the code if they wish to gain some familiarity with it.

The project viewer itself is unlikely to undergo update until at least after the new Oculus Development Kit is available to the Lab, although it is expected that the viewer will undergo periodic merges with the viewer release code in the coming weeks / months so that it does not stray too far out of step with viewer releases.

As well as supporting the Oculus Rift, the code within the project viewer is also intended to support other, similar VR headsets, although the Lab obviously does not have any definitive time frames as to when such headsets will become available or when they are liable to be officially supported in the viewer.

ANTVR: to be supported by Second Life at some point? (Assuming it gets to a production status)
ANTVR: to be supported by Second Life at some point? (Assuming it gets to a production status)

Group Ban and Snowstorm Viewers

[03:08] Again, as reported earlier this week, the Group Ban viewer is currently awaiting the server-side code to be fully deployed across the main grid prior to it officially appearing in a project / RC form. This is now likely to be delayed a little longer as a result of the GnuTLS issue, which promoted an additional server-side deployment which replaced the initial Group Ban deployment to LeTigre (the server code should return to the RC channel in week 24).

[03:20] There are further tweaks being made to the Snowstorm release, which should include the likes of STORM-1831, “Obtain LSL syntax table from simulator so that it is always up to date”, which has in turn been impacted by STORM-2026. Hopefully, the viewer will be heading for the release channel very soon.

Maintenance Viewer Updates (with more Cocoa Fixes)

[06:40] There are more maintenance (JIRA: MAINT) fixes coming down the pipe, none of which are expected to be particularly huge, but as things progress there could be a number of MAINT-related viewer releases.

[14:24] The next MAINT viewer to be released should include further Mac Cocoa fixes within it. Unfortunately, Oz did not have a list of what these might be, so expect an update at the next TPV developer meeting if the MAINT viewer hasn’t already appeared by then.

Upcoming Viewer Items

New Viewer Log-in Screen

[03:52] This has yet to make a public appearance, but the Lab is working on a new viewer log-in screen. Details are not clear as to precisely what is changing layout-wise, but it will not result in any actual changes to how log-ins are physically handled between the viewer and the SL servers, nor will it carry any significant updates other than to the initial splash screen. Commenting on it at the meeting, Oz Linden described it as, “yet another attempt to make a friendlier intro for new users”, as a part of ongoing attempts to smooth people through the sign-up and initial log-in activities.

It is expected that this viewer may appear as a release candidate as the current number of RC viewers in the release channel thins down (particularly if the MemPlug and Sunshine RCs are retired, as noted above).

The official viewer log-in screen is due for a revamp, although the mechanics of the log-in process will remain unchanged, and at least some of the widgets will remain in some form. In addition, at some point grid status updates *may* be returning to the screen
The official viewer log-in screen is due for a revamp, although the mechanics of the log-in process will remain unchanged, and at least some of the widgets will remain in some form. In addition, at some point grid status updates *may* be returning to the screen (see below)

Return of the Grid Status Information?

[18:36] There has apparently been talk within Linden Lab about returning the grid status information to the viewer log-in screen – and also in other places as well (although where exactly has yet to be specified. While no decision has as yet been made either way, I for one would be extremely pleased to see it return to the official viewer’s splash / log-in screen, as I took to banging that particular drum from the moment LL launched the updated log-in screen back in August 2011:

Grid status-1

Good point it may have been, but nothing was done to fix it, although some TPVs opted to re-implement it themselves, fortunately. Even so, as overdue as it might be, seeing it back now would still be welcomed.

[19:27] News that this may be happening sparked questions about in-world notifications (again, something which had been a little niggle of mine in the past). Responding to these questions, Oz said:

That’s been one of the possibilities that’s been discussed. The principal problem with that is, when there’s a problem with the grid, sending notices to everybody doesn’t tend to work. So it’s kind-of one of those Catch-22 deals. We may try to make that an easier thing for us to do and begin using it more often when we think it will work. But, for example, in each of the problems that Landon blogged about recently, the systems for sending messages would not have worked, so it would not have helped. The problems for which the message system is still reasonably reliable, and there’s something worthy of sending a message to everybody about, may not be a very big set these days.

So it remains to be seen whether this will be taken-up, or whether the Lab will try to more reliably use other means of pushing out messages to users – such as through Twitter. While the latter doesn’t have the same immediacy / directness as an in-world message might, there are many SL users on Twitter who do turn to that service when they notice something amiss with the SL service, so making more reliable use of Twitter would not necessarily be a bad thing.

Viewer Library Updates

[07:05] Monty Linden’s work on cleaning-up the various third-party libraries used in building the viewer has been continuing. The libraries he’s been working on comprise: ares, boost, colladadom, curl, fontconfig, freetype, gmock, libpng, libxml2, openssl, pcre, sdl, and zlib, and his work is now approaching the point where it can go to LL’s QA.  Some of these libraries have been updated to current versions, others are just being built “more correctly”.

Qtwebkit (webkit) is still proving to be a challenge. As previously noted, this is the library used within the viewer for a number of tasks. For example,  it powers the built-in web browser, and is used to display profiles (unless you’re using a viewer supporting legacy profiles). It is also used with Media on a Prim (MOAP) and many in-world televisions.

Commenting on qtwebkit in general, Monty said:

I just so hate that library! This initial release [of the updated libraries], to keep the scope under control, is just going to be a rebirth of the existing lqtwebkit repo. I don’t know what happened in there; I think somebody got in there and tried to bring the company down from the inside using the lqtwebkit repo! [Chuckles.] So … what is coming out is a rebirth of the repo; still 4.7.1, nothing’s fixed, but you can build the thing on modern hardware … it uses the correct libraries to do its things, and we’re going to go out with that as the first pass.

Although still only 4.7.1, the release is seen as being beneficial as it offers some really good improvements and is seen as developer-friendly, code-wise, without the Lab having to run-out a complete version update. However, there are additional versions being worked on as well, and if it is felt that one is required as a release, it will be dealt with separately.

A problem remains with qtwebkit is that it has officially been deprecated, so the Lab is having to consider what to do longer-term. As previously mentioned, one of the options being considered. CEF is the obvious alternative, but would require a significant amount of work to integrate into the viewer, so the Lab has yet to make a decision on which direction it will take.

Boost is another library which causes considerable pain when building the viewer. Work has been going on to clean this up as well, and while it is showing promise, there is still some hackery going on around some of the functions. At the moment the focus here is on trying to make sure the Lab is in good shape to take advantage of some new things which have been indicated are coming down the boost pipeline. When this does happen (later in summer), the Lab will likely revisit the boost library.