[Bf-taskforce25] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [18095] branches/blender2.5/blender/source /blender/editors/space_view3d: 2.5

[Matt Ebb]

On Sat, Dec 27, 2008 at 9:54 PM, Michael Fox <mfoxdogg at gmail.com> wrote:
> selection operations ( invert selection, select random) to be handled by a single operator, atm only normal/mouse selection is possible
>
> to be ported
>  - invert selection
>  - select random
>  - select by layer
>  - select by type

If the idea here is to make all these different tools accessed by RNA
properties in the one operator, I don't like that much. I feel
similarly about the recent 'numpad' operator that combines a lot of
different functionality into the one operator.

Are there any design guidelines for operators? In the sense of how
fine-grained they should be?

Personally, I think they should be relatively fine-grained. i.e. a
separate operator for each thing that would exist independently in the
menu system. It should be related to workflow, if it's a different
tool that you would use in a different situation, it should be a
different operator. The operators aren't just being used in C code
keymap definitions, they're potentially going to be used in a lot of
different things - notably the py api, macro recording, and hopefully
things like auto-generating menus, custom popups or radial menus, etc.
I presume in these cases, it would make things much easier to be able
to just iterate over a list of individual tools as operators, rather
than having to worry about all combinations of different property
arguments as well.

The operators are forming an API, internal to blender and via python,
I think there needs to be some sort of discussion or consensus about
how this API should look. Correct me if I've got the wrong idea here,
but I personally wouldn't be happy with something like:
bpy.view3d_select(mode=random, randomness=30) or
bpy.view3d_select(mode=bytype, type=mesh)
as opposed to the simpler and more readable
bpy.view3d_selectbytype(mesh)
bpy.view3d_selectrandom(30)

Regardless, if this is going to form an API which we'll should stick
with for a while, it's important that we make some decisions about how
it should work, and stick to it consistently, otherwise it'll be a
mess from day one.

What do you guys think?

cheers

Matt