GUI for custom scripts

[Spiritreader]

Describe the enhancement or feature you'd like
A GUI to enable/disable/configure custom script parameter would be nice as it lessens the complexity of adding custom scripts and allows us to create presets.

Additional context
Start with a very simple base GUI first that can enable/disable scripts, then extend with features such as add/remove/edit and presets

Todo

• Ability to toggle scripts on and off
• Button to open scripts file
• Sync with config file on change
• Add links to script resources
• Abillity to add and remove new scripts
• Abillity to modify scripts
• Ability to manually run scripts right from the UI, for testing or other purposes
• Ability to turn specific scripts on/off (requires backend support)
• Script Presets

[Spiritreader]

Rudimentary support is here:

[igspo-gnunes]

There was one person in another thread that presented a list of scripts registered in the scripts.yml file. This could be an idea. It could also have a button on each to run it and a button on top to run all at once.

In my case, I adjusted a script to activate a trigger (file -shaped) so that the power automate power adjusts application themes that do not support or do not work well with "flight" theme exchanges.

As for the editing/updating of the Scripts.yml file. I don't believe it is worth building an internal editor. When clicking, you could open the default app (should fall to the application selection screen), where the user will select the "Notepad" probably. LOL. Then the ADM identifies the change (observing the settings folder) and leaves ready for the next execution.

Perhaps a "turned on" for each script can be a good one. But what purpose? If the person is required to edit the script file.

[Spiritreader]

@igspo-gnunes

Clicking on "open script config" will already open the default editor.

I see your point for not including a GUI based editor.
Adding the ability to individually enable or disable scripts is certainly planned.

Perhaps a "turned on" for each script can be a good one. But what purpose? If the person is required to edit the script file.

The reason why i think it would be practical to enable/disable and run existing scripts from the UI is that it makes testing scripts a lot less painful and makes it easier to see what you have currently enabled/disabled.

If we don't build an internal editor, we wouldn't really need to change the current UI much though, no?
Would just need a bit of touch up and the aforementioned per-script enable/disable functionality.