On 01/10/2010 10:43 PM, Krzysztof Kosiński wrote:
So we are not showing what will actually happen, or are only showing it after some delay which interferes with normal work. If the majority really wants to use the snap delay only as an optimization, then we should set the snap delay to something low (like 50 ms) and remove it from the UI, because it has absolutely no effect for the user.
It's in the UI because I didn't know at that time what a good value would be, and to allow users to turn it off and get the old behavior back. The latter might still be desired, so I propose leaving the slider there, but we can indeed lower the default value as you suggested. Could you do a short test and see at what value it becomes acceptable for you?
Now when dragging an object it will become unaligned, but it should be aligned again once its released (only if snapping has been enabled ofcourse). That's why snapping is triggered when the mouse button is released.
That's circular. Why should it become aligned again if I dragged it, especially if there is no indication of that happening in the UI?
My assumption here is that the user is moving from one aligned position to the other, and the unaligned position is just an intermediate state. So if the user drags an object it's not because he wants it to become unaligned, but to move to another aligned position. Different users might have different expectations though.
The snap delay mechanism controls how often Inkscape tries to snap while dragging the object around, but still we always snap when releasing the mouse button. The snap indicator only tells us where snapping took place.
Yes, I know but you didn't give any explanation why this is the best behavior. I think it is counter-intuitive, based on the assumption that when snapping is enabled, we should always snap.
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.
Believe me, there are users who prefer it like this! I found that out _after_ implementing the snap delay ;-)
Maybe they did not want the snap delay at all?
That could very well be the case, so that's why they can disable it. You will need it though on complex documents, or on a slow pc
The current behavior is really making this setting useless. It only affects how much time you need to waste to see what will happen after you release the mouse, so setting it to something else than 0 is counter-productive
For me 150 msec (the current default value if I'm correct) is hardly noticeable, but maybe I'm getting old ;-) ? Please confirm if you really want to go as low as 50 msec. Have a try at e.g. 75 or 100 msec and report your experiences. I think the higher the more better, but obviously there should be an optimum somewhere.
If I did not move the pointer for the last 300 ms or so, then it means I want to snap. If I did, then probably I'm making a movement that shouldn't snap. If I wanted different behavior, I would adjust the snap delay setting. When we snap on release, we are guessing that the user wants to snap
No we're not guessing here, we're being predictable! Snapping is enabled, so we'll snap. Always. Period.
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.
This way minor accidental movements after the snap delay expires do not break the snap - I have to make a larger movement to move away the point. This way most of the user-side rationale for always snapping on release (it's easy to accidentally move the mouse a bit while releasing the button) would disappear.
Because of the boundary condition that snapping should always occur, and because we don't want to snap on each and every motion event (the snap delay mechanism), we must snap when releasing the mouse button. If the user drops an object "on the fly", snapping must be triggered, even though the mouse speed doesn't drop to zero. So only monitoring the speed of the pointer to trigger snapping is not sufficient.
Diederik