Marlin: [FR] WIP Refactored formatting for `Configuration.h` and `Configuration_adv.h` files

Created on 10 Apr 2020  Â·  8Comments  Â·  Source: MarlinFirmware/Marlin

Would Marlin be interested in reworked formatting of the Configuration.h and Configuration_adv.h files? _If so, I'd be happy to submit a PR on GitHub._

I was working through settings for my Ender 3 with SKR Mini E3 mainboard a couple of days ago and have some ideas for how their layout could be made more intuitive, especially given the move to VSCode/Atom editors with code folding support.

I threw together a prototype in markdown earlier today, and I uploaded it to GitHub Gist. As of yet, it only covers options from Configuration.h, but the same structure would be expanded to Configuration_adv.h

What do you all think of this idea? I think this refactor would be made even better if it made use of the VSCode #pragma region and #pragma endregion markers to encourage code folding. As I see it, every section header would be the opening/closing of one of the #pragma regions.

Feature Request

Most helpful comment

I would be interested in seeing your thoughts. Why don't you update both a sample configuration.h and configuration_adv.h and do a Pull Request. That would give us a basis to have a discussion where everybody can participate.

All 8 comments

I would be interested in seeing your thoughts. Why don't you update both a sample configuration.h and configuration_adv.h and do a Pull Request. That would give us a basis to have a discussion where everybody can participate.

Great! I'll get working on that and submit a PR when I'm ready for commentary!

Just do the main Configuration.h and Configuration_adv.h files in the Marlin directory. Please don't do the extra work to get all of the example Configuration files to match. We just need a starting point for the discusion.

Oh, of course. Ha, that would be quite an annoying time indeed!

The idea of a conceptual hierarchy is fine, and if #pragma is better-supported by editors then it might be preferable to the current method (see below). The trouble with any schema is that it adds one more layer of maintenance, and this must have a disciplined keeper to faithfully apply it, otherwise in our haste to incorporate new features these details will tend to get misplaced or overlooked. Moreover, converting existing configurations to any new schema is going to be non-trivial for maintainers of Marlin and its forks, and for users wanting to upgrade.

This doesn't mean we shouldn't move. However, I want to first hide the details behind a configuration tool. And then we can freely rip apart the configurations into all kinds of forms, from JSON to MySQL to INI to YAML…. and put them back together again.

So, the current very basic "schema" is this…. In the configuration files you'll see @section hints that the "Auto Build Marlin" extension is meant to use for its configurator (work in progress). I used these hints to build the UI in MarlinConfigurator (incomplete), which I now also have running inside of VSCode, though not yet fully parsing the configs.

I would enjoy having help in the work of getting this configuration tool together. Check out this video to get an idea of where I'm at in the current development of "Auto Build Marlin":

https://youtu.be/COPorXhbnRk?t=19757

And connect with us more on Discord to collaborate on the actual work of getting this vital tool together. Yes: It is possible to automate a generic interface with all options, and MarlinConfigurator does a reasonable job with the 1.1.x configs. But: to really help users I think it's important to tailor each "config panel" for the items it handles, so when editing geometry there's a graphic of the bed and the mesh points and so on…. I'm starting on that stuff, but with all the other tasks on my plate what I most need is help to produce the needed code and end products.

Like I commented on the now-closed PR, I'm sorry to hear this, but I understand.

I'd love to continue in the spirit of my effort here and help out with a proper settings configurator. What would be the best way for me to reach out on Discord and contribute? I'm not exactly sure what channel you're suggesting here.

Yes: It is possible to automate a generic interface with all options, and MarlinConfigurator does a reasonable job with the 1.1.x configs. But: to really help users I think it's important to tailor...

I like the fact the source code is the ultimate documentation on what is supported. I want to be able to easily build the firmware without any extra tool set complicating things. I like raw, low level Configuration.h file(s).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jerryerry picture jerryerry  Â·  4Comments

W8KDB picture W8KDB  Â·  4Comments

spanner888 picture spanner888  Â·  4Comments

Ciev picture Ciev  Â·  3Comments

Tamonir picture Tamonir  Â·  3Comments