XMLify the whole UI

A substantial number of the feature requests and technical issues reported in many forums relate to arbitrary choices made in the UI. It occurs to me that LL could avoid the trap of never-ending UI change requests and never-satisfied customers by making the UI entirely XML-based and hence user-configurable. Support would of course be available only to those who have not modified their system, that goes without saying, but that's OK.

XML is already used to a small extent in the client --- I see 29 XML files currently in 1.5.5, and Reload UI XML (Ctrl-Alt-R) from the Debug menu does seem to work, for small mods at least. However, the range of options available for customization is pretty limited.

A general solution using this approach is perfectly feasible. It would need all of the possible UI actions to be listed, as well as all the UI event names that can be used as triggers for binding in the XML. Not all UI events would raise visible panels like in many of the existing XML controls.

For example, response to a RightMouseClick event could be specified by an XML block defining the pie menu, with the default "Edit" subsection calling both an EnterEditSelectedObject action and a MessUpMyCamera action, as at present. Likewise, the default ExitObjectEdit event could also trigger the MessUpMyCamera action as it does now. Needless to say, that would be the first thing most of us would cut out of the damn default.

XMLifying is in general a good thing, and it doesn't have to have any performance impact whatsoever, because the XML is only parsed once, when the user requests it.

I agree that better control of the interface would be wonderful.

Back when I joined (around 1.2) I heard they were already planning on doing this. I think 1.6 was the projected timeframe, but I'm sure plans have changed since then.

Excellent! feature suggestion.

I'm writing an XML UI system for another game due out next year. I'm trying to put as much of the graphical behavior (buttons lighting up when the mouse moves over them) and all of the layout into the XML files. The source code only sends limited data traits into the loaded XML structures, and they do the rest.

The XML even has a psudo-programming system in it to allow one object, a button for instance, to set its position relative to another object. If it moves, so does the button. It's simple, but quite powerfull.

So this sort of thing is quite doable... But not something that can be dropped in with only a month or two's worth of work from Linden Lab. With more power comes a greater potential for bugs.

TC, you are a god.

Btw, yes, nobody that's remotely reasonable should expect full support if they modify their clients away from default, because the combinatorial explosion of possible configurations is then not amenable to full-coverage testing.

Despite that, I'm always happy to accept the risk along with the extra flexibility it gives.

This is something I want too.

As Moleculor already said, they fully intend to make the GUI fully XML, but are doing it one bit at a time. I have been constantly testing how far they are with allowing us to skin with each new release, the latest release added some more buttons to be skinned. I believe skinning/XML GUI would be on the "back burner" of things they're doing little by little sadly.

The projected was 1.5-1.6 but more than likely this has been moved up to 2.0 or later

/agree

Let's also integrate Flash / Shockwave, Mozilla, and an easy text system so XyText can go into retirement

Although I do see the smiley on the end of that, there is indeed some scope for enhancements to do with information linking between worlds, as well as with in-chat SL object references.

For example, in various MMOGs, you can create an object reference and paste it into private or group or area chat, and the remote reader can click on the highlighted reference and bring up its details, including a thumbnail.

SL has scope for something similar, and it has the supreme advantage over most other worlds of already possessing the ability the stream anything it likes. Consequently, if Eggy pastes his lovely Austrian frock into an IM chat line to me (which only inserts a reference), there is no strong reason why the object shouldn't appear in my cache and be displayable when I click on the reference at my end, for my admiration. The streaming subsystem is the bees' knees for this.

Where are we on this issue now?

Has LL increased the amount of XML'ifying since the last time we looked, way back?

Morgaine,

If you put a proposal up on this, I'll vote for it. (If you've already done that and I missed it, please post a link here.)

neko

I've put this up as a proposition already (#120) the details can be found in this thread

/me applied all ten of my votes to this proposal

Excellent! Thanks Cienna, that's going to get my vote right now.

Thanks, Cienna -- as promised, I've added my vote.

Do you think for political reasons it might have been better not to make the comparison to WoW? Though I suppose the competition might help spur LL to actually do something....

neko

Right up to that point I am 100% with you.



Why use a completely new developement technique for the user interface when we already have something awesome?

Let's use the 3D world engine to do your client user interfaces. I would love to construct a 3D toolbar using prims. All we need is more functions to control the client, like llUploadTexture, or llToggleMapDisplay. Simply create a box, attach something to on_click, and dock the prim on your screen.

Users/builders/scripters already know how this environment works, let's re-use that knowledge.

Obviously there are still a few missing blocks for a true functionnal 3D interface, the biggest one being a good text support. But being able to display HTML (and who knows, maybe javascript and CSS too) would practically make the thing possible right now.

On a related note and if the idea interests you, I suggest you also have a look at my other thread where I discuss client-side prims.

Jaynius, UI-dockable client-side prims and even client-side LSL scripts to drive them would be fine by me. In fact, that would even provide some nice consistency, and would avoid the ickyness of yet another language like the proposed Javascipt.

In fact, the Javascript was the only part of Cienna's proposal that I didn't like at all ... if we're going to have a different language that isn't LSL, then we might as well stick to Lua as in WoW! It would be a hell of a lot easier to integrate than Javascript, enormously faster, hugely flexible, and easier to sandbox.

Moving over to Cienna's thread to discuss this in more detail.