[sldev] noob question: is llTextBox in the Snowglobe SVN?

[Fire]

Woa, that would be great Mike,
What UI element for instance, would allow user input?  Thats really what I
am after, because, I'd like a way for students to take entire quizes via
input huds, or compete in an educational adventure game etc... also, would
new UI elements be possible? Ie: embedded video clips?  Thats probably a far
stretch but just checking

Here is the Jira from the link you posted:

This is a design for a scripted HUD/UI requested by Charlette Pronto at a
User Experience Interest Group meeting
http://wiki.secondlife.com/wiki/User_Experience_Interest_Group/Transcripts/2008-12-04
[16:07] Charlette Proto: tell us about the XUI/XML magic Mm if you like

The idea is to allow scripted objects to create custom HUDs that use the
standard GUI widgets. Widgets created out of prims are clumsy and have too
much lag for efficient operation. So here's a solution.

The LSL script command LLDialog does provide a GUI element that does provide
instaneous feedback (it's usually referred to as the blue dialog box), but
it is limited to only twelve buttons in a fixed format, no other widgets are
possible.

The blue dialog box is implemented as a type of notification, but its tie to
that code is not really necessary. It could also have been implemented with
other kinds of button widgets.

The key to tbe function is the ScriptDialog message,
http://wiki.secondlife.com/wiki/ScriptDialog This message delivers 512 bytes
of text, twelve button labels, the object and owner identification, and a
chat channel number for the reply. There is also an ImageID field that is
currently unused. When the user clicks on a button in the blue dialog box,
the viewer generates a ScriptDialogReply message,
http://wiki.secondlife.com/wiki/ScriptDialogReply with the button index and
label. The sim then sends the button label over the given chat channel to
the script.

Now suppose the function that handles the ScriptDialog message were to look
for a keyword in the text, say <?HUD/> and if it found it:

1. Display the prompt "Object owned by Whomever Resident would like to
create a HUD for you. Select a language or Cancel." along with the usual
buttons to select languages (defined by the LLDialog call).

2. If the user selected a language, the viewer would start a listener (let's
call it the HUD builder listener) on the chat channel specified in the
ScriptDialog message (created by LLDialog) and send the button response
ScriptDialogReply to the object.

3. The object would send XML defining a UI display (floater, menu, or panel
in LL parlance) using the same syntax used in Program
Files\SecondLife\skins\default\xui\en-us\ and related directories (or the
equivalents on Mac and Linux)

4. The HUD builder listener would store the chat in a buffer (limit the size
to prevent griefing) and when it recieved an end of file token (or closing
tag if you want to do a syntax check on the XML here) it would pass the XML
to a function similar to the one that builds the UI from the XML now. The
difference is that the XML would come from a buffer rather than from a file.
Bonus points for providing the dual functionality in one method.

5. The XML specifies callbacks for each element. You could use the existing
callbacks to build a reformatted UI element from the existing pieces and so
the purpose of the in-world object would be just to provide the XML and be
done with it.

6. Additional callback functions would be written that send information back
to the object over the chat channel. These callbacks would be selected using
the XML definition. When a button is pressed, its value is sent by chat to
the object. When a slider is moved, its value is sent. You get the idea.

7. For security purposes, you may want to exclude some of the standard
callbacks from being used. The function processing the XML would check a
flag in the mapping table for the callbacks and ignore it or replace it with
a "You tried to do a forbidden function" callback.

8. To the user, all of the widgets would act like any other UI widget giving
instantaneous feedback when clicked or moved, allowing placement in the
window, or creating tearoffs from menus.

9. When the UI element is closed, however, standard GUI functions are just
hidden, but here we would want to actually delete the element. Since the
viewer currently does not delete UI elements on the fly, this will probably
give you a few headaches making sure you don't leave any stale pointers.

Since the changes are entirely in the viewer, this would be a good Open
Source project for anyone interested. I am willing to provide advice and
guidance to anyone, but I already have too many things that I'm working on
to implement this. Add a comment to this JIRA if you have any questions or
suggestions.

Mm Alder

On Mon, Jun 29, 2009 at 7:18 AM, Mike Monkowski <monkowsk at watson.ibm.com>wrote:

> I've convinced Admiral Admiral to work with me on
> https://jira.secondlife.com/browse/VWR-10924 which will give you much more
> than text boxes.  We should have something by the end of the summer.
>
> Mike
> SL: Mm Alder
>
>
>
> Fire wrote:
>
>> Hi there,
>>
>> just a question - I quite excited about llTextBox...  as it would greatly
>> enhance our lovely llDialog!
>>
>> Is llTextBox functionality in the opensource Snowglobe client, or are
>> their any active devs in the sldev community working on this?
>> How big an effort would be needed for this implementation? If you have any
>> idea about this, please share.
>>
>> Thanks!
>>
>>    *Paul Preibisch*
>>    Research Assistant, Sloodle.org
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090630/171b417b/attachment.htm