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

[Ton Roosendaal]

Hi,

Right, Michael is now overshooting too much. The select-activate 
operator for mouseclicks should definitely not be combined with other 
selections.

The 'invert select' and 'select random' and 'select by type' and 
'select by layer' are individual operators yes. However, the last ones 
will still get a property, in that case grouping functionality is 
useful.

The operator for numpad; this could be split a bit, but a single 
operator that can do top/down/right/bottom/left/right view is not bad. 
Will still access very easily.

We're still learning how to make the nicest operators, it also depends 
on how the Python api and UI usage will go.
A design should be as fine-grained as possible (and practical), also to 
enable macros. That I know. :)

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The Netherlands

On 27 Dec, 2008, at 14:05, Matt Ebb 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
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>