Feature request: Function llCustomDialog()
tracked
Jenna Felton
The function llCustomDialog works similar to llDialog function but allows creating more modern and fancy dialogs.
key llCustomDialog(key avatar,
string message, list buttons, integer channel,
list options);
The return value is not used at time. It can be used in future to identify open dialogs (and for example to let the viewer close it).
The options parameter allows the scripter to control rendering and behavior of the dialog. I organized it in 3 categories.
1. Dialog symbol options
A dialog symbol is a large symbol shown at the side of the text. The actual position and size of this symbol is up to the viewer.
This option defines static dialog symbol:
[CUSTOM_DIALOG_TYPE, key symbol]
The symbol parameter is a key of the image to show as the dialog symbol. Additionally we can define key constants using pre-defined dialog symbols:
CUSTOM_DIALOG_TYPE_CONFIRMATION,
_INFORMATION, _ERROR, _WARNING, _OPEN, _TRANSFER.
The types OPEN and TRANSFER are used to confirm opening of product boxes or transferring items to someone else (usual operations for vendors and product boxes).
To animate a user-defined dialog symbol we use this option block:
[CUSTOM_DIALOG_TYPE_ANIM,
integer mode, integer sizex, integer sizey, float start,
float length, float rate]
The parameters are quite similar to the llSetTextureAnim so that we not need to describe them. When no CUSTOM_DIALOG_TYPE option is set, the dialog will show no symbol. When a predefined dialog symbol is used, the animation option is ignored.
2. Tab-stop option
When I create dialogs I mostly want to provide some information and I'd like to make it look like a table. This option aims to acheive this:
[CUSTOM_DIALOG_COLUMNS, string columns, integer softbreaks]
The parameter columns is a comma-separated string of column definitions, as "<size><alignment><margin>".
- The size and margin are given either in pixels or in ratio to the size of the text area.
- When size is omitted, it dynamically adaptes to fit the content.
- The alignment is one of 'L', 'C', 'R' and is mandatory.
Example:
[CUSTOM_DIALOG_COLUMNS, "50 L, 0.75 L 5, C", FALSE]
Here we define three columns and forbid softbreaks. How the dialog renders the text?
- When a text line contains "\t" characters, these segmentate the text line into columns.
- When a text segment is too large for staticly defined column, it continues in the next column.
- When softbreaks parameter is TRUE, a text segment which is too large for a column is broken in lines which remains in the same column.
- When softbreaks is FALSE, the dialog shows a horizontal scroll bar when the text is too wide.
3. Metaoptions
These options define the behavior of the dialog and it's lifetime.
[CUSTOM_DIALOG_LIFE, integer time]
When time is positive, the viewer should clean the dialog away after the given time. The viewer may display the remaining time in the dialog window to warn the user.
[CUSTOM_DIALOG_REPLACE, string response]
When a dialog is replaced by an other dialog sent from the same device then the viewer should send the response string on the dialog channel to report this.
[CUSTOM_DIALOG_IGNORE_BUTTON, integer hide, string response]
This option allows to handle the ignore button.
- When hide = TRUE, then the ignore button is hidden, the response parameter is then ignored.
- When hide = FALSE, then the response parameter defines a string to be sent when the user presses the ignore button.
This option allows scripts to recognize pressing of the ignore button or hide it when it uses a menu button for same purpose.
4. Button symbols
This part is controlled by button names. The Idea: I'd like to show certain symbols together with the buttons text. Like this: "🔧 settings".
One can do this by using Unicode characters in the button text but I'd suggest to define the symbols logically: The button name should start with the symbol enclosed into curly bracket:
"{symbol}button name"
The symbol name can be a
- Unicode character, e.g. "{🔧}settings",
- Texture key to use,
- Logical symbol name, e.g. "{CONFIG}settings".
It is up to the viewer to choose the symbol, its size, position, and the distance to the button text.
Note: When a button is pressed, the viewer will only send the button name but exclude the symbol definition. For example when button "{CONFIG}settings" is pressed, only "settings" is sent. This enforces the scripters to use button names the user will recognize even if the viewer not knows how to show the button symbols.
Following symbol names should be defined:
OK, CANCEL, ABORT, STOP, YES, NO, IGNORE, UNDO, REDO, RETRY, HELP, INFO, OPTIONS, CONFIG, WHITELIST, BLACKLIST, CLOSE, EXIT.
The symbol names are strings, only known to the viewer. The server will not parse the button names for them. This list can be extended in future.
Log In
Bleuhazenfurfle Resident
{} is very plausible as valid text at the start of a button (especially if we want to allow a symbol with no text). However, it could be done with a controlling option that turns the feature on, though, a simple separating | character or something (even just a space) would probably be better. (CUSTOM_DIALOG_SYMBOLS)
Some other options we've been desperately wanting forever;
* Ability to specify a different text to be sent back, from the text presented on the button; an option that turns the buttons list into a 2-stride for this purpose would be fantastic. (CUSTOM_DIALOG_RETURNS) Could perhaps take an int instead of a bool, allowing some lighter-weight options like responding with the buttons index rather than it's text; 0 = button text, 1 = button index, 2 = 2-stride with value to be returned.
* Ability to include a prefix for the returned value; would also fit just fine as an option. (CUSTOM_DIALOG_PREFIX)
* Sane button ordering. (CUSTOM_DIALOG_SANITY) That option name is a joke, but the idea is not.
* Let a button with no text, not show any button at all. Alternatively, some specific text, or some specific text specified as an option (allowing it to be trivially retro-fit to existing scripts), or a special symbol name (if that feature is implemented).
* Allow some buttons to be disabled (and not clickable), or even actually just show the text where the button should be without a clickable button at all. (Could also be a special symbol names.) This feature can supersede the prior one if "text without an actual button" is an option.
For the last two, if symbols aren't implemented or can be optional (as per my suggestion at the top), an option to enable it, and then adding a "button state" integer (normal, disabled, text only) to the stride of the buttons list is probably a better option. Alternatively, a bitmap of buttons to disable or do text-only could work (though you'd no doubt receive hate mail from some scripters who don't like having to do math).
Jenna Felton
Hi Bleuhazenfurfle Resident,
Thank you for your comments and suggestions!
* The curly brackets can be indeed a wanted button character, as well the pipe character. But I like the suggestion of the pipe character as a separator, it allows to define more then two parts for a button text.
* So I am for the pipe suggestion now :) But because the pipe character could be also a part of the button text, I'd suggest to add an option
[CUSTOM_DIALOG_BUTTON_SEPARATOR, string separator]
here you can define any separator you want which would not clash with used text of all buttons. By default it will be the pipe.
* Making a menu button show one text but return something else is really interesting idea. It would allow for example to show on a button the login name of a resident but send their key when clicked, and save so the keeping the list of the residents in the script memory and looking up for the key, really cool.
However, for this idea it should be possible that a button can send more then 24 characters of text if clicked.
* Making a button look&feel disabled is also pretty interesting.
* I did not understood what you mean with "buttons having no text or not show at all". When you want this you can give button a space (no text) or not list it in the buttons list.
* Altogether I'd suggest to allow defining a button text off multiple parts connected via pipe character, for example
"CONFIG|options|config|1"
The parts (we can call them parameters) of the button would be
- button symbol
- button text (visible as button in menu)
- button value (what the viewer will send when button clicked)
- options (a bitflag, e.g. 1 if button is enabled, 0 if disabled)
When the button uses no pipe character, the whole text is handled as the button text and button value (missing value inherits from text).
If one wants to define parameters, giving all 4 may feel too complicated, thus there could be an option defining which parameters will be actually used and which not. We define this via
[CUSTOM_DIALOG_BUTTON_PARAMS, integer params]
params is a bitflag selecting which button parameter is used. The used parameters must appear in the order above. When the option is not set, by default are two parameters used, the button symbol and the button text (which equals the button value).
Jenna Felton
Rethinking it once more :) I think CUSTOM_DIALOG_BUTTON_PARAMS is not actually needed. The viewer will understand what is what when you give less then four parameters if the order is right and right separator (e.g. pipe) is used:
When the button is "help" then the button will show as [ help ] and send "help" when clicked (no symbol and the value = text).
When the button is "HELP|help" then the button will show as [ ? help ] and send "help" if clicked (symbol is used, but value = text).
When the button is "HELP|" then the text = value is empty, the button will show as [ ? ] but send nothing on click (no idea how it is useful).
When the button is "HELP|hilfe|help" then the button will show as [ ? hilfe ] but send "help" on click ('hilfe' is 'help' in german).
When the button is "HELP||help", then the button will show as [ ? ] and send "help" on click (the text is empty but value set).
And when the button is "HELP|help||0" then the button will show as [ ? help ] but it will be disabled (the last parameter is the option which only disables it by now) so that we not need give the value here. Usefull maybe when there is no help notecard installed.
Bleuhazenfurfle Resident
Jenna Felton: If you're dead set on cramming it all into a string;
- There are some unicode options that probably don't even make sense in button text. Going that route, you can even put the button text first, and each optional part gets it's own prefix (separator).
- Other good options for a normal-text default are ` (backtick), and ~.
Regarding, "buttons having no text or not show at all":
- Allowing a "diamond" button arrangement, by not showing any buttons in the corners (no button, and no text)
- Allowing some buttons to appear to be "labels" instead (text, but no button).
Spidey Linden
tracked
Issue tracked. We have no estimate when it may be implemented. Please see future updates here.