We have already a .sh file to build epydocs from Linux, so why not to have it in Windows as well ;) I think that this guide can help people interested in help with the API documentation to test their work.
I'm actually already in touch with at least one volunteer helping with PhysicsConstraints module. VideoTexture may not be a one man job though, for I hope this document can also help.
Theme colours were getting overwritten on startup with defaults (as in 2.4
system). Changed this to allow changing the default theme, and added a
'Reset to defaults' operator in user prefs. Perhaps next step to look into the
py presets system for themes too (nice and easy to share).
If you're using a custom B.blend you may get some strange theme colours on
startup if they weren't saved properly before. 'Reset to default' button in theme
preferences should fix it back to defaults.
if compositing, sequencer, fields, etc should be rendered, or if the
render does that itself. The weak point is that this only applies to
rendering, so if you open the compositor, it will still run on the
rendered result. Enabled by default, set to False to disable.
1) glCopyTexImage2D - www.opengl.org/sdk/docs/man/xhtml/glCopyTexImage2D.xml
2) dome post_draw. Now dome mode can also use scene.post_draw. It only runs for the last scene. It's really useful. I'm working on a nice showcase for this (a dome visualizer for the dome mode running with bgl. In the mean time this is a (lame) example of both working together (the buffer is being copied and draw on top of the window):
http://blenderecia.orgfree.com/blender/tmp/dome_bgl_copytex2d.jpg
scene from context for background render. Ideally this should not be
using the context to get the scene but currently the active scene is
not stored anywhere, as it's a concept we tried to get rid of.. just
did a simple fix for now.
Based on the assumption that requiring object targets to be OB_EMPTY makes any other object compatible as a target. If the assumption is wrong can be reverted. Only the Cast modifier uses this at the moment and to me it looks like Cast only uses object transform so should be fine.
* Update several Property Windows for Physic Modifiers in the Physic Tab.
* Update several Property Windows for ND_DRAW Notifier, used by Camera Data, Object Force, and general Object settings.
of course it wasn't only a matter of adding the properties in the api :)
The code of validValueForIntervalProperty and modeChange are the same BUT in the future they shouldn't be, for I think it's fine to keep them as separated functions.
Bonus fix: Also we are now checking if the new mode is interval and update the range expression.
