[Bf-funboard] command-history, undo, scripting, and other goodies..
davidj at gmail.com
Sun Jul 7 22:31:46 CEST 2013
> 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
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
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..
...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)
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
More information about the Bf-funboard