[Bf-taskforce25] context/operator changes

[Shaul Kedem]

On Wed, Mar 18, 2009 at 4:48 PM, Brecht Van Lommel <brecht at blender.org> wrote:
>
> 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.

by dependence you mean that the operator does stuff according to the
information handed by the scene? if so, the "set scene" function
should come before the operators which uses it start off.

>
>> * 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.

maybe python scripts should be limited to vertice selection only? just
a thought.

anyway, an operator which does stuff according to some hidden
selection somewhere is never good :) maybe it should be changed to 3
separate operators ?

>
>> * 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.

I think that such "mode-less" scripts should be able to do as much as possible.

>
> 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.

I get this, but it's really hard to put some guidelines in place
before actual programmers start toying around with the sdk and see.

>
>> in/out RNA: can we have ot->inout ?
>
> Can you give examples of what this would be used for?

examples : blurring operator - I want to send a 2d texture and get it
back blurred. anything you want to use the same memory for, actually.
an accumulator, a send and receive message in networking, a memory
allocated in on place and used in an operator (I am not saying its a
good idea, but the need arises from time to time)

>
>>  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.

not always, if you agree to any of the above,

>
> 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.

ok, I see the distinction.

>