[Bf-taskforce25] Taskforce expanding, roadmap & planning

[Ton Roosendaal]

Hi all,

Good to see all the enthusiasm to get Blender back working!

Apart from the RNA project - which is well defined and can get finished 
- the bulk of the work is in the new editors/ module. Here's an 
overview of the current status.

(While typing the text became very long... will move this to wiki too :)

In the editors directory you find:

- generic screen, area, region, spaces manager stuff
- all editors themselves (space_view3d, space_ipo, and so on)
- object and object-type modules, for editing (object, mesh, curve, ...)
- generic tools used in more places (transform, animation, ...)

Work on editors can be put in the following categories:

1) Copy over the old code

This is a very complex job, especially for the ancient parts of 
Blender. It's a bit like trying to eat spaghetti in a civilized manner. 
:)
The main results of copying should be:

- removal of depricated globals (curarea, G.qual, G.scene, G.vd and so 
on).
- make a more-or-less usable API for the module with exported calls, 
and keep all internally shared calls in xxx_intern.h
- get it all to compile without warnings, if needed by adding stub 
functions that will be later filled in.

This work is really best done by people who are very familiar with the 
old code, you have to know where the ugly hacks were, what parts are 
sane, and what to recode a bit. This migration job has been assigned to 
'owners' who will do the first migration, and then will be ready for 
the next stage where it's easier to assign smaller jobs to people. 
Currently these are assigned:

spaces:

- space_node: Nathan L
- space_file: Andrea
- space_ipo and space_action: Joshua
- space_view3d: Ton
- space_image: Brecht
- space_equencer: Campbell
- space_outliner: Brecht/Ton?
- space_time: Ton (anim playback especially)

general modules:

- screen and space_api: Ton
- animation: Joshua
- interface
- object and mesh: Ton
- transform: Martin
- util: Ton
- python: Campbell

Unported an unassigned:

- space_buttons
- space_info
- space_text
- space_sound
- space_script (undefined how this comes back)
- space_nla (postponed, joshua hopes to review it entirely)

To be created still:

- armature (also pose)
- curve
- surface
- text (the object type)
- mball
- lattice
- constraint
- shapekey
- gpencil
- uvtools (could be in mesh?)
- sculpt
- preview
- paint (2d, or only 3d?)

(I realize the amount of directories/modules explodes a bit, but still 
seems to be better for now).

Volunteers for migrating code of the above are welcome, but please be 
aware that you really should know this code well!

2.1) Create operators

Target is to at least "operatorify" all tools formerly accessed via 
shortcuts. A lot of such tools were already quite atomic, so easy to do 
(like "clear parent"). Some of them were horribly complicated with own 
subloops, and have to split or recoded (view flying, edge slide, 
painting, etc).

I propose that each owner of a module will coordinate himself the help 
or code buddies to tackle this together. At this very moment it's still 
a bit difficult, there are many loose ends still in the code you have 
to be aware of. A 1:1 communication about this (via irc) might be 
preferable still.

As for my own work; I definitely would like to see people helping with 
the object and mesh operators. Especially the latter is a big job. :)

2.2) Make a new Python API

This is much related to the previous work. Once we're satisfied with 
how operators will work in general, a new Python api for it can become 
frozen. This is also quite complex, since a lot of dependencies are 
with unknown quantities, like defining UIs, custom spaces, python 
hotkeys, etc.

2.3) Bring back UI to work

This work can be done almost in parallel with the previous steps, 
although having operators will make things easier, especially for 
menus.

We have a nearly 1:1 compatible UI code wrapper for panels, buttons and 
menus, which will help us bringing back a lot of existing 
functionality. We will also accept to not make operators for 
everything, a lot of UI code just directly operates on a property or on 
data, no reason to make that more complex now.

We also have to check on how far this stage can go, some parts of 
Blender better are left alone (i.e. NLA) so we can move to the last 
step:

3) UI redesign and context

There's already roughly some consensis about what the focus for 
improving the UI would imply, like separating property editing from 
tools, that stuff. The new area manager will also allow better context, 
putting buttons or toolbars or channel/list views where they actually 
belong.

This design stage is in progress, and I don't see a reason to rush it 
now. A good target will be to wrap this up in March. By then we also 
should get a Python design frozen.

4) Get all the new goodies to work well

This can be done in parallel to previous stages, or only in the end, it 
has a lot of dependencies all over! Think of:

- keymap editor, saving custom maps
- defining hotkeys for tools 'on the fly' (via menus or so)
- defining and saving macros
- api for custom spaces
- better area/region management (dragging region dividers around, 
collapsing them, tabs?)
- good multi-window support, proper context for it.

And of course all the work to get the new ui design implemented well. :)

Happy 2009 everyone, it'll be a remarkable year!

-Ton-

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