Refactoring - thoughts and plans

[kgutwin]

Hi all! 👋

I've really appreciated the Micro Panel I've printed and assembled based on this code and design files - it's made it a lot easier to work with my printer which is quite a distance from my working laptop. I especially like the stock design of the case; it's very easy to print and fits in perfectly on my Ender 3, plus I learned a lot of excellent tips and techniques just from reviewing the Fusion 360 design file! I also appreciate how easy it is to start and stop print jobs with one button, especially when I can see that I messed up the bed level 😬

There are a few additional things that I want to use the Micro Panel for, such as running arbitrary G-code for doing manual bed leveling and having the ability to select the file to print. I spend a lot of time writing Python code, so I planned to implement these features and submit them as pull requests. However, as I started looking into it, I found it hard to fit these new features into the current code structure. Instead, I kept coming up with ideas on how to refactor the plugin to make it easier to understand and expand.

If this was my code, I'd dive right in to refactoring, but since I'm just coming to this project, I want first to show my respect and appreciation for @sethvoltz and the other contributors on this project -- you all have done the hard work to get to this point, and I don't want to be rude in suggesting some major changes. That said, my main goal is to have a Micro Panel that does all of the things that I know it's capable of, and so I plan to start the refactoring process; I'm opening this discussion so that we can have some good communication from the start.

To give a high-level overview, my goals are:

• Decouple the core of the plugin from the display/GPIO hardware interface, primarily so that I can make a "virtual panel" for easier development, but also potentially to support other hardware configurations in the future (more buttons, larger screens, support for other platforms beyond Raspberry Pi)
• Have an extensible system of "screens" to build a modular user interface, so that the display logic and event handling are more localized to the current state of the UI, and to make it easier to add additional screens. This would be first to support the features I want, but others could use this for implementing other suggested features (such as [Feature] Add rotating information in large letters #39 and [Feature] Add ability to change temperature when not printing anything. #25)
• Provide a smooth upgrade path through the transition so that no breaking changes are made from the current revision
• And, to take in feedback from other code contributors so that the changes are sustainable and maintainable long-term

My thought is to implement the first two goals in a set of parallel draft PRs - this will make it easier to do code review on the changes, and to merge them separately if desired. I'd be thrilled if you end up merging them into the main code base, but it would be fine as well if you decide to keep the code on its current path and would rather I maintain my changes as a separate fork.

Do you have any thoughts or concerns? I appreciate your effort and feedback! Thanks!

[sethvoltz]

Well this is very exciting. Thanks for starting this discussion, as I've been thinking about how to go about refactoring to clean up some of my hacky initial code. My experience with Python has been all through embedded use and this plugin, so I am very aware I am not familiar with time-tested patterns, plus this started as a weekend hack project to scratch an itch I had on my printer.

I would love support a refactoring effort and your plan seems like a great place to work off of. I'm also not precious with my code, personal or work. More minds make it better and the amazing community contributions I've reviewed and merged from other users have leveled the functionality up here more than I would have done individually. Let's rock and roll, looking forward to the initial PRs!

Bonus: I get to learn more, which is always great.

[kgutwin]

Thanks, I appreciate the welcome!

I've hashed out the first PR (#65) which is focused on modularizing the panel interface and adding a virtual panel. I'd welcome anyone to test it, it should be essentially equivalent to the current code, with the obvious exception of the new virtual panel feature.

My next plan is to modularize the screens; I've already gotten started a bit on it, but it will take a few more days for that to be ready to show off.

Please add your comments, concerns, and questions!

One last thing is that I realized as I was working through this, that it would be nice to take some of the current logic that handles the two-color displays and the display rotation, and to push that up into the panel interface. The "screens" interface would render elements like the progress bar and the main display, and then the "panels" would composite those together in the proper location for the user's specific setup. I think something like this will need to follow on later, but I wanted to mention it in case the idea made sense.