[Bf-taskforce25] Context/Operator: alternative
joe
joeedh at gmail.com
Fri Mar 20 15:29:29 CET 2009
If we can come up with a clear design for a context-less api, perhaps
it could be prototyped to implement the absolute minimum api the py
api needs. That way we could evaluate how well it'd work. Perhaps
simply have some functions to manipulate Main (instead of the Main
database operators).
The idea being we'd add to this new API gradually, as needed for
python. We'd have to make sure this api doesn't violate the "don't do
something blender can't" rule, of course. By working in small steps,
we eliminate the immediate need to refactor all the operators at once,
or to add hackish operators, like the Main operators idea.
Joe
On Fri, Mar 20, 2009 at 4:09 AM, Ton Roosendaal <ton at blender.org> wrote:
> Hi Brecht,
>
> Good points here.
>
> I think that it could work very well to review and improve current
> operator state to first ensure Blender itself will work stable and
> highly flexible, like supporting macros, history, repeat. There's still
> unresolved issues to tackle.
>
> If we can eachieve this in a good way, the Python counterpart will be
> just as powerful too. :)
>
> -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 10:40, Brecht Van Lommel wrote:
>
>>
>> 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
>>
>> _______________________________________________
>> 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
>
More information about the Bf-taskforce25
mailing list