[PD] pasted objects now end up under the original object
abonnements at revolwear.com
Mon Sep 1 23:56:45 CEST 2008
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
cmd-alt-shift-v should do what the paste does now: paste to same
that's how it is in adobe products by the way.
Am 01.09.2008 um 13:09 schrieb Frank Barknecht:
> 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
> 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.
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: Signierter Teil der Nachricht
More information about the Pd-list