Idea: Simple GUI system for configurations about dashboard HOT 5 OPEN

CC @jesserockz @balloob if you find this idea interesting

from dashboard.

I like it. It would be a great step forward.

Unfortunately I to lack the frontend skills to implement something like this.

from dashboard.

The biggest problem I see is that writing to users YAML means users lose their original formatting. We can switch to ruamel.yaml to at least make comments survive, but it won't deal with secrets for example.

So then we can swap out the complete storage format and just create our own format without comments. We do this in HA, the biggest gotcha for people is that comments are lost as we store in JSON (which doens't have comments), but we have a UI in YAML.

So I like the idea, but also a hornet nest 😅

from dashboard.

comments are lost as we store in JSON

Yes, round-trip YAML is hard and not an option for us. But storing comments written inside the card YAML is possible. The main idea is: "store the card YAML contents as plaintext".

An example: In the GPIO switch example a user could write:

# This is my comment
name: GPIO Switch
pin: GPIO23

The backend would store this as JSON:

{
  "component": "gpio.switch",
  "content": "# This is my comment\nname:e ...",
  "x": 150.0,
  "y": 90.0
}

Notice content is plaintext; When reading the config in the backend then parses each JSON entry's content as YAML, then combines those to the full config data structure.

The editing system would write directly to the plaintext content, without ever parsing the YAML. Only when installing/validating the config do the comments get lost, but those actions don't mutate the config, so not a problem.

but it won't deal with secrets for example.

Example 2: secrets

WiFi Card's contents are

ssid: !secret my_ssid
password: !secret my_psk

With the system I propose, no YAML tags would be lost. The frontend+editing system don't care what you write in your card YAML and just store it as plaintext. Only the validation/install system in the backend need to parse it, but those systems never mutate the config so no problem

from dashboard.

Honestly I'm not completely sure it wouldn't be easier to just create a proper GUI that didn't expose YAML at all.
The YAML is not at all difficult for even slightly intermediate users. Actually installing and launching the program might be just as intimidating for some beginners(Perhaps the whole thing could actually be integrated as an Arduino IDE plugin or something, so you can double click launch it?)

It's the true beginners, and people who would rather not have to Google 5 different things to find the stuff they already know but forgot the syntax for, who need the visual editor.

I could see building a simple, opinionated, and consumer-friendly config editor in just a few days with something like Vue. The whole thing could run completely in the browser for portability to different backends.

Manufacturers, or anyone else who might like to, could set up code generator sites specific to their product, entirely separate from the actual compiler. If/when there's ever a truly consumer-ready way to actually compile the project, you'd already have the frontend.

You'd have some static boxes for things like your WiFi setup, your hostname and friendly name(Although I really think those should be in flash and user-settable), API keys, etc.

You'd have a list of Apps(componenets), each of which would be a handwritten Vue component and a bit of YAML editing logic. Only a small set of these would be necessary I think to be pretty useful. They could integrate the documentation right in the UI.

I think the big use case might be user-defined timers, which you could make a nice editor for with(https://github.com/JossyDevers/cron-expression-input).

Actions would be similar, a select group of actions would be supported in the UI.

UI elements could have access to global things like lists of IDs for select-box input instead of text.

For anything not natively supported, you'd have Raw YAML components and actions(Build them first, and the editor would start life roughly equivalent to OP's proposal!).

Your "Apps" could generate multiple components each and serve as drivers, and your base configuration items could be done as an App too, so your entire "Visual source code" becomes one flat list of variations on one primitive.

At the end, all the outputs of each component editor would be merged together, and as a bonus, if you just swap out the merge function, and the of "Apps", you could reuse the framework as a config editor for anything else as well.

You avoid any issues with comments and round trip, because you simply don't support making brand new things with the visual editor. If people want comments, they can be embedded in a notes property on each individual component.

It would make the YAML file longer, but you could include the "Sources" of the file in a special property, so you could go back and edit a file that was originally made with the visual editor.

from dashboard.