scenario:
You have multiple windows of vvvv running with different patches
You want to copy some nodes from one patch and paste it to different window
You however forget after copying the nodes click into the window you want to paste them to
So you paste them out of view in your original window, eventually you might have to scroll around, and delete them
solution
Either clamp the paste position to window edge or automatically paste into window which is under the cursor.
What’s wrong with Ctrl Z, select the correct window and Ctrl V?
it might sound crazy, but i sometimes dont notice it, especially when doing something fast, and later i find bunch of nodes out of canvas
Why should it be allowed when it is only taking away from user experience
Well, copying stuff from an object and pasting it on another selected object is probably one of the greatest feats, like ever, in computing, IMHO.
It is so great, simple, perfect and widespread that even Apple hadn’t the guts to change its name to something else (because “we re-invented it”).
So yes, it sounds crazy to me. Clamping the paste position to edge would mean to move **EVERYTIME** the pasted objects to the actual location; pasting on the window under the cursor may have some sense, some fascination I’d say; nonetheless, I strongly disagree with this. But that’s like, my opinion, dude.
I hope this issue doesn’t stem from the use of a touchpad (not to be confused with trackpad).
This pasting things in with bizarre offsets seems to be new behavior; I never noticed it until I think beta35.
I think the intuitive behavior is to paste under the cursor like pretty much every other program does (and how I thought it worked before) - give the user the ability to specify where it goes, This having to scroll way out to timbuktu to look for things is a pain and highly prone to error.
Agree with @mediadog, I never got why it needs to paste things in the same position as in the patch it was copied from. It should paste under the cursor like every other software. Maybe a special shortcut for “paste in place”. I too have pasted stuff, thought it wasnt working, then later found loads of copied nodes mixed into the rest of a patch, so I cant even easily remove it, but have to select every node one by one and delete.
@mediadog Please note that stix was talking about pasting content under the cursor without selecting the window below the cursor; in other words pasting on any window (hopefully on top) that’s below the cursor.
Pasting on a selected window under the cursor, afaik, works correctly.
hm, i don’t think this works always. at least it doesn’t work if the paste comes from a different instance.
@sebl True, when different instances are involved the behavior is unpredictable.
Initially it seemed that the node offset from top left of source patch was added to the offset of cursor on dest patch (second instance). Added a getpatch node to see if it was true and this “predictable” behavior was gone.
@sebl beat me to it - maybe that’s why I’m seeing it lately, as I’m doing more multi-instance setups. And @h99 for me it does seem to consistently be original patch position added to the cursor; how is this not the case?
@mediadog come to my place, we’ll check this out. I’m not going to gif this stuff.
Edit: Nevermind, I have to get up early tomorrow morning, so I’m going to bed. We have to reschedule this.
Oh fine, there goes my evening…
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.