diff --git a/Documentation/Doxygen/API/Groups/ModuleAdaptors.dox b/Core/Documentation/Doxygen/Groups/ModuleAdaptors.dox similarity index 99% rename from Documentation/Doxygen/API/Groups/ModuleAdaptors.dox rename to Core/Documentation/Doxygen/Groups/ModuleAdaptors.dox index 87c36285cf..de2854d62b 100644 --- a/Documentation/Doxygen/API/Groups/ModuleAdaptors.dox +++ b/Core/Documentation/Doxygen/Groups/ModuleAdaptors.dox @@ -1,142 +1,139 @@ -namespace mitk -{ /** \defgroup Adaptor Adaptor Classes \ingroup ProcessAdaptor \brief This subcategory includes adaptor classes for the integration of algorithms from other toolkits, especially ITK. The task of most of the classes in this category is to deal with the conversion between the (templated) itk::Image and the (not-templated) mitk::Image. Methods for conversion are provided for both directions: \li \ref MitkToItk \li \ref ItkToMitk Care has to be taken regarding the involved coordinate systems, see \ref ItkToMitkCoordinateSystems. For limitations on ITK-type conversion see the section \ref ModuleAdaptorLimitations. VTK-based access to MITK images is straightforward: simply ask your mitk::Image for a \a vtkImageData by calling Image:GetVtkImageData. Similarily, to get a \a vtkPolyData from the MITK class for storing surfaces, mitk::Surface, call Surface::GetVtkPolyData. \section MitkToItk MITK to ITK adaptors Pixel type and dimension of MITK images can be specified at run time whereas ITK images are templated over the pixel type and the dimension, thus in ITK both need to be specified at compile time. There two different situations, which are covered in the following sub-sections: \li Either you know the pixel type/dimension the ITK image should have at compile time for some reason (e.g., you always create MITK images of a specific pixel type/dimension) \li or the pixel type/dimension of an MITK image is really unkown and the ITK image should have the same (unkown) type. \subsection MitkToFixedItk Converting MITK images to ITK images with known type If you know the type (pixel type and dimension) of the MITK image you have two options: \li mitk::ImageToItk: is a process class that takes an mitk::Image as input and produces an itk::Image of the given type \a TOutputImage as output (to be accessed using \a GetOutput()). In case the MITK image does not have the same type as \a TOutputImage an exception will be thrown. \li mitk::CastToItkImage: this function has two parameters, the mitk::Image (input) and a smartpointer to an itk::Image (output, does not need to be initialized). In case the MITK image does not have the same type as the ITK image it will be casted (if possible; done via itk::CastImageFilter). Thus, mitk::CastToItkImage is the more powerful variant: here it is sufficient that you know what you want to have (the ITK data type), to which the MITK image will be casted, if needed. \subsection MitkToUnkownItk Accessing an MITK image as an ITK image (type unkown) If you do not know the pixel type/dimension of an MITK image in advance and the ITK image should have the same (unkown) type, e.g., to run a filter on the MITK image data, we cannot really convert to one ITK image. This is simply, because we cannot instantiate an itk::Image object with unkown pixel type/dimension. Nevertheless, MITK provides a way to access an MITK image as if it was an ITK image of unkown type. To do so, first define an access method, which is templated as an ITK image is: \code template MyAccessMethod(itk::Image* itkImage) { ... } \endcode If you don't understand this template syntax, we need to refer you to an C++ text book. Understanding template syntax is crucial to successfully using ITK. To call this templated method with an (untemplated) mitk::Image, you can use the #AccessByItk macro (or one of its variants) from mitkImageAccessByItk.h. This macro checks for the actual image type of the mitk::Image and does any neccessary conversions. This works for all configured pixel types (default is char, unsigned char, short, unsigned short, int, unsigned int, float, and double) and dimensions (default is 2 and 3). You can change the considered default pixel types and dimensions by modifying the CMake variables MITK_ACCESSBYITK_*. \code AccessByItk(mitkImage, MyAccessMethod) \endcode An example is given in \ref Step6Page. The AccessBy... macros create quite a lot of code: the user defined access method has to be compiled for all considered pixel types \em times the supported dimensions (default is 2 and 3). Therefore, depending on the complexity of the access method, some compilers may run into problems with memory. One workaround is to use explicit instantiation and distribute it on multiple files. The macro #InstantiateAccessFunction and its variants are for this purpose. An example is again given in \ref Step6Page. Another workaround is to reduce the created code by fixing either the type (#AccessFixedTypeByItk) or dimension (#AccessFixedDimensionByItk). There is one variant of AccessByItk... for passing additional parameters to the access-function, called #AccessFixedTypeByItk_n. \link mitkImage.h \endlink \link mitkImageCast.h \endlink \link mitkImageToItk.h \endlink \link mitkITKImageImport.h \endlink \section ItkToMitk ITK to MITK adaptors Converting ITK images to MITK is easier than the other way round. Basically, you have three options: \li mitk::ITKImageImport: is a process class that takes an itk::Image of the given type \a TOutputImage as input and produces an mitk::Image as output (to be accessed using \a GetOutput()). The image data contained in the itk::Image is referenced, not copied. \li mitk::ImportItkImage: this function takes the itk::Image as input and returns an mitk::Image. Internally, it uses the class just described. So again, the image data contained in the itk::Image is referenced, not copied. \li mitk::CastToMitkImage: this function has two parameters, the itk::Image (input) and a smartpointer to an mitk::Image (output, does not need to be initialized). In contrast to the other described methods, this function copies the image data! \section ItkToMitkCoordinateSystems ITK image vs MITK coordinate systems Converting coordinates from the ITK physical coordinate system (which does not support rotated images) to the MITK world coordinate system should be performed via the Geometry3D of the Image, see mitk::Geometry3D::WorldToItkPhysicalPoint. \section ModuleAdaptorLimitations Limitations The \ref MitkToItk for unspecified types have to do type multiplexing at compile time. This is done for a limited number of pixel types and dimensions, defined during the CMake configuration process. Especially, color image types are not multiplexed. This is because many algorithms do not support color images (e.g. with data type itk::RGBPixel) because they do not have a scalar data type. If your algorithm do support color and you want to multiplex over all scalar as well as the color data type, try the following: \code try { AccessFixedPixelTypeByItk(myMitkImageThatMaybeColor, // The MITK image which may be a color image myAlgorithmFunction, // The template method being able to handle color MITK_ACCESSBYITK_PIXEL_TYPES_SEQ // The default pixel type sequence (itk::RGBPixel) // The additional type sequence ) } catch(const mitk::AccessByItkException& e) { // add error handling here } \endcode */ -} diff --git a/Documentation/Doxygen/API/Groups/ModuleGeometry.dox b/Core/Documentation/Doxygen/Groups/ModuleGeometry.dox similarity index 99% rename from Documentation/Doxygen/API/Groups/ModuleGeometry.dox rename to Core/Documentation/Doxygen/Groups/ModuleGeometry.dox index aa6ca16d8f..988a18d3b3 100644 --- a/Documentation/Doxygen/API/Groups/ModuleGeometry.dox +++ b/Core/Documentation/Doxygen/Groups/ModuleGeometry.dox @@ -1,47 +1,47 @@ namespace mitk { /** \defgroup Geometry Geometry Classes -\ingroup DataManagement +\ingroup Core \brief This subcategory includes the geometry classes, which describe the geometry of the data in space and time. The Geometry3D class holds (see figure) \li a bounding box which is axes-parallel in intrinsic coordinates (often integer indices of pixels), to be accessed by Geometry3D::GetBoundingBox() \li a transform to convert intrinsic coordinates into a world-coordinate system with coordinates in millimeters and milliseconds (floating point values), to be accessed by Geometry3D::GetIndexToWorldTransform() \li a life span, i.e. a bounding box in time in ms (with start and end time), to be accessed by Geometry3D::GetTimeBounds(). The default is minus infinity to plus infinity. \image html ModuleGeometryFig1.png "Geometry: Bounding box and transform" Geometry3D and its sub-classes allow converting between intrinsic coordinates (called index or unit coordinates) and word-coordinates (called world or mm coordinates), e.g. Geometry3D::WorldToIndex. Every data object (sub-)class of BaseData has a Geometry3D, to be more specific, a TimeSlicedGeometry, to be accessed by BaseData::Get TimeSlicedGeometry(). This is because data objects are objects in space and time. The data values are often stored in intrinsic coordinates, e.g., integer pixel/voxel or time indices. The information required to convert these intrinsic coordinates into a physical world coordinate system, with coordinates in millimeters and milliseconds, is stored in Geometry3D class and its sub-classes. TimeSlicedGeometry describes a geometry consisting of several geometries which exist at different times. It contains a list of Geometry3D instances to be accessed by TimeSlicedGeometry::GetGeometry3D(t), with t between 0 and TimeSlicedGeometry::GetTimeSteps().To convert between world-time in milliseconds and the integer timestep-number use mitk:TimeSlicedGeometry:: MSToTimeStep, for conversion in the opposite direction mitk:TimeSlicedGeometry:: TimeStepToMS. Often all Geometry3D instances contained in a TimeSlicedGeometry have the same duration of life. The initialization for this case can be done using TimeSlicedGeometry::InitializeEvenlyTimed(Geometry3D *geometry3D, unsigned int timeSteps). The Geometry3D parameter must have a limited life span set by Geometry3D::SetTimeBounds(). It is used as the first Geometry3D contained in the TimeSlicedGeometry (thus returned by TimeSlicedGeometry:: GetGeometry3D(0)). The next one will start to live immediately at the end of life of the first. The bounding boxes and transformations are copied. The instance of Geometry3D provided to TimeSlicedGeometry::InitializeEvenlyTimed is referenced, not copied! TimeSlicedGeometry is a Geometry3D itself. Its bounding box and transformation is usually the same as the bounding box and transformations of the contained Geometry3D instances. Its life span (to be accessed by TimeSlicedGeometry::GetTimeBounds()) is the span from the beginning of the first contained Geometry3D to the end of the last contained Geometry3D. TimeSlicedGeometry can also contain Geometry3D instances that do not have the same bounding box and transformation. In this case, TimeSlicedGeometry::GetEvenlyTimed() has to be \a false. SlicedGeometry3D is a sub-class of Geometry3D, which descibes data objects consisting of slices, e.g., objects of type Image (or SlicedData, which is the super-class of Image). Therefore, Image::Get TimeSlicedGeometry() will contain a list of SlicedGeometry3D instances. There is a special method SlicedData::GetSlicedGeometry(t) which directly returns a SlicedGeometry3D to avoid the need of casting. Geometry instances referring to images need a slightly different definition of corners, see Geometry3D::SetImageGeometry. This is usualy automatically called by Image. Comparable to TimeSlicedGeometry the class SlicedGeometry3D contains a list of Geometry2D objects describing the slices in the data object. Instead of time steps we have spatial steps here from 0 to GetSlices(). SlicedGeometry3D::InitializeEvenlySpaced (Geometry2D *geometry2D, unsigned int slices) initializes a stack of slices with the same thickness, one starting at the position where the previous one ends. Geometry2D provides methods for working with 2D manifolds (i.e., simply spoken, an object that can be described using a 2D coordinate-system) in 3D space. For example it allows mapping a 3D point on the 2D manifold using Geometry2D::Map. The most important sub-class is PlaneGeometry2D, which describes a planar rectangle. \section ExampleForImage Putting it together for Image Image has a TimeSlicedGeometry, which contains one or more SlicedGeometry3D instances (one for each time step), all of which contain one or more instances of (sub-classes of) Geometry2D (usually PlaneGeometry2D). \deprecated For ITK rev. 3.8 and earlier: Converting coordinates from the ITK physical coordinate system (which did not support rotated images for ITK v3.8 and earlier) to the MITK world coordinate system should be performed via the Geometry3D of the Image, see Geometry3D::WorldToItkPhysicalPoint. As a reminder: Geometry instances referring to images need a slightly different definition of corners, see Geometry3D::SetImageGeometry. This is usualy automatically called by Image. */ //\f$-\infty\f$ to \f$+\infty\f$. } diff --git a/Documentation/Doxygen/API/Groups/ModuleGeometryFig1.png b/Core/Documentation/Doxygen/Groups/ModuleGeometryFig1.png similarity index 100% rename from Documentation/Doxygen/API/Groups/ModuleGeometryFig1.png rename to Core/Documentation/Doxygen/Groups/ModuleGeometryFig1.png diff --git a/Documentation/Doxygen/API/Groups/ModuleMicroServices.dox b/Core/Documentation/Doxygen/Groups/ModuleMicroServices.dox similarity index 100% rename from Documentation/Doxygen/API/Groups/ModuleMicroServices.dox rename to Core/Documentation/Doxygen/Groups/ModuleMicroServices.dox diff --git a/Documentation/Doxygen/API/Groups/ModuleVisualization.dox b/Core/Documentation/Doxygen/Groups/ModuleVisualization.dox similarity index 100% rename from Documentation/Doxygen/API/Groups/ModuleVisualization.dox rename to Core/Documentation/Doxygen/Groups/ModuleVisualization.dox diff --git a/Documentation/Doxygen/API/Groups/ModuleVisualizationMapper.dox b/Core/Documentation/Doxygen/Groups/ModuleVisualizationMapper.dox similarity index 100% rename from Documentation/Doxygen/API/Groups/ModuleVisualizationMapper.dox rename to Core/Documentation/Doxygen/Groups/ModuleVisualizationMapper.dox diff --git a/Documentation/Doxygen/API/Groups/ModuleVisualizationNavigationControl.dox b/Core/Documentation/Doxygen/Groups/ModuleVisualizationNavigationControl.dox similarity index 100% rename from Documentation/Doxygen/API/Groups/ModuleVisualizationNavigationControl.dox rename to Core/Documentation/Doxygen/Groups/ModuleVisualizationNavigationControl.dox diff --git a/Documentation/Doxygen/API/Groups/ModuleVisualizationRenderer.dox b/Core/Documentation/Doxygen/Groups/ModuleVisualizationRenderer.dox similarity index 100% rename from Documentation/Doxygen/API/Groups/ModuleVisualizationRenderer.dox rename to Core/Documentation/Doxygen/Groups/ModuleVisualizationRenderer.dox diff --git a/Documentation/Doxygen/API/Groups/Modules.dox b/Core/Documentation/Doxygen/Groups/Modules.dox similarity index 69% copy from Documentation/Doxygen/API/Groups/Modules.dox copy to Core/Documentation/Doxygen/Groups/Modules.dox index 3185b1b870..8a1f055fd8 100644 --- a/Documentation/Doxygen/API/Groups/Modules.dox +++ b/Core/Documentation/Doxygen/Groups/Modules.dox @@ -1,129 +1,98 @@ /** - \defgroup Core Core Classes + \defgroup Core Core + \ingroup MITKModules - \brief This category includes classes of the MITK Core library. + \brief This category includes classes of the MITK Core module. + + The MITK Core module contains abstractions for common data types and their + geometries, I/O facilities for loading and saving data in various formats, + infrastructures for handling user interaction and undo/redo operations, + GUI toolkit independent visualization classes, and a generic service registry. + + In almost all cases, additional MITK modules will make use of classes contained + in the Core module. */ /** \defgroup Data Data Classes - \ingroup DataManagement + \ingroup Core \brief This subcategory includes the data classes, e.g., for images (mitk::Image), surfaces (mitk::Surface), vessel-trees (mitk::VesselTreeData), etc. Data access classes are only included, if there is no equivalent in itk (see \ref ProcessAndAdaptorClasses "Process and Adaptor Classes" below). */ /** \defgroup IO IO Classes - \ingroup DataManagement + \ingroup Core \brief This subcategory includes the IO classes to read or write data objects. */ /** \defgroup DataStorage Data Storage Classes - \ingroup DataManagement + \ingroup Core \brief This subcategory includes the classes to store and retrieve objects from the mitk::DataStorage */ /** \defgroup ProcessAdaptor Process and Adaptor Classes \ingroup Core - \anchor ProcessAndAdaptorClasses \brief This category includes process (algorithm) classes developed specifically for mitk and (mainly) adaptor classes for the integration of algorithms from other toolkits (currently vtk, itk). The itk adaptor classes are also useful for data access to mitk data objects. */ /** \defgroup Process Process Classes \ingroup ProcessAdaptor \brief This subcategory includes process (algorithm) classes developed specifically for mitk. */ /** \defgroup InteractionUndo Interaction and Undo Classes \ingroup Core \brief This category includes classes that support the developer to create software that allows the user to interact with the data. This includes complex interactions that have multiple states (e.g., moving a handle of an active contour vs changing its local elasicity) and a concept to realize an undo/redo-mechanism. A detailed description of the rationale for these classes can be found in \ref InteractionPage. */ /** \defgroup Interaction Interaction Classes \ingroup InteractionUndo \brief This subcategory includes interaction classes (subclasses of mitk::StateMachine) that change the data according to the input of the user. For undo-support, the change is done by sending an OperationEvent to the respective data object, which changes itself accordingly. A detailed description of the rationale for these classes can be found in \ref InteractionPage. */ /** \defgroup Undo Undo Classes \ingroup InteractionUndo \brief This subcategory includes the undo/redo-specific classes. For undo-support, the change is done by sending an OperationEvent to the respective data object, which changes itself accordingly. A detailed description of the rationale for these classes can be found in \ref InteractionPage. */ - -/** - \defgroup ToolManagerEtAl Classes related to the Segmentation plugin - - \brief A couple of classes related to the Segmentation plugin. See also - \ref QmitkSegmentationTechnicalPage -*/ - -/** - \defgroup Registration Registration - - \brief A couple of classes related to registration. -*/ - -/** - \defgroup RigidRegistration Classes related to rigid registration - \ingroup Registration - - \brief A couple of classes related to rigid registration. -*/ - -/** - \defgroup PointBasedRegistration Classes related to point based registration - \ingroup Registration - - \brief A couple of classes related to point based registration. -*/ - -/** - \defgroup MITKPlugins MITK Plugins - - \brief This group includes all MITK Plugins. -*/ - -/** - \defgroup MITKExamplePlugins MITK Example Plugins - - \brief This group includes all MITK example plugins demonstrating specific framework features. -*/ diff --git a/Documentation/Doxygen/API/Groups/CMakeLists.txt b/Documentation/Doxygen/API/Groups/CMakeLists.txt deleted file mode 100644 index 8b13789179..0000000000 --- a/Documentation/Doxygen/API/Groups/CMakeLists.txt +++ /dev/null @@ -1 +0,0 @@ - diff --git a/Documentation/Doxygen/API/Groups/Modules.dox b/Documentation/Doxygen/API/Groups/Modules.dox index 3185b1b870..7303dff8a3 100644 --- a/Documentation/Doxygen/API/Groups/Modules.dox +++ b/Documentation/Doxygen/API/Groups/Modules.dox @@ -1,129 +1,24 @@ -/** - \defgroup Core Core Classes - - \brief This category includes classes of the MITK Core library. -*/ - -/** - \defgroup Data Data Classes - \ingroup DataManagement - - \brief This subcategory includes the data classes, e.g., for images (mitk::Image), - surfaces (mitk::Surface), vessel-trees (mitk::VesselTreeData), etc. - - Data access classes are only included, if there is no equivalent in itk (see - \ref ProcessAndAdaptorClasses "Process and Adaptor Classes" below). -*/ - -/** - \defgroup IO IO Classes - \ingroup DataManagement - - \brief This subcategory includes the IO classes to read or write data objects. -*/ - -/** - \defgroup DataStorage Data Storage Classes - \ingroup DataManagement - - \brief This subcategory includes the classes to store and retrieve objects from the mitk::DataStorage -*/ - -/** - \defgroup ProcessAdaptor Process and Adaptor Classes - \ingroup Core - \anchor ProcessAndAdaptorClasses - - \brief This category includes process (algorithm) classes developed specifically for mitk and - (mainly) adaptor classes for the integration of algorithms from other toolkits - (currently vtk, itk). - - The itk adaptor classes are also useful for data access to mitk data objects. -*/ - -/** - \defgroup Process Process Classes - \ingroup ProcessAdaptor - - \brief This subcategory includes process (algorithm) classes developed specifically for mitk. -*/ - -/** - \defgroup InteractionUndo Interaction and Undo Classes - \ingroup Core - - \brief This category includes classes that support the developer to create - software that allows the user to interact with the data. - - This includes complex interactions that have multiple states (e.g., moving a handle of an - active contour vs changing its local elasicity) and a concept to realize an undo/redo-mechanism. - - A detailed description of the rationale for these classes can be found in - \ref InteractionPage. -*/ - -/** - \defgroup Interaction Interaction Classes - \ingroup InteractionUndo - - \brief This subcategory includes interaction classes (subclasses of mitk::StateMachine) that change - the data according to the input of the user. - - For undo-support, the change is done by sending an OperationEvent to the respective - data object, which changes itself accordingly. - - A detailed description of the rationale for these classes can be found in - \ref InteractionPage. -*/ - -/** - \defgroup Undo Undo Classes - \ingroup InteractionUndo - - \brief This subcategory includes the undo/redo-specific classes. - - For undo-support, the change is done by sending an OperationEvent to the respective data object, - which changes itself accordingly. - - A detailed description of the rationale for these classes can be found in - \ref InteractionPage. -*/ - /** \defgroup ToolManagerEtAl Classes related to the Segmentation plugin \brief A couple of classes related to the Segmentation plugin. See also \ref QmitkSegmentationTechnicalPage */ /** - \defgroup Registration Registration - - \brief A couple of classes related to registration. -*/ - -/** - \defgroup RigidRegistration Classes related to rigid registration - \ingroup Registration - - \brief A couple of classes related to rigid registration. -*/ - -/** - \defgroup PointBasedRegistration Classes related to point based registration - \ingroup Registration + \defgroup MITKModules MITK Modules - \brief A couple of classes related to point based registration. + \brief This group includes all MITK Modules. */ /** \defgroup MITKPlugins MITK Plugins \brief This group includes all MITK Plugins. */ /** \defgroup MITKExamplePlugins MITK Example Plugins \brief This group includes all MITK example plugins demonstrating specific framework features. */ diff --git a/Documentation/Doxygen/API/Groups/RenderingSequence.png b/Documentation/Doxygen/API/Groups/RenderingSequence.png deleted file mode 100644 index 5e5a64bb21..0000000000 Binary files a/Documentation/Doxygen/API/Groups/RenderingSequence.png and /dev/null differ diff --git a/Documentation/Doxygen/API/Groups/RenderingSequence.vsd b/Documentation/Doxygen/API/Groups/RenderingSequence.vsd deleted file mode 100644 index 6a6e7ab060..0000000000 Binary files a/Documentation/Doxygen/API/Groups/RenderingSequence.vsd and /dev/null differ diff --git a/Documentation/Doxygen/API/Groups/dialogbarSlicer.png b/Documentation/Doxygen/API/Groups/dialogbarSlicer.png deleted file mode 100644 index 839a4d94be..0000000000 Binary files a/Documentation/Doxygen/API/Groups/dialogbarSlicer.png and /dev/null differ diff --git a/Documentation/Doxygen/API/Groups/dialogbarStandardViews.png b/Documentation/Doxygen/API/Groups/dialogbarStandardViews.png deleted file mode 100644 index 570003ecfc..0000000000 Binary files a/Documentation/Doxygen/API/Groups/dialogbarStandardViews.png and /dev/null differ diff --git a/Documentation/Doxygen/API/Groups/dialogbarStereoOptions.png b/Documentation/Doxygen/API/Groups/dialogbarStereoOptions.png deleted file mode 100644 index 0440c2a04d..0000000000 Binary files a/Documentation/Doxygen/API/Groups/dialogbarStereoOptions.png and /dev/null differ diff --git a/Documentation/Doxygen/API/Groups/dialogbarbuttons.png b/Documentation/Doxygen/API/Groups/dialogbarbuttons.png deleted file mode 100644 index 5626290498..0000000000 Binary files a/Documentation/Doxygen/API/Groups/dialogbarbuttons.png and /dev/null differ diff --git a/Documentation/Doxygen/API/Groups/functionalityButtons.png b/Documentation/Doxygen/API/Groups/functionalityButtons.png deleted file mode 100644 index dfb7b1bf83..0000000000 Binary files a/Documentation/Doxygen/API/Groups/functionalityButtons.png and /dev/null differ diff --git a/Documentation/Doxygen/API/Groups/renderwindowOptions.png b/Documentation/Doxygen/API/Groups/renderwindowOptions.png deleted file mode 100644 index 08c1eda9b5..0000000000 Binary files a/Documentation/Doxygen/API/Groups/renderwindowOptions.png and /dev/null differ diff --git a/Documentation/Doxygen/API/Groups/renderwindows.png b/Documentation/Doxygen/API/Groups/renderwindows.png deleted file mode 100644 index 6d781311c8..0000000000 Binary files a/Documentation/Doxygen/API/Groups/renderwindows.png and /dev/null differ diff --git a/Documentation/Doxygen/API/Groups/undoredobutton.png b/Documentation/Doxygen/API/Groups/undoredobutton.png deleted file mode 100644 index 16cc086f8b..0000000000 Binary files a/Documentation/Doxygen/API/Groups/undoredobutton.png and /dev/null differ diff --git a/Documentation/Doxygen/ModuleDataManagementClasses.dox.template b/Documentation/Doxygen/ModuleDataManagementClasses.dox.template deleted file mode 100644 index e3a706d3fc..0000000000 --- a/Documentation/Doxygen/ModuleDataManagementClasses.dox.template +++ /dev/null @@ -1,93 +0,0 @@ -/** - \defgroup DataManagement Data Management Classes - - \brief This category includes the data classes themselves as well as management classes to organize the - data during run-time in a tree structure. - - Available sections: - - \ref overview - - \ref inthisgroup - - \ref notinthisgroup - - \ref seealso - - \ref future - - \ref changes - - \section overview Rationale and overview - - kurze Zusammenfassung - -Ich bin Blindtext. Von Geburt an. Es hat lange gedauert, bis ich begriffen habe, -was es bedeutet, ein blinder Text zu sein: Man macht keinen Sinn. Man wirkt hier -und da aus dem Zusammenhang gerissen. Oft wird man gar nicht erst gelesen. - -Aber bin ich deshalb ein schlechter Text? Ich weiss, dass ich nie die Chance -haben werde, im Stern zu erscheinen. Aber bin ich darum weniger wichtig? -Ich bin blind! Aber ich bin gerne Text. Und sollten Sie mich jetzt tatsaechlich zu -Ende lesen, dann habe ich etwas geschafft, was den meisten "normalen" Texten nicht -gelingt. - -Übrigens: lieber ü statt ü schreiben. und & und ß Und noch besser einfach englisch ohne Umlaute. - -\em Ein \e Code-Block -\code -#include - -class QUndoRedoButtonPlugin : public QWidgetPlugin -{ -public: - QUndoRedoButtonPlugin(); - - QStringList keys() const; - QWidget* create( const QString &classname, QWidget* parent = 0, const char* name = 0 ); - QString group( const QString& ) const; - QIconSet iconSet( const QString& ) const; - QString includeFile( const QString& ) const; - QString toolTip( const QString& ) const; - QString whatsThis( const QString& ) const; - bool isContainer( const QString& ) const; -}; -\endcode - -Ein \c Verbatim-Absatz: - - -cd /src - cvs -d :pserver:anonymous@mbi.dkfz-heidelberg.de:/usr/local/cvsroot login
-cvs -d :pserver:anonymous@mbi.dkfz-heidelberg.de:/usr/local/cvsroot co mitk - - -Und noch ein Bild: - -\image html step4a_result.png "Bildunterschrift" -\image latex step4a_result.png "Bildunterschrift" - -Eine kleine Aufzählung: - -\li \ref Step4.cpp "Step4.cpp"\n -Contains the code of step 4a + b. -\li \ref Step4.cpp "Step4.cpp"\n -Contains the code of step 4a + b. -\li \ref Step4.cpp "Step4.cpp"\n -Contains the code of step 4a + b. - - - \subsection inthisgroup What belongs into this group - Beispiel - \subsection notinthisgroup What belongs not into this group - evtl. Gegenbeispiel - - - \section seealso See also - - \ref DataManagement, - \ref Geometry - - \section future Plans for the future - - \section changes Major changes since version x - - wenns denn mal zutrifft - -*/ - -