Just something i was thinking about today, as I’m deciding upon how a new tool’s UI should function…
With undoable operations, sometimes things happen in different parts of the UI. If an operation was performed in one panel, but the user has changed the display to a different aspect of the document, it can be useful to incorporate a display switch into the action; when pressing undo, the relevant part of the interface is made visible so the user can see what the result was. If this didn’t happen, it could appear as if nothing has changed, which might be confusing.
Now, when making all your own undoable actions, while a chore, it’s easy to add such a trigger to the perform/undo function. When ValueTree handles all the gibbons (was gubbins, but my iPad autocorrected it and I thought I’d leave it), you don’t get that hook.
So, I was thinking, would it be a reasonable approach to simply bung an otherwise-inert display focus operation into the transaction? It’d mean an extra object for the manager for each transaction, but it’d be a tiny one. Does that sound like an ugly solution, or does perhaps the whole idea of shifting the interface with undo fill you with disgust? I’m not entirely certain if it’s even something I’d actually need to do, but i was just pondering.
The only other thing I can think of is maybe using change notifications of the ValueTree’s modifications. Perhaps some kind of ‘aspect of change’ status structure could indicate whatever the last-changed-thing was, which could be checked after an undo. Psh, just thinking directly into this text box at the moment, should probably go and eat some food.