----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: Jonathan Wilkes jancsika@yahoo.com Cc: 'Roman Haefeli' reduzent@gmail.com; "pd-list@iem.at" pd-list@iem.at Sent: Monday, January 21, 2013 1:16 AM Subject: Re: [PD] enhance pd-extended with pd-l2ork featues ?
On 01/21/2013 12:15 AM, Jonathan Wilkes wrote:
Also see the end of: http://www.youtube.com/watch?v=wTPZxcgWoI0
When undoing the creation of an object or objects, at some point Pd-l2ork
will move
the object to the place where the mouse happened to be hovering when the
user clicked
<ctrl-1> to get an empty box dangling from the mouse. But the user
never actually
anchored the object there-- they only anchored it somewhere once they
clicked the
mouse button. Thus, your undo history erroneously adds an object placement
event
that was never performed by the user in the first place.
Theoretically the corresponding undo event should make the object dangle
from the
mouse again, but that's of very little practical value and would just
bloat the undo
history with an extra step for every object in the chain. Instead this
event should
simply not be added to the undo history. I don't know the innards of
pd well, but those
"dangle" events should all have a single "0" as a
coordinate so maybe you can check
for that.
-Jonathan
That is not a bug. That is how pd instantiates objects. As soon as your cursor touches canvas, it will instantiate an object at the last known cursor position (if the cursor is off-canvas) or next to mouse cursor and then enable motion for the object to follow the cursor until a mouse clicks (there is an exception when autopatching in which case motion is not enabled, but that is not relevant to this example). So, if you create an object without having a mouse on canvas, then move mouse onto it, the object will instantiate where you had your cursor the last time and then immediately move (since the startmotion was triggered) next to your cursor once you've positioned it back over the canvas. So, in essence there are 2 steps undo is keeping track of. Yes, this addition adds extra step but is a lot easier to manage than coming up with yet another exception on how the editing works. Doing what you suggest could easily obliterate undo and annoy user when they do series of undos and then suddently the object is back hooked onto mouse and the next thing you know, the undo has rebranched since it assumes that the user is now wanting to do something new from that spot onwards making them lose forward undo history. This is all because pd first instantiates objects, then asks question where the object should go. While ideally this one step could be skipped, it would require a fairly hefty rewrite for a mere skip of one undo step...
For each object the user instantiates through the "Put" menu or keyboard shortcut, they end up with an entry in the undo history they are guaranteed _never_ to use and which they almost certainly understood as a transient patch state since the object had a _blue_ outline and was dangling from the mouse in the same way it dangles from the mouse when they left click and drag (which itself is a transient patch state). That means when making a new patch, for every n object that is not autopatched the user must view n patch states on their way to the beginning of the history that never actually existed by the rules of the graphical interface. I'd call that a recurring nuisance that is not unlike an insect sporadically greeting different parts of your head by buzzing around it.
More practically: when the user is one step away from the history to which he/she wants to return, he she has a $n/$undo_count*100 chance of being two steps away.
-Jonathan