[sldev] Magical scripted HUD/UI

Geneko Nemeth kakurady at gmail.com
Wed Dec 10 10:06:30 PST 2008


I would like to toss this in here:

http://wiki.secondlife.com/wiki/Client-side_Scripting_for_HUDs_and_Widgets

In any case the objective is to move more HUD functionality to the 
client, since building them in-world is troublesome and its performance 
is at the mercy of the servers.

HTML is good for documents and forms, but isn't really up to building a 
general interface. That didn't stop people making AJAX applications of 
course. (Note that an asynchronous communication with the server, 
similar to AJAX, might be handy.)

On the other hand... XUI in its current form, is quite inflexible. This 
is on the Linden's roadmap, but last time we checked they were working 
on "secret projects".

My personal wish is that improve XUI and add some kind of scripting 
support, so you could put XUI on in-world vendors, HUDs and viewer 
extension packages.


But... we have a third option here.

http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul

Mozilla (now Seamonkey) and Firefox both implements their interface with 
XUL + JavaScript. And currently, the web browser embedded in Second Life 
client is based on Mozilla. That means... we have an existing long-used 
UI description language usable with the browser HUD. Now all you need to 
add is an client API into that.

Of course, allowing HUDs to talk to the client and even to servers could 
lead to new security and privacy concerns.  You don't want random pages 
on the interwebs to send chat spam, or lock the viewer up.

Geneko

Argent Stonecutter 写道:
> On 2008-12-09, at 10:18, Mike Monkowski wrote:
>> "richer dialog" is probably too vague.  Specifically VWR-10924 
>> provides two things.  First, it allows the current UI widgets, with 
>> new callbacks, to be used for communicating with in-world objects 
>> using chat channels.  Second, it allows the current UI widgets, using 
>> the current callbacks, to be rearranged to provide custom UI panels, 
>> menus, and floaters.  In the second case, the purpose of the in-world 
>> object is just to define the new UI component.
>
> OK, you're talking about two separate use cases. I hadn't even thought 
> of the second one, and I think it would be a lot more work than you're 
> envisioning. The SL client XML schema seems to be heavily tied to the 
> files, rather than having the callbacks driven from the XML directly. 
> The extra work of creating a meta-language to define the callbacks 
> outside that context, and managing interactions between components, is 
> likely to scuttle the whole project.
>
> The first use case... an improved dialog mechanism... is much more 
> easily accomplished via HTML. The XML schema is extremely primitive 
> and hyper-specialized, and even modifying the current UI is much more 
> work than creating a simple HTML form.
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting 
> privileges



More information about the SLDev mailing list