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

[Campbell Barton]

On Sat, Dec 27, 2008 at 5:05 AM, Matt Ebb <matt at mke3.net> wrote:
> 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

>From Matts example, thought Id mention an issue with calling operators
from python.

At the moment all arguments MUST be keyword args when called from python.
at the moment operators called in python look like this...
bpy.view3d_selectrandom(percent=30)
bpy.view3d_selectbytype(type='MESH')

Its easy enough to change the api so the args are assumed to be in the
property order set in the operator and missing values just use
defaults.
only down side to that is when args are added to operators later it
could mess up existing scripts, if argument order changes scripts
could function but incorrectly without giving any errors.

My reasoning for not doing this is - imagine a user makes some buttons
from copying and pasting the operator output with minor edits... some
time later they upgrade blender and suddenly their macro's don't work
and theres no obvious reason - debugging such situations is tricky
especially for people who aren't that technical.
In that case its a lot better they get a message "Operator X is
missing arg Y", so they can make the change and continue.

Not sure how often operators will change, this might be over
paranoid... can deciede later.