diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step10.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step10.dox index 9cd8829c24..ea9e4d01e8 100644 --- a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step10.dox +++ b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step10.dox @@ -1,499 +1,501 @@ /** \page Step10Page MITK Tutorial - Step 10: Adding new Interaction \tableofcontents \section HowToUseDataInteractor Step 01 - How to use an existing DataInteractor in your Module/Plugin/... MITK provides finished DataInteractors for a variety of tasks, they can be found in Core/Code/Interactions. They can be used with state machine patterns and config files located under Core/Code/Resources/Interactions. A mitk::DataInteractor consists of four parts. The class describing the functionality and two XML files; one describes the state machine pattern, that is the workflow of an interaction and the second describes the user events which trigger an action. Lastly every mitk::DataInteractor works on a mitk::DataNode in which it stores and manipulates data. To use a mitk::DataInteractor these parts have to be brought together. ** TODO add code of mitk::PointSetDataInteractor Plugin .. This code demonstrates the use of an existing mitk::DataInteractor exemplary for the mitk::PointSetDataInteractor: First we need a mitk::DataNode in which the PointSets is stored. It has to be added to the mitk::DataStorage. \code mitk::DataNode::Pointer dataNode = mitk::DataNode::New(); GetDataStorage()->Add(dataNode.GetPointer()); \endcode Then we create an instance of a mitk::PointSetDataInteractor and load a predefined statemachine pattern as well as a configuration for it: \code m_CurrentInteractor = mitk::PointSetDataInteractor::New(); m_CurrentInteractor->LoadStateMachine("PointSet.xml"); m_CurrentInteractor->SetEventConfig("PointSetConfig.xml"); \endcode Lastly the mitk::DataNode is added to the mitk::DataInteractor \code m_CurrentInteractor->SetDataNode(dataNode); \endcode now the mitk::DataInteractor is ready for usage. \section HowToModifyInteraction Step 02 - How to modify the behaviour of a DataInteractor The behavior of a mitk::DataInteractor is determined by two aspects. One, the state machine pattern which describes the flow/order of actions that are performed. Secondly the configuration which determines which user interaction triggers the actions. \subsection ModifyDisplayInteractorBehavior How to modify the display interactor behavior Sometimes it may be desirable to change the behaviour of the mitk::DisplayInteractor which controls zooming, panning and scrolling, e.g. when a Tool is activated that reacts to the same events. Changing the behavior of the DisplayInteractor (or possibly any other EventHandler) can be achieved from anywhere in the code by requesting the InteractionEventObserver and assigning an alternative configuration to it, as demonstrated in this example: \code std::ifstream* configStream = new std::ifstream( #path to alternative configuration file# ); mitk::EventConfig newConfig(configStream); // Requesting all registered EventObservers std::list listEventObserver = GetModuleContext()->GetServiceReferences(); for (std::list::iterator it = listEventObserver.begin(); it != listEventObserver.end(); ++it) { DisplayInteractor* displayInteractor = dynamic_cast(GetModuleContext()->GetService(*it)); // filtering: only adjust the DisplayInteractor if (displayInteractor != NULL) { displayInteractor->SetEventConfig(newConfig); } } \endcode \section SectionImplementationDataInteractor How to implement a new DataInteractor This second part of the tutorial step goes beyond the activation of an interactor, that modifies data by user interaction) as shown above. It shows what needs to be implemented to add a new way of interaction within your MITK application. Please see \ref DataInteractionPage as an introduction to the MITK interaction mechanism. This tutorial is structured as follows: The first section deals with config files, describing all the parameters of events and how to use them in a configuration file. In the second section the basics are described that are needed to write a state machine pattern. The last section deals with brining configuration, state machine pattern and code together and gives an exemplary implementation of a mitk::DataInteractor. \section ConfigFileDescriptionSection How to create a Config-File \subsection EventDescriptionSection Event Description Events are described by their parameters. Each event type has its own set of parameters that can be set in the configuration file. If a parameter is omitted it is set to its default value. All possible parameters are listed and described below. Event parameters are also described in the documentation of the event class itself. Mandatory for each event description is the event class and the event variant. The parameters of an event are set by attribute tags. \note Refer to \ref EventClassSection for the meaning of event class. \b Mouse \b Buttons \n mitk::InteractionEvent::MouseButtons represent the buttons. They can be used for two attributes. First the EventButton attribute which describes the button that triggered the event, this always is a single button. Secondly the ButtonState attribute that describes which buttons were pressed at the moment the event has been generated. For example assume the right mouse button and the middle mouse button are already pressed, now the left mouse button is pressed too and generates a second event, this would be described as follows: \code \endcode Note: Technically the LeftMouseButton is also pressed and should be listed in the ButtonState, but this is taken care of by the mitk::EventFactory . Key Events \n mitk::InteractionKeyEvent represents a pressed key, which key is pressed is provided with the Key attribute like this \code \endcode or \code \endcode \note Key Events do not require an explicit configuration, for all key events there exists a predefined event variant with the name 'Std' + value, that is key a is named 'StdA'. The names for special keys are listed here: \dontinclude mitkInteractionEvent.h \skipline // Special Keys \until // End special keys Modifier Keys \n mitk::InteractionEvent::ModifierKeys represent the combination of pressed modifier keys, several modifier keys pressed at the same time are denoted by listing them all separated by commas. \code \endcode \b ScrollDirection \n This attribute is unique to the mitk::MouseWheelEvent and describes the direction in which the mouse wheel is rotated. In the event description actual only the direction is provided, but the event is generated with the actual value, and this value can be retrieved from the object. \code \endcode \subsection ExamplesSection Examples Examples for key events: \code \endcode Examples for MousePress events: \code \endcode There exists a standard configuration file for the most common events called GlobalConfig.xml that can be used to as a default and can be extended by a specific definition. \subsection ParameterDescriptionSection Parameter Description It is also possible to store parameters in the config file. Those are stored using the param-tag, like this: \code \endcode Within the application these properties can then be access via a mitk::PropertyList like this: \code // sm - state machine loaded with config file example2 mitk::PropertyList::Pointer properties = GetAttributes(); std::string prop1; properties->GetStringProperty("property1",prop1); \endcode \section HowToStateMachine HowTo Write a State Machine A state machine pattern is described in a XML file. \subsection StateSection States States are described using the state-tag. Each state has to have a name. Exactly one state has to be a start state in each state machine to indicate the state in which the state machine is set when it is constructed. So a valid, but rather useless state machine would like like this: \code \endcode Optionally a state can be assigned a special mode that influences the event distribution. These modes are GRAB_INPUT , PREFER_INPUT and REGULAR (where REGULAR is default and does not need to be indicated). See \ref DataInteractionTechnicalPage_DispatcherEventDistSection for a description of these modes. Use the special modes only when necessary as they prevent other DataInteractors to receive events. \code \endcode \subsection TransitionSection Transitions + Transitions are part of a state and describe all possible state switches, and are therefore important for modeling an interaction scheme. Transitions consist a part that describes the event which triggers the transition (event class and event variant) and a target which is state to which the state machine switches after executing a transition. An event class describes the event type (see mitk::InteractionEvent for the different classes) and the event variant is a specification thereof and the exact description is taken from a config file. Together they determine which event can trigger this transition. For example this state machine will switch from state A to state B when the StdMousePressPrimaryButton event (left mouse button is pressed) occurs. -\subsubsection EventClassSection Event Class +\subsection EventClassSection Event Class + The event class description supports the polymorphism of the event classes. Therefore state machine patters should be written in the most general ways possible. So for a given class hierarchy like this: \dot digraph { node [shape=record, fontname=Helvetica, fontsize=10]; a [ label="{InteractionPositionEvent}"]; b [ label="{MousePressEvent}" ]; c [ label="MouseReleaseEvent" ]; d [ label="TouchEvent", style=dotted ]; a -> b; a -> c; a -> d; } \enddot in the state machine pattern the mitk::InteractionPositionEvent can be declared as event class to restrict to the events which hold a position information. The actual implementation is then given in the configuration file. In this case it allows to define events of the classes mitk::InteractionPositionEvent itself, or mitk::MousePressEvent, mitk::MouseReleaseEvent, mitk::TouchEvent. This has the advantage that the patterns remain the same no matter what input devices are used, and the state machine patterns can be configured for newly added event classes as long as they match the class hierarchy (this ensures they hold the necessary properties). \code \endcode \subsection ActionSection Actions Actions can be added to transitions and represent functions in the mitk::DataInteractor that are executed on taking a transition. The following simple state machine will listen for left mouse clicks and execute two actions (and actually never stop). \code \endcode In order to tell the mitk::DataInteractor which function to execute these actions are made known to the mitk::DataInteractor using the CONNECT_FUNCTION macro. This example assumes that there exists an ExampleInteractor which inherits from mitkDataInteractor. This class implements the functions AddPoint and CountClicks. The actions are introduced by implementing the virtual method ConnectActionsAndFunctions(): \code void mitk::ExampleInteractor::ConnectActionsAndFunctions() { CONNECT_FUNCTION("addPoint", AddPoint); CONNECT_FUNCTION("countClicks", CountClicks); } \endcode \subsection ConditionSection Conditions Conditions can be added to transitions and represent functions in the mitk::DataInteractor that are executed on taking a transition. A condition is used to determine if a following action should be executed or not. \code \endcode In order to tell the mitk::DataInteractor which function to execute these conditions are made known to the mitk::DataInteractor using the CONNECT_CONDITION macro. The ConnectActionsAndFunctions() method has to be augmented accordingly: \code void mitk::ExampleInteractor::ConnectActionsAndFunctions() { CONNECT_CONDITION("checkPoint", CheckPoint); CONNECT_FUNCTION("addPoint", AddPoint); CONNECT_FUNCTION("countClicks", CountClicks); } \endcode \section ReferenceToIncludeFiles Integration of the pattern and configuration files The usage of custom files slightly differs from the existing ones. Custom pattern and config files have to be stored in the /Resources/Interactions directory of the Module that they were designed for. When loading files from a module location into an interactor, the module has to be supplied as a parameter: \code m_CurrentInteractor = mitk::CustomDataInteractor::New(); m_CurrentInteractor->LoadStateMachine("CustomStateMachinePattern.xml", us::GetModuleContext()->GetModule()); m_CurrentInteractor->SetEventConfig("CustomConfig.xml", us::GetModuleContext()->GetModule()); \endcode See \ref IncludeFiles for a description. \section HowToDataInteractor Implementation of a new mitk::DataInteractor DataInteractors are to inherit from mitk::DataInteractor. Their functionality is implemented in functions that follow this interface: For Actions: \code bool SomeFunctionality(StateMachineAction* , InteractionEvent*); \endcode For Conditions: \code bool SomeFunctionality(const InteractionEvent*); \endcode Your functions are connected with actions and conditions by implementing the function ConnectActionsAndFunctions(), e.g. \code void mitk::ExampleInteractor::ConnectActionsAndFunctions() { CONNECT_CONDITION("checkPoint", CheckPoint); CONNECT_FUNCTION("addPoint", AddPoint); CONNECT_FUNCTION("enoughPoints", EnoughPoints); } \endcode Now all that is left is to write a state machine pattern and a config file as is described in the tutorials. To provide a useful example the mitk::PointSetDataInteractor is annotated with comments that describe the important parts for an implementation of a mitk::DataInteractor. This step assumes knowledge of the Interaction concept described in \ref DataInteractionPage and some background of the implementation. Please refer to these pages before proceeding. Now all that is left it to write a state machine pattern and a config file as is described in the tutorials. \subsection ExampleInternalEvent Example Interactor using InternalEvent A useful tool in creating DataInteractors is mitk::InternalEvent which allows the mitk::DataInteractor to send signals on its own. The following will describe how to build a mitk::DataInteractor that allows to add points until a certain number of points is reached. The number of accepted points is provided in the config file as a parameter. So we start by writing a state machine pattern that add points until it receives an mitk::InternalEvent telling it, that enough points have been added. \code <--! dead state, nothing happens any more, once we reached this --> \endcode In our config file we set the number of maximal points to 10, and define AddPointClick as a right mouse click with the ctrl button pressed. \code \endcode The implementation is described in the following. \see Step10.h \see Step10.cpp \dontinclude Step10.h Implementation of protected functions: \skipline protected: \until virtual void ConfigurationChanged(); ConnectActionsAndFunctions - Is inherited from mitk::InteractionStateMachine, here action strings from the xml are connected with functions in the mitk::DataInteractor (as seen above). In our example this looks like this: \dontinclude Step10.cpp \skipline void mitk::ExampleInteractor::ConnectActionsAndFunctions() \until } ConfigurationChanged - Is called whenever a new configuration file is loaded (by the mitk::InteractionEventHandler super class), this function allows to implement initialization code that depends on configuration values. In our example we want to set the limit of allowed points: \dontinclude Step10.cpp \skipline void mitk::ExampleInteractor::ConfigurationChang \until } Next the actual functionality of the DataInteractor is implemented, by providing one function per action, following this prototype described before. \dontinclude Step10.h \skipline private: \until bool CheckPoint(cons \dontinclude Step10.cpp \skipline bool mitk::ExampleInteractor::AddPoint(StateM \until //- If the conditions returns false the calling transition and the included actions will not be executed. If a condition fails the event is considered as untreated, and will be offered to other Interactors. \dontinclude Step10.cpp \skipline bool mitk::ExampleInteractor::CheckPoint( \until //end Here we see an internal event used to signal that the point set reached the maximal number of allowed points. The event is created and added to the Dispatchers event queue. \dontinclude Step10.cpp \skipline // create internal \until positionEvent->GetSender( \note Internal events do not need any mapping to event variants. Their signal name is equivalent with the event variant. There are also two documented classes implementing a mitk::DataInteractor and a mitk::InteractionEventObserver which can be looked at for further understanding: \see mitk::PointSetDataInteractor \see mitk::DisplayInteractor Have fun with creating your own interaction and please think about contributing it to MITK! If you meet any difficulties during this step, don't hesitate to ask on the MITK mailing list mitk-users@lists.sourceforge.net! People there are kind and will try to help you. \ref Step09Page "[Previous step]" \ref TutorialPage "[Main tutorial page]" */ diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/SettingUpMITK/HowToNewProject.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/SettingUpMITK/HowToNewProject.dox index ca78ac4728..7bb8ca2707 100644 --- a/Documentation/Doxygen/3-DeveloperManual/Starting/SettingUpMITK/HowToNewProject.dox +++ b/Documentation/Doxygen/3-DeveloperManual/Starting/SettingUpMITK/HowToNewProject.dox @@ -1,254 +1,254 @@ /** \page HowToNewProject Creating a new MITK project \tableofcontents This page is intended to give a comprehensive guide to setting up your own MITK based project. It will use the application framework provided by MITK and is probably the preferred way for most users. The first part of this document is a tutorial aimed at newcomers to MITK and possibly %CMake and tries to give as much help as possible on setting up your own project. If you are looking for more technical information about customizing MITK, the structure of the superbuild or packaging you might want to read the \ref HowToNewProjectAdvancedInformation. If you have set up your MITK project already and want to start developing you could take a look at \ref TutorialPage. \section HowToNewProjectGettingStarted Getting Started To bootstrap your project MITK offers two convenient options:
  1. Use the MITK Plugin Generator, a command line tool used to generate a customized MITK project and/or MITK plug-ins.
  2. Use the MITK project template as an example project.
Both options will provide you with a project which contains a "superbuild" mechanism to automatically download, configure, and build MITK as a dependency of your own project. The MITK Plugin Generator generates code using the supplied command line arguments, whereas the MITK project template needs immediate modifications to customize it to your naming schemes. However, the project template will potentially contain more code demonstrating features of MITK. \note Using the MITK Plugin Generator is recommended for beginners. \section HowToNewProjectPrerequisites Prerequisites What ever option you choose, a MITK-based project needs essentially the same prerequisites as MITK itself. Please see \ref BuildInstructions_Prerequisites for details. \note If you use one of the two options above you will \b not \b need to build MITK yourself. This will be done automatically. \section HowToNewProjectCreatingSourceDir Preparing your source directory In order to start developing with MITK, you first have to set up the source directory for your project. \subsection HowToNewProjectSourceUsingGenerator Using the MITK Plugin Generator The usage of the Plugin Generator for creating a new project is described in \ref NewPluginWithProject, please have a look there. \subsection HowToNewProjectSourceUsingTemplate Using the MITK Project Template Download the project as a tarball or zipball and extract it to your desired source directory. \note This is a template. You must modify it such that it fits the needs of your particular project. Especially you should do a global search and replace for the string "awesome" to rename the template application and plug-in. You may want to rename some files too. \section HowToNewProjectGeneratingCMake Generating your binary with CMake After you have set up your source directory you can proceed to generate your binary directory using %CMake. Depending on your operating system and preferences you might want to use "cmake-gui" or "ccmake" (shell). This document assumes you are using cmake-gui.
  1. Start "cmake-gui" and enter your source (e.g. "D:\AwesomeProject") and binary directory (e.g. "D:\AwesomeProject-superbuild").
  2. Upon first pressing "Configure" you will be prompted to select your generator. This determines what project files will be generated by %CMake. Set this to the development tool you are intending to use (e.g. "Visual Studio 2010 64Bit" or "linux makefiles".
  3. Press "Configure" until no new variables appear and then "Generate". Now all project files have been generated into your binary directory.
  4. Double-check that the right Qt version is used.
Now you are ready to compile your code. Depending on your choice of tool this will be done differently, we cover two possibilities here. \subsection HowToNewProjectCompilingLinuxMakefiles Compiling using linux makefiles
  1. In the shell, switch to your binary directory.
  2. type "make" and hit enter
\subsection HowToNewProjectCompilingVisualStudio Compiling using visual studio We assume your application is called "AwesomeApp" and your project "AwesomeProject" and your binary directory is "D:\AwesomeProject-superbuild\". Replace names and paths accordingly.
  1. Close %CMake and open "D:\AwesomeProject-superbuild\AwesomeProject-superbuild.sln". Your Visual Studio should appear and by pressing F7 you start the compilation. This will clone the MITK source code, build it, and then start building your own project.
  2. After the superbuild compilation has finished, close the superbuild solution file and start the build solution file "D:\AwesomeProject-superbuild\AwesomeProject-build\AwesomeProject.sln"
  3. Set the "AwesomeApp" project as start-up project (right click > "Set as StartUp Project") and press "F5" to start your MITK AwesomeApp.
\note Just opening AwesomeProject.sln from your explorer by double-cliking won`t allow you to start or debug your application because the required environment variables would be missing. Use the supplied batch files or set your PATH variable accordingly. \section HowToNewProjectAddingMITKFunctionality I want to use some MITK plugin but it is not available Due to the sheer number of MITK plugins not every plugin is activated by default. To activate a specific plugin (again replace paths as needed):
  1. Start "cmake-gui" and set the binary directory to "D:\AwesomeProject-superbuild\MITK-superbuild\MITK-build\", the source will adjust automatically and you will see new settings appear.
  2. Navigate to the plugin you want to use (e.g. "MITK_BUILD_org.mitk.gui.qt.segmentation") and tick the checkbox behind it
  3. Press "Configure" until no new variables appear and then "Generate".
  4. Build MITK using your development tool (as in \ref HowToNewProjectCompilingLinuxMakefiles or \ref HowToNewProjectCompilingVisualStudio only in the "D:\AwesomeProject-superbuild\MITK-superbuild\MITK-build\" directory )
  5. Start "cmake-gui" and set the binary directory to "D:\AwesomeProject-superbuild\AwesomeProject-build\", the source will adjust automatically and you will see new settings appear.
  6. Press "Configure" until no new variables appear and then "Generate".
  7. Build your project
  8. Start your application
\note If you want to use an application provided by MITK (e.g. MITK Workbench) you have to tick the appropriate checkbox as well (in this case MITK_BUILD_APP_Workbench) and build MITK. Do note, that this application will be located in the bin directory of the "D:\AwesomeProject-superbuild\MITK-superbuild\MITK-build\" folder. \section HowToNewProjectAdvancedInformation Information for advanced users \subsection HowToNewProjectCustomizingMITK Customizing MITK The %CMake scripts from the Plugin Generator of the project template provide some handy options which allow you to customize the MITK build used in your project. You can either inject an already build MITK to be used by your project or configure some MITK options directly in your project's superbuild configuration if MITK is going to be build inside your project. -\subsubsection HowToNewProjectCustomizingMITKInjectMITK Inject a MITK build +\subsection HowToNewProjectCustomizingMITKInjectMITK Inject a MITK build By setting the \b EXTERNAL_MITK_DIR \b variable in your project's superbuild %CMake configuration to a MITK build directory (containing the MITKConfig.cmake) you can skip the MITK build process. If MITK is the only external project in your project, you might want to disable the superbuild of your project completely (set _USE_SUPERBUILD to OFF or edit your CMakeLists.txt file to set it to OFF by default) and set the \b MITK_DIR \b %CMake variable to your MITK build directory. -\subsubsection HowToNewProjectCustomizingMITKConfigure Configure the MITK superbuild +\subsection HowToNewProjectCustomizingMITKConfigure Configure the MITK superbuild If MITK is being build inside your project's superbuild process, you can enable the use of certain third-party libraries inside of MITK. The following variables control the MITK configuration:
  • \b MITK_USE_BLUEBERRY Enable the use of the BlueBerry application framework
  • \b MITK_USE_CTK Download, compile, and use CTK in MITK
  • \b MITK_USE_DCMTK Download, compile, and use DCMTK in MITK
  • \b MITK_USE_OpenCV Download, compile, and use OpenCV in MITK
  • \b MITK_USE_Python3 Download and compile 1CableSwig and enable Python wrapping in ITK, VTK, OpenCV, and MITK
  • \b MITK_USE_Qt5 Use the Qt 5 framework in MITK
You can also inject already build third-party libraries from inside your project's superbuild in the MITK superbuild by using any of the following %CMake variables:
  • \b MITK_CTK_DIR Reuse a CTK build directory in MITK.
  • \b MITK_CableSwig_DIR Reuse a 1CableSwig build directory in MITK.
  • \b MITK_DCMTK_DIR Reuse a DCMKT build directory in MITK.
  • \b MITK_GDCM_DIR Reuse a GDCM build directory in MITK.
  • \b MITK_ITK_DIR Reuse a ITK build directory in MITK.
  • \b MITK_OpenCV_DIR Reuse a OpenCV build directory in MITK.
  • \b MITK_VTK_DIR Reuse a VTK build directory in MITK.
If the corresponding \b MITK_USE_ \b option is set to on, the MITK superbuild will use the provided build directory instead of building the project itself. You can also control the source code location for MITK in your project's superbuild configuration by using the following %CMake variables:
  • \b MITK_SOURCE_DIR The path to the MITK source directory. If the value for this variable is non-empty, the variables below are ignored.
  • \b MITK_GIT_REPOSITORY The Git repository containing the MITK source code.
  • \b MITK_GIT_TAG The hash id, tag or branch name used for a checkout from MITK_GIT_REPOSITORY.
-\subsubsection HowToNewProjectProjectStructure Project Structure +\subsection HowToNewProjectProjectStructure Project Structure If you are using the superbuild feature of the generated project (the default), you might want to familiarise yourself with the layout of your build tree. The top-level build directory which you specified in %CMake when configuring your project will contain all the required dependencies. Suppose we call our project MyProject and the build directory is "C:\MyProject-superbuild". Then the layout looks something like this: MyProjectLayout.png The top-level directory contains the source code and the build directories from the dependencies of your project. In the current case, the only dependency of MyProject is MITK, which in turn has downloaded and built its own dependencies (CTK, DCMTK, ITK, etc.). The "real" build tree for your project is located in MyProject-superbuild/MyProject-build, so point the %CMake-GUI to this build directory if you want to change the set of enabled plug-ins for example. Further, you should open the MyProject.sln solution file (for Visual Studio) or execute "make" in the MyProject-superbuild/MyProject-build/ directory. Only for the very first time or if you want to update and newly build the project's dependencies should you use the project files in the MyProject-superbuild directory directly. The same applies for the MyProject-superbuild/MITK-superbuild directory. This directory contains the MITK superbuild, nested inside your project's superbuild. If you want to change %CMake options for MITK, use the MyProject-superbuild/MITK-superbuild/MITK-build build directory. \imageMacro{HowToNewProject-MyProjectLayout.png,"Layout of MyProject",4.02} -\subsubsection HowToNewProjectPackaging Packaging +\subsection HowToNewProjectPackaging Packaging The project template and the generated projects by the Plugin Generator come with full packaging support. You can create deployable packages of your project for all supported operating systems my building the PACKAGE target. On Linux, this will create a tarball, on MacOS a .dmg file, and on Windows a zipball and an NSIS installer (if NSIS is installed and found). You can read more about deployment \ref DeploymentPage "here". */