Home
Phabricator
Search
Configure Global Search
Log In
Transactions
T23721
Change Details
Change Details
Old
New
Diff
{F904416, layout=center, size=full} = Summary = == Weak Pointer == `mitk::WeakPointer` was completely rewritten to ensure safe usage. It is designed specifically for `itk::Object` classes and adds/removes `DeleteEvent` observers to fulfill its purpose of representing temporary ownership. The new public API is based on `std::weak_ptr` by providing the two methods `IsExpired()` and `Lock()`. The latter method creates an `itk::SmartPointer` for safe temporary access. == Unique IDs == A new base class `mitk::Identifiable` was introduced that has the sole purpose of encapsulating a unique ID for identifiable objects. It provides read-access through `GetUID()`. It is movable but not copyable. Both `mitk::BaseData` and `mitk::DataNode` derive from `mitk::Identifiable`. We also introduced two new node predicates for convenient data node filtering: `mitk::NodePredicateUID` and `mitk::NodePredicateDataUID`. Write-access to the unique ID is encapsulated by the `mitk::UIDManipulator` class. It usually shouldn't be used unless absolutely necessary. For example, data readers may set the unique ID of a read data object after its creation. == Abstract interfaces for properties == The two new interfaces `mitk::IPropertyProvider` and `mitk::IPropertyOwner` were introduced, where the latter derives from the former. The interfaces enable unified access to properties in a specified context. `mitk::IPropertyProvider` encapsulates read-access and does not guarantee ownership of the returned properties. `mitk::IPropertyOwner` also provides write-access as it guarantees ownership of the properties. Both `mitk::BaseData` and `mitk::DataNode` implement `mitk::IPropertyOwner`. The context for `mitk::DataNode` maps to the name of the `mitk::BaseRenderer`, as `mitk::DataNode` encapsulates a `mitk::PropertyList` for each `mitk::BaseRenderer` in addition to the common `mitk::PropertyList` (empty context). `mitk::BaseData` doesn't have any context for property access. WARNING: The default behavior of querying properties from `mitk::DataNode` changed. If a property couldn't be found in the specified context or in the default context of the data node, the encapsulated `mitk::BaseData` object is queried as a fallback. == Node predicate for callables == A convenient new node predicate named `mitk::NodePredicateFunction` was introduced. It takes an arbitrary callable (`std::function`) like free functions, member functions, function objects, or lambda expressions to perform the actual check.
{F904416, layout=center, size=full} = Summary = == Weak Pointer == `mitk::WeakPointer` was completely rewritten to ensure safe usage. It is designed specifically for `itk::Object` classes and adds/removes `DeleteEvent` observers to fulfill its purpose of representing temporary ownership. The new public API is based on `std::weak_ptr` by providing the two methods `IsExpired()` and `Lock()`. The latter method creates an `itk::SmartPointer` for safe temporary access. == Unique IDs == A new base class `mitk::Identifiable` was introduced that has the sole purpose of encapsulating a unique ID for identifiable objects. It provides read-access through `GetUID()`. It is movable but not copyable. Both `mitk::BaseData` and `mitk::DataNode` derive from `mitk::Identifiable`. We also introduced two new node predicates for convenient data node filtering: `mitk::NodePredicateUID` and `mitk::NodePredicateDataUID`. Write-access to the unique ID is encapsulated by the `mitk::UIDManipulator` class. It usually shouldn't be used unless absolutely necessary. For example, data readers may set the unique ID of a read data object after its creation. == Abstract interfaces for getting and setting properties == The two new interfaces `mitk::IPropertyProvider` and `mitk::IPropertyOwner` were introduced, where the latter derives from the former. The interfaces enable unified access to properties in a specified context. `mitk::IPropertyProvider` encapsulates read-access and does not guarantee ownership of the returned properties. `mitk::IPropertyOwner` also provides write-access as it guarantees ownership of the properties. Both `mitk::BaseData` and `mitk::DataNode` implement `mitk::IPropertyOwner`. The context for `mitk::DataNode` maps to the name of the `mitk::BaseRenderer`, as `mitk::DataNode` encapsulates a `mitk::PropertyList` for each `mitk::BaseRenderer` in addition to the common `mitk::PropertyList` (empty context). `mitk::BaseData` doesn't have any context for property access. WARNING: The default behavior of querying properties from `mitk::DataNode` changed. If a property couldn't be found in the specified context or in the default context of the data node, the encapsulated `mitk::BaseData` object is queried as a fallback. == Node predicate for callables == A convenient new node predicate named `mitk::NodePredicateFunction` was introduced. It takes an arbitrary callable (`std::function`) like free functions, member functions, function objects, or lambda expressions to perform the actual check. == MITK extensions (experimental) == The advanced CMake cache variable `MITK_EXTENSION_DIRS` was introduced to the MITK-superbuild and the MITK-build, where the former passes the variable to the latter. Each directory specified in this variable will be parsed for modules, plugins, external projects, CMake scripts, and so on. The directory layout should be the same as MITK's, e. g.: - {icon folder-o} ExternalRepo - {icon folder-o} CMake - {icon folder-o} PackageDepends - {icon file-o} FooConfig.cmake - {icon file-o} FindFoo.cmake - {icon folder-o} CMakeExternals - {icon file-o} Foo.cmake - {icon file-o} ExternalProjectList.cmake (`mitkFunctionAddExternalProject(NAME Foo OFF) ...`) - {icon folder-o} Modules - {icon folder-o} Foo - {icon file-o} ModuleList.cmake (`set(MITK_MODULES Foo ...)`) - {icon folder-o} Plugins - {icon folder-o} org.mitk.gui.qt.foo - {icon file-o} PluginList.cmake (`set(MITK_PLUGINS org.mitk.gui.qt.foo:OFF ...)`) Everything is optional. If something is found in the expected location, it is included into the MITK-(super)build. Don't forget to list your modules, plugins or external projects in the corresponding *List.cmake file.
{F904416, layout=center, size=full} = Summary = == Weak Pointer == `mitk::WeakPointer` was completely rewritten to ensure safe usage. It is designed specifically for `itk::Object` classes and adds/removes `DeleteEvent` observers to fulfill its purpose of representing temporary ownership. The new public API is based on `std::weak_ptr` by providing the two methods `IsExpired()` and `Lock()`. The latter method creates an `itk::SmartPointer` for safe temporary access. == Unique IDs == A new base class `mitk::Identifiable` was introduced that has the sole purpose of encapsulating a unique ID for identifiable objects. It provides read-access through `GetUID()`. It is movable but not copyable. Both `mitk::BaseData` and `mitk::DataNode` derive from `mitk::Identifiable`. We also introduced two new node predicates for convenient data node filtering: `mitk::NodePredicateUID` and `mitk::NodePredicateDataUID`. Write-access to the unique ID is encapsulated by the `mitk::UIDManipulator` class. It usually shouldn't be used unless absolutely necessary. For example, data readers may set the unique ID of a read data object after its creation. == Abstract interfaces for
getting and setting
properties == The two new interfaces `mitk::IPropertyProvider` and `mitk::IPropertyOwner` were introduced, where the latter derives from the former. The interfaces enable unified access to properties in a specified context. `mitk::IPropertyProvider` encapsulates read-access and does not guarantee ownership of the returned properties. `mitk::IPropertyOwner` also provides write-access as it guarantees ownership of the properties. Both `mitk::BaseData` and `mitk::DataNode` implement `mitk::IPropertyOwner`. The context for `mitk::DataNode` maps to the name of the `mitk::BaseRenderer`, as `mitk::DataNode` encapsulates a `mitk::PropertyList` for each `mitk::BaseRenderer` in addition to the common `mitk::PropertyList` (empty context). `mitk::BaseData` doesn't have any context for property access. WARNING: The default behavior of querying properties from `mitk::DataNode` changed. If a property couldn't be found in the specified context or in the default context of the data node, the encapsulated `mitk::BaseData` object is queried as a fallback. == Node predicate for callables == A convenient new node predicate named `mitk::NodePredicateFunction` was introduced. It takes an arbitrary callable (`std::function`) like free functions, member functions, function objects, or lambda expressions to perform the actual check.
== MITK extensions (experimental) == The advanced CMake cache variable `MITK_EXTENSION_DIRS` was introduced to the MITK-superbuild and the MITK-build, where the former passes the variable to the latter. Each directory specified in this variable will be parsed for modules, plugins, external projects, CMake scripts, and so on. The directory layout should be the same as MITK's, e. g.: - {icon folder-o} ExternalRepo - {icon folder-o} CMake - {icon folder-o} PackageDepends - {icon file-o} FooConfig.cmake - {icon file-o} FindFoo.cmake - {icon folder-o} CMakeExternals - {icon file-o} Foo.cmake - {icon file-o} ExternalProjectList.cmake (`mitkFunctionAddExternalProject(NAME Foo OFF) ...`) - {icon folder-o} Modules - {icon folder-o} Foo - {icon file-o} ModuleList.cmake (`set(MITK_MODULES Foo ...)`) - {icon folder-o} Plugins - {icon folder-o} org.mitk.gui.qt.foo - {icon file-o} PluginList.cmake (`set(MITK_PLUGINS org.mitk.gui.qt.foo:OFF ...)`) Everything is optional. If something is found in the expected location, it is included into the MITK-(super)build. Don't forget to list your modules, plugins or external projects in the corresponding *List.cmake file.
Continue