[Bf-taskforce25] Operator standardization

Shaul Kedem shaul.kedem at gmail.com
Sun Feb 1 19:15:49 CET 2009


Hi,
 Regarding : "in order to make a nice UI after operator executed, the used
properties should be useful in UI too. When an operator uses internal
props it should be set as such."

 I think that an op can flag itself after the first prop is defined in
its context, that way we'll have an automatic way of finding ops.

 As for other things, a bit worried about modal and non modal -but-
multi step operators use the same operator API,

shul

On Sun, Feb 1, 2009 at 9:58 AM, Blender Institute <institute at blender.org> wrote:
> Hi,
>
> We've got now over 250 operators defined, time for some thoughts about
> what good standards are for naming, flags, and property definitions.
>
> Campbell did interesting test with epydoc output, see here:
>
> Operators
> http://www.graphicall.org/ftp/ideasman42/html/bpyoperator-module.html
> RNA
> http://www.graphicall.org/ftp/ideasman42/html/class-tree.html
>
> Some issues we noted;
>
> - operator names should try to keep in mind the part after _OT_ should
> fit as a useful api name. (not MESH_OT_mesh_delete, but MESH_OT_delete)
>
> - selection operators should use default boolean for 'extend' and for
> 'deselect' ?
>
> - toggle operators (editmode, vpaint) should get standard enum "set,
> clear, toggle", so the op->invoke() can check for this enum, and
> optionally then handle toggle.
>
> - add a tooltip/doc string to operators, describing the intended
> operation well?
>
> - classify operators well that heavily rely on mouse input, or cannot
> be redone or cannot be used for the py api.
>
> - standard border-select or circle-select ops should not return 'event
> type' property, but some other standard like the default booleans
> 'extend' and 'deselect'. Those then can later always become configured
> with modal keymaps.
>
> - in order to make a nice UI after operator executed, the used
> properties should be useful in UI too. When an operator uses internal
> props it should be set as such.
>
> - Transform is currently the most gigantic one... how can we extract
> from a transform operator the useful (used?) ones, and how to
> communicate the api well?
>
> So! I guess people can name more issues, let's get them listed and work
> to a proposal of some kind?
>
> -Ton-
>
> ------------------------------------------------------------------------
> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
> Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The Netherlands
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>


More information about the Bf-taskforce25 mailing list