I've searched a couple times for any kind of hook to notify a plugin that it is being uninstalled and have come up empty.
Some plugins have to make global config.yaml settings to function properly. Is there a way to hook into an uninstall to facilitate this?
A sample use case if this isn't clear:
Plugin "Do Stuff" disables the built-in gcode viewer plugin because it has its own implementation. How does "Do Stuff" go about re-enabling the built-in gcode viewer if the user decides to uninstall it?
Hi.
I can answer this because I wanted to do the same. Long story short: Foosel decided to implement such a hook which I think will be in the next release (1.8).
In the meantime I managed to get a workaround running. Check L147 and following and especially check L156. The event workaround should work for plugins which have the restart needing mixin activated, but might not be 100% predictable. My tests say it works though.
Try the link here for the example from my plugin of settings overlay (Charlie's link broke because of markdown formatting). Definitely the way to go in most cases, however there are some caveats. Lists don't always work as expected, and if there exists a setting already in a list setting then the overlay won't apply.
I've taken a look at __plugin_settings_overlay__ previously and ruled it out because it only partially solves my problem. Yeah, I'm the GRBL guy.
Here's all the stuff I have to touch:
appearance / components / temperature tab
controls (any / all customizations made to it)
feature / temperatureGraph
feature / gcodeVisualizer
feature / modelSizeDetection
serial / neverSendChecksum
serial / checksumRequiringCommands
serial / helloCommand
plugins / _disabled / printer_safety_check
appearance / components / disabled / tab
It looks like settings such as neverSendChecksum, helloCommand, and modelSizeDetection would be covered for the most part so long as they were not already changed to something (non boolean) within config.yaml
I'm not sure what it would do with others... like tab display order and disabled tabs, especially if a Plugin such as "Tab Order" was already installed and overrode the default (blank) entries.
I'm thinking it may just be easier to build the implementation myself using "initial values" within my own config block the first time the plugin fires up. And then on uninstall it's simply matter of stuffing those initial values back.
Appreciate the guidance / dialog regardless. This one has been on my mind for quite some time.
__plugin_settings_overlay__ = {'system': {'actions': [{'action': 'octodash_start',
'command': 'sudo service getty@tty1 start',
'name': 'Start OctoDash'},
{'action': 'octodash_stop',
'command': 'sudo service getty@tty1 stop',
'name': 'Stop OctoDash',
'confirm': 'You are about to shutdown OctoDash.'},
{'action': 'octodash_restart',
'command': 'sudo service getty@tty1 restart',
'name': 'Restart OctoDash',
'confirm': 'You are about to restart OctoDash.'}]}}
What I really like about your implementation, @jneilliii, is it targets stuff that you have full control over and alleviates the need for you to have to deal with carnage left over after your plugin has been removed.
No one else is going to mess with octodash_start, stop, etc and this looks like a super easy way to ensure they get yanked upon uninstall automagically.
I wish that was true, but because the setting itself is a list for system commands, it isn't actually targeted. I actually submitted a feature request for this reason, but it hasn't got anywhere yet because of the complexity of merging lists. That's why I mentioned there were caveats...and you can't expect your settings to apply.
Because of the breadth of your changes I would still look into UIPlugin mixin implementation (Mr Beam did this for laser). Then you can leave out whatever parts you want to leave out and have what you need.
I may just go there with it at some point. My (laser) engraver was collecting dust for most of the past year and I just recently powered it back up to do some engraving. My development cycle on this project tends to align to how much time I'm spending with the laser itself.
My printer goes through cold spells too but not as long duration wise.
I finally broke down and acquired a (reasonably priced) CNC machine and will have something with a real spindle to play with here soon. Naturally, I'm going to extend the plugin to cover CNC functionality as well.
Completely OT, but I previously hacked OctoPrint-TFT to run my engraver... rewriting a couple of the screens to be more laser friendly.
I've had my eyes on OctoDash for a while but haven't gotten around to customizing it. I jumped to OctoDash on my Wanhao printer very early on.... was very nice to put Go and Touch UI behind me.
Yeah, I have OctoDash on all my printers and have contributed a little to the project. The upcoming release is pretty cool with a new notification panel for the custom action buttons that are accessible from any screen and not just while idle.
was able to accomplish everything I had hoped for with your "workaround". I verified the uninstall hook is called on 1.7.2 when a plugin is uninstalled, both with and without data cleanup.
2021-12-17 20:31:23,687 - octoprint.plugins.bettergrblsupport - DEBUG - we are being uninstalled :(
2021-12-17 20:31:23,692 - octoprint.plugins.pluginmanager - INFO - Plugin bettergrblsupport uninstalled
