On Tue, 12 Jan 2010 05:46:30 +0100, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
The argument that some behavior is predictable is weak, because almost all programs (even viruses) behave in a predictable way, unless they are broken or purposefully random. If something is predictable, it doesn't mean it's right, intuitive or convenient.
It's the other way around: something that is _not_ predictable is bad. I'm obviously not arguing that something that's predictable is always good, regardless of the implementation
Also note that the suggested new behavior is also trivially predictable: only snap when a snap indicator is present.
No, because the snap indicator can be overlooked or can be disabled. And if that happens the predictability is gone.
The first time I encountered it, it was like this:
- I move the node near another node, with snapping enabled.
- I release the mouse button, and there is no snap indicator. I think
it should stay where I drop it. 3. Bang! It moves to the other node's position. What happen?!? There was no snap indicator, so I expected the node to stay where it is.
Reduce the snap delay and this will be solved.
Adding the snap indicator changed the game fundamentally. When there was no snap indicator, the only information the user had was that snapping is enabled. But with the snap indicator present, we notify him when we'll snap. So why do we sometimes snap without notifying him?
We don't. It's there within 150 msec.
Not quite. The whole point is to "stick" only to the target we snapped to, and ignore other snap targets. To snap to another target, the user has to move the pointer out of range and wait for the snap delay to expire again.
That won't work. If you have a cloud of points, it will not be possible to snap to points in the middle of that cloud. When moving towards that cloud, Inkscape will snap to a point at the circumference and stick there. Only by moving away from the cloud the user can snap again, but by approaching that cloud from a different direction another point on the circumference will be snapped too, and again not the point at the center of the cloud. This can only be solved by taking into account each small motion increment, looking at all points in the vicinity for each motion event, and each time determining which snap target is the closest.
To get the behavior I suggested, I only need to either: a) check whether the distance from the snapped point would be larger than the snap distance, if I snapped to a point. b) compute the nearest point for the path fragment, and check whether it's farther away from the new position than the snap distance, if I snapped to a path. Those computations are trivial and cannot impact performance in any significant way. There's already some processing done on each motion event. Adding this would be insignificant.
See my reasoning above about the cloud of points. Snapping code must be executed on each motion event and your algorithm won't work in this case. The only way to speed this up is to use the snap delay mechanism which eliminates snapping on some of the motion events, to implement better caching of the snap target candidates and their snap points, and to make it faster to find the items in the vicinity (e.g. using some 2D database).
Diederik
Regards, Krzysztof