Dev:2.5/Source/Development/Status

Status June 7, 2010

Still heading towards beta within the next month. Plenty of bugs have been fixed and specs are getting locked down, to be ready for documentation

Status March 29, 2010

We're nearing the beta release, preceding a 'finished' stable release.
The plan for now is to freeze svn trunk for major new features, and concentrate on stabilising/fixing/finishing up what we have now. We haven't achieved everything that we'd like to for '2.5', but Blender is constantly in development all the time, and there is plenty of room for further planned UI improvements and additions in the coming versions.
The priority right now is to get a stable version released to then build upon, and get out of the 'alpha' mindset!

Status November 22, 2009

We're getting ready for the first test build, nicked 2.5 alpha zero.
Roadmap for 2.5x releases you can find here:

 http://www.blender.org/development/release-logs/blender-250/

Status September 12, 2009

Testing and bugreporting now can start! See the todo list link.
Roadmap for 2.5x releases in development still.

Status April 20, 2009

- Widget/button drawing code fully revised now, pixel exact and crispy anti-aliased
- Layout engine work in progress
- First version of Python based UI scripts being tested
- New definition of "Style", to define multiple font types and layout or button appearance suggestions.
- New font system, dropping FTFont module, directly using freetype code
- Work on further refining Python API started, adding lower level calls outside of (UI) operators for import/export.
- Grease Pencil being brought back
- Tests done with using buttons to add Function Curve keys, drivers, and visualize them
- Whole lot of work on animation system UI!
- Over 500 Operators (tools) added now

Status March 10, 2009

The Wintercamp workshop reports wintBlender2.5/WinterCamp/Agenda.

Status Feb 8, 2009

Progress is going very well! Almost 300 tools have been converted into the new "Operator" system now.
Here's a shortlist of work that has been done in the past month.

RNA API

This API provides generic access to properties, whether it's via the UI, via Operators (tools), via Python or the Animation System.
Wrapped in past month were many modules, including modifiers and armatures.

Animation System

- Ipo Window now is generic Function Curve window, allowing to edit and view entire scenes even.
- Action Editor now provides much more flexible use as Dopesheet Editor.
- The "Ipo block" has gone, and is now a generic Action (= collection of Function Curves). Each Action channel provides an "RNA path" to the animated data. This will allow animation of any property, including Composite Nodes, Constraints or Modifiers.
- Actions, NLA and Drivers are collected in "AnimData", which is available for every linkable data type in Blender's library system. You can find AnimData on Scenes, Objects, Curves, Cameras, Shape Keys, Lamps, Materials, Textures, NodeTrees, Worlds.
- NLA system will allow 'tracks' (i.e. layers), and multiple strips per track.
- Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
- F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this).

Coding stuff:
- Removed loads of globals from Blender, including the dreaded 'Global Scene' and 'Gobal Edit Object'.
- All code now has been ported, apart from button definitions, menus and the old python api.

ObjectEditing

- Most of the tools for Object/Group editing have been restored.

Mesh Editing

- About half of the tools for Edit Mesh have been restored.
- Mesh editing is now fully local, code allows multiple "editmodes" to co-exist.

Sculpting
- Work started on migrating all sculpt tools
- Removed old multi-res code, added the improved version of the Google Summer project
- Made generic "Radial control" (to edit brush size)

Vertex Paint / Weight Paint
- Localized editing data for paint modes.
- restored functionality

Editors
- Node editor allows selection, dragging, scaling, rotate, and linking
- Image editor migration started
- File Selector halfway back
- Sequence editor halfway back
- View3D can be further split, each with own viewing context
- Four-split view3d options with automatic box view and box clip

UI toolkit
- Improved menu system, allowing near-automatic generation of pulldowns or toolboxes
- Buttons now can directly use RNA, switching types and appearance automatically

Render / Composite

- New threaded "Jobs" system in Window Manager now handles preview rendes for Materials, but also compositing and rendering. While previews, composites or renders happen the UI now is fully responsive.

Transform
- Most of the common transform tools are back (constraints, num input)
- Added support for transforms in other editors (Node, FCurve, Action)
- Restored support for editmodes transform (curve, armature) and Posing

WindowManager

- Tests being done with several swapbuffer methods, including a triple-buffer system that probably will become default.
- wmJobs manager handles threaded jobs

Support added for:
- generic lasso select
- line tools (like for cutting)
- circle select
- custom paint cursors
- generic 'tweak' event (hold mouse button + drag)
- Repeat or Redo last operator
- Editors can assign custom drawing calls to area types

Status Dec 31, 2008

We are now accepting more help for 2.5 migration, here's an overview of status and potential todos.

In the 2.5 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_sequencer: 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!

Current status (dec 24 2008)

RNA conversion is over 80% now. Being in use all over Blender now with success.
New window-manager and area-manager nearly finished and stable
UI code nicely wrapped for conversion of old code. Panels in progress still.
New view2d api in use for every area-region, better scollbar handling
Basics for all spacetype (editors) back
Editor porting started for Outliner, View3D, Ipo, Action, Node, File, Imageselect, ...

Current status (nov 18 2008)

Work on window manager has restarted by Ton. Will do reviews and clean code, and make docs
Brecht finishes the generic data access API, nicked RNA.

Current status (jun 6 2008)

There are plans to restart development. However, after discussion, it appears that still some parts of the core windowmanager code must be worked on before more people can get involved in coding.

Current status (jan 7 2008)

Blender now draws (empty) areas/regions and area dividers again
Design final for Area API (pluggable later)
Window duplicating/scaling works with the screen layouts
Headers for files in svn now show correct gpl license note, with no commercial option.

Current status (jan 3 2008)

Removed entire blender/src, python and include directories
Window Manager toplevel added in source/blender/
New code for Event manager, Event Handlers, Operators, Keymap...
Subwindow management
Framework for new blender/editors module added

Help needed for:

RNA conversions (last bits, come on!) http://wiki.blender.org/index.php/BlenderDev/Blender2.5/RNATasks

Converting old Object tools and View3D options to generic Operators can start now.

Win32 Ghost: (Nathan Letwory) windowmove, full-size-borderless windows, ...

X11 Hhost: (Diego Hernan Borghetti) windowmove, full-size window, borderless, ...

OSX we need to clean ghost for depricated quickdraw APIs (OSX 10.5)

OpenGL profile module, to collect (and user-configure) all opengl hacks for 3d card variations