[Bf-committers] Scripts accessible from menus

[Willian Padovani Germano]

Hi Matt,

----- Original Message -----
From: "Matt Ebb" <matt@mke3.net>
To: <bf-committers@blender.org>
Sent: Saturday, January 17, 2004 4:06 AM
Subject: Re: [Bf-committers] Scripts accessible from menus

> Works great here on OS X 10.3.2

Thanks, guess we're safe with Linux, Linux PPC and OS X 10.3.2.  No luck
on Windows, but I'll try to use the old (text win) method to run Python
code, that might solve it.  Still need confirmation from other
platforms.

> Ideally, every script will have a place in the interface, rather than
> the 'Misc' in the scripts window (hard to find).

The Scripts window header "Scripts" menu is good for having all scripts
listed in one place, but surely each group can get its place somewhere
else in the GUI.  Another advantage of the menu in that window is that
big script apps are better put there, their gui will use the Scripts win
automatically.

BTW: the code I added to header_info.c does this regarding script guis:
if a scriptspace is available, it is used, otherwise the biggest area is
used, like done for the file selector.

> Having the Scripts/Misc menu is not that good since it's harder to
> find, and is yet another different (inconsistent) menu
> hierarchy/organisation (along with pulldown menus and toolbox) that
the
> user must learn.

Yes, I just added 'Misc' because we still didn't decide the groups we'll
have.  Misc should be split and killed eventually.

However, like Willian said the problem is scripts that
> have GUIs - where should the GUI go if a script is called from a 3D
> View menu? (for example). A solution could be to introduce floating
> panels with Script spaces inside them, but that sounds rather tricky.

Yes, probably better not to go there, at least now.  Panels architecture
/ management is different, would require deep changes.

> Or perhaps temporarily turn the buttons window into a Script space?

This is really script (and taste) dependant, some of them need material
buttons available for tweaks, like Fiber, etc., while the user tests
renders with different material settings and different Fiber settings.

> In any case, my personal opinion is that the aim should be that
> the user doesn't even need to know what is a script and what isn't -
> the functionality is added seamlessly to the interface.

It's good to know when a script is being used, the user might want to
take a look at its source or look for an update.  If we really hide,
we'd get questions: is this a script, is that done with scripting, I
thought that was a script, etc.  That's why I like the Scripts menu in
scriptspace, it has all of them there, clearly stating they are scripts.

> re. python scripts path:
> Would it be possible to do this automatically whenever the text field
> is changed? May be tricky, but nicer than having to manually 'refresh'
> it.

Should be easy to do, but I added a button there, making it really close
to automatic.  When we get installation issues solved, the default
scripts dir will probably not be user pref python dir (U.pythondir), so
that can be used simply to add a different dir to the python path.  It's
probably better to let the users control if they want changes there to
affect the menus.  Besides, a button is useful too for when a script is
added or removed, since then you can update menus without leaving
Blender.  We could of course check dir timestamp everytime a menu was
accessed, but that's overkill for my tastes.

> re. script headers:
> While scripts are in this 'transition phase', is there other metadata
> that may be useful to add to script headers as well as the name,
> version, etc?

The problem are required ones, like 'Blender' for version that was added
yesterday.  No required one occurs to me, it's good to keep tags at a
minimum, but if someone knows of a good one to add, just tell us.

PS: After 2.32 we could discuss if letting script guis from scriptspace
also be accessed at the script buttons win is a good idea.  As you once
wrote, it's a good place for many scripts.

--
Willian, wgermano@ig.com.br