[Bf-committers] Scripts accessible from menus

Matt Ebb bf-committers@blender.org
Sat, 17 Jan 2004 17:06:17 +1100


On 15 Jan 2004, at 3:20 PM, Willian Padovani Germano wrote:
> Hi,
>
> The code needed for scripts to be accessible from menus was already
> committed to cvs.

First of all, wow! Excellent work and a big congratulations, Wilian. I 
bet something like this is truly worthy of the shuttleworth bounty :P

> - It works for me (linux), but I need confirmation from other linux
> users and from all other platforms.

Works great here on OS X 10.3.2

> Group refers to script category.  Currently I've added 'Import',
> 'Export' and 'Misc', but it's absolutely trivial to add more (check
> comments in
> source/blender/python/BPY_menus.[hc] and code in
> source/blender/src/header_info.c )

re. LarstiQ / Willian
>> - I looked for the Scripts/Misc menu in the main blender menu, and
>>   only later thought of looking in the Scripts Window, this is
>>   something for Matt I guess.
>
> Yes, from now on these things can be tackled.  But the Scripts win is
> the best place for 'misc' scripts with guis.  We should later separate
> misc in more cathegories.  Things like mesh tools can be better in the
> 3d view header's (editmode) "Edit" menu, etc.

Ideally, every script will have a place in the interface, rather than 
the 'Misc' in the scripts window (hard to find). Hopefully the menu 
guidelines here ( 
http://www.blender.org/docs/UIGuidelines/menus/menus-intro.html ) will 
help script authors find a good place to put them, though I suppose 
we'll need to add the functionality for it in the various places in 
header_info, header_view3d, etc. etc.

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. 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. 
Or perhaps temporarily turn the buttons window into a Script space? Who 
knows.. 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. Anyway what we 
have now is a great step in that direction :)

> is enough, but note that the single-quotes are necessary.
>
> The Submenu line: Submenu: 'Submenu name' arg works like this:
>
> - you can define many submenu lines.  When that menu entry is chosen, a
> pupmenu opens up for the user to choose a submenu entry.

It's best to use this approach as much as possible, rather than 
pupmenu()s - I recently spent some time messing with code to expand out 
some of the menus in header_view3d as submenus, rather than using 
pupmenu()s. Hierarchical menus are much easier for users to explore and 
see what the capabilities and functionality are, without having to 
actually choose the item. Not to mention that the advantage of pupmenus 
is that they're right under the mouse when you press a hotkey, which 
doesn't really work with pulldown menus.

re. python scripts path:
> Yes, it is only evaluated at startup, I'll add a menu entry, probably 
> at
> the Scripts menu (Scripts window), to re-evaluate on-the-fly once when
> pressed.

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.

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? If there are going to be changes that script authors have 
to update their scripts with, it's probably better that it's all 
changed over at the same time, so authors don't have to continually 
keep updating, or have partially compatible scripts. I personally have 
no idea, but it pays to think ahead about what information may be 
useful in the future.

Again, thanks for your hard work and well done!

Matt