[Bf-taskforce25] context/operator changes

[Shaul Kedem]

Hi,

 My thoughts:

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

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

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

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

 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.

 i/o: I think input()/output() is fine, after all the context is clear
since it is inside a function

my .2 cents



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