Allowing for the use of buttons in plugin settings would enable more dynamic settings options beyond what is currently available for settings. For example, on button click, a modal could be opened where developers could then cater a settings dialogue specifically for their plugin.
If this is possible and I've somehow missed it, I apologize, however here it seems that buttons are hardcoded to error out if they aren't one of the 3 registered buttons that are for the Sync section.
Another possible solution would be to allow the onClick?(): void callback method to be used on the SettingsItem interface as it is in default.
I am aware that this could pose security risks, so perhaps making certain actions available to the button type like opening modals, resetting all settings in the section to default, and etc. would mitigate risks while still allowing for customization.
I guess a better error there would be NotImplementedError? I don't believe there is any specific reason why buttons aren't available to plugins, just that it hasn't been done yet. Buttons are even present in the plugin SettingItemType enum.
Yeah it is strange, and by looking at the prior 3 conditions before the error, it's not like anything special is happening. We should just be able to override handleSettingButton, all it seems to be is a callback that passes which button was pressed by pluginId.section.settingId (something along those lines).
On a side note (which I might put in a different thread), as of right now Objects (and arrays) in settings are only used for private data storage. If they were public I don't see why you couldn't pass an interface or object literal (for defaults) and then have the settings render inputs based on the object key types, which would then be stored directly into that object.
Buttons in settings are not properly implemented at the moment, they are a bit of a hack. Ideally it would be better if all plugin settings use the same standard layout.
What kind of behaviour is currently missing from the settings to do what you need?
Specifically I was looking to add my own keybinds, and I was going to do it by having 2 text inputs representing the keybind and what it would do, then the button would push it to storage. There would be another button to open up a menu listing them and allowing you to remove them. This definitely is not the best way to do it but its what I've come up with the small amount of brainstorming I've done. Ideally I would just have the already implemented keymapping input to deal with the binds. However I just had to think of an idea to get around it since that also isn't available.
In the grand scheme of things, the plugin I'm trying to create would allow the user to set custom keybinds to essentially paste text at the cursor. I do have a working concept with just 1 text input where the user uses a pseudo object format to assign a bind to a string and then chains them together to make more binds, but this is confusing and not good UX.
When you create a new MenuItem (with an associated command) you're able to specify an "accelerator". That is, you specify the default keybindings for the command. When you do it this way, the user is able to use the Joplin keybindings menu to rebind the command however they want. I think thats a better UI for what you want to do.
Joplin essentially forces plugins to have a menu item for all commands, which IMO is the right thing to do because users forget keybindings all the time, and menu entries are more discoverable (and as a bonus, they show that the current keybinding is).