If we're wishlisting, I'd like to add mouseover options for buttons. Hover mouse over a button for long enough and there's an optional pop-up window next to the dialog showing either some explanatory text or an image.

While we're on the topic of asking for a better Dialog (let's call it, llDialog2), here are some ideas:

* Menu Identity. This allows the script to easily figure out from which menu the value is coming from.

* Decouple between button title and value being sent back. In other words, what's returned can be anything, not just the button's title. This can GREATLY simplify handling!

* Allow timeout; after timeout, the dialog should close on itself, an a proper event is raised.

* Also raise an event if the resident close the dialog box.

* Allow colors. So important buttons (like "Back" or "STOP" or "Exit") can be highlighted.

* Pagination, with possibly different text for different pages.

(Decoupling means that a breadcrumb system can be easily implemented on the scripter's; side the scripter can, say, return value of "M.Options" for the "Options" button in the main menu, then in the submenu the value returned can be "M.O.Len" for the "Length" button in the "Options" submenu. And everything can be handled by a simple if..elseif ladder without having to track which menu was last shown.)

To implement the above, I suggest a new function:

key llDialog2Menu(string menu_name, list page_text, list buttons, integer page_size, float timeout)

* menu_name is the menu Identity; it will be prepended to the values returned the buttons, with a period added

* page_text contains the text for successive pages

* buttons contain triplets of label (string), value (string), and color (vector)

Might need to add another event:

on_dialog(key id, integer type, string value)

* id is the key that matches the one returned by llDialog2Menu

* type can be DIALOG_VALUE, DIALOG_TIMEOUT, DIALOG_CLOSED

* value is the value returned by the button (after having the menu name prepended

I have been intending to submit a feature request similar to this. There are a couple of other features that I would really like to see. Dialogs often are intended to communicate urgent information. That they are all the same color and appear at the same location on the screen impairs their usefulness. I often have one from one script open when another script opens another one. Because they are in the corner of my screen and are the same size and color, I may overlooked that that the second (or third, or fourth) one opened. Can we please have the option of having them not stack on top of one another and the option of having them different colors?

I rather ask for HTML-like UI API, maybe Qt framework. I don't want to be limited by LL's crude designs.

LUA is coming and while it might not be client-side at first, but it can lead to better UI workflow if they played their cards right.

For those who want to make dialog easier for non-programmers... you're just asking for magic.

Great ideas. Dialogs are needlessly complicated, and scripting them, especially complicated ones, is far outside of the skills of average users.

Hello, and thank you for your feature request regarding an improved llDialog function. Another resident brought up a similar idea in the past, and we are merging your comments to get to it faster. We understand how enhancing the llDialog function with features like key/label buttons, colored buttons, more than 12 buttons, built-in pagination, and a menu system could significantly improve both scripting and user experience. We have set this request to tracked, but we have no estimate when it may be implemented. Please keep an eye on future updates. We appreciate your input and hope you continue to share your ideas to help improve Second Life. Thank you!