[Bf-python] Better integration of Python in Blender

Willian Padovani Germano wgermano at ig.com.br
Fri Jul 25 23:33:06 CEST 2003


Finishing this:

On Thu, 2003-07-24 at 22:03, Willian Padovani Germano wrote:

> ------------------------------
> Ok, now specific details open for discussion:
> 
> 0) The mechanism.
> 1) How easy for the user should adding a new script be?
> 2) How transparent we want the integration to be?
> 3) Can we find a suitable, clear classification for script types?
> 4) Persistence of script data (variables).
> ------------------------

2) How transparent we want the integration to be?

We should make the interface act independent from the underlying code:
the user pulls down a menu, clicks on a command and it simply gets
executed, be it compiled C/C++ or a Python script.  Ok.  Up to the point
where the user might not even know if it is a .py script or not.

But do we really want it this way?  Isn't it better if the user can
immediately know which commands are actually scripts?  Because scripts
can be loaded as texts, tweaked, updated, studied (the ones in source
form, of course).

If we put all scripts in a specific menu (with submenus for each type,
of course), we both simplify the code to add scripts to menus and also
make it plain clear for the interested user that all commands in that
menu are Python scripts.
------------------------------

3) Can we find a suitable, clear classification for script types?

This is a side topic, but important anyway.  We need to know how to name
the submenus, classify them for web lists, define the header I wrote
about yesterday, ... Is there an easy classification for scripts?  We
have:

- importers and exporters between two different file formats (3d
usually, but also 2d, lists, descriptions, whatever);

>From here on it's not so clear.

- There are scripts that add functionality to Blender (those that
automate some task and those that actually add new previously
unavailable operations).  This can further be subdivided according to
the type of the object affected.

- There are scripts that are more like whole apps built on top of
Blender: they add new functionality but also their own windows / buttons
/ variables -- they are like the previous group, but bigger.  How do we
call them?  Apps?

So let's start with this poor classification in 4 groups: 1 - importers,
2 - exporters, 3 - "functions" or "operations", 4 - "apps".  Ideas to
make this better? (it sure needs to improve)

I'll leave the 4th item to the third email, since it relates to the
global dictionary.

Jacques: if you're already coding, please just don't commit anything,
it's better to send it as a patch to the bf-committers list once you
finish.

I've sent the two emails about interface, later we'll wrap this and move
the discussion to the other list.  As always and more than ever,
opinions are welcome.  Did I miss something important?  Wasn't it well
expressed?  Do you aggre or not with some point?  I've made many
questions, that will also be forwarded to the other list with the
feeback we get here.

--
Willian, wgermano at ig.com.br




More information about the Bf-python mailing list