[Bf-taskforce25] [Fwd: Re: Python/RNA high priority TODO's.]

Campbell Barton ideasman42 at gmail.com
Sat Sep 12 03:29:37 CEST 2009


--- snip
>>> Would that be workable? I think it would be fairly easy to implement
>>> (the
>>> startup bit is done already for ui scripts) and the second part it could
>>>  be implemented in small step as the need arises. I could recode
>>> space_info.py myself if you like to get started or just to show the
>>> concept.
>> As for having user scripts with blender scripts, this is needed though
>> Id prefer something more like 2.4x does where you can set a user
>> script dir, rather then having the user scripts as a subdir of system ones.
>
> Well, we would need both I think, after all some scripts will be bundled
> and some will be added by (end)-users. So what I meant is not that any and
> all scripts should be residing in some system directory but that there are
> documented directories (like the io an ui system dirs) that will be
> scanned for scripts that will be run at atartup.


The users scripts dir problem is just a matter of agreeing on a
directory and having it work on multiple OS's, or agreeing on a new
way, Im not against this but such discussion I also find tedious, yes
we should look into this further but I was assuming we'd just have
something similar to blender 2.4 where you can set an extra scripts
dir.

Linux packagers have asked to be able to use /usr/share/blender/*
rather then always ~/.blender/*, so could try solve this too, but to
me this is less a python api issue and more one of distribution, could
solve both at once but for now its not high priority for me.


>> adding an operator into an existing menu I dont think is supported yet,
>> we'll need to look into how this can work. - Could be as simple as having
>> lists of operators in the menu classes and external scripts could add
>> themselves there. All python, no code changes needed in blender/C
>
> Access to the menu class wouldn't be enough IMHO, you would need a way to
> notify the instances of that class as well (although that would be the
> responsebility of the menu class method that adds a new entry I think)

Not sure why you think its not enough. Python classes can be modified
py other classes without having to notify blender.
The next time the poll/draw functions are called they will show any
changes made to the class.

An example of how this can happen already is with external engines
adding themselves to blender internal classes as being compatible so
you can have some materials panels draw and others be hidden.

I have doubts about this as a way to make all menus, since it could
make them hard to read nevertheless its one way...

Rather then the draw function call menu items directly the class could
store a list of menu items+options as strings. then these could be
called in a loop when drawing.

The main part I don't like about this is we'd have to somehow have a
way to check each menu item should be drawn (a per menu item poll
function ?) - this seems overkill.
To avoid polling for each item we could have a nested list with a poll
function at the start of each.

So external classes would only need to import the module and add
themselves into the classes menu item list (possibly including their
own poll function).

...or store a list of functions that can be adjusted externally too,
since its plain python there are loads of options for this.

-- 
- Campbell


More information about the Bf-taskforce25 mailing list