[L2Ork-dev] canvas snap-to-grid

Linux ROUEN Normandie linux.rouen at free.fr
Fri Oct 30 22:38:06 EDT 2020


1. I confirm that after having moved (towards right and down) all 
objects in an existing given patch until the screen is not jumping 
anymore, the things are getting better on the left/middle parts of the 
canvas.
Q: How can we easily reset canvas to (0,0)?
Unfortunately, if there is a GOP in the patch it will still have to be 
moved manually.

2. Even with that, all the objects on the right side of the patch at 
high zoom level are not snapping correctly to the gridlines.
*The issue starts when zooming-in and the scrollbars appear.*
So resetting to ~ (0,0) seems to be only one part of the solution.

3. Comparing a totally new patch with above 1., its behavior is the same 
than in above 2.

Joseph
- - - - - - - - - - - - - - - - - - - -
Le 31/10/2020 à 02:33, Jonathan Wilkes a écrit :
> On Fri, Oct 30, 2020 at 8:08 PM Albert Graef <aggraef at gmail.com> wrote:
>> I *think* that this happens with patches extending up and/or left from (0,0) into negative coordinate territory. At least I can reproduce the same kind of behaviour if I first drag some objects past the upper left corner. Jonathan, any idea?
> I can see a spot where this may be off in the code.
>
> But there's a bigger problem: the grid is a background image and it is
> sized and positioned relative to its container.
>
> So if you move an object to be at (-1,-1) this will change the svg's
> viewbox to extend from (-1, -1), but the
> background image of the grid is still positioned at (0, 0).
>
> This means that every time the viewbox changes (i.e., any time the
> scrollbar state changes), we have to check to see whether we need to
> change the background position to ensure it's at the same offset at
> the two first values of the viewbox.
>
> I'll take a look at it tomorrow.
>
> Anyway, this means the background grid as we currently ship it will
> get offset from the content any time the
> user puts objects at negative coords.
>
> -Jonathan
>
>> Albert
>>
>>
>> On Fri, Oct 30, 2020 at 11:56 PM Linux ROUEN Normandie <linux.rouen at free.fr> wrote:
>>> Four more using Peek.
>>> It's the same for all my existing projects / patches / subpatches.
>>> Joseph
>>> - - - - - - - - - - - - - - - - - - - -
>>> Le 30/10/2020 à 23:34, Linux ROUEN Normandie a écrit :
>>>
>>> 2nd trial (4 MB) was refused as it was exceeding 2048KB.
>>>
>>> So, this one (~ 1 MB) ... Am I alone ?!
>>>
>>> I will try with Peek to give a larger view on this subject.
>>> Joseph
>>> - - - - - - - - - - - - - - - - - - - -
>>> Le 30/10/2020 à 20:46, Albert Graef a écrit :
>>>
>>> Forgot the attachment, here it is.
>>>
>>> On Fri, Oct 30, 2020 at 8:45 PM Albert Graef <aggraef at gmail.com> wrote:
>>>> On Fri, Oct 30, 2020 at 6:36 PM Linux ROUEN Normandie <linux.rouen at free.fr> wrote:
>>>>> 1. I'm having an issue with my attached file size limit (max. 10 MB), so I do need to change my screencast parameters for getting it smaller. It's coming soon...
>>>>
>>>> Do you use Peek (https://github.com/phw/peek)? Just a short gif animation showing a rectangular region of your patch window should be all that's needed. That's typically not a lot more than a few 100 KBs, like the one that I attached below.
>>>>
>>>>> 2. I have made additional tests. I can confirm if you start with a totally fresh-empty patch, Canvas Snap-to-Grid is effectively working well regardless of the used zoom level... But not with my existing patches!
>>>>
>>>> I also took existing patches. Granted, these probably aren't as complicated as yours and might use different font sizes, but I haven't run into any issues with these.
>>>>
>>>> Albert
>>>>
>>>>> Joseph
>>>>> - - - - - - - - - - - - - - - - - - - -
>>>>>
>>>>> Le 30/10/2020 à 16:47, Albert Graef a écrit :
>>>>>
>>>>> On Fri, Oct 30, 2020 at 2:10 PM Linux ROUEN Normandie <linux.rouen at free.fr> wrote:
>>>>>> On my side the experience with Purr Data 2.15.2 (Albert's 20201030) under Ubuntu 20.04 / Linux Mint 20.0 is not positive and the behavior changes with the zoom level.
>>>>>
>>>>> Joseph, I tried, but I can't reproduce this. For me, on Manjaro it works exactly the same on each zoom level. Can you please post a screencast showing the issue that you're seeing?
>>>>>
>>>>> Also note that if you have multiple objects selected, *only* the dragged object gets aligned to the grid, any other selected objects just move along with it, retaining their relative positions to the dragged object.
>>>>>
>>>>> Albert
>>>>>
>>>>>
>>>>>> I'm taking the top/left of the objects being the reference point with a screen resolution of 1920 x 1080 and Purr Data Grid = 10.
>>>>>>
>>>>>> With Zoom level = 9.
>>>>>> I take any object and move them with the mouse. Snap to Vertical grid is OK but not the horizontal one which -2 pixels down the grid.
>>>>>>
>>>>>> Change Zoom level = 13.
>>>>>> The reference point of above objects has moved by -2 pixels to the left and no change on the horizontal one.
>>>>>> Moving them with the mouse, now Snap to Vertical grid is effectively -2 pixels left and the horizontal one is still -2 pixels down. So no possible alignment to the grid.
>>>>>>
>>>>>> Change Zoom level = 15.
>>>>>> Same as for ZL 13 with more shift: from -2 pixels to -5/6 pixels, but never on the grid.
>>>>>>
>>>>>> Best, Joseph
>>>>>> - - - - - - - - - - - - - - - - - - - -
>>>>>>
>>>>>> Le 30/10/2020 à 03:47, Albert Graef a écrit :
>>>>>>
>>>>>> On Thu, Oct 29, 2020 at 10:30 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>>>>>>> Canvas snap-to-grid feature is now available for review:
>>>>>>>
>>>>>>> https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/597
>>>>>>
>>>>>> Thanks a bunch, I've really been waiting for this! :)
>>>>>>
>>>>>> I already merged this into my testing branch and had a quick look, works fine for me so far.
>>>>>>
>>>>>> I noticed one cosmetic issue, though. I'd suggest changing the translations for prefs.gui.grid.show_grid and prefs.gui.grid.show_grid_tt. This option is still displayed as "grid background in edit mode" right now, but has actually become a "snap to grid" option.
>>>>>>
>>>>>> My suggested translations can be found at https://bitbucket.org/agraef/purr-data/commits/7aca2748. (@Joseph, can you please check my French? Thanks.)
>>>>>>
>>>>>> I already have these in my testing branch, so I can add this to your MR if you want. Just let me know.
>>>>>>
>>>>>> If anyone else wants to give it a go, try purr-data_2.15.2+git4745+7aca2748 which is currently building in the OBS preview channel at https://build.opensuse.org/package/show/home:aggraef:purr-data-git/purr-data.
>>>>>>
>>>>>>> Albert-- can you take a look at my math in canvas_snap_to_grid?
>>>>>>
>>>>>> Looks good to me!
>>>>>>
>>>>>>> I notice that once you start moving the selection, it kind of "snaps
>>>>>>> backwards" to the "floor" gridline. Is there an easy way to fix it so
>>>>>>> it always snaps to the closest gridline for the general case (e.g., in
>>>>>>> the assignment to dx/dy below the snap_got_anchor conditional)?
>>>>>>
>>>>>> I haven't thought about this in any depth, but have you tried rounding just xnew-xwas to the nearest grid point and finally adding snap_dx, likewise for y? That said, for me it already works well enough as it is. :)
>>>>>>
>>>>>> Albert
>>>>>>
>>>>>>> -Jonathan
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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/
>>>
>>>
>>> --
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev



More information about the L2Ork-dev mailing list