[L2Ork-dev] snap-to-grid

[Mario Sottile - Marionetas Mey]

Blender:

Inkscape:


Marionetas Mey

Mario Sottile - Director
(011) 15.6283.1576
www.mariomey.com.ar
info at mariomey.com.ar

On 21/10/20 11:09, Jonathan Wilkes wrote:
> On Wed, Oct 21, 2020 at 9:02 AM Mario Sottile - Marionetas Mey 
> <mariomey at gmail.com <mailto: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 <http://www.mariomey.com.ar>
>     info at mariomey.com.ar <mailto: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 <mailto:L2Ork-dev at disis.music.vt.edu>
>     https://disis.music.vt.edu/listinfo/l2ork-dev
>     <https://disis.music.vt.edu/listinfo/l2ork-dev>
>
>
> _______________________________________________
> 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/695f4dc1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bdfojfhifalfekan.gif
Type: image/gif
Size: 379509 bytes
Desc: not available
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20201021/695f4dc1/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pggochaflijppplg.gif
Type: image/gif
Size: 807127 bytes
Desc: not available
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20201021/695f4dc1/attachment-0003.gif>
-------------- 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/695f4dc1/attachment-0001.png>