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
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges
