[Bf-funboard] Re: [Bf-committers] Integration of scripts in the UI

[Matt Ebb]

Sounds really good!

A couple of notes from a UI-perspective...

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 -
to the user it shouldn't really matter whether something is a script or not, as
long as it works right. As an example, under the file menu there should be
sub-menus "Import" and "Export". The relevant scripts could appear under there
along with the other things like DXF, Videoscape, etc. For other things like
mesh editing, it's not so clear cut, but I think it would be good to reserve
space in possible "edit" or "animation" or whatever top-level menus, to put the
relevant scripts in there along with Blender's internal functions.

About the 'script' window space, perhaps it would be good to integrate this into
the buttons window? Imagining how this would work practically (eg. ripsting's
fiber script), in the default layout, a user would have the 3D viewport and a
buttons window on screen. If the user then selected 'Fiber Generator' or
whatever from the menu, the script's controls could be shown in the buttons
window. This would make sense since the buttons window is known as a place where
users have access to settings and functionality to edit/select/etc. their
objects. I think someone posted a mockup along this idea to the funboard a while
ago.

Switching the largest active window to a 'script window' like the fileselect
does is not so good, because usually the largest active window will be the 3D
viewport - you need to be able to see the script's controls and the 3D view (or
Ipos, whatever) at the same time.

Anyway, this is very exciting, and a tricky topic. I'm interested to see how
this pans out.

Cheers

Matt


Quoting Willian Padovani Germano <wgermano@ig.com.br>:

> Hi, (long post, sorry)
> 
> We've been discussing and experimenting, trying to find the best way to have
> python scripts accessible from menus / spacebar toolbox.  This is a summary
> of the current ideas:
> 
> Jacques Guignot already made a test with a menu, but as he saw, scripts that
> open guis don't work.  That is because the current system is hardwired to
> put the gui over the text space where the user pressed ALT+P.  To finish his
> test, his solution was to, when a script entry was chosen from a menu, load
> it as a blender text and follow the current procedure.  It works and he can
> explain more / send a patch to anyone who would like to try it.  But we'd
> better not have to load all scripts as texts, that's not necessary.
> 
> Guignot's test hinted that we need a space in Blender where scripts can open
> their guis.  That's the idea, now.
> 
> We can divide the job in two parts:
> 
> [1] Create the SpaceScript, similar to the SpaceText (text window in
> Blender):
> 
> - its header should have a dropdown list with currently running scripts
> (like the text header has with currently loaded texts).
> 
> - when the user chooses a script from a menu: if the script has a gui, the
> active window jumps to the script window and the script gui appears there,
> +- like the file selector does.
> 
> (issue): this creates a problem if we put scripts with guis in the top
> menubar, since then no window has focus and we have to choose one, again
> like the file selector does (but scripts in general shouldn't need to stay
> open only for a short while, the idea is to allow them to work like normal
> Blender spaces/modes).  This issue doesn't happen with the spacebar toolbox,
> since
> then some window has the current focus and we use it to open the script
> space.
> 
> [2] Scanning the scripts directory and building the Scripts menu
> 
> Think Gimp:
> 
> - a default installation blender/scripts/ and
> - a user dir (.blender/scripts, for a linux example).
> 
> This so that installing new versions of Blender don't mess with "user"
> scripts (ones they modified, created, downloaded from the net, etc).
> 
> To draw the scripts menu or submenu we play simple, like Ton suggested: scan
> the scripts/ dir and use filenames and subdirs themselves to create entries
> and submenus, resp.  Like this bogus example: the dir structure
> 
> blender/scripts/ :
> ./modeling/
> ./export/
> ./import/
> 
> blender/scripts/modeling/ :
> ./TurtleMakerV0_2.py
> ./GalaxyBuilderV32_5.py
> ./HandModeler.py
> 
> blender/scripts/export/ :
> ./FormatXYZ.py
> ./NoUVTex.py
> ./OnlyTriangles.py
> ./OnlyNames.py
> 
> and so on, would become the menu "Scripts":
> 
> -- Export ...
> -- Import ...
> -- Modeling ...
> 
> opening the Modeling submenu:
> 
> -- Turtle Maker 0.2
> -- Galaxy Builder 32.5
> -- Hand Modeler
> 
> [[
> Possible filename conventions:
> 
> -- normal script to be in the menus (executable): ScriptNameV1_0.py,
> which becomes the menu entry "Script Name 1.0".
> 
> (So to get the menu entry we parse the name and separate it where a
> capital appears. If the letter is a "V" followed by a number, we include
> it as the script version number.)
> 
> -- scripts not to be in the menus ("libs" or data for executable scripts):
> m_scriptname.py (or .pyc, .pyo).
> 
> (So if an "m_" (or maybe "mod_") for "module" is prepended, we ignore the
> file while creating the menus.  We also ignore any extension except those of
> executable python code: .py, .pyc, .pyo, .pyd (I guess))
> ]]
> -------------------------------
> 
> Once clean / ready, I'll send the SpaceScript to Ton for checking.
> Suggestions are of course welcome, just keep in mind that, targetting 2.29
> and with possibly big and still undecided changes in the UI being discussed,
> the best we can do now is to try to get a simple and flexible design.
> 
> While thinking / working on this, I've discussed with (in order of whom I
> bothered the most): Ton, LarstiQ, Michel, Guignot, R. Kimball.
> 
> Shoot someone I forgot!  Mm?! ...
> 
> Thanks,
> 
> --
> Willian, wgermano@ig.com.br
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
_______________________________________________
Bf-committers mailing list
Bf-committers@blender.org
http://www.blender.org/mailman/listinfo/bf-committers