[JIRA] Commented: (VWR-10924) Magical scripted HUD/UI

TigroSpottystripes Katsu (JIRA) no-reply at lindenlab.cascadeo.com
Fri Jan 29 13:37:41 PST 2010


    [ http://jira.secondlife.com/browse/VWR-10924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162710#action_162710 ] 

TigroSpottystripes Katsu commented on VWR-10924:
------------------------------------------------

i do consider this a step in the right direction, i brought up the idea of letting scripts define the interface by themselves to help not close any doors and in the hopes that it wouldn't require much beyond what is being done for static GUI designs in order to be implemented together with that

> Magical scripted HUD/UI
> -----------------------
>
>                 Key: VWR-10924
>                 URL: http://jira.secondlife.com/browse/VWR-10924
>             Project: 1. Second Life Viewer - VWR
>          Issue Type: New Feature
>          Components: User Interface
>         Environment: Any
>            Reporter: Mm Alder
>         Attachments: example_.xml.zip, MSH1.1.patchfile, MSH1.2.patchfile, MSH1.patchfile
>
>
> 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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.secondlife.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the Jira-notify mailing list