[Bf-python] user feed back

[Willian Padovani Germano]

Hi, Jacques : )

On Sun, 2003-07-06 at 21:37, Jacques Guignot wrote:
> Hi!
> 
> I received a mail from a french blender artist (dwarf, maybe you already 
> know him?), which is very interesting, and presents some TODOs and some 
> guidelines which, I think, should be very seriously considered...
> 
> a) a list of scripts should be accessible(?)  from the main interface, 
> with a button "exec plugin", allowing the user to load and execute 
> directly a plugin (the "old" way with Alt-P should of course been kept)
>  >>> Does not seem difficult. I think I can do it.

Yes, that's our main TODO for after 2.28: better integration of Blender
and Python:

First there are two kinds of scripts: default ones that come with
Blender or are big/important/integrated enough to have special treatment
and general scripts the user can download.

- The better integrated ones can have their own entry in specific menus,
just like any Blender functionality.

- For the general case, we should be able to scan a folder (or list of
folders) upon startup and import all the .py filenames there to a menu
list.

I've been looking / thinking about this.  Menu entries are linked to a
callback, like (pseudo-code):

MenuItem("Name", x, y, w, h, callback, "Tooltip")

For specific cases, the callback is also specific, but for the general
case of scripts scanned on startup, we need a general callback, like a
Do_Python_Script() that runs the filename using PyRun_File() or
PyRun_SimpleFile().  And how do we tell it which script to run, since we
can't give the callback a parameter inside the MenuItem call above?

That's along what dwarf said, of course: the menu is of that kind where
you can make only one item active at each time, so we know which script
to run (Blender supports this kind of widget).  And to run it the user
presses an "Execute Script" button, possibly by the side of the
currently chosen script name.

But note, Guignot, that this discussion must first be carried in the
main bf-committers list.  This is not specific to BPython, it involves
choosing how to do it, where to put it, finding a place at the
interface, etc.
 
> b) Sripts should be made "permanent", ie been kept when the user changes 
> his working screen, and theur parameters should be kept in memory.
>  >>> Does not seem difficult. I think I can do it. btw, I never tried to 
> change wk screen...

He means making a script just another Blender window, to which you can
come back, right?  Another thing to discuss at bf-committers, but
probably this can only be done for very special cases, scripts that
bring new "apps" into Blender and are used enough to deserve that. 
Supporting all scripts, this could become a bother.  About keeping the
parameters, again there's a number of ways of doing this, must be
investigated / discussed.

> c) Scripts should be able to interact directly with the current object 
> (Mesh, Material, etc...)
>  >>>I am not sure to fully understand. I can ask dwarf to elaborate on that.

That's what GetSelected() is for.  The script would preferably give
users the option to execute itself on a chosen object (from a menu), the
currently active one(s) or all.

> d) Some important functions that are accessible from the interface, like 
> extrude, share, warp (csg?) should be accessible from the API.
>  >>> Seems difficult. I think I can ***try*** to do it.

This is not trivial.  In edit mode we have EMesh, a structure different
from the normal Mesh one, where we can select vertices and operate on
them.  Some operations in Blender only work with these.  And since
Blender will hopefully support both manifold and non-manifold meshes, we
may have to wait to rewrite / add this functionality.

Another solution is developing *in Python* a lib of mesh operations, but
we'd have to deal with being able to select vertices, edges and faces to
tell which ones to work on.

> e) python scripts cannot change the rendering process (this task has 
> been devoted to Sequences plugins, but these plugins are not so that 
> easy to write.)
>  >>> Seems difficult. I think I can ***try*** to do it.

We've discussed this on the Sun meeting: it involves being able to
access image pixel buffers to read/write pixels, among other things (a
Render module).

Dwarf listed the most wanted features we should try to support after our
initial integration.  He won't be the only one pushing us to implement
these things : ).

You decide if you want to try any/all of these things, to propose an
implementation already with a patch available (since bigger changes like
this can't be committed in small pieces like we've been doing for
exppython).  Or maybe propose and take care (after 2.28, please!) of
writing / updating a design doc during discussions at the main list,
before implementation starts.

--
Willian, wgermano at ig.com.br