[Bf-committers] Integration of scripts in the UI

[Willian Padovani Germano]

Hi, Matt

Thanks for forwarding to the funboard and for your comments.
(I'll also reply to Chris in the end of this msg, his reply has just
arrived)

From: "Matt Ebb" <matt@mke3.net>
> Sounds really good!
>
> A couple of notes from a UI-perspective...

I agree with you:
> Following the Gimp's approach of putting everything in a top-level
'scripts'
> menu is not so good. The menu items should be organised by their
> functionality -

Yes, we should have this, since the subdirs of the scripts/ dir will become
submenus in the Scripts menu.  We just need to choose a good classification
for scripts -- ex: import, export, tools, modeling, new primitives, "apps"
(complex ones like MakeHuman), user (submenu for user's dir scripts), ...
???

> About the 'script' window space, perhaps it would be good to integrate
this
> into the buttons window?

I thought about that and agree that is a good place.  Problems are: 1 - some
scripts may need more space and 2 - the layout, quantity and current choice
of windows in Blender is so configurable that the best way, really, is to
let the user choose where to open the script gui.  Currently I see two easy
possibilities:
- Put the scripts in the spacebar toolbox, since the user can open it in any
window, choosing where to open the gui.
- (little awkward) Ask the user to click on the window s/he wants the script
gui to appear.

If we later go far with the "contexts" idea for the UI, then we can have a
scripts/buttons subdir just for scripts that were meant to be there, in the
buttons win.

> Switching the largest active window to a 'script window' like the
fileselect
> does is not so good

I agree again, not good at all.  Letting the user choose the window each
time is the better approach.

--------------
Chris Want wrote:
> The Gimp scripts register themselves
> in menus through a function call, not through
> using a directory structure.

Yes, this was suggested and is an interesting mechanism.  But it's kind of
expensive, since we'd have an Init() function in each script and would have
to run the Python interpreter for each available script when starting
Blender.  Who knows?  If we reach 100 or more scripts there (and I do
believe that this is possible -- I'll contribute at least 4 myself, soon,
and I'm not an avid script writer) the overhead can start becoming
noticeable.

So *if we don't find* other uses to justify this mechanism, it may be a
little overkill right now.

> There is also no need to worry about script file naming
> conventions under this scheme, e.g., the script in the
> 'xachlego' file appears under the name 'Xach Blocks...'
> in the menu heirarchy.

Instead of the registering mechanism, I had thought of a simpler/faster one:
add a header to each script, with the info about it, like:

# [Type] [Cathegory] "Script Name Version N.NN"

where type would indicate if it was executable, cathegory would tell where
to put it and the string would be its name in the gui.  Discussing with Ton,
LarstiQ and Michel,  I ended up agreeing that it could be done in the
simpler way: getting all the info from the headers and using subdirs to
define submenus.  Then thought of a possible naming convention to "encode"
the needed info.

BTW, LarstiQ and Michel also liked the registering mechanism idea.  It is
really a flexible, powerful design.

--
Willian, wgermano@ig.com.br