Every time I connect to my printer OP resets the terminal window check boxes. Could a future version please remember my settings?
Do you have a cookie destoryer addon in your browser or clean the history and cookies with every closing? Then it does not remember it. Otherwise it does.
I don't have either of those set up. Hmm. I'll investigate.
I don't have a cookie destroyer and I'm reasonably certain that every new OctoPrint session I have to remove three checkboxes.
Too bad you can't style a checkbox to be marked or I'd knock this out with Themeify.
Oddly mine are unchecked every new session and I have check them all!
In theory, foosel could add a checkbox to the Settings -> Terminal filters entries and store this in
~/.octoprint/config.yaml. She'd then use this to determine if the checkbox should be marked or not by default.
This is the underlying code and
activeFilters is the checked/unchecked status of each. I can't see any easy way of just patching the code there. It would be necessary to either change things a bit at the end to replay the last state or to add a plugin which uses jQuery to just select all three.
Or a plugin that stores which ones are checked in it's settings and then uses jQuery to check them when the UI loads. Similar to my StatefulSidebar plugin.
I suppose... since we're in here thinking about it... what if we add more filters? How about filtering all the moves/extrusions as well so that you're now only down to errors...?
That might be a little more in depth as you'd have to add additional binding, etc. The below would be a simple method of triggering the click of the inputs. They aren't individually identifiable so would have to store the values as an index number and perform some loop to figure out which ones to click after binding.
So it looks like someone else beat me to it. I started programming it and then thought I remembered seeing something that did this...
This is exactly what I needed.
If there was an option to suppress temperature messages as default would be great for me.
@jneilliii Yeah, that option is what got me thinking about this. And secondly, I'll be installing that Active Filters plugin because that's going to save me some time. (There are times when I'm like "awe man, someone else did that already" and this would be one of them.) ha
Yeah, I got through completely writing a plugin on this one that worked like my stateful sidebar plugin and then thought to look in the plugin repo...one difference between the two would be saving the state to config.yaml versus what I'm assuming is saving the state in cookies with the Active Filters plugin.
The state is saved in the LocalStorage.
IMHO saving it in config.yaml would be the nicer way, because it's more consistent betweeen different PC's and/or browsers ...
LocalStorage would be good enough if: 1) you only did this, say, at home and 2) you have a dedicated IP reserved to the Raspi. Otherwise, LocalStorage is located on a per-address basis; if you get issued a new IP address your browser then has a new/empty LocalStorage.
I'll see about continuing development. I agree, having the option work between clients/network changes would probably be better. May look into the knockout persistance library used by the other plugin to see if there is a way to move the saved state to settings instead of LocalStorage.
So if you guys are interested in testing, here is my variant that uses a different knockout plugin to persist the storage in config.yaml instead of LocalStorage of the browser. Let me know how it works out for you.
I'll add this on Monday since I'm working on something at the moment. But I like the concept.