RFC : responding to the "Ignore" button on dialog boxes

Making the "Ignore" button smaller is a good idea, but I would like to be able to allow a script to react when a user selects "Ignore".

I think the following changes would allow this, without breaking any code that currently exists:

1. Have llDialog() return a key value (it currently doesn't return anything).

2. Introduce a new callback function "ignore(key dialogkey)" that is triggered when the user pushes the ignore button. (The parameter is set to the key value of the ignored dialog box.)

These features would permt (but not require) scripts to react to ignore button presses. Existing code would adapted very easily : just save the returned key value of the called dialog box in a global variable, and add an ignore function to the state in which the dialog box is called. You wouldn't have to touch the listen function that reacts to the other dialog button presses at all.

If nobody complains about this idea, and a few people support it, I will submit it to the "vote for" feature of this website.

If you're going to suggest adding an entirely new event and modifying the llDialog processing to use it, can I suggest actually adding a dialog() event and working the ignore functionality into it? It's kind of a hack to use listens the way things are right now. It'd love to see this worked into its own full-fledged event.

Its possible to get the same functionality by just setting up a timer, to Timeout after x seconds. So if someone did hit Ignore, you could rollback to certain functionality.

Its not perfect, but It is how Me and a few of my friends have worked around the Null action of Ignore.

I too would like the dialog to respond to an event of its own, it would certainly reduce listener lag. There is an in game LSL suggestion box which you could submit a notecard to with an elaborate example of how the dialog should work, or even for you to code (in which ever language you're familiar with) how to make it work or an equivilant. I'd love dialogs to be set up like Java, for instance.

1. I too would like to have a real dialog event (and while were at it, how about a broader selection of controls, like text boxes, spinners, radio buttons, check boxes, etc.). My proposal just asks for a minor improvement in the way one little thing is dealt with.

2. The trouble with timeouts is that you can't tell the difference between somebody who pressed ignore, somebody whose just walked away and forgot to close the box, and somebody who was standing there thinking about what to do next when the timer rang.

If you want your script to have a null button that you can react to, make a "cancel" button.

The whole point of the "ignore" button is that it's NOT handled by the script. So you can always close the dialog even for buggy scripts.

Lee,

I'd support any improvement to llDialog(); here's my feedback on your tentative proposal:

1. Return value - not likely to work; as I understand it, llDialog is like a "throw the ball over the wall and listen if someone says ow", where control is turned from server to client.

2. On detected event processing; more potential here, as this could work with the client issuing some signal back to the server, triggering an event.

May I suggest this thought: when Ignore is clicked, have the client send 'Ignore' just like any button to be picked up by the listener event?

As Argent indicated, there are some end-user experience ramifications to changing the functionality as it stands. I like how a user can "get out" of any client-side "blue box" (true with nearly any kind of GUI). Like in a payment, there is a cancel (can't think of any other client-side blue box input situations).

If we propose LL map ignore to a functional result, and the LL system architects think like me (self-depreciating comment suppressed), then I would anticipate the 'Cancel' button being added to the dialog box. Think in terms of abusive spyware that opens up your browser so you can't click out of it... I see the 'Ignore' button serving that kind of 'close the window go away' function now.

Your post inspires me to perhaps write a vote/proposal of my own to add in a text box option as part of llDialog where the user can type in a string to be returned. I like that the reply to llDialog is always centric to the object which 'asked' so the answer is always in range for the listener.

Hope my feedback helps you write a good proposal!

I appreciate the comments. I don't want to get into an argument, but I do want to point out that the suggestions do not accomplish what I'm after.

1. I want script to react to the user hitting the ignore button. Under the present functionality, I have to wait for a timeout, and even then I don't know if the user hit the ignore button or is just standing around thinking about something. Adding a 'Cancel' button doesn't solfe this.

2. The effect of hitting 'ignore' under my proposal remains exactly the same as now. The script can ignore if it chooses, but the dialog box closes anyway. My proposal merely makes it possible to react to hitting 'ignore' if I want to do so.

3. In my proposal reacting to an ignore event and deciding which dialog box caused this event using a global key is exactly the same as reacting to a dataserver event and deciding which notecard (say) you've asked to be read. When you ask to read a line from a notecard, the server spawns a process to do just that, but immediately returns control to the script. Sooner or later, the dataserver kicks in. I don't see any difference in the basic architecture between these two instances.

4. Having the dialog box send the word 'ignore' to listen when the user presses the ignore button might be an improvement. But, if you have more than one dialog box, how would you know which one raised this response? Also, this 'fix' could break existing code : 'ignore' could trigger an "else" clause at the end of a chain in listen, and make something happen that's quite different from what you want to happen when the 'ignore' button is pressed.

5. Yes, under my proposal there is an opening for abusive code : I could program a script that would just open the dialog box again if the user hits ignore. Of course, under the current setup I can open the dialog box again when it times out, so I can write a nasty script now if I'm so inclined.

this is good but could be made better:

Like instead of an ignore event, lets take this further.

key id;
string user;

default
{
    touch_start(integer a)
    {
        user = llDetectedName(0);
        id = llDialog(llDetectedKey(0), "Click a Button", ["A","B","C","D"], (integer)llFrand(-2147483648.0));
    }
    dialog(key query_id, string button)
    {
        if(query_id == id)
            llWhisper(0, user + " click \"" + button + "\"");
    }
}

BTW this should be in feature suggestions.

The problem is that this is a change in functionality. If your script has a bug, it may not be possible to get the box to go away and not come back without moving out of listen range of the object, hitting a *different* key than ignore, and coming back again.

Why make it a dialog() event? What's wrong with using the existing dataserver() event?

But if you're going to "fix dialog", then let's fix it right:

key llNewDialog(list dialog)

DIALOG_BUTTON, "label", "name"
DIALOG_CHECKBOX, "label", "name", is_checked
DIALOG_RADIOBOX, "label", "name", is_checked
DIALOG_LABEL, "label"
DIALOG_NEW_LINE

dataserver(key id, string value)
{
    if(id == dialog_id)
    {
      string l = llParseStringKeepNulls(value,[" "],[]);
      string name = llList2String(l, 0);
      if(name == "") return;
      string value = llDumpList2String(llList2List(l,1,-1)," ");
    }
}

The single greatest improvement you could add to the dialog box... is a settable timeout .
llTimedDialog(integer channel, string str, list buttons, float timeout);
and have it ignore automagically after timeout expires.

In the far far future when lsl actually becomes a language. a key returned by the llDialog call that would allow you to cancel dialogs explicitly would also be welcome.

Walking away from the object wouldn't help; when you hit the button, the message is said centered on the object that called llDialog(), not on the person that got it. Only way to get out if Ignore did something would be to either stop the script from running, or remove the object. Personally, I'd prefer to keep Ignore as it is, but being able to close a dialog box from the script would be nice.

There are three issues here:
1) Whether a script should be able to capture the Ignore button from Dialogs (and possibly Pay);
2) How the feature set of Dialogs could be enhanced;
3) Whether the API around Dialogs more generally should be changed.



While 2 and 3 are very open questions 1 is not.
It is a simple yes/no about the power of the user as compared with the script.

It would certainly be useful to script writers to gain more 'control', but I don't think that just because you _could_ easily write an abusive script which keeps re-presenting a Dialog means that it is necessarily a good idea to make it easy to re-present Dialogs.

Menu systems with errors, let alone script-kiddie type abusive coding, would be much more likely to have problems if Ignore messages were sent. Users would be more likely to be shown unwanted Dialogs and have to move away to get rid of them.


I think that the user experience should come first and ignore buttons should mean that. The user has ignored you and you will not receive another event from them.


Peter

Even if you're not in the same sim?
Yah. Add a DIALOG_TIMEOUT, seconds to that proposal above.

Just tested this out. Clicked an object to get a dialog, flew to the next sim and pressed a button. The object did recieve the command. However, this also caused the object to no longer hear any commands from the dialog until the script was reset. I believe I've seen that somewhere as a known issue, just not sure where it was.

Could you post an example list to feed to llNewDialog with a mockup of what the layout would look like? i'm having trouble envisioning this (though i think its a good idea).

But lets take this another step further. Using dataserver compilcates parsing.

dialog(key id, integer event_type, string event_lable, list values)
event_type would be either BUTTON_PRESS, CHECKBOX, RADIO, TIMEOUT, CLOSE, SCROLL_DOWN, SCROLL_UP, SCROLL_LEFT, SCROLL_RIGHT
event_lable would return the lable of the element that generated the event.
values would contain a list of DIALOG_* constants each followed by it's lable and attributes
llCloseDialog(key id) close a dialog box by it's key, pressing buttons in the dialog box close the box (unless they clicked the "X".

One thing about all this, is that llDialog as is does something important and unique. It's the only way to force an avi to actually say something and many scripts depend on that.

Wouldn't it be best to create a completely different thing rather than replace the functionality of the current llDialog function?

Actualy yes, we discussed that higher up that the function name would be llNewDialog

Whilst you remain a child of the sim that the object is in llDialog will still work for you... How long that it depends on a timer (about 60s if you tp away) and whether or not you can see in to the sim (in which case you remain a child).

[ DIALOG_LABEL,"Select new color and click OK:",
  DIALOG_NEWLINE,
  DIALOG_RADIOBOX,"color","Red",0,
  DIALOG_RADIOBOX,"color","Blue",1,
  DIALOG_RADIOBOX,"color""Green",0,
  DIALOG_NEWLINE,
  DIALOG_CHECKBOX,"flags","Permanent",0,
  DIALOG_NEWLINE,
  DIALOG_BUTTON,"response","OK",
  DIALOG_BUTTON,"response","Rescan"]

+-----------------
| Select new color and click OK:
| ( ) Red     (x) Blue    ( ) Green
| [ ] Permanent
| ( OK )                      ( Rescan )
|

It does, but it already exists and will serve the purpose. With the dataserver event something like the code I used would be necessary. With a separate event, you'd have something like dialog(key agent,list response), where response is a list of name-value pairs. For example, ["color","blue","response","OK"].

I'm not sure I like your "event" model. I don't want the dialog to generate a stream of events, but rather a virtual list of values after a button is selected... it sounds like you want to get notifications of every change in the dialog... that's not really necessary: if you want real-time responses then let them click on prims and use XYText (or, better, some kind of Linden-supported llPaintText). But... if you're going to go with an event-stream model, then dialog(key agent,integer event,string name,string value); would work as well as one with a list, with a special DIALOG_CLOSED event.

What's the "SCROLL" event for?