[Bf-taskforce25] Context/Operator: alternative
Ton Roosendaal
ton at blender.org
Fri Mar 20 10:10:27 CET 2009
Hi Michael,
To me this seems relatively close to the idea Brecht proposed too, just
worded a bit simpler. :)
The issue is not so much that this is not a good idea, but that the
underlying code in Blender gives problems using that concept, as Brecht
pointed out in his code mockup.
For as long all (all!) of Blender code considers selections/active to
be fixed data-level properties, "Context" will define automatically how
the tools work. Decoupling this, to make tool input independent of such
selection state, is more work than just rewrapping things on Operator
level. A potential can of worms we might better keep closed for a
while...
-Ton-
------------------------------------------------------------------------
Ton Roosendaal Blender Foundation ton at blender.org www.blender.org
Blender Institute BV Entrepotdok 57A 1018AD Amsterdam The Netherlands
On 20 Mar, 2009, at 0:37, Michael Fox wrote:
> in all honesty in/out should not be abandoned just made simpler.
> as already been pointed out poll should stay because the eg TEXT_ ops
> can only run in Text editor.
>
> now here is code for what i am proposing http://pasteall.org/4630/c
>
> firstly operators have in and out sockets which are arrays with a
> length
> that is defined by the _count property and can be any kind of data, rna
> or dna dosn't matter.
>
> in and out sockets are defined in an init function which python can use
> to build data types and rules for calling such data, we may need to
> make
> specific functions to initialise these properly etc etc
>
> in the operator itself some new macros, functions will be needed to
> access the data from the in and out sockets.
>
> now with the system like this the py call would be
>
> objects[]=OBJECT_OT_clear_scale(selobjects[]);
>
> or any object array you would like to use.
>
> so with somthing like this in's and out's can be made and used properly
> without being overly complex or inefficient and the work already been
> done can easily be ported over to this, no worries.
>
> I hope this is ok with every one as i want 2.5 to be used on both ends,
> by users and pythoners and for durian
>
> On Thu, 2009-03-19 at 15:46 -0700, 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>
>> 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
>> www.blender.org
>> Blender Institute BV Entrepotdok 57A 1018AD Amsterdam The
>> Netherlands
>>
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> 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
> --
> Michael Fox
> Developer and user of Blender3d
> www.blender.org
>
> mfoxdogg at gmail.com
>
> _______________________________________________
> 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