AutoDarkMode / Windows-Auto-Night-Mode

Automatically switches between the dark and light theme of Windows 10 and Windows 11
GNU General Public License v3.0
7.36k stars 261 forks source link

GUI for custom scripts #532

Open Spiritreader opened 2 years ago

Spiritreader commented 2 years ago

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

Spiritreader commented 1 year ago

Rudimentary support is here:

image

igspo-gnunes commented 1 year ago

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 commented 1 year ago

@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.