[Bf-python] ScreenAreasWindowsEvents (was Text3d)

Gilbert, Joseph jgilbert at tigr.org
Fri Feb 11 17:39:15 CET 2005


Interesting wiki page stiv.

It sounded to me (from the IRC chat log) that the idea is to have
scriptlink like binds to windows/objects i.e. objects/windows that have
a link to a python script that they would execute. This is an
interesting idea.

>- design a method for how Python scripts can be attached to any Space
type >(probably by just becoming an event handler!)
Y not just have a spacetype that accesses data in the G.main with no
access to the other space/areas? (just floating this here) From what I
understood the architecture is to have spaces independent of each other
accessing only the data in G.main? Is that possible to do with the
scripts window? Also you still need a window in which to bring up text,
right? How does textspace and scriptlinks work with each other without
knowing anything about the other spaces then? (Sorry if I sound
confused)

[10 11:29]<kaito> i also wouldnot recommend adding py panels (for now)
[10 11:30]<kaito> thats the b) handler-queue thing as well

Well I guess I should stop work on this until we have developed an event
handler for python. (If we go that route)

>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.

Are we ruling out extending python? It sounds this way from the
discussion. The ideas being floated sound like Blender should by running
an embedded interpreter to execute python scriptlinks. (Not that I have
a problem here :) I prefer embedded myself). 


-----Original Message-----
From: bf-python-bounces at projects.blender.org
[mailto:bf-python-bounces at projects.blender.org] On Behalf Of Stephen
Swaney
Sent: Friday, February 11, 2005 8:11 AM
To: Blender Foundation Python list
Subject: Re: [Bf-python] ScreenAreasWindowsEvents (was Text3d)

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

_______________________________________________
Bf-python mailing list
Bf-python at projects.blender.org
http://projects.blender.org/mailman/listinfo/bf-python



More information about the Bf-python mailing list