Thanks Werner for reviewing this change.
wmayer wrote:3. Once you press the Refresh button the first time the parameter 'DisableRecomputes' is set to false and never set back to the original value. So, any further call of Document::recompute() won't be blocked any more. If this is on purpose then I do not even understand the idea of the solution.
The reasoning behind this was, to make it as easy as possible for a user who is unaware of this functionality to get back to the normal behavior.
Like I asked somebody to disable the recomputes and save a file with Feature without computing it. So instead of allowing a single manual recompute, running the GUI command restores the normal behavior. I also thought about somehow reseting to be default behavior at startup. But i haven't found a suitable way in the given time.
This mode is intend to make a few changes in row, without being locked out by a blocking GUI.
When I tested this, i sooner or later came to the point when there had to be a recompute. Mostly when Task View commands bumped into null shapes. Since this change is aimed to be included in the 0.15 release as a hidden feature that can be enabled by python commands, I choose that rendering the recompute button useless (easy for me) or allowing single overrides would be a bad option. And providing a proper GUI interface that would permanently (visually) warn the user that recomputes are disables would not be ready until the 0.15 feature freeze. (And i decided not to spend any time on this, until I got confirmation that it will be actually included)
wmayer wrote:Instead of blocking Document::recompute() I would reduce its number of calls. E.g. the property editor could check the above user config parameter and if set simply doesn't call the recompute() method.
To me this is not an either or kind of decision. Reducing the number of recomputes won't suffice. Depending on structure of the document recomputes can be quite be quite expensive. And a lot of times when i tweak an object
while parent objects are hidden. I want to keep on working without fully recomputing the whole document.
Recomputes need to run in the background and the GUI needs to be responsive. And then they need to be aborted and restarted if there was a change in the mean time. And of course they needs to be a progress bar if a recomputes takes more than 2 seconds.
But until then I'd like to disable recomputes when they are stopping me to changing several simple properties in a row.
wmayer wrote:1. The document class shouldn't depend on any user config parameters because this makes it complicated to use it from Python.
I consider this as a feature. Completely disabling all recomputes is something that should not be easily used from python (macros or modules). Like someone using the Draft module from a python script, might actually want to prevent doc.recomputes inside there stopping his script and updating the GUI while, the script has not finished. This behavior leaves the GUI with intermediate results. (You probably saw this in earlier versions of the OpenSCAD importer). It might be tempting, to disable recomputes in this scenario as well. But everything that is not meant to work totally parametric might rely on Shapes being correct after. And as there is no way to recalculate a single feature or a subtree up to a certain feature, there is currently no alternative to recomputing the whole document (
issue #1957). And those recomputes need be done synchronously.
But my change is only intended for interactive use. A script should, besides offering a simple GUI button, never ever mess with the recompute setting. A script changing user preferences is most probably a bad idea. And a script (globally) disabling the recomputes breaks FreeCAD instantly.