Difference between revisions of "LSL Browser HUD"
Jump to navigation
Jump to search
(New page: {{TOCright}} * Initial Design Doc here: Browser_HUD_Design == Scenarios == "Browser HUD" is a small HTML web-browser widget that appears in a 400x300 pixel window in the top-left co...) |
|||
Line 1: | Line 1: | ||
* Initial Design Doc here: [[Browser_HUD_Design]] | * Initial Design Doc here: [[Browser_HUD_Design]] | ||
Line 90: | Line 88: | ||
** least amount of distractions in order to make it easier and simple for users | ** least amount of distractions in order to make it easier and simple for users | ||
** '''Should we allow resize?''' | ** '''Should we allow resize?''' | ||
== Links == | == Links == | ||
[[PERMISSION CONTROL BROWSER HUD]] | [[PERMISSION CONTROL BROWSER HUD]] |
Revision as of 14:25, 9 April 2008
- Initial Design Doc here: Browser_HUD_Design
Scenarios
"Browser HUD" is a small HTML web-browser widget that appears in a 400x300 pixel window in the top-left corner of the screen. It will be used for our internal OI tutorial (replacing the attachment-based HUD).
These LSL commands will let content creators control this Browser HUD to:
- Display a HUD with user customized URL
- Controls for a vehicle?
- Map of a store?
- Interact with objects through chat on specific channel with special secondlife:// URLs
- Works like llDialog(). The Browser HUD window remembers which channel to chat on
- User can add links or buttons.
- Use links like: secondlife:///app/browserhudchat/vehicle-set-color-red
- Clicking that URL makes the client "chat" on a script-channel, set as part of script call.
- Easier to localize/update tutorials than attachment-based HUDs
We require a permissions check for this:
- To protect users from getting spam browsers or other type of unwanted browsers
- See PERMISSION CONTROL BROWSER HUD for details
Function
Function Name | Parameter(s) |
---|---|
llMiniBrowserCreate ( ) | ( key agent_id, string title, string url , vector size, integer channel_number ) |
llMiniBrowserDestroy ( ) |
Requires script permission PERMISSION CONTROL BROWSER HUD, requested through llRequestPermissions().
Params
Constant Name | Description | Parameter(s) | Example Rule | Value |
---|---|---|---|---|
BROWSER_HUD_TITLE | Title for Browser HUD | string title | [ BROWSER_HUD_TITLE, "Tutorial" ] | |
BROWSER_HUD_CONTENT_URL | URL for this browser HUD | string title | [ BROWSER_HUD_CONTENT_URL, "http://randomuser.com/vehicle.php" ] | |
BROWSER_HUD_SIZE | Size for HUD window content area (not including title bar) | vector size in pixels, <width, height, ignored>, clamped to SL window size, or 500x500, whichever is smaller | [ BROWSER_HUD_SIZE, <400, 300, 0> ] | |
BROWSER_HUD_CHAT_CHANNEL | chat channel for browser HUD | integer channel_number | [ BROWSER_HUD_CHAT_CHANNEL, 123] |
Implementation
- Server (via LSL) sends client message to create browser hud
- Checks for permissions first
- Client creates browser HUD (class LLFloaterHUD)
- Chat channel is set to 0 by default, can be changed by LSL
- int mChatChannel will have a record of what channel the browser is currently using.
- Destroy browser HUD when user closes the window, or when script requests it
- Must allow user to destroy window in case:
- script times out, or crash
- script goes out of range
- Possible implementations of LLFloaterHUD window. Which should we do?
- case one browser per agent
- the last browser creating LSL call gets the single browser HUD
- case one browser per object:
- Client has one window per object-id, allowing multiple objects to each have their own HUD window
- Object ID is obtained automatically from message, user doesn't need to type it into script
- Browsers will stack up like image previews when multiple of them are created
- case one browser per agent
Differences between Browser HUD and Media Browser
- No back or forward buttons or address bar for browser HUD
- least amount of distractions in order to make it easier and simple for users
- Should we allow resize?