[Bf-committers] Starting changes in Python UI

Willian Padovani Germano bf-committers@blender.org
Sat, 13 Dec 2003 23:24:12 -0200


Sorry, long email.  I marked the main part with "***", feel free to skip
to it.

A few months ago we discussed how to better integrate Python in Blender.
The main ideas that got more recommendation were:

- add scripts to menus where they belong, like: importers in
File->Import, etc;
- follow more or less what Gimp does: let scripts register themselves
with Blender, info that we get once, store in a file and only update
when the scripts dir is newer than this file.

There are many things that can be done, but luckly the steps are well
defined and small, so we just have to be careful that the implementation
is well designed and flexible / adequate for improvement.

Jacques Guignot released a patch some months ago where he managed to get
a scripts dir scanned and a "Python" main menu built from that.  He had
to use the current system (first load script as Blender Text, then run
it), because scripts that draw their own guis were not working otherwise
by simply loading them from disk with a Python/C API function called
PyRun_File.  This is because the old system was hardcoded to give the
Text Editor space where you pressed ALT+P to the script, for it to draw
its gui and get events in that space.

Jacques' experiment (thanks Jacques!), then, showed that the system
isn't good for the integration work (imho), because:

1 - all scripts would have to be added as Blender Texts first;
2 - only one running script with gui would be accessible in each window;
3 - each running script with gui blocks the Text Editor in that window;

1 is the real or main problem, because if we expect many scripts to be
available, for example those that introduce new mesh operations, we
could have many unneeded texts lying around (or worse, being created /

The current work takes this into consideration and is aimed at
supporting cleanly both the old Text scripts system and the new from
menus (where scripts are kept as files stored on disk).

(small note: in Blender, windows are the "partitions" of the screen, the
ones you can split / join / resize.  Spaces are window "contents": 3D
win, Text Editor, Oops, File Browser, etc., all those accessible from
the main window button)

The first part is already done, ready for more testing.  It introduces a
new space type, called SpaceScript, to serve as the space for scripts to
put their guis on and get events.  Its benefits right now are:

- the Text Editor becomes available again, even while a script w/ gui is
running in a window;
- if we keep more than one script w/ gui running at once, we can switch
between them in spacescript just like we can do with texts in the text
editor: just choose the one you want from the databrowse dropdown list
at the header.

Another important change is that we'll use the Blender.Registry module
to let scripts keep "persistent" data during a Blender session (later we
can save this data to disk, too).  This way scripts can communicate with
each other and also check if they have already been executed, to get
their tweaked options instead of always opening with default ones.  Each
script will have its own namespace which is deleted when the script
finishes, so the new module is the way (besides saving to disk) to keep
data around after a script finishes.

Another issue: introducing a new space makes new .blend files crash
older blender binaries, including 2.31a -- BUT ONLY if you save the
.blend file with a SpaceScript *visible* at the moment.  Ton will fix
this so that future Blenders won't crash even when new spaces are


With this basis in place we can work on the other parts.  Some issues
remain to be discussed, specially UI related, I'll mention them later,
along with the rest of the work.  The actual implementation is also ehh
(understatement!) being friendly discussed : ), but the internal details
can change easily without breaking anything or even affecting the
expected behavior.

Ah, we need an icon for SpaceScript, something related to Python would
be great.  I'd go for a tilted close-up on a snake's eye, black with
yellow eyeball, little bits of green skin appearing at the corners of
the icon, but ok, I'll just shut up!

I'll enjoy opinions and bug reports, of course, will try to fix as soon
as possible any problem.  Already committed the changes.

Willian, wgermano@ig.com.br