* duplicate code removed
* marked as gtk-specific

* skip move to safety height if we go straight down afterwards

* additional TimeLimit filter
* read feedrate and safety height from configured toolpath filters

* implement toolpath cropping via a filter
* highlighted warning label in toolpath cropping UI dialog
* filters gain a "clone" method (this allows deep copies of toolpaths)
* MachineSetting filter preserves the order of settings (before: last in first out)

* don't forget to close polygons (if the ancestor was closed, as well)
* take direction of offset into account before skipping small polygons
  (growing is always allowed - shrinking is limited)

Toolpaths ("moves") are now created as simple lists containing a tuple
of two values:
- a type identifier (numeric constant) - e.g. "move", "move rapid", "safety move"
- arguments (can be a tuple, as well)

This structure allows the use of "filters" for GCode generation.
A simple example:
A "laser" GCode generator will turn all "safety move" items into
"laser power on" and "laser power off" respectively.
A milling machine GCode generator will turn all "safety move" items into
rapid moves up, then sideways moves and then slow moves down to the next
destination.

Currently the following filters are implemented:
- skip a safety move if a short sideways move does no harm (e.g. zigzag mode)
- replace safety moves with the proper combination of normal and rapid moves
- a simple example filter for machine settings (feedrate, metric system, ...)
Tool change and touch off, as well as the missing startup settings are still
open.

The "decimal" module can cause the output of values like "0E-12"
with the "%s" formatting string.

Test case:
   import decimal; print decimal.Decimal("0.0000001")
=> 1E-7

This fix uses a "%.?f" (? = number of digits) format string based
the number of significant digits as given via "minimum step width"
in GCode settings.

1) There was a piece of code that erroneously closed polygons.
2) Inside polygon culling was falsly catching open polygons. At best this code needs to be rewritten to correctly detect inside polygons.

Whitham D. Reeve II

Original developer left out a condition in a trailing else to generate an additional line to close a polyline when specified.

Made changes to remove consecutive duplicate points, combined two loops that iterated through points into one.

This code commits draw_direction_cone_mesh which is an adaptation of draw_direction_cone to generate a mesh of triangles for compression inside a vertex buffer object. The rest of the opengl code in Toolpath has been changed to use this. Only remaining use of old rendering path way is simulation.

Whitham D. Reeve II

Profiler suggests that the min/max functions for x/y/z of the Toolpath object were the main bottleneck. They iterate through all the points in each path every time they are accessed. These values are now cached which provides a huge speed boost. Originally I thought the problem was the opengl drawing code so I created a new code path that converts moves into an arrays of vertices and indices. The vertices array particularly is stored in video memory. While faster, I don't think it is all that much faster.

Whitham D. Reeve II