[Bf-python] threading needed for pyverse

[models at paposo.com]

> Anyone got other ideas?
:)
I was playing around a litle with this issue previously  to try to get
blender to open child windows from python (for a script gui)...........
These are just some of my thoughts. Read on at your own risk :)

  I tried to get GHOST and python to work previous but without luck. You can
create a window from ghostwinlay.c using the python modules really easy.
It's the handling of events in that window that's the problem. It crashes
blender if you try :) However, it just hit me - have you thought about the
rendering window?  They seem to be able to open the rendering window ok from
blender without generating a new thread. Check out renderwin.c/h for the
details on how the rendering engine opens and processes events.
static void open_renderwin(int winpos[2], int winsize[2]){
 Window *win;
 win= window_open("Blender:Render", winpos[0], winpos[1], winsize[0],
winsize[1], 0);
 render_win= renderwin_alloc(win);
 /* Ghost calls handler */
 window_set_handler(win, renderwin_handler, render_win);
 winlay_process_events(0);
 window_make_active(render_win->win);
 winlay_process_events(0);
 renderwin_draw(render_win, 1);
 renderwin_draw(render_win, 1);}

Notice here that they
1. create a new ghost window with window_open
2. set up a ghost message pump with window_set_handler
The message pump they use is defined in:
 renderwin_handler(Window *win, void *user_data, short evt, short val, char
ascii)
3. They then call winlay_process_events(0) (to clear out blender messages i
guess)
4. Make this the active window
5. Send new messages to this window

There also might be a way to integrate the above code in ghostwinlay.c and
the underlying ghostC-api with some genuine low level C threading code.
Something like what's here:
http://rabbit.eng.miami.edu/class/een512/threadsc.txt Doing this might be
the job for the GHOST team though. Although I don't know if it's necessary
or not. They also have event consumers which might be linked to blender's
dispatch pump which would act as a pseuedothread for the new window I guess.
You could check out GHOST_EventManager.cpp. I think some experimentation
here is necessary to see what is possible and what is not.

  As for the python threading, the problem here is that everytime blender
executes a script it clears it's global namespace and sets up for a new
script. This means that any vars (like new open windows created by python)
are going to be invalid unless you get blender to not clear out the global
namespace. Like willian was saying, the draw module accomplishes it's
drawing ablilities by forcing the global namespace to stay open until a
callback fails (through the Draw.Register() function) and then allowing the
namespace to close out. The difference here with the Draw module is that the
messages are sent to blender's message pump for processing and are routed to
the 'text space' window that you run your scripts in. There is a reason that
the draw module draws in the text window(i believe) - because you probably
don't want to run any more scripts until the global namespace has be cleared
out and blender is set up to run a new script. (I could be wrong though :)
Some things would work fine but other scripts mght be a bit unpredictable, i
would image, if you ran them multiple times in the same namespace.
  I think that the most promising way to do this would be to set up a new
window using GHOST from a python script (which is easy). However, when the
window is created you need to have blender manage it instead of python (most
likely through the ghostC-api and winlay_process_events).  It would be a bad
idea for these reasons,  to create a python wrapper for the ghost window
(cause it will disapear once the namespace is cleared - poof!) So you could
simply wrap the creation and destruction of the window from python in a
python_ghost module and let blender manage the processing of it's messages
until it needs to be closed.