There are eight directories on the top level, each containing several sub-directories that contain the implementation. Thus, as far as code is concerned, the depth of the directory structure is limited to two. Classes in a sub-directory may reference classes in other sub-directories on the same level and in sub-directories that have already been mentioned, when you the following list from top to bottom:
- DataStructures: contains sub-directories with data classes. Besides the actual data storage classes, the same sub-directory may contain functions inherently associated to the data storage class in the sense of object-oriented programming. For example a container class may include methods like add, remove, addSorted (add and keep the container sorted), and comparison operators. Classes in a directory may reference classes in other data-directories, but not in any of the other seven directories at the top level.
- Algorithms: contains sub-directories with algorithms, which may reference other algorithms and data-structures.
- Controllers: contains sub-directories with controllers. Controllers are invisible data management classes. An (non-exclusive!) example are controllers in the sense of the model-view-controller design-pattern. Controllers may reference other controllers, algorithms and data-structures.
- Rendering: contains sub-directories with rendering classes, e.g. mitk-mappers. Rendering classes may be graphics library dependent (e.g. OpenGL or vtk), but are GUI-toolkit independent (independent from Qt, FLTK, etc.). They produce output within a widget provided to them. Other classes within sub-directories of Rendering and all above mentioned directories my be referenced.
- Interactions: contains sub-directories with interaction classes, which may reference other interactions and all above mentioned directories.
- AppModule: contains sub-directories with classes creating a (part of a) GUI, which can be used within applications. This includes widgets and combinations of widgets and other AppModules. Classes in all directories except the Functionalities and Application directory may be referenced.
- Functionalities: contains sub-directories with functionalities. A functionality combines a main-widget area with a control widget area and an icon/menu-entry/description. Functionalities may include other functionalities. Classes in all directories except the Application directory may be referenced.
- Applications: Each directory includes the files required for at least one application. Classes in all directories may be referenced. In future, this directory may be moved to a separate cvs-repository.
Naming Conventions
If the classes within a sub-directory are implemented according to the mechanisms or on basis of a toolkit, the name of the sub-directory should start with the acronym of the toolkit. For example, if a registration algorithm uses itk, a reasonable directory name is itkRegistration. The classes within the directory need not be in the namespace of the toolkit (as in the case of itk-using classes), but they may, as in the case of directories containing mitk-core-classes. Typical acronyms are mitk, itk, vtk, ip and Qmitk (following the Qt-Naming Guidelines).
Naming Conventions
If a file contains a class that is within a namespace, the file name must begin with the namespace name, e.g. mitkImage.h and mitkImage.cpp contain the class mitk::Image. Namespace names are normally identical to toolkit acronyms. Consequently, name of the directory will begin with the acronym according to the previous section.
Conventions
Files created during compilation should be stored in a separate directory tree parallel to the source tree (e.g. mitkBinary). For mitk, cmake should be used.
1.7.2
