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

[Campbell Barton]

Hi Michel,

what your talking about is a few steps a head of where we are right now.
We've had a number of discussions about how things might work but for
the short term Im mostly interested in having the existing api's
functional (since they are missing some fairly important parts)...
other replies inline.


On Tue, Sep 8, 2009 at 5:39 AM,  <M.Anders at inter.nl.net> wrote:
> Hi Campbell,
>
> as subscription to mailing list is appparently not equal to being allowed
> to post (or i don't undestand mailman anymore) I forward this to you
> personally as I got a waiting for moderator approval bounce :-)
>
> ------------------------- Oorspronkelijk bericht -------------------------
> Onderwerp: Re: [Bf-taskforce25] Python/RNA high priority TODO's.
> Van:       M.Anders at inter.nl.net
> Datum:     Di, september 8, 2009 14:28
> Aan:       bf-taskforce25 at blender.org
> --------------------------------------------------------------------------
>
> Op Ma, september 7, 2009 12:10 schreef Campbell Barton:
>> Its hard to give a good answer when people as how the py api is since
>> some things work very well, yet often when I try do something useful I hit
>> immediate problems that end up being non-trivial to fix.
>>
>> Heres a list of [...]
>
> 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.

> What I really miss though is two or three things needed to start porting
> wizard and addmesh like scripts (maybe they are already possible, in which
> case I apologize, but I searched quite well I think):
>
> - 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.

> many things are now possible and even preferred form context sensitive
> panels and the might even be modal if I understand correctly, but
> sometimes it makes sense to show the user a popup with all sorts of
> parameters that will instantiate something after pressing OK (wizard like
> scripts)
We may have this in the future but ATM this is very low priority for me.

> - a way to register external scripts
> - a way to add these scripts to menus in spaces in a predefined way
>
> These two are related I think. A simple scheme could look something like
> this (reminiscent of the 2.49 approach):
>
> - on start up (or 'rescan') run all scripts from a specified subdirectory
>
> .blender/ui/addons would be a suggestion as its name states its intention
> and enables you to keep the still to be ported scripts in the
> .blender/scripts directory during development,
>
> - these script can do anything they like of course, but mainly they
> register operators with a certain naming convention, e.g. the INFO_MT_add
> class could list all bpy.ops.addmesh.* operators in its Add menu.
> The class definitions of these operators could define extra class
> variables like those for the help system browser (similar to the globals
> used in current scripts) and for some UI hints, e.g. an __icon__ variable
> to hold an icon name.
>
> 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.

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


> -- Michel.
> (varkenvarken)

-- 
- Campbell