This gives what is to me smoother and more predictable snapping motion with
respect to the current mouse position.

For example-- imagine the grid cell size is 10 and the selected object under
the mouse already has its top left corner aligned with vertical grid line #2.

If I begin dragging that object to the left, within a single pixel of motion
it will snap to vertical grid line #1 which is 9 pixels away from the
object's current position.

With this commit, the user must drag the object cellsize / 2 pixels before it
snaps to a new position.

To me this seems smoother as it rounds to the nearest grid line rather than
to the grid line with the smallest coordinate value.

We also keep a partially transparent version of a grid for editmode. This
allows us to keep editmode visually distinct from runmode, even if snap-to-grid
isn't turned on.

If needed it's pretty easy to make the following changes:

* set the "big" cell size to something that isn't 100 (but I'm not sure how
  much control over the grid we actually want to give users-- e.g., setting
  the big cell to something for which the small cell isn't a factor
* allow snap-to-grid to be set independently for each canvas. (But again,
  what would be the use case for this?

Sam Thursfield authored 4 years ago and Albert Gräf committed 4 years ago

This causes tar_em_up.sh to download an older version of nw.js suitable
for OSX 10.8.

It was accidentally removed by me in 4bffb36f.

Disable zexy/lpt on Windows for now, it doesn't work there at present and causes a segfault in the regression tests.