[Bf-python] Memory bug in Bpy api

[Bobby Parker]

I guess what I'm looking for is a way to have a "global" GUI and sub GUIs
that appear based on the "application state", i.e. ShaderEditor, Shader
assignment, etc.

The thought was to have a set of buttons that were always visible on the
screen, and use those for notifying the script of a state change, so I could
do some cleanup if neccessary, and maybe save some data before launching
another part of the script that would rely upon data that I've created (but
not saved).

As an example, see http://www.stormwind-studios.com/Misc/Blenderman.jpg <

The buttons at the top of the script are the ones I'd like to be persistent
across the board, and everything below that depends upon state variables.

Using the Registry isn't a bad idea, tho I wonder about it
performance-wise.  I suppose I could maintain the same set of global buttons
per script, tho.

On 1/18/06, Willian Padovani Germano <wgermano at superig.com.br> wrote:
>
> Bobby Parker wrote:
> > Can you suggest a better method of developing a script in such a fashion
> > that several people can work on components of it?
>
> I don't know the details of how your script should work, so please point
> any problem with my suggestions.
>
> Blender.Run() can be used to execute another script. If your data is
> kept in a place accessible to all scripts (*), you can open each
> component as a separate script, with its own gui, called with
> Blender.Run() from the master script.
>
> (*) aka anywhere outside that script's global dict. The Registry dict
> would be the fastest, but Blender texts, external files or an external
> database are other possibilities, depending on the type and amount of
> data you need.
>
> If one script changes data used by others or sets state info that other
> scripts need, just be sure to get / check this data in the draw
> callbacks, because these all always executed when you move to a script's
> gui and thus you will get the current value of the needed data.
>
> So you can divide your script: one dealing with the data (and a place
> where the data is stored), module(s) with common functions and "light"
> ones to display the guis.
>
> > Also, I'm not following your above indicated method, rather I'm doing
> > import from math.* since the Register() function doesn't appear to be
> > happy with callbacks stored in a module (as in ShaderEditorGUI.draw()),
> > since that loads the functions/variables I need into the current
> > namespaces( at least I think/hope that's what's happening, and results
> > seem to bear me out).
>
> Saving a function is not enough, you'd also need to store everything it
> used (which can be cumbersome for methods, complex functions, etc), or
> some references are lost. The simplest is to only store very basic data
> (numbers, strings) in the Registry, not Blender objects, functions, etc.
>
> Yep, I understood math was only an example Toni used in his email and
> used it as an example, too (sorry if I "sounded" harsh or anything).
>
> There are multiple ways to create the data for shader parameters and
> keep it around to create guis dynamically, you know. I didn't test your
> code, but if you're saving created Blender buttons, that might cause the
> crashes (String buttons come to mind). Try to save only the info needed
> to recreate the buttons.
>
> Feel free to keep discussing, we all benefit from it (and we enjoy
> Python :) ).
>
> --
> Willian
> _______________________________________________
> Bf-python mailing list
> Bf-python at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-python
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-python/attachments/20060118/5699e28b/attachment.html>