Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Captive windows in SL

Doom Looming
Registered User
Join date: 6 Nov 2007
Posts: 2
11-30-2007 10:37
I expect this has been discussed in the past, and I am not sure of the correct windowing terminology for what Im thinking, but Is there any plan to allow windows such as search, Inventory, preferences, and in fact any window within the SL client to be broken out of the main view window? This would be cool for many reasons, not the least of which is that on a dual headed, 2 monitor system you could have your mainview on one monitor and your tools on the other. Even if the windows were still captive within an application window, if the main view were its own window, then the applaication window could be stretched over 2 monitors with the windows sized in a usefull format that minimized obstruction of the main view or for that matter, the main view shrunk down temporarily on a single monitor system so you could have inventory, notepad and such arranged for say an inworld scripting class.

Probably not the best description of what I'm envisioning but I think I got my idea across.
Matthew Dowd
Registered User
Join date: 30 Jan 2007
Posts: 1,046
12-01-2007 00:58
There's *talk* on the SL Open Source developers list.

The current windows are actually drawn via OpenGL - or in other words are draw on the main window as if they were just another object in the scene such as avatars, prims etc.

This has the benefit that it is very portable (the code works on any platform which supports OpenGL and the windows all look the same).

It has a number of disadvantages:

there is no seperation between the draw of the 3D scene and the draw of the UI components. If something causes the fps to stutter the UI slows as well.

as OpenGL only allows you to draw within the window, you can't have UI components display outside the SL viewer.


There has been discussion of replacing these LL grown OpenGL UI compionents with various opensource UI libraries which would (at some level) access the operating system's UI components directly. This would have a number of advantages: windows outside the viewer; UI remains responsive during low framerates.

There is however the question of choosing a suitable UI library with ideally would be opensource, well maintained, supports a wide variety of platforms. A number have been suggested but I don't believe there is any clear consensus.

Also, replacing all the existing UI components with such a library is a non-trivial task. It isn't a task LL seem keen to undertake, and whilst there are a few external open source developers who might be willing to take it on, it isn't clear the LL would regard the work needed to import such a patch as a particularly high priority.

Matthew