|
This is a preliminary version and not yet official documentation.
Available sections:
Functionalities facilitate the structured combination of modules for specific tasks. They combine a user interface with algorithmic function. A functionality consists of (compare screen-shot)
Communication between functionalities is largely based on the data tree. Each functionality accesses the data objects contained in the tree, changes them and/or creates new data objects. Other functionalities can continue to work on the changed and/or newly created data tree entries. By that, functionalities can communicate without becoming dependent on each other.
The visible parts of a functionality. The algorithmic implementation, which is also part of a functionality has no visual representation.
A functionality should comprise a complete set of controls that are necessary to complete a certain task, where the task should be on a reasonably high level that makes sense for the user of the application. Before you consider a new functionality, check if the feature you want to implement could instead be implemented as a widget that can be used in different contexts. Possible examples for functionalities are:
A set of controls that could possibly be of use in more than one context should not be a functionality, but rather a widget. Widgets are good for sub-tasks from the user's point of view. Some examples for things that should not be implemented as functionality
Technically a functionality is a derivative class of QmitkFunctionality. The functionality object gets an mitk::DataTreeIteratorBase when it is created and has to return on request QWidgets for its main widget and its control area, and a QAction (Combination of icon, description and keyboard shortcut) for its identification.
The functionality can own and use arbitrary objects to create and manipulate objects of the data tree.
A functionality is meant to exist only with the context of an application. It is the application's task to create an environment, where it can place the main and control widgets of functionalities, and to create a data tree.
Since the intention is to combine several functionalities in one application, there is a "functionality mediator" of class QmitkFctMediator. A single instance of this object is created by the application and it is told about every functionality that should be available for the application. It is then the mediator's job to arrange the correct switching between functionalities, which involves calling the functionalities' Activated() and Deactivated() methods and hiding/showing the correct main and control widgets for each functionality.
The diagram below shows the important classes related to a functionality.
Classes related to a functionality
Documentation you should read
Classes you should be aware of:
If you want to enhance the SampleApp, you should read the directions on how to create a new functionality.
One idea for future development is to change the current use of functionalities in a way that different functionalities can be active at the same time. This would allow the user to select and arrange a sensible set of functionalities for his or her specific task at run-time. This would allow for more flexible applications.
Implementing this idea would probably require changes to existing functionalities, since currently authors of functionalities can assume that nothing else is manipulating the data tree when their functionality is active.
1.7.2
