So I finally started looking at the source code of the webUI with the goal of implementing some of the quality of life features ( adding a bounding box / printing the max X and Y dimensions of the gcode, adding a command to jog the router to the extremeties to validate that the work piece is positioned correctly, etc.
As a software engineer, I fully understand feature creep. However, this feels completely unsupportable in the current state.
Is the main concern the total size it takes?
if so, I would recommend to split out the javascript to proper .js files (so each is nicely formatted and maintainable), and when creating index.html.gz, you can first run it through a javascript
minifier, and then just take the output and append to index.html before compressing it.
Are there any other considerations I should keep in mind before I attempt to set this up? Or would this work?
Also, yea, its a constrained environment and also not what I’m used to (plain html/js only, simple bootstrap styles, a bunch more constraints). Feel free to reach out for pointers.
to build it, gulp package -en - output in dist
to run it without uploading, get python installed (probably a couple pip installs I forget) then run python fluidnc-web-sim.py maslow.local and point a browser to localhost:8080 (or whichever port it reports.
no hot-reload or any modern convenience for front end development
, just repeat above to test changes.
This relates to how this environment ESP32 web server behaves with multiple file accesses like browsers like to do. best to (for now) keep it as one index.html.gz and have that be served from the firmware. I am sure more should be possible, but the ESP envornment (server) is NOT robust like we are all used to with proper web servers.
And… the above project does have things broken out a bit better.
Yep no worries! @md8n and I have another thread talking about improvements to this. I think we can work toward them, but also I know upstream there is a rewrite going on that I have not dived into yet.
I was annoyed with that too and will someday just change the default branch on my fork of Bar’s fork
I don’t imagine we will send any of the maslow stuff up to upstream though, so I’d think we don’t need to care about the other branches? (i.e. feature branch->Maslow-Main works?) I then PR to @bar against his Maslow-main
I don’t imagine we will send any of the maslow stuff up to upstream though, so
I’d think we don’t need to care about the other branches? (i.e. feature
branch->Maslow-Main works?) I then PR to @bar against his Maslow-main
We should, it will make it much easier to maintain in the long run.
It will require us to change some things to meet their standards and decouple
the hardware support from being maslow specific, but those are good changes
anyway.
