sunday meeting agenda sepember the 24th 2006!!!

SoC Status

Nick Sculpt Branch

Addison-Wesley is interested in a blender-python book!
The API currently is too flexible in some things, such as allowing access to the global object database.
The current plan is to refactor the existing API into a better form wihout breaking older compatibility; this however may not be possible for all cases.
Rewriting the API (perhaps reusing some old code) may be an option too.
API needs a clearer roadmap, perhaps blender could benefit from one too.
API discussion pages/ideas on the wiki needs cleanup.
ianwill sums up current bpyapi discussion nicely: "current discussion is about a new / cleaner / less verbose / more intuitive / safer way to create objs."
API topic needs some better/clearer design work, like how it could work with the planned Tool API.
kaito: so it would help if the py api provides a clear list of targeted functionality, like import/export, custom tools, stuff like that
kaito: We need consensis on specs for py api refactor + define it for blender c code itself (event/tools api)
Scriptlinks could handle the script's state data better, like have an option for scriptlinks to keep their namespaces between frames.

As always, developer docs could use with some updating and perhaps migration to mediawiki!
We need a maintainer for all developer docs.

In practice, it seems defaulting to group normal for exrude region really isn't that usefull, half the time most users end up cancelling and then doing a different transform.
It's a really annoying behavior for some people.
Perhaps default to grab mode, with perhaps a nkey shortcut or something to go to group normal-constrained mode.
Extrude could be coded to go into normal grab mode, if all selected faces arn't close to co-planar. For example, if you select a face loop that's a full circle then press E, you don't want it going into traditional EKey normal-grab.