[L2Ork-dev] snap-to-grid

Jonathan Wilkes jon.w.wilkes at gmail.com
Fri Oct 23 17:24:45 EDT 2020


On Fri, Oct 23, 2020 at 5:02 PM Albert Graef <aggraef at gmail.com> wrote:

> That looks awesome, I can't wait to have this! Where's the branch for it?
> :))
>

I still have to hook in a sys_gridsize and a g_editor field for it.

Btw-- ran into a weirdo bug testing this. Sometimes I can drag an object
outside the window bounds (as you should be able to do). Other times the
object stops at the edge of the window and cannot be dragged any further.
Same with or without snap-to-grid, so I'm not sure what the problem is
there.

-Jonathan


>
> On Fri, Oct 23, 2020 at 8:59 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
> wrote:
>
>>
>> On Fri, Oct 23, 2020 at 8:35 AM Mario Sottile - Marionetas Mey <
>> mariomey at gmail.com> wrote:
>>
>>>
>>> It wouldn't be a problem *if* there were clear visual evidence that the
>>> objects are indeed connected. Without the GUI offering that clear
>>> evidence, I don't think it's a good idea. For example, if the user runs
>>> into a really difficult bug, it requires *moving* those objects around or
>>> clicking "Tidy up" to confirm the connections.
>>>
>>> And I have seen stacked objects where it turned out one of the objects
>>> wasn't connected. It is similar to perfectly horizontal wires connecting
>>> objects-- I've seen a Pd Vanilla patch where the connection crosses
>>> over the inlet of an object that wasn't actually connected. The curved
>>> wires in Pd-l2ork/Purr Data help somewhat with that, but it should still
>>> be avoided IMO.
>>>
>>> Curved wires gives us a solution! (joke)
>>>
>>
>> Honestly, it's not out of the question to make a special case for when
>> the out coordinates match the in coordinates. :)
>>
>> Attached is a prototype of the "snap to grid" feature. (The default
>> output format was mkv-- let me know if you can't read it.)
>>
>> You can see when I try to position the object at (0, 0) why inkscape
>> allows free displacement between the gridelines. Otherwise, the user loses
>> responsiveness when trying to "park" the object at a given snap position.
>>
>> However, it still seems quite usable without that feature. So if there
>> aren't any objects I'll go ahead and turn the prototype into a merge
>> request.
>>
>> Also note: the editmode grid is offset by five pixels. Now that we have
>> snapping, I *think* users will want to align the snap points to the
>> gridlines. So I'll need to change the grid line placement.
>>
>> -Jonathan
>>
>>
>>> You are right. Snap to objects is, for the moment, a bad idea.
>>> _______________________________________________
>>> L2Ork-dev mailing list
>>> L2Ork-dev at disis.music.vt.edu
>>> 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
>
>
>
> --
> Dr. Albert Gr"af
> Computer Music Research Group, JGU Mainz, Germany
> Email: aggraef at gmail.com, web: https://agraef.github.io/
> _______________________________________________
> 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/20201023/72a51226/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debfknjjodafekng.png
Type: image/png
Size: 11440 bytes
Desc: not available
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20201023/72a51226/attachment-0001.png>


More information about the L2Ork-dev mailing list