I'm running Pd-extended 0.40.3 on an iBook G4 in OS X 10.4.11, and I've noticed that if I copy an object and then paste it to the same place, the newly pasted object ends up under the old object. This is annoying because if I have some objects that are already connected to other objects and I copy and paste them, I then have to move the original objects out of the way to get access to the newly pasted objects. I feel like in the previous version of Pd-extended the newly pasted objects end up on top of the old objects, so that you could just paste and them move them out of the way.
So first, is my memory of the old behavior correct? Second, is this the behavior people would expect? Third, are people seeing this across platforms, or is it just me?
andy
Your memory is correct. Quick fix: use CTL/Apple + D for duplicate instead of CTL/Apple + C for Copy and CTL/Apple + V for Paste. This pastes objects offset from the original, plus it uses less key commands. I can't verify the buggy Paste behavior you report right now, although I did have a workshop full of n00bs over the weekend and no one using 0.40 mentioned this problem to me...
best! d.
Andrew Turley wrote:
I'm running Pd-extended 0.40.3 on an iBook G4 in OS X 10.4.11, and I've noticed that if I copy an object and then paste it to the same place, the newly pasted object ends up under the old object. This is annoying because if I have some objects that are already connected to other objects and I copy and paste them, I then have to move the original objects out of the way to get access to the newly pasted objects. I feel like in the previous version of Pd-extended the newly pasted objects end up on top of the old objects, so that you could just paste and them move them out of the way.
So first, is my memory of the old behavior correct? Second, is this the behavior people would expect? Third, are people seeing this across platforms, or is it just me?
andy
Yeah, Copy-Paste needs work. It should probably paste based on mouse
cursor location.
.hc
On Aug 31, 2008, at 6:26 PM, Andrew Turley wrote:
I'm running Pd-extended 0.40.3 on an iBook G4 in OS X 10.4.11, and I've noticed that if I copy an object and then paste it to the same place, the newly pasted object ends up under the old object. This is annoying because if I have some objects that are already connected to other objects and I copy and paste them, I then have to move the original objects out of the way to get access to the newly pasted objects. I feel like in the previous version of Pd-extended the newly pasted objects end up on top of the old objects, so that you could just paste and them move them out of the way.
So first, is my memory of the old behavior correct? Second, is this the behavior people would expect? Third, are people seeing this across platforms, or is it just me?
andy
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[T]he greatest purveyor of violence in the world today [is] my own
government." - Martin Luther King, Jr.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Yeah, Copy-Paste needs work. It should probably paste based on mouse
cursor location.
If I paste I usually don't care where the mouse cursor is, and quite often it's not even over the window I'm pasting into - for example when I copy stuff from one patch window into another, I select stuff with the mouse in window 1, copy it with Ctl-V, then Alt-TAB over to window 2 and paste. There is no mouse over window 2 then, and if there would be, it would be in a random position. Pasting where the objects where before makes more sense.
Ciao
Frank Barknecht _ ______footils.org__
So, maybe, one should only paste to where the cursor is when the copy and paste are in the same window?
hmm...
M
On Mon, Sep 01, 2008 at 10:50:28AM +0200, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Yeah, Copy-Paste needs work. It should probably paste based on mouse
cursor location.If I paste I usually don't care where the mouse cursor is, and quite often it's not even over the window I'm pasting into - for example when I copy stuff from one patch window into another, I select stuff with the mouse in window 1, copy it with Ctl-V, then Alt-TAB over to window 2 and paste. There is no mouse over window 2 then, and if there would be, it would be in a random position. Pasting where the objects where before makes more sense.
Ciao
Frank Barknecht _ ______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
So, maybe, one should only paste to where the cursor is when the copy and paste are in the same window?
But copy and paste in the same window is the same as Ctl-D, isn't it? For Ctl-D I think, the current solution which pastes with a little offset is quite convenient. Normally I move objects with the cursor keys then to keep nice alignments.
I do think that pasted objects should get a "z-index" in front of the old objects, though, as often they are the objects that will get moved immediatly and pasting them behind existing objects makes it more likely to select one of the (now unselected) old objects and thus de-selecting the group of newly created objects. (I think, in pd-0.41 pasting is in front already or again. I don't remember if that was different in 0.40.)
Ciao
Frank
Right, control-D should probably stay as it is, but separately copying and pasting migt want to do something "smarter".
I've always wanted to have Pd's behavior be absolutely independent of stacking order (back-to-front). Unfortunately, the way things look when Tk draws them depends on the order they're created in, which causes all sorts of confusion.
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.
cheers Miller
On Mon, Sep 01, 2008 at 11:53:33AM +0200, Frank Barknecht wrote:
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
So, maybe, one should only paste to where the cursor is when the copy and paste are in the same window?
But copy and paste in the same window is the same as Ctl-D, isn't it? For Ctl-D I think, the current solution which pastes with a little offset is quite convenient. Normally I move objects with the cursor keys then to keep nice alignments.
I do think that pasted objects should get a "z-index" in front of the old objects, though, as often they are the objects that will get moved immediatly and pasting them behind existing objects makes it more likely to select one of the (now unselected) old objects and thus de-selecting the group of newly created objects. (I think, in pd-0.41 pasting is in front already or again. I don't remember if that was different in 0.40.)
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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:
user presses Ctl-C and copies objects from coordinates (xc,yc)
user presses Ctl-V, mouse is at (xm, ym)
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
Another possibility would be to use command-shift-paste to paste and immediately go into the "stick" state. I think I might have to try a few different ways to see which is most natural.
M
On Mon, Sep 01, 2008 at 01:09:49PM +0200, Frank Barknecht wrote:
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:
user presses Ctl-C and copies objects from coordinates (xc,yc)
user presses Ctl-V, mouse is at (xm, ym)
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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Miller Puckette wrote:
Another possibility would be to use command-shift-paste to paste and immediately go into the "stick" state. I think I might have to try a few different ways to see which is most natural.
i am only glad that there are so few modifier keys on american keyboards. just imagine the possibilities we had with 9 different modifier keys (leaving the last finger for the modified key)...:-)
anyhow, gmasdr IOhannes
With Flash you copy using : command-c
you paste in the center of your doc using : command-v
you paste in place using : command-shift-v
I like the command-d under Pd to duplicate because it is easy to
align using shift-arrow keys.
++
Jack
Le 1 sept. 08 à 13:17, Miller Puckette a écrit :
Another possibility would be to use command-shift-paste to paste
and immediately go into the "stick" state. I think I might have to try a few
different ways to see which is most natural.M
On Mon, Sep 01, 2008 at 01:09:49PM +0200, Frank Barknecht wrote:
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:
user presses Ctl-C and copies objects from coordinates (xc,yc)
user presses Ctl-V, mouse is at (xm, ym)
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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On Mon, Sep 1, 2008 at 9:47 AM, Jack jack@rybn.org wrote:
With Flash you copy using : command-c you paste in the center of your doc using : command-v you paste in place using : command-shift-v I like the command-d under Pd to duplicate because it is easy to align using shift-arrow keys. ++
It sounds like these are pretty standard across Adobe's products, as these sound like all the keyboard command used in all their other graphics products...
Mike
Jack
Le 1 sept. 08 à 13:17, Miller Puckette a écrit :
Another possibility would be to use command-shift-paste to paste and immediately go into the "stick" state. I think I might have to try a few different ways to see which is most natural.
M
On Mon, Sep 01, 2008 at 01:09:49PM +0200, Frank Barknecht wrote:
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:
user presses Ctl-C and copies objects from coordinates (xc,yc)
user presses Ctl-V, mouse is at (xm, ym)
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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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:
user presses Ctl-C and copies objects from coordinates (xc,yc)
user presses Ctl-V, mouse is at (xm, ym)
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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Max Neupert wrote:
i think it's worth it to look at how some other applications handle it.
one of the biggest problems with copy/paste right now in pd is, that if you copy a large amount of objects and you want to move them, but miss to click on a selected object, and instead move another objects which is close to a selected one, then you 1) unselect all copied objects and 2) move the wrong object. in this case, you can only undo the last action (moving the wrong object), and end up with a big mess of copied objects at places where you don't want them.
in this case, it would be better to confirm the copying with the enter key, or draw a dashed selection line around the whole copied region and as long as you click within that region you are able to move the pasted objects.
max btw copies with an offset, similar to ctrl+d. one nice feature in max, if you use ctrl+d to duplicate an object, and you drag it for example to a spot 1cm right of the object that you copied from, then, if you hit ctrl+d again, max remembers the relative offset and will place the next copied object using the same relative information (in this case 1cm right of the second instance).
and another nice max feature related to patching: holding the shift key in max when you connect two objects will connect to the object, but then automatically allow you another connection from the same origin. a new cord connection from the original outlet is created and you just have to click on the next inlet that should be connected to the same outlet.
marius.
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:
user presses Ctl-C and copies objects from coordinates (xc,yc)
user presses Ctl-V, mouse is at (xm, ym)
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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, Sep 2, 2008 at 12:19 PM, marius schebella < marius.schebella@gmail.com> wrote:
one of the biggest problems with copy/paste right now in pd is, that if you copy a large amount of objects and you want to move them, but miss to click on a selected object, and instead move another objects which is close to a selected one, then you 1) unselect all copied objects and 2) move the wrong object. in this case, you can only undo the last action (moving the wrong object), and end up with a big mess of copied objects at places where you don't want them.
YES. Dear God, that's frustrating when that happens. Aside from the suggestion of a selection line around the copied region, would it be possible for Pd to have more than one "undo" available?
--Stefan
Yes, I've spent lots of time fixing the results of this flaw.
On 9/2/08, Ichabod ichabod@gmail.com wrote:
On Tue, Sep 2, 2008 at 12:19 PM, marius schebella < marius.schebella@gmail.com> wrote:
one of the biggest problems with copy/paste right now in pd is, that if you copy a large amount of objects and you want to move them, but miss to click on a selected object, and instead move another objects which is close to a selected one, then you 1) unselect all copied objects and 2) move the wrong object. in this case, you can only undo the last action (moving the wrong object), and end up with a big mess of copied objects at places where you don't want them.
YES. Dear God, that's frustrating when that happens. Aside from the suggestion of a selection line around the copied region, would it be possible for Pd to have more than one "undo" available?
--Stefan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Why not just move those newly pasted object immediately upon pasting? Once they have been pasted, they are still selected, and you can move them with the cursor keys. You don't need to move anything to get at them. If you use the cursor key by, it will move the objects one pixel. If you hold the shift key while you use the cursor key, it will move the objects by 10 pixels. I use this technique to keep patches looking "clean"...
Mike
On Sun, Aug 31, 2008 at 5:26 PM, Andrew Turley aturley@acm.org wrote:
I'm running Pd-extended 0.40.3 on an iBook G4 in OS X 10.4.11, and I've noticed that if I copy an object and then paste it to the same place, the newly pasted object ends up under the old object. This is annoying because if I have some objects that are already connected to other objects and I copy and paste them, I then have to move the original objects out of the way to get access to the newly pasted objects. I feel like in the previous version of Pd-extended the newly pasted objects end up on top of the old objects, so that you could just paste and them move them out of the way.
So first, is my memory of the old behavior correct? Second, is this the behavior people would expect? Third, are people seeing this across platforms, or is it just me?
andy
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote:
Why not just move those newly pasted object immediately upon pasting?
The problem is, if you click by mistake, you're in an un-undoable mess. In my "smart placement" proposal some mails ago I suggested a "sticky state" for the first click after pasting where the pasted objects would stick to the mouse to be positioned until the next click anchors them. This would make the mess less likely.
Of course more undo steps would still be nice.
Ciao
Frank Barknecht _ ______footils.org__
-
Andrew Turley -
Derek Holzer -
Frank Barknecht -
Hans-Christoph Steiner -
Ichabod -
IOhannes m zmoelnig -
Jack -
marius schebella -
Matthew Logan -
Max Neupert -
Mike McGonagle -
Miller Puckette