[Bf-funboard] command-history, undo, scripting, and other goodies..

[Vincent Akkermans]

On Sunday, 7 July 2013 at 21:31, David Jeske wrote:
> >  
> > This is where things get a bit tricky I think. There are in fact two
> > histories: one is the history of the document and the other is the history
> > of user interaction. Normally you would display the history of the document
> > to the user, because that's what you'd be interested in changing.
> >  
>  
>  
> As a *user* I think of this as one history, "the things I've done with the
> app". That history is divided into two kinds of things: (a) things on the
> undo-history, and (b) things not on the undo history.

> I can see the reason users who are not scripting would be primarily
> interested in the undo-able entries only. However, if I'm looking at the
> FULL history (aka Command-History), I'd really like it to show me when
> entries are user-interaction entries, and which entries are "undoable
> document modifications".

I see your point. There's definitely a large part of the interactions that are not undoable and making visible what is and what isn't is probably a good thing. Perhaps a helpful distinction to make is to look at what user interactions are targeted at: content or interface.

I wonder how aware users are of all those actions that they take that do not show up in the history list (I hope not too many, because being consciously aware of all of them would be an immense cognitive burden) and how many of them we would actually want to consider including. For example, changing the tab in the properties window, tooltip hover, panning the 3D view. What are good criterions for deciding what should be shown and what shouldn't (regardless of whether they're undoable)? You could look at whether an interaction can be a direct effect or a side-effect on the interactions with the content. Changing a tab in the properties window wouldn't change anything, but changing the proportional edit status would.

It might be good to work on a bit of a taxonomy to unravel what is what:

Each user Interaction belongs to exactly one of the following subclasses:
Interactions that change content (add vertex, unwrap, etc.)
Interactions that change tool settings (toggle proportional edit, changing visible layers)
Interactions that change interface (reorder panels, change tabs)
Interactions that change history (these are meta-actions, undo/redo)
Non-diegetic interactions with content (ruler, background image)

> More specifically, if I'm scripting, and I do things, and the script does
> things, I'd like to know what "undo" is going to do.. and I'd like "undo"
> to be able to undo my script-execution.

>  
> > The history of interacting with the history system is something that
> > should probably be kept hidden unless you're doing usage interaction
> > analysis to find usability problems for example. Imagine undoing an undo,
> > and then undoing the undoing of an undo, and so on and so forth, ad
> > infinitum.
> >  
>  
>  
> Personally, I would prefer to have the undo shown directly in the history
> as is done in some applications. I've seen this visualized by causing undo
> to move the "current pointer" back away from the end of the history, making
> the new entries into redo entries. Taking a new action causes the
> "redo/undone" entries to be collapsed/hidden... they are restored if the
> user does an undo back to that point.
>  
> I can't find a really good screenshot of this. I'll try to make a mockup
> soon, but in the meantime, here is the best thing I could find..
>  
> http://mardiweb.com/web/psp7/menus/editing/history_palette.jpg
What I wanted to point out was that there is a history that can never be changed, simply because we cannot time travel. Therefore, there will always be a history of user interaction (the full one) that only grows with every action. I can only imagine that mixing this with the document interaction will be confusing and misleading. If I go through the following interaction:

- Add Circle
- Toggle edit mode  
- Select all
- Rotate 90 around X
- Select top vertices
- Delete
- Undo
- Undo

I will then have a representation of the history stack (if we include operations on history itself in the history) with the pointer at the arrow:

- Undo
- Undo
- Delete
- Select top vertices
- Rotate 90 around X <------------ current state
- Select all
- Toggle edit mode   
- Add Circle

I now execute redo twice:

- Redo
- Redo
- Undo
- Undo
- Delete <------------ current state
- Select top vertices
- Rotate 90 around X
- Select all
- Toggle edit mode  
- Add Circle


Those top entries in the stack have lost their meaning now. How would you interpret going forward in the history stack? Would going forward and executing that undo undo itself? Personally I would very much welcome a representation of full interaction history, but probably not mixed with the normal undo stack.

Oh… I now see I've misunderstood the screenshot… This is a more typical undo stack. That would mean the full interaction history isn't completely visible, because, as you say, it hides certain things when a new action follows an undo. Being able to restore future actions after undoing again, whereby there are two possible futures, is something that would be much work for little gain.  
1. It would require the undo system to be tree based
2. It is cumbersome to represent all future histories to the user
3. In several applications less than 1 in 10 undo actions are actually followed by a redo (i.e. undo is actually a 'delete')

>  
> ...A question I've been struggling with is how to deal with the context of
> > commands (bContext and selection) that determines the result of that
> > command. For example, in Emacs the commands that select text are recorded
> > in the macro as well. That way I can start a macro at the first character
> > of a line of text, select some text in some way on that line, operate on
> > it, move to the next line, and stop recording the macro.
> >  
>  
>  
> Consider carefully what the emacs macro selection is doing. It does *NOT*
> use the current view-scroll-position in macro selection recording/replay.
> It uses only the CURSOR position. This is because emacs selection
> operations are expressed in-terms of the cursor, not the viewport-scroll.
> This is made convenient because the document is a one-dimensional space of
> non-overlapping characters, navigated by the operations "forward, back,
> search-forward, search back".
>  
> The closest thing to Emacs' cursor is the Blender "Active" object, and it
> is generally positioned merely by clicking or using the box/circle select
> tools -- none of which are very useful for macro replay. The selection
> operations suitable for macro recording are those that are "logical", such
> as (object mode) select grouped, select hierarchy, select by type and (edit
> mode) select similar, select more/less, select vertex-path, select linked,
> and sharp flat select.
>  
> Therefore, just like Emacs, a macro-recording would start with the "current
> cursor position" (aka active), and record all actions, and logical
> selection modifications. These could then be replayed, either by (a)
> manually changing active and doing a "replay" (just like in emacs you can
> manually move the cursor and then replay), or (b) by using a looping
> structure over some set of objects to replay those operations for all those
> objects (just like running an emacs lisp function over a set of files)
>  
>  

Yes, I have exactly this view as well. The trick is indeed to allow logical selections and not the viewport-based selections.  

However, wouldn't it be nice if viewport-based selections could be made logical by inference? Imagine tweaking a part of a mesh, shrinking, subdividing, loop cutting, etc. and then being able to apply that sequence to a similar part of the mesh (e.g. legs of a table). I think it's too much work, but it's probably possible to generate selection paths by walking the edges of a mesh and represent selections that way. These could then be reapplied to another mesh, or part of the same mesh. Anyway, happy to stick to logical selections and not supporting viewport-based selections, because there are many corner cases for which this doesn't work and there's a lot of other achievable stuff to do.  
>  
> Like you I think it will be more useful to avoid the "start macro
> recording" model, and simply go to the command history and pick the actions
> you would like to turn into a macro. However, I could see either model
> working.
>  
>  

I guess the main reason that a retrospective macro record feature is better is because it allows you to realise afterwards, or after the second time of doing a sequence of actions, that you're going to be doing this same sequence quite a lot. Retrospective recording prevents you from having to do it once more. Also, I think that there's probably some tweaking involved after recording, so a visual representation would be good for that too. I agree, both could work well.