Change naming convention for C++ interfaces

[alexxy/gromacs.git] / docs / doxygen / lib / wrapperbinary.md

diff --git a/docs/doxygen/lib/wrapperbinary.md b/docs/doxygen/lib/wrapperbinary.md
index 98f6fcc50d49f3488f91e2da8c77c78866297619..23f7ba16cb0561918326318edd4467aeff45a7d0 100644 (file)
--- a/docs/doxygen/lib/wrapperbinary.md
+++ b/docs/doxygen/lib/wrapperbinary.md
@@ -29,14 +29,14 @@ Command line modules
 ====================
 
 All modules within the wrapper binary are implemented as classes that implement
-the gmx::CommandLineModuleInterface interface.  There is generally some helper
+the gmx::ICommandLineModule interface.  There is generally some helper
 class in between:
  * General C++ modules typically use gmx::Options for their command-line
    handling.  Instead of each module implementing parsing and help separately
-   with identical code, they implement gmx::CommandLineOptionsModuleInterface
+   with identical code, they implement gmx::ICommandLineOptionsModule
    instead.  The framework then provides a bridge class that contains the
-   common code and wraps gmx::CommandLineOptionsModuleInterface into a
-   gmx::CommandLineModuleInterface.
+   common code and wraps gmx::ICommandLineOptionsModule into a
+   gmx::ICommandLineModule.
  * For C++ trajectory analysis modules, there is a general implementation for
    running the gmx::TrajectoryAnalysisModule subclasses in cmdlinerunner.cpp.
  * For old C-style %main() functions, see \ref section_wrapperbinary_cmain.
@@ -75,7 +75,7 @@ line manager throws away all the other arguments before passing control to the
 module.
 
 After the above translations, the internal help module handles all the help
-output.  All the help is organized into a hierarchy of gmx::HelpTopicInterface
+output.  All the help is organized into a hierarchy of gmx::IHelpTopic
 instances.  The help module internally creates a root help topic that is
 printed with `gmx help`.  If there are additional words after the `gmx help`
 command, then those are taken to specify the topic to show in the hierarchy.
@@ -83,7 +83,7 @@ command, then those are taken to specify the topic to show in the hierarchy.
 gmx::CommandLineModuleManager internally creates a help topic for each added
 module.  These topics are shown when `gmx help` _module_ is invoked.
 They forward the request to the actual module (to
-gmx::CommandLineModuleInterface::writeHelp()).
+gmx::ICommandLineModule::writeHelp()).
 
 In addition to the topics created internally, gmx::CommandLineModuleManager
 provides methods to add additional help topics.  Currently, this is used to
@@ -104,7 +104,7 @@ of which targets to use for generating the documentation..
 If this option is set, the help module loops through all the modules in the
 binary, writing help for each into a separate file.  The help module writes
 common headers and footers, and asks the actual module to write the
-module-specific content (with gmx::CommandLineModuleInterface::writeHelp(),
+module-specific content (with gmx::ICommandLineModule::writeHelp(),
 using a different help context than for console output).
 
 Additionally, a list of all the modules is generated (`gromacs.7` for man