gEDA-dev: Grid snapping bugs

[Peter Clifton]

Having converted the much of the internals of libgeda / gschem to use
world coordinates, I've discovered some problems relating to grid
snapping.

SCREENtoWORLD will implicitly grid-snap, and since I'm now doing hit
detection in world coordinates (having used SCREENtoWORLD to convert the
mouse coordinates), the hits are being thrown off in some cases.

My solution is to remove implicit grid snapping from SCREENtoWORLD, and
make code which NEEDS to grid-snap call snap_grid( w_current, ... ).
Much of the code does this anyway, immediately after a SCREENtoWORLD,
which must cost some CPU cycles due to snapping twice.

I was thinking that ideally, we could do the snap early on, possibly
moving the w_current->{start|end}_{x|y} and related coordinates to world
coords too. In the first instance, I'd left these as screen coords for
ease or porting, and since the rubber-banding drawing ought to be faster
without the coordinate transforms.

Is there ever any possibility of grid snapping being turned on / off
whilst drawing an object? I presume that operations made with snapping
on, would snap, and operations made with snapping off, would not.

The most difficult concept (I think) is how objects which are not
grid-aligned will react when operated on.

Peter