On the Klipper Facebook group, I have noticed that most of the issues new Klipper users have are related to the fact that they’re using Octoprint, and after further discussion with them, it seems that that decision was influenced by the fact that the official documentation still recommends to install OctoPi in the “installing” link in the main README on GitHub and on the home page of Klipper’s website.
Octoprint has some serious issues with klipper and is often the weak link when attempting to print fast or printing a high detailed object.
Could we add a paragraph at the top explaining those issues, and offering the installation of Fluidd/Mainsail with Moonraker as an alternative? Maybe even suggesting FluiddPi and MainsailOS as simple install packages.
FWIW, I agree that we should change the recommended installation to recommend Mainsailos and/or Fluiddpi.
If someone was totally new to Klipper I’d point them to Fluidd or Mainsail. I think all the core developers except for myself, have stopped using OctoPrint.
However, it’s a lot of work to change the official documentation. Also, Fluidd and Mainsail are both under rapid development. So, although I’m confident this change will come, I estimate it’s still some time (likely months) away.
Maybe the community could help with the documentation. The klipper documentation pages could point to (or reuse) the documentation already available on Fluid / Mainsail respective sites.
I recently converted my Marlin / Octopi setup to Klipper / Fluid using FluiddPI (not recommended) | Fluidd and I will never go back to Octoprint.
As for the rapid development of Fluid and Mainsail, I would argue that it is preferable than a non or partially working solution.
In a first phase of the rewrite, we could simply add a line at the top stating that Klipper can also be used with Fluidd/FluiddPi and Mainsail/MainsailOS which are using the Moonraker API. and give links to each repo. This would allow to keep the fastly changing instructions on each respective repo for the install procedure while still acknowledging them in the official documentation.
Here’s example of a simple addition to the documentation:
Klipper dedicated Web UIs
Two different dedicated interfaces have been created for Klipper using the Moonraker API.
I agree with this - it might also be worth mentioning KIAUH as an easy installation option (with a disclaimer about it not being officially supported by Klipper, probably)
Being frontend and Pi image (or even OS) agnostic would be ideal, but you certainly have to pick at least one frontend to use… I think I’d want the installation instructions to be able to work from a completely fresh Pi image too, with no assumptions about level of skill made, although that could be difficult.
I’d also like to add a list of prerequisites at the top of the installation document, and a set of basic troubleshooting instructions for before they go running to Discord or Discourse (or Facebook, I didn’t even know there was a group!) - I’ve seen a lot of people come in without having actually read their /dev/klippy.log file, which usually explicitly spells out what is wrong.
Some clearer instructions on flashing boards might also be useful, I’ve seen quite a few people that have clearly failed to flash their MCU especially with those that don’t work with the standard make flash process.
I know rewriting the documentation to be more newbie-friendly isn’t a priority for developers right now, and it probably shouldn’t be, so I’m planning on taking a stab at some of this in a few weeks when I should have some free time.
I’m also very interested in PR #4327 on swapping over to the Just The Docs theme - navigation and structure are certainly issues with the documentation right now, at least from my perspective.
I have some other things I’d like to change about the documentation, but they’d probably be best saved for other threads later down the line…
Scripts like KIAUH is the best way to maintain coherent, standardized ecosystem. Standardization in turn helps with debugging and makes supporting user problems easier. KIAUH is not to different from make menuconfig for building software and hardly anyone would argue against that.
Overall, my point is that scripts like KIAUH are step in the right direction from user perspective and should not be dismissed but build upon.
@th33xitus has my full respect and admiration for this very cool bash scripting, nevertheless for me personally:
too many dependencies
not maintained by the original author → any breaking change on any of the bundled system can lead to a failure, which is virtually impossible to diagnose for the regular user
KIAUH always needs to “run after” the development of the bundled dependencies
Should, for whatever personal / professional reason, @th33xitus stop to maintain or even just develop a backlog, then the whole ecosystem potentially crumbles
So, don’t get me wrong: @th33xitus and all the other devs around this have my highest respect for their work, I just do not like to rely on this as a “standard”.
