[L2Ork-dev] snap-to-grid

[Jonathan Wilkes]

On Wed, Oct 21, 2020 at 9:02 AM Mario Sottile - Marionetas Mey <
mariomey at gmail.com> wrote:

> 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
>

Hm... I'm not able to view the videos you linked.

The Blender version is quite easy to implement. But I agree with you-- it's
not a good fit for Purr Data.

-Jonathan


>
> 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.
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20201021/70a59e27/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/70a59e27/attachment-0001.png>