+1. This would be really good. Perhaps some of the issues are just that the operators currently in 2.5 are incomplete; I don't know. I do know that changing parameters for many of them causes them to behave in unintuitive ways.
I think the Fracture operator shows best one of the limitations of the current operator system-- sometimes it's better to have an operator start up and only show the parameters before the user applies it. The hack that Fracture uses to achieve this is (using that little check mark box) is neat, but I personally believe there needs to be a bit of thought put into how operators work in general: - There should be a way to fire off an operator without applying it, so that settings can be changed and that those settings stick between uses. - There should be a better system for how operator parameters are changed and applied live on objects, because whatever's going on under the hood right now (IIRC changing operator parameters calls an Undo, then reapplies the operator?) is not very stable. (Undo in 2.5, in general, crashes a lot for me.) I'm thinking the operator class should be extended so that the operators restore what they've changed instead of the undo system, while they're live, and then that data gets removed when the operator's class goes out of scope when the tool changes. I'm not sure how to approach either. In Maya you get those little boxes next to tools that have parameters you can change which bring up the properties box for the tool; there really isn't a place for those to exist in Maya. Although, perhaps defaults could be set by executing an operator in a different fashion from the space bar search. For example, perhaps hitting shift+enter after searching for an operator instead of enter just pops up the tool properties but does not activate the tool. Modo's system for this really works -- you enable the tool, and at any time you can change any parameter and see it updated in real time, but for this to work they have a system in which the operator never stops executing until the user "drops" the tool. I don't mean to say Blender should copy either, but it'd be nice to hear what other people think of how the workflow could be made better. ~ C On 2010-04-30, at 2:27 PM, Wahooney wrote: > Has any thought been given to the saving of default values for > operators? For instance, in my case: I'd like to set up default values > for exporting to FBX. > > I know that the defaults can be changed in the .py, which is easy enough > if you know how, but may be out of the scope of your standard user. > > I'm thinking that the defaults could be saved into .b.blend on a per > operator basis, instead of all operators having all settings saved into > .b.blend from the get go, which could be a difficult to impossible task. > > Regards, > Keith > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
