GUI: SelectionProperty: preparation to replace Descriptor
Current selection mechanism for setting up sample and instrument is based on so called "catalogs".
Catalog is a class that contains list of target classes, between which we choose, and supporting information: labels, icon paths, enumeration lists.
SelectionProperty
may operate on such catalog, it owns the instance of currently selected class, provides serialization interface, common label and tooltip.
This hierarchy looks reasonable and the goal is to simplify it, diminishing the generality, and merging SelectionDescriptors
to SelectionProperty
SelectionDescriptors
, like other previously existed descriptors, are generic interfaces that may represent corresponding property or can be build ad hoc to represent other parameters in the same way. But SelectionProperties
may represent themselves without sharing functionality between two similar classes. If SelectionDescriptor
is constructed for non-SelectionProperty
object, that means that we need SelectionProperty
here. So that descriptors should be eliminated.
Steps of SelectionProperty/Descriptor
refactoring:
- make
SelectionProperty
less generic, make catalogs usage mandatory, not optional - reduce usage of ad hoc
SelectionDescriptors
, e.g. descriptors that are not derived fromSelectionProperty
- move
Descriptor
functionality toProperty
- use
Property
instead ofDescriptor
- remove
Descriptor
from code - refactor serialization of
Property
This MR is related to points 1 and 6.