As very much more a software than hardware guy, I am wondering what the level of interest would be in developing an alternate, standalone maslow UI which could run on a connected computer (to start with) and be built from the ground up in a better, easier to develop in framework.
FluidNC as it currently exists provides some API interfaces over its wifi network connection including http, websocket, and also telnet via wifi or USB. The ui is served in the form of a single gzipped html page, which has some pretty severe restrictions on code size and as such is written in a pretty basic way with code that is not the easiest for people to reason about. The current html based ui uses http and websocket to communicate with the maslow. This UI would not go away, and in fact has to exist to provide for initial setup of wifi, etc.
I was thinking about alternatives to this.
a web based solution.
Probably to make this standalone and easy to run it could be encompassed within an electron based application that could run on windows, linux, macos. We could also potentially support mobile as well with some of these alternatives. Iād argue that the application in this case be designed such that the core code would not really care if it was running in electron or served from an http server, electron, etc.
Frameworks:
react
angular
vue
backbone
etc (there are MANY web frameworks that exist that have huge followings) running from within
a non-web based solution.
GTK
QT
Java
python frameworks (kivy, etc)
others? there are many cross-platform and even mobile options
Are there others like me out there that would want to participate in such an endeavor?
I think it would need to be browser based, the other options just need too much
maintinance, especially to support on all platforms
supporting multiple simultanious clients is important.
The FluidNC UI is complicated by the fact that itās got limited primary storage,
and cannot count on having an Internet connection. It may be that just having a
fileserver available (which could be as trivial as an old phone) would allow for
a UI to be partially hosted on the esp, but reference the libraries/etc on the
other network resource. Thatās not going to be as easy to manage as something
completely separate, and it would need some sort of fallback for when the
external resource sināt available, but I figured Iād throw the idea out.
Iām thinking outside the existing constraints of esp32 for the UI. The UI Iām talking about would not replace but provide an alternative for some / most who have an internet connection and computer to host the ui on. My main frustration with the existing esp hosted ui is how slow it is to develop for compared to what Iām used to.
IĀ¢m thinking outside the existing constraints of esp32 for the UI. The UI IĀ¢m
talking about would not replace but provide an alternative for some / most who
have an internet connection and computer to host the ui on. My main
frustration with the existing esp hosted ui is how slow it is to develop for
compared to what IĀ¢m used to.
Iām thinking that if you have multiple machines connected to the ESP as an AP,
it should still be able to work.
or if in a remote shop, the other machine and the ESP can be connected to a
router, even if that router canāt reach the Internet.
Please at least map out what is needed to have everything locally hosted.
Considering that .net runs on absolutely everything now (which in truth cannot be said of python) I would seriously consider it as a non-web option. Iām about to explore using avalonia for GCodeClean. However, Iād tend to agree with @dlang that a web-first approach would be best.
And then having said that, anything that can target wasm would be awesome, and thereās lots of stuff that can pull that off now. Which would allow us to program in a language of choice, but still target browsers first.
And please no more C/C++, if for some reason we really need high performance the best choices these days are definitely Rust or Zig. And Iād lean towards Zig at this stage.
So in this new UI, nothing at all would change with the current system or UI. The new UI would simply be an executable that runs on your device (windows, linux, macos, maybe mobile) and uses the fluid websocket and http that already exists in the firmware over the wifi network (and maybe usb) to communicate with maslow. The details of what that would require are highly variable. If I was to write it in, say, gtk (NOT a choice Iād probably vote for), then Iād have to have a build that builds the various OS runtimes, would have to keep that up to date, etc. If I was to write it in .NET (I donāt know what platform independent ui frameworks there are for .NET, but I trust @m8dn knows some) then it might take much less. If I were to use electron, then virtually no extra effort would be required unless we were to use special OS specific features, as it provides the ability to create executables for the 3 main desktop OSs out of the box. None of these listed are perfect and every single one would be preferable to me to develop software in to what we have with ESP3D-WebUI which feels like going back to the early 2000s in web development, and restrict the ability to use features such as frameworks like vue or others that need a bigger footprint.
What Iām talking about is just making it possible to not be dependent on
Internet hosted things.
The idea is to avoid the makercam problem where something on the Internet
vanishes. As long as things can be copied to a self-hosted machine, even if the
common case is to use it on the Internet, if it vanishes from the Internet, it
can be hosted elsewhere (or locally)
So in this new UI, nothing at all would change with the current system or UI. The new UI would simply be an executable that runs on your device (windows, linux, macos, maybe mobile) and uses the fluid websocket and http that already exists in the firmware over the wifi network (and maybe usb) to communicate with maslow. The details of what that would require are highly variable. If I was to write it in, say, gtk (NOT a choice Iād probably vote for), then Iād have to have a build that builds the various OS runtimes, would have to keep that up to date, etc. If I was to write it in .NET (I donāt know what platform independent ui frameworks there are for .NET, but I trust @m8dn knows some) then it might take much less. If I were to use electron, then virtually no extra effort would be required unless we were to use special OS specific features, as it provides the ability to create executables for the 3 main desktop OSs out of the box. None of these listed are perfect and every
single one would be preferable to me to develop software in to what we have with ESP3D-WebUI which feels like going back to the early 2000s in web development, and restrict the ability to use features such as frameworks like vue or others that need a bigger footprint.
AH! Yes I totally agree with that, and I would not want whatever the UI I start is reaching out for libraries or whatever at runtime, or be āhostedā per se. I would want it to be fully open source also such that if (maybe when) I or others could not update it, someone else can take it forward. Simply build it into a platform specific installer and that is the only runtime the user needs.
A big problem with makercam specifically, in my opinion, is that it was closed source and written in flash, because if it were open and available others could have rewritten it in another technology. It is fortunate that someone wrote a flash player for wasm I guess
While electron has some bloat, I think it is a great choice.
If we can target WASM then all modern (and most no-so-modern) browsers can run it. So that opens up several choices as to what to write things in, i.e. anything that can target WASM is a starter.
However, some frameworks that target WASM can be more than a little bloaty as they throw in the kitchen sink of functionality (i.e. the entire framework in WASM form). So preference should be given for frameworks that do optimised transpiling to WASM.
Iād also strongly recommend looking at bun (bun.sh) for delivering in the whole Javascript/Typescript space.
It wasnāt mature enough 18 months ago. It very definitely is now.
Itās an almost drop-in replacement for node js, but that runs Typescript natively. It also doesnāt care about requires vs. imports. This may not be a big issue for what weāre looking at here, but having the option is great.
Itās a āthrow away just about every hackā replacement for webpack and other JS/TS bundlers. This is potentially very useful for us.
Itās a really good JS/TS test runner. This is important for me, because I like to automate tests where I can.
If weāre doing development with a Javascript/Typescript focus, then bun is the infrastructure to deliver that.
Also, from the perspective of lowest barrier to entry for anyone to contribute, then Javascript/Typescript is the best choice of all. And Python second, close, but not that close.
I think that this is a great idea. The hosted web UI is always going to be hamstrung by needing to be tiny.
I would like to further refine and tweak the hosted UI a little bit, but I donāt think itās going to develop too much farther (because of the limitation of the approach).
Having a separate (optional) UI with the ability to be more fully featured (I would love pan and zoom gcode preview for exampleā¦easy to do in some environments, hard in the current environment) would be an awesome way to expand whatās possible.
You could always have another tab on the existing UI for an āadvanced viewā or whatever that loads the necessary files from GitHub.
I run into the issue where I close my browser, refresh the page, or whatever and loose the webpage and am not able to load it since the machine is running. Assuming that the machine will respond to new websocket requests It probably would not take too much to add the necessary JS to turn the UI into a PWA with a service worker, so on each visit the browser only has to load the ajax and websocket calls, actually with that you could even cache the gcode on the client.
Curious to see where this goes. Would be neat to see sharing/collab between projects (e.g. WebUI extensions useful for both projects). Some info that may helpā¦
fwiw - Jason Yeager and others on V1E forum have embarked on some curiosity (and frustration) driven development improvements to FluidNC WebUI v2 and v3ā¦
Improve Dev inner loop experience using multi network setup, e.g. add a USB wifi dongle for network connection to ESP32 AP separate from your existing wifi/ethernet connection to home/internetz.
Jackpot / FluidNC WebGUI V1E topic starting with Iām this close to making a fork of the FluidNC web GUI contains a bunch of ideas, context and perspectives from people. The topic is long, meandering and unfocusedā¦ But hopefully contains some nuggets that benefit what you/we end up doing/using.
Thanks! This is good info and Iām glad to see it going on. That said, though, I donāt think Iām up for supporting fluidnc in general as this is a bigger scope then I have time for. Iām sure there would be some overlap, but my focus would be on making a maslow specific UI (with calibration support, etc) using the communication with the fluidnc fork running on the maslow, with the maslow specific APIs weāve got there. At least initially. We can see how much interest there will be in this and how much time I can spend.
I can already connect to maslow for instance from Openbuilds CNC via usb, and to some extent get it to respond, although it canāt really talk much other than basic fluidnc / gcode .
Last night I was looking into Tauri (a rust based runtime project, like but not as bloated as electron. Seems like a great place to start a web-based application for macos, ios, android, linux, and windows (FYI, mobile app development is not something Iād start with, but this would allow it). Works with any web framework, as it just acts as a host with hooks to talk to the host operating system via rust in pretty much any way you want from the web code.
Is there a reason we canāt use some of the storage space on the sd card to store files for UI? Itās not like the board and server running on it donāt have access to it, since we can upload files to it through the interface and load them for use at will using the same interface.
My second thought would be something akin to cookies, where files could be loaded from the machine that is connecting to the server, and it could be set up to check for them, load them if present, and default to what is on the board if they arenāt. Would be much easier to maintain a simple script that places files in the right place on a machine than a wholly separate program. Would be an easy download-run-done thing for each update as well as not needing additional infra, because itās still all just running there in the browser, itās just loading some files from the local machine for the interface.
Yes and no. We could add files to the sd card and probably figure out how to load it from the main ui from the board(there are as you say APIs to get to this data from the ui). But it would not be as seemless from the application, it would be a custom loader using that api. We could also probably get the webserver being used to also use the sd card as a filesystem too, but the webserver involved in ESP32 development is not a full featured, multithreaded webserver. It cannot handle UIs written to fetch mutiple files at once from the webserver, which most modern web frameworks expect to be able to do. While it may be possible to cram more ui data onto the device, I personally would rather keep the focus of the code running on the ESP32 focused on running the machine and not serving files to a browser. Currently it just serves the one file at connection time, which then frees up all the resource to communicate with that and run the firmware.
Long winded way of saying āyea, we might be able to, but I think that is not the direction I had in mind, and would add complication rather than reducing itā
There is merit to this, certainly; if the other issues could be solved. That said too, though, after the initial development curve, which seems like where we are, the UI and the firmware are not tied together so tightly, and we already have a separate project for the ui. Bar just releases both artifacts at the same time.
Just to be more clear, I was specifically referencing it being easier than introducing a 3rd pillar, which would be the standalone software, not comparing it to the current state of things.
You guys are at a point where my experience level starts to break down, so I will admit that I donāt have all of the context, and was just flagging a potential way forward that Iāve seen used before in environments Iāve worked in. The context in the explanation is very much appreciated.
