This branch implements an observer/subscriber pattern among the core controllers and consumers of them in the GUI module.
Rationale
The reasoning behind this is that the controllers (which themselves encapsulate primitive 'data'/model classes comprising the project structure), are used within the GUI to construct various interfaces for the user to interact with and mutate data in the project; particularly in the gui/workspace package at the moment.
The reason for implementing such a observer system is that mutations and actions can be initiated by the user from multiple contexts, e.g. the user can create Data Set segments from within the Data Set workspace tab (clicking on the graphical plot), which creates a new child entry in the project tree.
These segment children can be mutated from outside of the workspace by a context menu in the project navigator. When a segment is mutated/deleted this action needs to be propagated back to the plot so that it can update/remove the visual representation.
The other primary case for this feature is for propagating attribute updates and/or state-changes from controllers to UI (e.g. workspace) subscribers. For example when a project is closed, or a flight is deleted from the project, all workspaces which reference those objects (or their children) must be disposed.
This feature branch also enhances the cloning interface for controllers which should deal with some minor UI bugs encountered in the past. Clones of a base controller similarly subscribe to updates in order to update their representation when the base object is mutated. Issues would often appear previously where the base object's friendly-name was changed, but this change was not propagated to any of its clones, resulting in an inconsistent visual state.
Other Changes/Enhancements
Some other changes were made in support of, or ancillary to the major observer/subscriber model implemented:
Controller interfaces have been renamed/enhanced. IBaseController renamed to VirtualBaseController. The VirtualBaseController implements some common methods for inheritors, and does away with the need for the IParent/IChild interfaces.
Documentation added for GUI Workspaces module/packages
Refactor controllers to carry a reference to their base (owning) project, this simplifies API calls for deeper nested controllers/models which occasionally need access to a project attribute (e.g. getting the projects HDF5 store path to load data)
This branch implements an observer/subscriber pattern among the core controllers and consumers of them in the GUI module.
Rationale
The reasoning behind this is that the controllers (which themselves encapsulate primitive 'data'/model classes comprising the project structure), are used within the GUI to construct various interfaces for the user to interact with and mutate data in the project; particularly in the gui/workspace package at the moment.
The reason for implementing such a observer system is that mutations and actions can be initiated by the user from multiple contexts, e.g. the user can create Data Set segments from within the Data Set workspace tab (clicking on the graphical plot), which creates a new child entry in the project tree. These segment children can be mutated from outside of the workspace by a context menu in the project navigator. When a segment is mutated/deleted this action needs to be propagated back to the plot so that it can update/remove the visual representation.
The other primary case for this feature is for propagating attribute updates and/or state-changes from controllers to UI (e.g. workspace) subscribers. For example when a project is closed, or a flight is deleted from the project, all workspaces which reference those objects (or their children) must be disposed.
This feature branch also enhances the cloning interface for controllers which should deal with some minor UI bugs encountered in the past. Clones of a base controller similarly subscribe to updates in order to update their representation when the base object is mutated. Issues would often appear previously where the base object's friendly-name was changed, but this change was not propagated to any of its clones, resulting in an inconsistent visual state.
Other Changes/Enhancements
Some other changes were made in support of, or ancillary to the major observer/subscriber model implemented: