[L2Ork-dev] snap-to-grid
Mario Sottile - Marionetas Mey
mariomey at gmail.com
Wed Oct 21 08:56:59 EDT 2020
I don't know if I correctly understood you... but I think that, if
snap-to-grid is on, objects that are not exactly at a grid vertex should
go inmediatly to the nearer.
Two examples that don't help :D
Blender: it snaps to "next increment value". If object is at 0.5, it
goes to 1.5. I think this is good for some needings... but not for
PurrData. Watch blender.mp4
Inkscape: when snap-to-grid is on, object can be moved between grid
vertices. When is near a vertex, object sticks to it. I think that Purr,
snap-to-grid should always stick to the grid. I think Inkscape is like
this, because it has lot of snap-to options. Watch Inkscape.mp4
Mario Sottile - Director
(011) 15.6283.1576
www.mariomey.com.ar
info at mariomey.com.ar
On 20/10/20 13:31, Jonathan Wilkes wrote:
> 2nd question:
>
> Suppose the mouse pointer and the top-left corner of the object
> underneath it are both 2/3 of the way to the post office from their
> shared home.
>
> 1. Does the object wait until the mouse pointer has safely arrived at
> the post office to "snap" itself to the post office?
>
> Or
>
> 2. Does the object "snap" immediately to the post office at the first
> step the mouse pointer takes toward the post office?
>
> If it's #1, then the selection will wait at an unsnapped position
> until the mouse arrives at a grid line/point. So the first step of an
> un-aligned object will have a UX like "gravity"-- i.e., you are
> coaxing the selection to its initial snap position. Also, the mouse
> may temporarily drag outside the bounds of the object beneath it
> before the object snaps to its new location.
>
> If it's #2, then the selection will immediately align itself to the
> grid constraints. This will provide consistency-- as any mouse motion
> will guarantee grid alignment-- but have a jagged feel on the first
> mouse motion of the un-aligned object. Edge case-- if the mouse is
> near the top-left corner of an unaligned object, then the object's
> initial grid snap will mean that the mouse will be outside the
> object's bounds for the rest of the time it's dragging.
>
> Since people generally drag more than one or two pixels with a mouse,
> I'm leaning toward #1.
>
> I want to pick a pattern before I implement it. The backend selection
> motion deals with deltas instead of coords, and that makes this a bit
> more of a pain than it should be.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20201021/073d22f6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: firma.png
Type: image/png
Size: 4902 bytes
Desc: not available
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20201021/073d22f6/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blender.mp4
Type: video/mp4
Size: 42995 bytes
Desc: not available
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20201021/073d22f6/attachment-0002.mp4>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inkscape.mp4
Type: video/mp4
Size: 140657 bytes
Desc: not available
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20201021/073d22f6/attachment-0003.mp4>
More information about the L2Ork-dev
mailing list