Generic Type for Settings API

[cyrusfirheir]

Problem

Currently, the Settings API allows for headers, toggles, ranges, and lists to be added to it. From a data standpoint, it makes sense that all sorts of settings would fit into those, but from a UI perspective, they are not enough types.

Proposal

A way to add custom UI to the Settings dialog—without having to use janky workarounds like injecting in elements based on the class of the Dialog that is opened—would be a nice feature to have.

Possible syntax

Setting.addGeneric(
  "name",
  Story.get("some passage").processText() /* a string that is wikified to the dialog */
);

Or,

Setting.addGeneric(
  "name",
  function () { /* a function which has an output buffer like the `<<script>>` macro, or a macro `handler()` */ }
);

Or something along those lines >.<

[tmedwards]

One of the primary reasons that the Setting API and dialog exists is to provide a consistent and sane interface for settings.

I'm not opposed to making changes to the system, if they make sense—as evidenced by the header and range types and descriptions, which were additions.

That said. Providing an easy method for the non-technical to dump whatever ill conceived nonsense they manage to smash together into the dialog is not high on my list of things to do.

Is there some background to this request?

[cyrusfirheir]

It was mostly me looking at people making custom dialogs for game settings, storing such data in the State, using the dialog synthetic events to insert elements into the dialog, instead of using the Setting API because it feels too limited. Settings are, in the end, lists or ranges or toggles, but creators wanna use arrays of buttons, text fields, accordions, and stuff like that.

And while that's doable with a custom API that the creator makes themselves, I feel like it doesn't take advantage of the Setting API where it could.

Yes, adding a completely custom element to the dialog will lose the onInit and onChange handlers, and leave it all up to the creator to manage, but I think the option would be nice.

The current way to have a custom dialog and use the Setting API is this:

Setting.addToggle("name", {});

/* code which changes `settings.name` */

Setting.save(); /* which is also run by the custom elements/dialog */

Which is okay, I guess. But feels like extra work.

Now that I look at it, this issue is more of a discussion, rather than feature request… Thoughts?

[ChapelR]

It would be nice to arbitrarily render content or elements into the settings API. I think maybe the best solution would be to just make like a Settings.append() method or similar.

[tmedwards]

Addressed by issue #236. Resolved by 223dad1.