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

[Michel.Anders at inter.nl.net]

Op Do, september 10, 2009 15:33 schreef Campbell Barton:
(thanks for forwarding BTW)

[...]
>> As a script writer I agree with almost anything on that list, those are
>>  absolute prerequites for porting scripts, although documentation
>> should be given more importance IMHO.
> For a reference api this is a matter of filling in docstrings, for
> more general docs this is important, but not sure adding it to the list
> helps.

Well filled in doctrings will do nicely actually but of course even that
is quite some work at the moment I reckon.

[...]
>> - popups from python, equivalent to the Draw.pupXXX() from the 2.49 API
>>
> These are done by making operators that have an enum properly, then
> calling them from python with invoke as the first argument,
> bpy,ops.my.operator('INVOKE_DEFAULT') # menu should popup # But I didnt
> test this yet, only that it should work since you can now set how the
> operator is called. if invoke is not given as an argument it will execute
> with the default enum or you could pass the enum as a keyword arg.

I didn't realize that was possible already, I will certainly look into that.

[...]

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

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

-- Michel.