[Bf-taskforce25] context/operator changes

[Ton Roosendaal]

Hi Brecht,

The issues you raise below and in the code are very valid, but for me 
mostly reveil that there's issues we might not easily overcome with 
this extension of operators.

Currently recoding the old tools into Operators has proven to be a 
relative painless affair, with a simplicity that helped doing this work 
as well. I'm afraid that it now will become a bit too hard, 
jeopordizing the feasibility of shorter term release targets.
Even when the proposal works out to be the best way forward, we can 
also think over a way to make this a migration path, with future 
expension to more functionality.

First back to the very basics:
It's especially this statement from you as feedback we should keep in 
mind:

"...because then the scripting API closely matches what the user does. 
Blender is
an artists tool, not a development API."

The real design issue is not so much "how can we give python the best 
access to program tools using operators", but "how can we design 
operators in a way that artists can apply operators in all ways we can 
foresee, like using history stacks, macros, redo/repeat."

The Python API should follow that principle, and only where required we 
can amend the design to improve access.

You seem to foresee a lot of python use cases that go entirely outside 
of the (User) Context; which I would propose to be not the spec, but 
the exception! :) We should assume safely that any script we'd like to 
see included in our releases will work within the UI, with a very clear 
contextual awareness similar to every other tool in Blender.

For example: tools like 'add object' or 'delete object' are only 
possible now within a Scene, referencing it via Base struct. For me 
that's perfectly OK.
To a requirement like "I want to code in Python access to 100s of 
helper objects, outside of Scene context" we can simply say "Sorry, 
Blender doesn't allow this yet".
Only when we have tools or concepts to manage objects in other ways 
(like creating groups with objects, outside of scene context) such an 
operator will be also available in Python.

It sounds maybe a bit strict and limiting for Py scripters, but it's 
also fair. If a py scripter prefers to use functionality Blender 
hasn't, he should first make this is in Blender logically available.

Back to the basics 2:

It was my impression that "decoupling context from operators" was not 
meant to be a full separation, but a means to overcome confusing 
definitions of "selection" and "active". For me this decoupling is just 
a wrapper, but it's still entirely within the context limitations as an 
operator defines.

I'm not sure yet about this all though, need to go over this a bit more 
in detail still. But it seems to me that if we first very carefully 
define and validate operators for the User cases (history, redo/repeat, 
macros) we then are probably much better equiped to also solve the 
scripting cases.

-Ton-

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

On 18 Mar, 2009, at 19:17, Brecht Van Lommel wrote:

>
> Hi all,
>
> I'm working on context/operator changes discussed at Wintercamp, mostly
> with the purpose of improving python interaction.
>
> Check this diagram:
> http://wiki.blender.org/index.php/Image:Operator_control_flow2.5.png
> And example code:
> http://pasteall.org/4607/c
>
> The basic idea is sound I think, but I'm running into some consequences
> and questions while implementing this, so I'm looking for feedback. See
> the XXX marked comments in the code, and the notes below.
>
> properties vs. context
> ----------------------
>
> When all context data is passed along as properties, it becomes 
> tedious,
> not only for the operator code but also for python scripts having to
> specify these things over and over. For me it's not clear where to draw
> the line. Some examples:
>
> * Does delete objects get scene as a property?
> * Does grab in mesh editmode get the selection mode (vertex/edge/face)
> as a property?
> * Does set 3d cursor get the 3d view space as a property?
>
> in/out RNA
> ----------
>
> As can be seen in the example code, the operator type and operator now
> have separate in and out properties. I prefer this over one RNA struct
> with properties tagged for input/output.
>
> poll
> ----
>
> The poll() callback now only should run when the operator is used as a
> tool. This means exec/invoke have to do more verification, since python
> may pass in an object that is not in editmode for example, while poll()
> would guarantee this otherwise.
>
> poll/input/output names
> -----------------------
>
> I've called the get_context/set_context callbacks input()/output(). The
> names of these callbacks, and actually poll() is a bit unclear. Longer
> names like user_input/user_output/user_poll or
> context_input/context_output/context_poll may be better, but are a bit
> long?
>
> context RNA
> -----------
>
> Context now works with RNA pointers, to get things accessible by 
> python.
> However some things currently in the context are not RNA wrapped, like
> Base or EditBone. Do we want this dependency of context on RNA, and
> assume things will get RNA wrapped in the future, or do we want some
> sort of support for putting stuff in the context that is not RNA
> wrapped? They could be passed as UnknownType, but that's not so nice.
>
> context global/localization
> ---------------------------
>
> Currently there are CTX_data_* functions in BKE_context, which look a
> lot like globals. In a way they should be global, to permit decoupling
> operators from spaces, but I'm not really comfortable with the way it 
> is
> now. It's not clear at all what is available when.
>
> I'm changing the context lookups to be based on strings, so that they
> become extensible by python. This permits to get rid of these 
> CTX_data_*
> functions, but it means what is in the context is effectively
> undocumented, and you might get a pointer of a type you did not expect.
>
> Not sure what to do here. Is there a good system to localize and
> document this context stuff better? One approach would be to make the
> input() callback do more, but then operators again get strongly coupled
> to the spaces. Or define context RNA and associated CTX_data_* 
> functions
> per module, but it's unclear where that fits.
>
>
> Brecht.
>
>
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>