I thought it might be interesting to discuss some design considerations of Stolen Notebook Tools.
Goals
One of the most important things to keep in mind when making tools is tool automation. Getting all assets from one end of the asset pipeline to the other with a single command is not only cool, it’s a massive time savings. Tools need to be easy to run from scripts. With scriptable tools it becomes very easy to tie tools together into a pipeline, or run a tool on an entire directory of files, etc.
While tools need to be accessible to scripting, they also need to be easy to for people to use. If a user is going to use a tool directly it must have a UI. Users are more comfortable using a tool with a UI and user error can be reduced by using well known interfaces such as file browsing. Further, a tool with a well designed UI can make the functionality of the tool much more understandable.
So, how does one create a tool that is accessible for scripting yet has a fantastic UI? By breaking the tool into two parts:
- A command line program containing the tool’s functionality
- A GUI program that generates calls to the tool executable
This structure achieves of all my goals. A tool can be used in a script by executing the command with arguments. The tool also has a nice interface for users.
An example is in order.
SN Material
SN Material exports materials contained in a collada file to Catharsis materials. It also copies all data files (textures, shaders, etc) used by a material into the proper location in the catharsis directory.
The command line interface for SN Material has the following parameters:
-r The Catharsis root directory
-m The module (subdirectory Catharsis root) to export into
-f The Collada file to export materials from
-n The name of the material to export. If this is not present, all materials are exported.
This tool might be run with:
snmaterial -f example.dae -r “f:/catharsis” -m “test”
This exports all materials in example.dae and copies all material data files to the module ‘test’ in f:/catharsis.
A script can easily assemble an snmaterial command. It would be a simple task to create a script that would export all materials from all collada files in a directory. More complicated functionality is not difficult.
In fact, the UI interface is just a script. This script creates a nice interface for the tool, assembling arguments to the command line tool and executing it.
I use Python for scripting and wxPython for creating GUIs. Although, any scripting language and widget library can be used since the UI is only bound to the tool through text commands. The previous command looks like this in the SN Material GUI.
As can be seen, this UI is much easier to understand than the command line tool. The user can just run the UI for the tool and will understand the tool much more quickly without having to lookup and memorize command line parameters and flags.
An unexpected benefit of this design is that I can modify and recompile the underlying tool while the UI is still running. While working on SN Material I just leave the UI open, recompile snmaterial.exe and test the exporter with a click.