Dev:Source/UI/Window Manager Events

Summary:

Ton has recently expressed some strong feelings about the direction and implementation of certain features of the Bpy API. His main concern is that we have violated a basic Blender design rule that each Space is independant and should not access the data in another Space.

Discussion:

One description of the Blender architecture is a database, implemented as linked lists, with multiple views or browsers. Each view/browser is concurrently accessing the database. Locking and concurrency issues are resolved by Blender's single threaded architecture.

Included below are some excerpts from the Blender Window Manager design document

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. The Spaces should be treated as individual applications, storing settings in their own SpaceXXX structs, and only working on what the Blender database is providing, or what the Screen defines to be the active context (like active Scene, Object, etc).

No G.vd (View3D) access should be allowed in Buttons, or Fileselect, or Script space, since that's undefined then (or can even be zero). It's a common mistake in Blender code - I even violated it sometimes - and it always were reasons for bugs or crashes. The Python Window module also abuses that, and this should be removed a.s.a.p. :)

from the How to move on section:

- design a method for how Python scripts can be attached to any Space type (probably by just becoming an event handler)

---

Edited transcript of IRC discussion on bpy scripts and Spaces. Off-topic messages have been trimmed.

• bpy_space_discussion_trimmed.txt: #blendercoder discussion of bpy and spaces

-- StephenSwaney - 11 Feb 2005

---