Proposed LSL function: llTextInput

I propose creation of a new LSL function that would trigger a dialog-like interface (like llDialog) but will allow direct text input onto a specified channel. This will allow easier resident interaction with scripted prims and objects throughout the world.

Yes, I acknowledge it is already possible for a resident to talk on a specific channel using /commands. That method isn't intuitive, requires user education, and unfortunately lends itself to error. And frankly, it's a pain in the butt.


My proposal is as follows:

llTextInput( key id, string message, integer channel, list settings )

Shows the user specified by <id> a popup dialog box (in the upper right corner of their SecondLife window) containing <message> and a text input box (limit of 255 characters). Clicking on the provided "Send" button will say the contents of the text box on channel <channel>.

Even though the chat will originate with the user's name and key, the chat position will be centered at the object calling llTextInput. This ensures the object will be always within listening range of the answer.

The list <settings> will function like the list passed into llSetPrimitiveParams, wherein settings can be applied to the textbox. Possible options would be character masking (for password purposes) and inputmasks. Having this parameter in place allows for future extension of the function without depracating it or breaking scripts already utilizing the function.



(Apologies if this proposal exists elsewhere, I haven't been able to find one. I've seen somewhat related variations, but nothing similar enough for me to jump onto.)

Formally added as Proposal 2448.

http://secondlife.com/vote/vote.php?get_id=2448

Too bad there was no time for discussion before the formal proposal was made. Anyway, the base API should include a 'string buttonText' so we could customize the affirmative button the user would click after filling in the input field. There should also be a way for the user to dismiss the dialog.

Personally, what I would rather see:

1. An extension or alternative to llDialog() that is form-oriented. Text input fields, text areas, radio buttons and checkboxes should all be supported in addition to labels and buttons.

2. Acting on those input widgets causes events to be generated, rather than chat messages. It would be up to the script's dialog event handler (e.g., on_dialog) to send chat messages if required by the application. Single object scripts no longer need to listen to channels to use a dialog.

3. Clicking on a dialog button does not automatically dismiss the dialog. An event is generated but the dialog remains. It would be up to the script to dismiss the dialog at an appropriate time, or after a timeout period.

4. Optionally allow the script to set the initial size and position of the dialog box, and let the user reposition it.

5. Optionally allow the script to set the background color, text color, texture and alpha of the dialog box.

6. Optionally provide standard (common) dialogs.


Sound like a lot, but really those are standard features all dialogs should support.

-peekay

Linked is an example of what this should look like.

http://jgroshomme.somee.com/img/llTextInput_example.gif

Ooh, that I missed. Although the official prop does link back to this thread, so your suggestion shouldn't get lost.

I figure (see my example) that since llTextInput() would ideally based off of the existing llDialog() example, it would have a built-in Ignore button.

I agree with you on your larger proposal as well. I proposed this as a way to try and fit as much functionality as I can into an existing product, since the blue box already exists in llDialog() and in system messages.

I'll add a couple of my votes; having any input box is better than none. Hopefully other scripters would also add their votes.

Given that LL already has HTML in the UI, how about using that? This would be infinitely more useful than HTML on a prim!

llDialogHTML(integer channel,string title, string HTML,key id);

HTML is either the name of a notecard containing the HTML, or a valid HTML body starting with "<BODY>", ending in "</BODY>", and containing at least one "<FORM>" tag. The leading "<" would distinguish the two cases.

When the use clicks on an <INPUT TYPE=SUBMIT> button in the dialog, then they chat on the specified channel a line containing the encoded "GET" response.

list llResponseToList(string response);

Converts "a=foo&b=bar" to a list ['a', 'foo', 'b', 'bar'].

string llList2Response(list l);

Reverses the above conversion.

What you appear to be suggesting is the ability to create what looks like a normal windows dialog.

For one idea I have had that would be ideal .... with that all I need is some inventory manipulation functions ... for those of you worried that I am going to try to create "Son of CopyBot" I am not thinking along those lines ... what I am thinking about is moving items from one place to another (all places to have the SAME owner [kills the possibility of son of CopyBot] and allows manipulation where permitted.

I have mixed feelings on using request-response model for dialogs, especially using chat messages to represent requests. Dialogs should be event-driven. If you look at Ajax, even the web is moving away from pure request-response. There are certainly pros and cons of either approach, mostly comes down to control vs. simplicity.

There are also hybrid solutions. Imagine an HTML-like form, but as you toggle a checkbox for example, an event is also generated. A 'submit' button causes the form to be "posted" to an event-handler, instead of a GET to a channel. The dialog remains until it is dismissed.

In any case, I don't mind using XML to define / declare dialogs, instead of (or as an alternative to) defining them programatically.

-peekay

I agree with the eventual features you guys have posted... eventually. I think it should be broken off from this proposal and be made into its own, so it can have its own rightful discussion.

I submitted this proposal as something that would meet our minimum needs, with (hopefully) as little Linden development as necessary, by reusing as many existing elements and possible.

This is one case where I'd rather see the smaller simpler feature get added and let them worry about adding a major feature-rich system at a later time when all benefits and drawbacks of it should be discussed.

I agree. Maybe you can rally those in the scripting forums to put in their votes.

You can have mixed feelings about it if you like, but that's how LL implements dialogs, and it works well for simple forms. AJAX is much more powerful, but also much more complex... and for event driven programs with multiple states I'd MUCH rather see them stay in LSL with improved prim-based objects that work *outside* the "HUD" environment as well.

With the hybrid approach I suggested, simple forms would be even easier to use than llDialog() today, and also makes possible more advanced uses.

First let me elaborate what I mean by a hybrid approch. In the this approach, you have:

1) Regular controls such as labels, buttons, text input field, text areas, radio buttons, checkboxes, drop downs, etc. An event handler is invoked each time a user interacts with them, passing the control's id and event data (such as "button 2 pressed". Clicking on buttons does not cause the dialog to be dismissed.

2) A "submit" button control. This button sends the current the state of all the dialog's controls to the event handler. Optionally it also dismisses the dialog.

3) A dialog timer. On expiration, an event is generated to the dialog handler (like anything else) and optionally dismisses the dialog.

Simple dialogs can take advantage of the "submit" button. It is analogous to an HTML POST. This approach is actually easier to use than llDialog: for single object scripts, you no longer need to set up & tear down listeners, have a timeout timer, etc. You might also do away with manually "parsing" what was "said" in a channel. All the data you need is passed at once to the event handler.

Advanced dialogs can take advantage of the fact that individual controls will generate asynchronous events. They may mix and match regular controls with submit controls.

In either case, this approach is simple to use and implement, because everything works the same way (by invoking an event handler.) You can handle just one event type, or you can handle them all, it's up to you.

It would also be very easy to write an event handler that simply "says" what event occured, to simulate what llDialog() does today. So from the programmer's point of view you've gained so much and lose nothing.

-peekay

Gratuitous bump.

Start from the beginning:
/13/3e/152183/1.html#post1351475


Vote for Proposal 2448.
http://secondlife.com/vote/vote.php?get_id=2448

The problem is that adding a new event to LSL is a much bigger problem for implementation by Linden Labs, than adding a new client interface that uses the existing APIs and only needs the code to marshal the arguments to an LSL call and pass them over the network to the client.