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

[Vincent Akkermans]

Hi all,

I'm the student doing the SOC project you mentioned, David. I might spent more time on a toolbar design than on the history stack, but I do think, like you, that there's room for improvement. My comments are interspersed below.  

On Friday, 5 July 2013 at 20:25, David Jeske wrote:

> This is a followup to some good points Harley brought up about
> Command-History here...
> 
> http://lists.blender.org/pipermail/bf-funboard/2013-July/005274.html
> 
> I agree there is opportunity to improve Command-History. IMO, "where" it
> lives is less important than "how it works" and how it's "easy to get to
> and put away".
> 
> For example, I could imagine a workable design in the info bar if there was
> a "push button" way to collapse or expand that area. Dragging it down is
> very non-intuitive, and closing it runs into weird confusion over dragging
> the header and the split-divider. Plus, if expanding it "runs into" another
> subpanel division, the expand gets stuck.
> 
> For now, I think it's better if we talk more about the functionality and
> less about exactly where it lives. I also think we should consider this in
> a larger scope including "current operator modal status-text", "tools ->
> operator subpanel", operator stack, undo/redo, and the interactive python
> console. This GSOC project is related..
> 
> http://lists.blender.org/pipermail/soc-2013-dev/2013-July/000073.html
> 
> Here is a totally random brainstorm of thoughts:
> 
> - How do the command-history, undo stack, and operator stack relate? How
> can we make them more coherent? Can we combine any/all of them?
> 
> 


As far as I can see the operator stack serves mostly to be able to adjust the parameters of the last operation. I assume this is a consequence of not allowing to set a tool's parameters before using it, and I personally like this style. The implementation of this functionality relies on the undo system (undo the last operation, redo it with different parameters), but this isn't necessarily the only way to implement it. So, they are related and especially with my latest patch which generates the operator stack from the current mode's undo stack. I would like to further look at make this integration more complete. 

I'm not sure what the envisioned use of the command history is at the moment, but what it does do is give an indication of what the state of the history stack *could* be. If you look at the list of python sentences you might be able to infer what the sequence of states are that you could undo your way back through. It probably isn't the clearest representation of the undo stack though. :) 

It is clear that the command-history, undo stack, and operator stack all offer a view on the same thing: the history of the interaction between the user and Blender. The undo stack keeps track of all the states, the operator stack should be what links those states together, and the command-history is a python representation of those links.

> 
> - What "should" the command history show? Right now it shows many
> python/DNA aware actions, but has notable omissions ... like undo/redo. It
> would also be nice if it was clearer which actions in the command-history
> were undoable and which were not.
> 
> 


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. 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.

> 
> - (on the mac) I can't copy command-history entries to the clipboard, which
> is probably the most useful thing I could do with it!
> 
> - Command History is a great stepping-stone for macros. When in the 3dview,
> I would like to quickly open/expand one panel, and have access to
> command-history, a python-scripting window, and some easy "scripting helper
> tools". Perhaps a UI block which runs all commands over all selected
> objects, or even just a Template that inserts "import bpy, for obj in
> bpy.context.selected_objects:"...Then the I could paste lines from
> command-history into the loop, tweak a few things, and boom. macro script.
> Hit the run-button. oops, it's wrong. Hit Undo. Change it, try again.
> 
> 


I agree, that would be a very nice feature! 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. I can then execute the macro n times so it works for the next n lines. What would be the equivalent in Blender? How can you make a selection action relative to the cursor or to the previous selection? I have some ideas about this, but it seems to become intractable for large meshes. I wonder how useful macros are if selection operations can't be made relative, or phrased as a question: what is a use case of a long sequence of actions that is applied to the same selection? 

If you're thinking of integrating the undo stack, operator stack, and command history into one, you could have a nice single visualisation of the history stack. You could click one element of it to return to that state, or select a range to create a macro, or perhaps copy the range as a python string to the clipboard. 

Vincent