Graphics Reference
In-Depth Information
1. You can put all the documentation for your plugin in a single file named
in-
dex.html
, and then simply call
showPluginHelp()
with no parameters to
display that help file when the user asks for help.
2. You can use a different filename for your help file and supply that name in the
filename
parameter when calling
showPluginHelp()
, for example,
showPluginHelp(filename="plugin_help")
.
3. You're not just limited to having one help file. You can have a whole directory of
help files, and have the
index.html
file act as a table of contents for the plu-
gin's online help. To do this, call
showPluginHelp
with
filename
set to
something like
os.path.join("help_files", "index")
so that the
help file is found in a subdirectory rather than the main plugin directory.
4. If you have multiple help files, for example, one for each of your plugin's main
features, you might choose to display the appropriate help file based on which
feature the user is using at that time. For example, you might add a
Help
button to
a complex dialog or window and have that button call
showPlu-
ginHelp(filename="my_dialog")
.
5. Finally, you might put all your documentation into a single file, and use HTML
anchor tags (for example,
<a id="my_dialog">My Dialog</a>
) to
define the various sections of your documentation. You will then use the
sec-
tion
parameter to jump directly to that section of your plugin's documentation,
like this:
showPluginHelp(section="my_dialog")
.
Of course, while your help file has to end up in HTML format, you might not want to
write HTML directly. Instead, you can write your documentation using a markup lan-
guage such as Markdown, reStructuredText, or Latex, and then use a documentation gen-
erator to convert your marked-up files into HTML. This is a perfect example of something
that can be automated using a Makefile, and indeed, the Plugin Builder's default Makefile
includes support for using Sphinx to convert reStructuredText markup into HTML.
