W dniu 11 stycznia 2010 22:11 użytkownik Diederik van Lierop <mail@...1689...> napisał:
It might be counter-intuitive to you, but at least it's predictable. IMHO that's very important for users who use snapping because they tend to value accuracy and want to be sure that their drawings are perfectly aligned and orthogonal. In the days before we had the snap-indicator this predictability was even more important because they didn't get any feedback; nowadays this predictability is still useful though.
This behavior might be predictable, but it is surprising. 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. Also note that the suggested new behavior is also trivially predictable: only snap when a snap indicator is present.
The first time I encountered it, it was like this: 1. I move the node near another node, with snapping enabled. 2. 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.
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?
No we're not guessing here, we're being predictable! Snapping is enabled, so we'll snap. Always. Period.
Snapping is enabled, but the snap delay is enabled as well! So apparently the user doesn't want to snap right away, otherwise he would decrease or disable it...
This could be improved even further by implementing my second idea: when something snaps, it should remain snapped to the same snap target until the pointer moves out of range.
... or until it comes closer to another snap target. This is exactly the behavior you'll get when you set the snap delay to zero. This requires some snapping code to be executed for each and every motion event.
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. This way it's harder for people that don't have a perfectly steady hand to snap to something they didn't want to if they are working in a crowded area of the drawing.
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.
Regards, Krzysztof