[Bf-taskforce25] Context/Operator: alternative
Brecht Van Lommel
brecht at blender.org
Fri Mar 20 10:40:43 CET 2009
Hi,
I have to agree with Campbell here. My point of view is this: In the
beginning, there was this vague idea that RNA + operators would make
an almost complete python API, to be extended with just a few things.
Before Wintercamp I got quite worried however that with the current
design we would end with a python API than is considerably less
efficient to use. So I proposed a design for extending operators more
with in/out properties that would permit scripting in a way more
similar to what it does in 2.4, i.e. context-less.
Now however I'm thinking I was influenced to much by looming deadlines
and made a mistake, trying to find the most feasible solution to
implement in a short time. We have three use cases here: tools,
programming API, and perhaps nodes in the future. All three of them
have quite different requirements. I'm leaning towards the idea that a
single operator may not be best suited to solve all three of them, as
vekoon has been pointing out.
I think it is reasonable to say that we should make operators tools,
and not more, as has been the 2.5 target. However that still leaves
the python API problem, and I'm still worried about that, we can't
just ignore that problem for now due to the consequences Campbell
points out. I think it is critical to at least define now how such a
python API should ideally work.
How well a context sensitive API can work is hard to guess, but we can
try to get an idea about it. It would be useful to take some bits of
code from 2.4 scripts and rewrite them as if you were using context
sensitive operators. I'll give that a try..
Brecht.
Campbell Barton wrote:
> read though the operator discussion, now this mail. (phew), some points...
>
> What Ton's suggesting is what we were planning to begin with? (no in/out
> for operators).
> Even though there are limitations like having to select data before
> operating on it (As Venkoon pointed out with Win32 RichText).
> Dealing with things like multiple scenes is not impossible, just set
> each scene active to operate on it. Same as the text editor, you could
> set the text editor active and then add text.
>
> Python still needs a way to reference data to modify the selection.
> (Which brings us back to the selection groups discussion)
> Even though we wont have selection groups, we need a way to do things
> like select a set of objects, sequencer strips etc.
>
> So in the future a more advanced API (with operator inputs and outputs)
> is possible, I find it hard to guess how annoying the basic PyAPI will
> be to use since 2.4x had the opposite problem,
> (with almost no macros or tools accessing context - like extrude).
> I worry that the new PyAPI with inputs/outputs...
> 1) ..doesn't happen and the existing one proves to be overly limiting.
> 2) ..doesn't happen and Theeth ports the 2.4x API to Blender 2.5.
> 3) ..doesn't happen and we hack in stuff to get the job done (in a non
> future proof way).
> 4) ..is written after a while but rather then giving Py scripters a nice
> API in 2.5 we tell them to wait for Blender2.6... and we get the worst
> of both worlds, 2.4x-scripts break, Writing 2.5 scripts is problematic.
> </doom&gloom>
>
> Maybe the new PyAPI without i/o isn't so limiting, ends up being really
> useful, not too hackish utility functions can work around context issues.
> Its just the "We'll make it good later" approch worries me.
>
> People have been wanting Blender 2.4x problems to be fixed for a long
> time (~ 6 years?).
> This isnt clear-cut but it would be disapointing to see Durian force bad
> design decissions.
> Maybe better to do Durian on blender 2.49?
> This way the render pipeline & compositing can be improved which isnt
> tied to 2.5.
>
> --
> - Campbell
>
> On Thu, Mar 19, 2009 at 11:51 AM, Ton Roosendaal <ton at blender.org
> <mailto:ton at blender.org>> wrote:
>
> Hi all,
>
> I've spent some time today with Brecht evaluating the discussion, and
> the more I looked into it the more it was clear we're overshooting at
> the moment.
>
> Regardless whether the proposals are good or bad - the design proposal
> from Brecht really is high quality - it reveils a serious weakness in
> Blender we then should tackle as well. And that's (if I understand him
> well :) exactly Vekoon's point, the lack of good API definitions and
> quite some messyness on the Blender side (code is still assuming it
> runs in UI).
>
> Knowing the code of Blender quite well, and regarding the amount of
> work already done, I think that such specs better not become pursued
> now. It will add a gigantic extra effort to the 2.5 project of which I
> can't even predict if that's feasible.
>
> I've asked myself and Brecht this basic question:
>
> "Ignoring the script specs, what should we do to get Context/Operators
> work for everything we want with tools, with macros, redo/repeat and
> history stacks?"
>
> With as simple answer: "Not much". :)
>
> Secondly: "what was the real issue we wanted to tackle especially?"
>
> -> Solve the context-defined definitions for "Selection" or "Active".
>
> This for example to allow operators to pass on new 'selections' like
> for Node systems, and obviously for scripters to define custom input
> and retrieve output.
>
> I think it's better to move this feature to the future, especially when
> we have operators really functional and users validating it. For the
> Python API we have to look at a way to make this future proof, and not
> halfway change APIs, but that's well possible if we just stick (for
> now) to this:
>
> -> Python scripts that use Operators will only work within Context
>
> Which already offers a great advantage over what we had, and which
> sticks closely to the starting point that "python should not do what
> user's cannot do".
>
> For example, in the operator case Brecht mentioned:
> TEXT_OT_new(wmOperatorType *ot)
> The prefix will just define "this operator runs inside text editor
> context". Period!
>
> For those obvious cases where Python needs to access data outside
> context, like for importing, or Mesh generating or animation system
> manipulations, we can add two easy to build apis:
>
> - A new MAIN_OT_xxx() operator set
> This one can do context-free Main database ops, like adding Images,
> or unlinking (= set users zero!)
> - where appropriate, a basic set of RNA data ops.
> This for example for context-free FCurve point insertion.
>
> Moving forward this way will still give a very powerful API to control
> and use Blender via scripting - provided you target at full
> integration. I'm even quite sure you will be able to code good
> importers this way, just using the context-sensitive OBJECT_OT_add
> calls, move it to editmode, and use what we already have (or fix what
> we have).
>
> Lastly; if you look at what we've already achieved, we've improved a
> lot in Blender. If you look at the minimum we still have to do to make
> it work, it's still quite scary. So... let's now work on first bringing
> back Blender to work, and then worry again about new advanced features
> for node systems, scripting, etc.
>
> -Ton-
>
> ------------------------------------------------------------------------
> Ton Roosendaal Blender Foundation ton at blender.org
> <mailto:ton at blender.org> www.blender.org <http://www.blender.org>
> Blender Institute BV Entrepotdok 57A 1018AD Amsterdam The Netherlands
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org <mailto:Bf-taskforce25 at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
More information about the Bf-taskforce25
mailing list