Architecture
============
-Hooke's main entry point is :class:`hooke.hooke.Hooke`. `Hooke` reads
-in the configuration files and loads Plugins_ and Drivers_. Then it
-forks off a :class:`hooke.engine.CommandEngine` instance to execute
-Commands_, and a :class:`hooke.ui.UserInterface` instance to connect
-the `CommandEngine` with the user. The `CommandEngine` runs in a
-subprocess, which allows command execution to occur in parallel with
-`UserInterface` interaction. The two processes communicate via two
-:class:`multiprocessing.Queue`\s.
+Hooke's main entry point is :class:`~hooke.hooke.Hooke`.
+:class:`~hooke.hooke.Hooke` reads in the configuration files and loads
+Plugins_ and Drivers_. Then it forks off a
+:class:`~hooke.engine.CommandEngine` instance to execute Commands_,
+and a :class:`~hooke.ui.UserInterface` instance to connect the
+:class:`~hooke.engine.CommandEngine` with the user. The
+:class:`~hooke.engine.CommandEngine` runs in a subprocess, which
+allows command execution to occur in parallel with
+:class:`~hooke.ui.UserInterface` interaction. The two processes
+communicate via two :class:`~multiprocessing.Queue`\s.
There are a number of special classes availiable to structure queue
-communications. See :mod:`hooke.interaction` and
-:class:`hooke.command.CommandExit` for details.
+communications. See :mod:`~hooke.interaction` and
+:class:`~hooke.command.CommandExit` for details.
Plugins
-------
-:class:`hooke.plugin.Plugin`\s contain bundles of Commands_,
+:class:`~hooke.plugin.Plugin`\s contain bundles of Commands_,
representing the various operations a user can carry out through the
Hooke interface.
-`Plugin`\s can depend on other `Plugin`\s, so you shouldn't need to
-repeat code. One central `Plugin` can provide useful functionality
-to several dependent `Plugin`\s.
+:class:`~hooke.plugin.Plugin`\s can depend on other
+:class:`~hooke.plugin.Plugin`\s, so you shouldn't need to repeat code.
+One central :class:`~hooke.plugin.Plugin` can provide useful
+functionality to several dependent :class:`~hooke.plugin.Plugin`\s.
-There is a `Plugin` subtype :class:`hooke.plugin.Builtin` which is
-just like a `Plugin`, but is considered fundamental enough to not be
-optional. `Builtin`\s are always loaded.
+There is a :class:`~hooke.plugin.Plugin` subtype
+:class:`~hooke.plugin.Builtin` which is just like a
+:class:`~hooke.plugin.Plugin`, but is considered fundamental enough to
+not be optional. :class:`~hooke.plugin.Builtin`\s are always loaded.
Commands
~~~~~~~~
-:class:`hooke.command.Command`\s specify user-actions in an
+:class:`~hooke.command.Command`\s specify user-actions in an
interface-agnostic manner. This makes writing
-:class:`hooke.ui.UserInterface`\s easier, because you don't need to
-know anything about particular `Plugin`\s or `Command`\s, you just
-need to be able to explain the base classes for you user and then
-speak the language of :mod:`hooke.interaction` and
-:class:`hooke.command.CommandExit` with the
-:class:`hooke.engine.CommandEngine` process.
+:class:`~hooke.ui.UserInterface`\s easier, because you don't need to
+know anything about particular :class:`~hooke.plugin.Plugin`\s or
+:class:`~hooke.command.Command`\s, you just need to be able to explain
+the base classes for you user and then speak the language of
+:mod:`~hooke.interaction` and :class:`~hooke.command.CommandExit` with
+the :class:`~hooke.engine.CommandEngine` process.
Drivers
-------
-:class:`hooke.driver.Driver`\s are responsible for reading assorted
+:class:`~hooke.driver.Driver`\s are responsible for reading assorted
data files into Hooke's Data_ structure.
Data
~~~~~~~~~~~
Force spectroscopy experiments come in several major flavors. Each
-flavor gets its own subclass of :class:`hooke.experiment.Experiment`
-in :mod:`hooke.experiment`. For example, force clamp experiments are
-:class:`hooke.experiment.ForceClamp`. This gives Drivers_ a way to
+flavor gets its own subclass of :class:`~hooke.experiment.Experiment`
+in :mod:`~hooke.experiment`. For example, force clamp experiments are
+:class:`~hooke.experiment.ForceClamp`. This gives Drivers_ a way to
tag experimental data so Commands_ know what they are working with.
Curves
~~~~~~
Experiments_ tags need a data-holding container to tag, and
-:class:`hooke.curve.Curve`\s are that container. Each `Curve` can
-hole several blocks of :class:`hooke.curve.Data` (for example approach
-and retract curves in a :class:`hooke.experiment.VelocityClamp`
-experiment would be seperate blocks). `Curve`\s also have an
-:attr:`~hooke.curve.Curve.info` attribute for persistently storing
+:class:`~hooke.curve.Curve`\s are that container. Each
+:class:`~hooke.curve.Curve` can hole several blocks of
+:class:`~hooke.curve.Data` (for example approach and retract curves in
+a :class:`~hooke.experiment.VelocityClamp` experiment would be
+seperate blocks). :class:`~hooke.curve.Curve`\s also have an
+:attr:`~~hooke.curve.Curve.info` attribute for persistently storing
arbitrary data.
Playlists
~~~~~~~~~
Normally you'll want to analyze multiple Curves_ in one session.
-:class:`hooke.playlist.Playlist`\s provide a convenient container for
-Curves_, and the subclass :class:`hooke.playlist.FilePlaylist` add
+:class:`~hooke.playlist.Playlist`\s provide a convenient container for
+Curves_, and the subclass :class:`~hooke.playlist.FilePlaylist` add
persistant file backing (save, load, etc.).
Utilities
There are a number of general coding features we need for Hooke that
are not provided by Python's standard library. We factor those
-features out into :mod:`hooke.utils`.
+features out into :mod:`~hooke.utils`.
There are also a number of features who's standard library support
-changes with different versions of Python. :mod:`hooke.compat`
+changes with different versions of Python. :mod:`~hooke.compat`
provides a uniform interface to those tools so that Hooke will work
with several Python versions.