prusa3d / PrusaSlicer

G-code generator for 3D printers (RepRap, Makerbot, Ultimaker etc.)
https://www.prusa3d.com/prusaslicer/
GNU Affero General Public License v3.0
7.55k stars 1.9k forks source link

Prusa Slicer GCode Viewer - Automatic reload #6363

Open dinther opened 3 years ago

dinther commented 3 years ago

Version

2.3.0

Operating system type + version

Windows 10 Pro

3D printer brand / version + firmware version (if known)

Prusa i3 MK3+ xyz !@#fras6 or something like that. ;-)

Behavior

This is most likely a new feature request.

Motivation:

Hand-coding GCODE allows me and other makers to push boundaries of what is possible. In my case the next step up from manually writing gcode is to write software that generates gcode while skipping the 3D mesh phase. But I really need a more streamlined dev process. This feature would be an enormous help.

Example:

Have a look at openSCAD, you can choose to use their build-in editor but you can also edit the SCAD code in your own editor and the openSCAD program re-renders the code upon saving in VS Code.

fortinmike commented 2 years ago

Just to continue the discussion, a quick search yielded at least two C++ libraries that perform cross-platform file watching with the appropriate platform-specific API:

https://github.com/SpartanJ/efsw https://github.com/apetrone/simplefilewatcher

Of course another option would be to directly implement each OS' file system watching API in PrusaSlicer. Having used the FSEvents API on macOS before (and if I remember well), it's not much code if you know what you're watching (say, a specific file). At least on that platform. Inspiration could be taken from the mentioned libraries. There are also probably OS-specific open source libraries that simplify file watching and that could be integrated instead of re-implementing this in PrusaSlicer.

On the other side, polling, while not optimal, is not very resource intensive if performed less often for a single file or only a couple of files (say, once per second or every few seconds) and for performance's sake only the file modification date could be read. It would be better than nothing and would have quite literally no impact on the app's performance. No need to watch a whole tree of files recursively like an IDE needs to; we know exactly what files we're interested in.

Having PrusaSlicer pop a small banner (similar to the "slicing" and "eject" ones) with a suggestion to reload the model when it detects a change on disk would be great to avoid slicing an outdated model by accident.