I would propose the following as a transitional addition to the configuration system.
-
Add a simple GUI based configuration utility or web frontend to the system (there are some modules that attempt to do this already so it would be minimal work to adapt it to the following second detail.
-
For the simple GUI enforce a configuration contract with modules that follows a defined schema using [tags] to define types of information blocks. For a module to be able to show up in the GUI developers will need to briefly update their github repository to add a contract.yaml etc file that defines the default settings for the module.
This merges into the main program a feature that other modules have attempted to create while transitioning the system to a true contract based configuration system that allows for much easier user settings changes. The onus is on the module developers to present the correct base configuration file from which the dynamic configuration file for magicmirror can then be crafted from.
sdetweil@forum.magicmirror.builders 1 week ago
@daedalus7 one other focus area for MMM-Config,
most of our ‘developers’ have never written a line of code before…
they just want something displayed on the MM screen…
so, I have done everything I can to make this a NO effort added value for them too.
i don’t read the code to figure out how variables are used, and looking thru the modules, this only applies in less than 10 of now 1418 modules
the mod to make a select list vs a text entry field is to add an
enum:[choice1, choice2, choice3…]
to the form definition
and sometimes what you CAN do in javascript, doesn’t fit to the form UI at all, so one can convert back/forth with a converter routine to make it better… see the compliments module for example