◀ Merged tasks: T37112, T39603, T37819, T37507.

While investigating this using the current git tree (git 3c9e11df37581c6faf937bbe974710a7fc95e380) I noticed that there's an error message:

Traceback (most recent call last):
  File "/home/thoth/vendor/git-blender/build_linux/bin/2.71/scripts/addons/add_curve_sapling/__init__.py", line 550, in execute
    addTree(self)
  File "/home/thoth/vendor/git-blender/build_linux/bin/2.71/scripts/addons/add_curve_sapling/utils.py", line 751, in addTree
    (vertTemp,faceTemp,oldRot) = genLeafMesh(leafScale,leafScaleX,cp.co,cp.quat,len(leafVerts),downAngle[n],downAngleV[n],rotate[n],rotateV[n],oldRot,bend,leaves, leafShape)
  File "/home/thoth/vendor/git-blender/build_linux/bin/2.71/scripts/addons/add_curve_sapling/utils.py", line 341, in genLeafMesh
    oldRot += rotate/(abs(leaves)-1)

Since this is in a branch for the condition ( leaves<0 ) I tried changing that statement to

oldRot += rotate/(abs(leaves))

and now dragging the leaves into negative territory doesn't crash blender, although its behavior is kind of weird if you don't have branch splitting levels >= 3, and even then it seems of dubious utility to my limited imagination.

Based the fact that the field permits negative values and has code to (sometimes) properly handle negative values, I'm assuming that this represents a special mode of the sapling generator which should be preserved.

A second aspect to the reported problem is how dragging can result in very large values for leaves which crash blender. This is mostly a Human Interface Design failure.

Dragging is by nature an interactive action, but in the case of leaf count it's pretty easy to increase the number to the point where it can take a second or ten to calculate the new mesh. At this point, blender is no longer interactive and it is plausible that user mouse movements could easily be interpreted to set the value even farther into crazyspace, exacerbating the problem.

When dragging, I'd say that -100 .. 100 would be a reasonable range (although people with slower computers might choose -50..50 .

However, if you were to just type in the value 1000, my computer takes 21 seconds to compute the mesh, but then the 3D viewport is plenty interactive. In this use case the 100 limit seems pretty silly. It is not unusual for parts of my workflow to take several minutes (physics baking, external simulations), so 21 seconds to generate a tree is no big deal.

I suspect that whatever limit we placed on the leaves value would become a straitjacket on somebody with a legitimate mission (although they would be outliers). If it were possible to limit the dragged values differently than the typed values, I would recommend doing that. If you can't impose separate limits, I'd recommend disabling dragging for the leaves field.

Since this could affect other values settings in the add on we should just disable the update fuction of the bpy.types.uilayout.prop() because each time the number is changed blender tries to recalculate the mesh.

I.E.: While dragging from 0 to 10, it has to go through 9 unnecessary recalculations before giving the one for the value 10.

Solution: add a recalculate button at the bottom and disable update argument.

initial fix by purplefrog in irc https://developer.blender.org/rBA0e536cd1b7225ef7b6c9edd982b2d9d5c527ce92
fixes for armatures are still needed.