[Bf-python] ScreenAreasWindowsEvents (was Text3d)

[Stephen Swaney]

On Fri, Feb 11, 2005 at 11:35:53PM +1100, Jonathan Merritt wrote:
> Stephen Swaney wrote:
> 
> >Heh.  Actually, Ton has expressed some doubts about both the direction
> >of the bpy project and our implementation.  But more on that will soon
> >be at the ScreensAreasWindowsEvents link on the Design Issues page.
> >  
> 
> There are some interesting points already brought up on this page:
> 
> """
> Another important aspect is that any Space is supposed to run fully 
> local. It is not (should not) be aware of any other editors that are 
> open, nor read data from it, nor access them to change data.
> """
> 
> If this rule were followed, wouldn't it mean then that it would be 
> *impossible* ever to implement things like:
>     1. a knife tool,
>     2. a customized vertex painter (maybe for game properties?),
>     3. a custom 3D object type (drawn in the 3D view)
>     4. etc...
> using Python?  (Unless, of course, you duplicated all of the 
> functionality you required in the 3D view from within the script!!!)  
> Surely this is a tremendous shortcoming?

You raise some good questions! ( I have snipped all the details )

The short answer to your question is that we need the ability to run a
python script within the 3d window itself rather than within our Script 
Space.

More Details:

First, let me say that page is still under construction and will have
a more complete discussion in the near future.  Real Soon Now(tm).

Ton has two main bpy concerns.  One is the issue of Space to Space
data access.  Yesterday, there was an irc chat about this issue.  Two
possible solutions came up:

1) a reworked event handling system with function callbacks capable of
executing python code.  We do need an event queues with actual
handlers rather than hard-coded functions.  However, this is no small
task and not a near-term solution!

2) the ability to bind and run a python script from within any Space.
This would let us run bpy scripts within the 3d window or the OOPS
window, for example, without violating Blender's design rules.  This
is the more promising approach.  It lets us create tools like you 
describe above.

Ton's other concern is that people are attempting to implement
features in python that should properly be coded in C.  The issue here
is that Blender does not have an actual api that can be wrapped in
python.

-- 
Stephen Swaney			
sswaney at centurytel.net