Mouse drag drifting issue

[trive]

I have noticed a dragging “drift” for elements rendered inside a Phone patch.

Download this patch and try to drag the circle—you'll see that the mouse position and the circle drift away.
https://dl.dropboxusercontent.com/u/369957/static/DragDrift.qtz

Is this a bug?

[samirda]

I have also noticed it. It seams like the hit area is transformed correct but the UI element is behind.

Steps to reproduce error:
Start drag the circle and stop when the mouse is near the end of the phone screen.
Release mouse button without movement.
Press mouse button without movement, circle gets selected/highlighted and is draggable.
Release mouse button without movement at the end of the phone screen.
Press on the circle, nothing happens.

Edit: It looks like the bug might be in the Render in Image macro.

[trive]

It looks like the scaling that happens in Origami's Phone.qtz messes with the coordinates provided by the Mouse and the Interaction patches.
It seems like the resizing Quartz' viewer resizes whatever is in Render in Image but doesn't “resize” correctly the coordinate system that Mouse and Interaction are using.

[samirda]

The bug is not in origami, I have reproduced the error in quartz composer with default macros.

Edit: Here is a workaround http://macoscope.com/blog/science-behind-snapping-scroll-part-i-dragging/

[bwalkin]

This bug is in Quartz Composer but we're planning on providing a workaround in a future version of Origami.

[trive]

Thanks for your replies.

The macoscope.com workaround works but only when not in full screen mode.
Looking forward to the Origami workaround—how are you going to do it?

[trive]

Btw, I've put together “Draggable Layer”, a packaged version of the Macoscope workaround.
Perhaps somebody will find it useful
https://dl.dropboxusercontent.com/u/369957/static/Draggable%20Layer%20Example%20v1.zip

[simblestudios]

The Macoscope workaround also falls apart (at least with Origami 1.2) if you make the window very tall and skinny. The magic number of 1.6 loses it's magic when the width of the window affects the height of the Phone patch. You can create a workaround that handles any viewer size, but you have to hard-code the device image sizes and the magic padding number (200) that's used to do all the calculations, so I'm not sure it's worth it.

[tarngerine]

Hey all, this seems super old (sorry, housecleaning) and as noted above it's not quite worth fixing this since our primary concerns are with supporting prototyping with origami Layers rather than QC unit based consumer patches.

[trive]

Makes sense.
Happy Holidays :)
On Fri, Dec 25, 2015 at 7:13 PM Julius Tarng notifications@github.com
wrote:

Hey all, this seems super old (sorry, housecleaning) and as noted above
it's not quite worth fixing this since our primary concerns are with
supporting prototyping with origami Layers rather than QC unit based
consumer patches.

—
Reply to this email directly or view it on GitHub
#22 (comment).