[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