[PD] pasted objects now end up under the original object

[Max Neupert]

i think it's worth it to look at how some other applications handle it.
it is quite annoying if the same function is different across  
applications and when you spent a lot of time in one program you get  
confused working with a different one. (for example i regularily try  
to go to edit mode in my PIM manager/address book with cmd-E and then  
remember that it is not pd)

copy and pasting is an important part of pd. what is very confusing  
for beginners is that things are pasted exactly where they where in  
the first place. a typical situation is that someone has discovered a  
certain thing in an help-patch and wants to experiment with that. so  
the part is selected and a new window opened and pasted. nothing is  
drawn, so the student presses cmd-v some more times and later  
realizes that it all was pasted somewhere far off.

i'd recommend that pasting pastes by default in the middle of the  
front window.
cmd-alt-shift-v should do what the paste does now: paste to same  
position.

that's how it is in adobe products by the way.

ciao, max

Am 01.09.2008 um 13:09 schrieb Frank Barknecht:

> Hallo,
> Miller Puckette hat gesagt: // Miller Puckette wrote:
>
>> Right, control-D should probably stay as it is, but separately  
>> copying and
>> pasting migt want to do something "smarter".
>
> What about this idea/specification for a possible smart placement:
>
> 1) user presses Ctl-C and copies objects from coordinates (xc,yc)
>
> 2) user presses Ctl-V, mouse is at (xm, ym)
>
> 3) Objects get pasted at position: (xc, yc) - the original  
> coordinates -
> but they don't get "anchored" yet.
>
> Now comes the new part:
>
> 4.1 a) If user moves the mouse now, the objects move to the mouse
> coordinates (xm, ym) and they "stick" to the mouse from that point on,
> until the next click.
>
> 4.1 b) Alternatively one could enter the "sticky" phase only if the  
> user
> clicks the mouse, i.e. as soon as the user after step 3) clicks  
> into the
> canvas, the objects move to the mouse position and stay selected for
> mouse movement until the button is released at which point the objects
> are anchored and possibly deselected. Deselecting could also require a
> second click. I like b) better than a): it contains less surprises.
>
> 4.2)  This alternate path is taken, if the user doesn't use the mouse,
> but the cursor keys instead after step 3): The objects move  
> relative to
> their new position at (xc, yc). They are still selected.  Mouse
> movements don't affect their position anymore, mouse clicks will
> deselect the objects. That's basically the old, non-smart placement,
> which has its uses, too.
>
>> THe current strategy for figuring out which object you clicked on  
>> is that, if
>> more tan one object is selected, Pd prefers to drag an already- 
>> selected one;
>> this is much better than whatever I had going before.
>
> Yes, that's good.
>
> Ciao
> -- 
> Frank
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: Signierter Teil der Nachricht
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20080901/9d21d238/attachment.pgp>