[Bf-committers] undopushes and using tools inside of tools

Joe Eagar joeedh at gmail.com
Fri Apr 14 02:43:41 CEST 2006


Matt Ebb wrote:
> Undo is a UI level feature, as in, when a user presses undo, it undoes 
> the last thing the user did - the most recent discrete command which 
> the user actually chose. The internals of how that singular UI level 
> command is built up from other functions is unimportant, I think we 
> can all agree on this.
>
> Therefore, it makes the most sense to me to keep undo pushes 
> completely out of all functions that perform editing functionality and 
> have them occur within the function that handles the user's input on 
> the a UI level, since that's when you can be sure it's been 
> specifically chosen by the user. Right now, that can be in multiple 
> places due to the current state of duplicated code for 
> hotkeys/menus/toolbox. Hopefully the unified tools API will solve 
> this. For what it's worth, for now I'd say it's best to make a wrapper 
> function that does the undo push, or put it in the (perhaps 
> duplicated) UI level code that triggers the command. I really don't 
> think that undo pushes have any business being in the internals of 
> editing functions.
>
> Matt
This sound like it violates the editmesh design anyway.  A lot of 
editmesh tools are separated into UI and functional parts (the 
subdivision and extrude functions all do this, or did at one time at 
least).  Cleaning this up sounds like it'd be a necessary thing for the 
Event Refactor.  It may even fall under it, in which case it might be 
better to wait for the Refactor (since it's coming so soon anyway--after 
next release is it?).

joeedh


More information about the Bf-committers mailing list