TODO list for Blender Python
============================


Requests and TODO list:
- read / write access to image buffers (can use / follow BGL's buffers);
- access to game engine properties (see logic.[ch]):
		It seems trivial to add the game engine modules to bpython, investigate
after 2.34;
- Blender.EMesh module: direct access to editmesh objects;
- update Material, Texture, Lamp, etc with recent Blender additions (done?);


The next section describes bpython projects.  Here's a suggested format:
============================
= Project: name of project =
============================
>Coordinator(s): DEVELOPER(S)
>Started on: DATE
>Priority: LOW/MEDIUM/HIGH/FIX IT!

>Current state: ...

>Description: ...

== End of name of project project ==



===============================
= Project: structural changes =
===============================
>Coordinator(s): Stephen, Willian
>Start: after release 2.34
>Priority: MEDIUM

>Description:

It's about time for some cleaning-up, we plan to do this since before 2.28.
First of all we should discuss what we'll do via mailing list, then divide the
task in small steps, some of which need to be finished fast once they've been
started, so our "men at work" signs don't bother other developers too much.

BPython is a perfect project to showcase Python embedding, besides being a
gentle host to new Blender developers, so keeping it readable and instructional
is a desirable goal.

Changes in files:
- DON'T BREAK BPYTHON API;
+ move things that should not be in header files to .c files;
++   Moved static declarations and data definitions out of headers.


+ consider moving declarations from bpy_types.h and modules.h to the module
    headers;
++	Some modules lack a .h file.  Otherwise, done.

+ add Id cvs tags to all files; DONE
- define a comments format (doxygen-friendly);
- define order: start with module declarations, then table and so on;
+ respect 80-column limit for readability and use tabs, not spaces; DONE
++     all source files have gone thru the indent formatter 

- use EXPP_incr_ret where applicable;
- consider macros and/or Joe's get/setVarType functions, maybe put in
	gen_utils.[ch] for some modules to use;
- remove unecessary redraws;
- check for refcount bugs, like PyList_Append, etc.
- Use new Boolean return values for True and False instead of integers.

Dir structure:
- move internal bpytypes (bone, euler, vector, etc) to a separate subdir:
	internal/ or something;
- rename EXPP_interface.[ch] to bpy_interface.[ch] and move internal stuff
	from python/BPY_interface.c to it;

- consider splitting BPY_interface.c, it's too big and should really only have
  what its name implies (BPY_ functions seen outside python/ dir);
- keep only the few "public" declarations (needed also outside python/) in
  BPY_extern.h, to avoid unnecessary recompilation every time it is changed.
  These should (and are) called BPY_***().

Interoperability:
- Modules and methods should play nicely together.  The return value from a getSomething() method should work as the input argument to a setSomething() method.  In otherwords,  ob.setSomething( ob.setSomething() )  should work.
- Methods taking or returning coordinate arguments should work with the bpy math types.  Using the tuple and list constructors can help us cheat here as opposed to making everything accept and return Vectors.

== End of structural changes project ==



==========================
= Project: documentation =
==========================
>Coordinator(s):
>Started on:
>Priority:

>Current state:

>Description:

Epydoc, under python/api2_2x/doc:
- review text and make small updates to make it more uniform.

Docstrings in .c files:
- define a clear and economic format and update all strings accordingly.

Tutorial:
- write a tutorial in chapters (each developer can then add new chapters to
it).  Willian will convert the one he's writing to use docbook
xml like the Blender docboard uses for the manual.

== End of doc project ==



==================
= Project: tests =
==================
Coordinator(s):
Started on:
Priority:

Rethink, discuss ways to automate test writing and work on a good set of tests.

== End of tests project ==

===============================
= Project: Python GUI =
===============================
>Coordinator(s): Joseph Gilbert
>Start: after release 2.34
>Priority: LOW

This project has been taking some thinking time. Idea is the following:
- Each script is run in a Panel() object inside the Panels window.
- Each script has it's own namespace for variables/globals
- Each script has access to blender's internal UI functionality
- Multiple scripts are run by the interpreter simultaneously
- Multiple copies of the same script can be run at the same time
- A new Console window that would show the output of scripts instead of 
  output going to console/terminal window

== End of Python GUI project ==

