|
|
|
Agree completely Haravikk. (doh, on the URL.) Also along the lines of implementation. Should read users 'load automatically' setting and determine whether or not to prompt before use. User triggered URL launches via touch etc. should be automatic, but if called without a trigger from the user, for example on sense - it should require approval by the user prior to launch.
I've been waiting for a proper usable browser in SL for SO LONG. It's very annoying, i never check out hyperlinks from SL because it means minimizing it and choking my already over-choked-and-bottlenecked-by-SL ram.
As http://sexsecond.blogspot.com/2008/02/how-to-browse-web-in-ll-client-really.html
 shows, it is possible to get out to the outside world wideweb via the internal browser, and the browser is relatively functional.
The following features would make this browser far more userful. 1. A direct way of invoking this browser, perhaps through a new tab on search. Even just direct invocation, resize and url would be a considerable improvement. Other clients, such as OnRez offer some of this functionality. The browser in the client is sufficient for many tasks, including editing wikis, email, reading news sites, teleporting to SURLS, and posting to blogs. While the lack of additional windows and tabbed browsing means that no one is going to replace their copy of firefox, the ability ot use the internet in world is a major step towards a "meta verse." Combined with the ability to read multi-section wikipages, it would obviate the need for configuring devices with notecards, thus reducing load on the asset server. I think Haravikk's comment is excellent - it fits in with how other LSL commands work. I fail to see how the X and Y position is too useful though - its not possible for objects to work out the dimensions of the client window to allow browser windows to be aligned within the interface. Its probably better to leave that down to the client.
I'm voting for this - it'd be useful to add a nice interface to objects combined with callbacks using RPC |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
llRequestWebViewer(integer width, integer height, integer xPos, integer yPos)
You may wish to consider an alternative format:
llRequestWebViewer(string URL, list params);
Constants for use in params:
WEB_WIDTH - interprets any following integer as the horizontal width in pixels for the window size, alternatively if the value is a float it will interpret this as a percentage size of the main-viewer window's width.
WEB_HEIGHT - same as for width (above) but for vertical height
WEB_POS_X - horizontal position of the window's centre-point. If an integer is supplied this is in pixels measured from the left of the screen, if a float it is the percentage of the screen-size to take from the left (ie, 0.0 is as far left as the window can go accounting for its size, 0.5 is centred and 1.0 is as far right as possible)
WEB_POS_Y - same as POS_X (above) but for vertical position.
WEB_ADDRESS_BAR - accepts either TRUE or FALSE, determining whether or not to include an address bar for user's to view/enter URLs. Default is true.
WEB_CAN_RESIZE - accepts either TRUE or FALSE, determining whether or not the user can resize the window (windows should always resize to ensure their close button remains visible). Default is true.
Possibly loads more, which is why a parameter list is good.
Also, if a script attempts to open a web-viewer for a user who already has one open for that object, then the existing viewer window is simply resized/positioned, rather than allowing an object to open multiple viewer windows.
Viewer windows opened by an object will always have an addition "Mute" button, allowing the object to be muted to prevent it constantly making this script call.