----- Original Message -----
> From: Ivica Ico Bukvic <[email protected]>
> To: Jonathan Wilkes <[email protected]>
> Cc: 'Roman Haefeli' <[email protected]>; "[email protected]" <[email protected]>
> 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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
