W dniu 10 stycznia 2010 21:13 użytkownik Diederik van Lierop <mail@...1689...> napisał:
On 01/10/2010 03:36 PM, Krzysztof Kosiński wrote: Ah, now I see: you're interpreting the snap indicator differently. If you see the snap indicator then snapping _has_ already occurred. The indicator has been implemented to show what we've snapped to, not to show what we'll snap to _after_ the mouse button is released.
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.
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?
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. If this assumption is true, the snap delay is redundant and gets in the way of efficient work, because we hold back information from the user.
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? 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 (unless you have a very big document and snapping is resource-intensive - then you can treat is as a kind of optimization).
If someone wants his movements to always snap, he should set the snap delay to zero, instead of making this setting useless for everyone else. If the majority really wants such behavior, then I think the snap delay setting should be reduced to about 50 ms and removed from the UI, as mentioned above.
Correct, you'll have to switch snapping off yourself explicitly, Inkscape will not do that for you. We should not try to guess when a user wants to snap and when not, we might guess wrong without the user noticing.
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, but this guess is not based on any input. It is just an assumption pulled out from nowhere. In fact we actively ignore the user's preferred value of snap delay. If we only snap after the snap delay expires, our guess is based on somewhat explicit input from the user - he didn't move the mouse.
If the majority wants to snap most of the time, we can set the default snap delay to something low (a few ms). This way we satisfy the always-snap group (they won't notice the delay), get most of the optimization benefits and don't make this setting useless for the rest (like me).
The most elegant way is to disable snapping when holding the SHIFT key, as some tools do, but unfortunately the modifier keys are already heavily contested so we will probably never get that implemented in all tools. The second best thing is to use the % key to toggle snapping, and to toggle it back on again afterwards.
I could turn snapping on and off every time, or use the already overloaded modifier keys. But I could as well tweak the snap delay to my liking and work more efficiently, without touching the keyboard - that's the point :)
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. 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.
For point snaptargets it's very simple to implement: after we snapped to a point, do not move until the point's new position would be more than the snap distance away from the current one. For paths and lines it's a bit more involved. After the initial snap we want to only move the point on the snapped line or curve. We would need to store some information about the snap target, for example the geometrical representation the snapped shape segment.
Regards, Krzysztof