[Bf-committers] Blender 2.5 api proposal.

[Ton Roosendaal]

Hi,

To clarify my statement:

> At this moment it's well
> possible we don't tackle all of that via Operators, still allowing
> direct callbacks to buttons (just for the sake of simpler migration).

This as a migration path only, bringing first back a working Blender  
for such options. It might be more efficient for UI redesign work, to  
step by step migrate parts to a new system. This is an unknown quantity  
though, needs some testing.

It will also depend on how quick we have a clear picture of ui redesign  
work, and how to integrate this well with Python... as soon as we have  
that picture, it's easier to decide on how to migrate efficiently.

-Ton-

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

On 1 Dec, 2008, at 20:27, Ton Roosendaal wrote:

> Hi Campbell,
>
> I'm no py user, so a lot I can't review. Keeping things compatible, or
> easy to migrate, would of course help everyone getting their (very
> important) im/exporters work. But thats what everyone agrees on I
> think.
>
> As for the main goals of the rewrite:
>
> "Features available in blender should also be available in python"
>
> I'd rather reverse that:
>
> "Features exposed in Python's API should also be available in Blender".
>
> This is worded by Chris Want as well ("focus on writing a decent C
> library/API").
> I do realize this is not really a 2.5 spec, but for at least in two
> areas we'll be doing that: for wrapping RNA and Operators. Hopefully we
> can also solve this very good for the definitions of UIs
> (button/panel/toolbar stuff).
>
> What remains is a lot of calls like "Add constraint" or "Delete
> modifier", which is currently a very undefined piece of Blender code,
> closely tied to the buttons for such options. At this moment it's well
> possible we don't tackle all of that via Operators, still allowing
> direct callbacks to buttons (just for the sake of simpler migration).
>
> I don't know how important such operators are in Python now, but it
> would be *very* nice if people who add such functions in Python only do
> this via proper C calls in Blender, even when it means to first cleanup
> (API-fy with Operators) Blender.
> One idea to resolve this is to make a shortlist of the most important
> py 'operators' that should get wrapped at least for the first version
> of 2.50?
>
>
> -Ton-
>
> ----------------------------------------------------------------------- 
> -
> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
> Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The Netherlands
>
> On 1 Dec, 2008, at 7:05, Campbell Barton wrote:
>
>> Here's is my proposal for the Blender 2.5 api.
>> http://wiki.blender.org/index.php/BlenderDev/Blender2.5/
>> PythonAPI_Ideasman
>>
>> I'm interested to know what people think of possibly moving to a new
>> api (especially active Blender/Python scripters).
>>
>> This page was started more to get an idea of what people wanted, its
>> still useful for discussion.
>> http://wiki.blender.org/index.php/BlenderDev/Blender2.5/PythonAPI
>>
>> Last meeting we discussed weather to use python 3.0, and it seems a
>> hot topic :)
>> PyRNA runs with Python 2.3 - 3.0rc3, in anticipation for a possible
>> switch, can we keep these issues separate since its has almost no
>> baring on a new API.
>>
>> Even though this is a blender-2.5 topic, most of the people this
>> affects are not on that list.
>>
>> -- 
>> - Campbell
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>