[Bf-python] ScreenAreasWindowsEvents (was Text3d)

[Jonathan Merritt]

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?

To give you an example: I have been hoping that the Python event system 
that is connected with the 3D view would mature enough for me to be able 
to implement my own custom object type for use in biomechanical 
modeling.  This object would consist of origins, waypoints, and 
insertions of muscles in a musculoskeletal system.  The muscles would be 
linked to rigid bodies (meshes) representing the bones.  I already use 
Blender and Python for reading off 3D coordinates for the design of 
these elements, but I had hoped to be able to use it to render the model 
in real-time in the 3D view as well.  The rules that govern the model 
geometry are *much* too complicated to be represented by the current (or 
planned!) animation tools (things like wrapping around spheres and 
cylinders in 3D, etc.), so they really require some kind of customized 
drawing in the 3D view.

Just out of interest, how would you suggest that an application such as 
this could ever fit in to the world-view of Python as you see it?  I 
think it could fit in to this wider world-view only if a higher-level 
drawing API were implemented; one that is separate from the 3D views 
(ie: stored in a general way in some part of the database that the 3D 
view looks in upon).

-- 
Jonathan Merritt BE(Mech)/BSc
PhD Student - Equine Biomechanics
The University of Melbourne 
Veterinary Clinical Centre, Werribee