add multiselect option type and allow mods to open their own settings

codingisfun2831t commented

2026-06-07 18:24:54 -05:00

(Migrated from github.com)

Self explantory. Multiselect options follow a format like this:

{
    id: "validHellos",
    name: "Select all hellos that apply",
    type: "multiSelect",
    options: {
        "Hi": "hi",
        "Hello": "hello",
        "Sick": "sick",
        "Howdy": "howdy",
    },
    // what options should toggled by default
    default: ["hi", "hello", "sick", "howdy"],
}

Options is a dictionary similar to a dropdown menu, and default is just the values that should e enabled. It looks like this:

And for the second part, a mod can open their own settings by calling this.api.openSettings(). I have added documentation for that function, and example.js has a menu option for it.

Self explantory. Multiselect options follow a format like this: ```javascript { id: "validHellos", name: "Select all hellos that apply", type: "multiSelect", options: { "Hi": "hi", "Hello": "hello", "Sick": "sick", "Howdy": "howdy", }, // what options should toggled by default default: ["hi", "hello", "sick", "howdy"], } ``` Options is a dictionary similar to a dropdown menu, and default is just the values that should e enabled. It looks like this: <img width="155" height="103" alt="image" src="https://github.com/user-attachments/assets/f4bb03b8-e3bf-421b-a498-bfa4ea024272" /> And for the second part, a mod can open their own settings by calling `this.api.openSettings()`. I have added documentation for that function, and example.js has a menu option for it.

PPPDUD commented

2026-06-07 18:30:52 -05:00

(Migrated from github.com)

Upon an initial review, it looks good to me, but I'll need some more time to test it out before I approve anything.

Is there any chance that you can add a feature to open a dialog with the options API's style of layout specification and have it return the resulting values without saving them anywhere?

Upon an initial review, it looks good to me, but I'll need some more time to test it out before I approve anything. Is there any chance that you can add a feature to open a dialog with the options API's style of layout specification and have it return the resulting values without saving them anywhere?

codingisfun2831t commented

2026-06-07 18:33:00 -05:00

(Migrated from github.com)

So something that takes in a option format and options and returns (probably via callback, like how DialogBoxMorph works) the new options?

PPPDUD commented

2026-06-07 18:35:45 -05:00

(Migrated from github.com)

So something that takes in a option format and options and returns (probably via callback, like how DialogBoxMorph works) the new options?

Precisely, but just to be very clear: I don't want this mechanism to change or read from the addon's settings. I want it to be independent from that altogether.

> So something that takes in a option format and options and returns (probably via callback, like how DialogBoxMorph works) the new options? Precisely, but just to be very clear: I don't want this mechanism to change or read from the addon's settings. I want it to be independent from that altogether.

PPPDUD commented

2026-06-08 18:02:40 -05:00

(Migrated from github.com)

@codingisfun2831t Why does each option have an inherent value assigned to it? Wouldn't it be better to just make each one produce a Boolean and then have the addon handle the rest?

codingisfun2831t commented

2026-06-08 19:16:17 -05:00

(Migrated from github.com)

What do you mean?

PPPDUD commented

2026-06-09 10:25:00 -05:00

(Migrated from github.com)

What do you mean?

Nevermind, I wasn't thinking too clearly yesterday. What do the values in the options dictionary do?

> What do you mean? Nevermind, I wasn't thinking too clearly yesterday. What do the values in the options dictionary do?

codingisfun2831t commented

2026-06-09 10:58:00 -05:00

(Migrated from github.com)

Basically, it's like the display=value thing in Snap! Menus. The display is what gets displays to the user (nice, human readable string), and the value is what actually gets stored.

Basically, it's like the `display=value` thing in Snap! Menus. The display is what gets displays to the user (nice, human readable string), and the value is what actually gets stored.

PPPDUD commented

2026-06-09 11:05:42 -05:00

(Migrated from github.com)

Basically, it's like the display=value thing in Snap! Menus. The display is what gets displays to the user (nice, human readable string), and the value is what actually gets stored.

Why are we storing string values like that though? Wouldn't it be easier to just do booleans (true/false) and let the addon do the rest?

> Basically, it's like the `display=value` thing in Snap! Menus. The display is what gets displays to the user (nice, human readable string), and the value is what actually gets stored. Why are we storing string values like that though? Wouldn't it be easier to just do booleans (true/false) and let the addon do the rest?

codingisfun2831t commented

2026-06-09 11:34:06 -05:00

(Migrated from github.com)

A dictionary of { value=selected}?

PPPDUD commented

2026-06-09 11:44:22 -05:00

(Migrated from github.com)

A dictionary of { value=selected}?

Yes.

> A dictionary of { value=selected}? Yes.

codingisfun2831t commented

2026-06-09 12:22:57 -05:00

(Migrated from github.com)

I just think it's a bit easier for the program. For example, if you need to check if something belongs in the list.

PPPDUD commented

2026-06-09 12:26:53 -05:00

(Migrated from github.com)

I just think it's a bit easier for the program. For example, if you need to check if something belongs in the list.

What's wrong with the expression this.options.validHellos["Hi"] instead of this.options.validHellos.includes("hi")? The former is much clearer in intent because you're getting the Boolean value for a string key, instead of checking for a string in a list.

> I just think it's a bit easier for the program. For example, if you need to check if something belongs in the list. What's wrong with the expression `this.options.validHellos["Hi"]` instead of `this.options.validHellos.includes("hi")`? The former is much clearer in intent because you're getting the Boolean value for a string key, instead of checking for a string in a list.

codingisfun2831t commented

2026-06-09 13:51:45 -05:00

(Migrated from github.com)

Hmmm.. actually, yeah. Let me change it real quick. And can the custom options dialog be postponed to another PR?

PPPDUD commented

2026-06-09 14:09:15 -05:00

(Migrated from github.com)