[Bf-taskforce25] context/operator changes

[Brecht Van Lommel]

Hi,

On Wed, 2009-03-18 at 15:50 -0400, Shaul Kedem wrote:
> * Does delete objects get scene as a property? can we have default
> value for this when called by python and the possibility to override
> it ?

In theory we can, in practice there is a fair amount of dependence on
the current scene. But on the other hand it is useful for python scripts
to operator on scenes outside the current one, to do some operations on
all scenes for example.

> * Does grab in mesh editmode get the selection mode (vertex/edge/face)
> as a property? no, this is more of an interactive operator and the
> selection mode should be declared before hand (+selection mode will
> affect future operators accordingly, so it sounds wiser to set it only
> once)

This was perhaps not a good example because changing selection mode can
lose information. But, when writing an python tool you would have to
be very careful about what the current selection mode is, because it
will alter the way the operators work.

> * Does set 3d cursor get the 3d view space as a property? don't think
> so. set 3d cursor should (IMO?) be an operator by itself..

It is an operator by itself. The question is, if python wants to do
something in a 3d view, do you require that 3d view to come from the
context, and hence restrict operations on it to operators running in the
3d view. Or do you also allow a script to run an operator acting on
another 3d view. I think it's not a bad restriction, but you may want to
make a operator that does something like "sync up the view in multiple
spaces", and then you would not be able to.

My main reason for these questions was, I tried to make some operators
work with this system, and did not easily see the best separation
between context and properties. So general guidelines for this will be
needed, trying to figure out what these should be.

> in/out RNA: can we have ot->inout ?

Can you give examples of what this would be used for?

>  poll: sounds like it should be called "pre-condition" and I think it
> should be included for python, don't see the reason its not included
> now.

Because poll should be fast, and run without an operator that is already
created. That means it has to check context. For a python script the
data comes not from the context but from the input properties.

Note that when I'm talking about python here I mean calling operators
(almost) context-less. For macro's you want to call things with
context, but for writing tools predictably you want little influence
from the current context on the operators you call.

Thanks for the feedback,
Brecht.