Skip to content

Elimination of the SessionItem and SessionModel from the GUI

The following are the subsequent phases for the major GUI refactoring to remove the SessionItem tree-like mechanism, after issues #88 (closed) and #89 (closed).

Phase II: Elimination of the SessionItem Mechanism

The SessionItem mechanism (i.e. tree-like hierarchy of SessionItem parents-childeren) is removed from the BA/GUI.

Some classes, denoted by [C] (like DataItem), are still derived from SessionItem merely to preserve type-compatibility, before the ultimate removal of the SessionItem class. They do not use any SessionItem method.

Note that the functions and methods in the GUI submodule often require a subtype of SessionItem as their argument. Therefore, the refactored classes are still derived from SessionItem class, but do not use any of its functionality.

The following are refactored within this stage:

  • Model/Job/FitSuiteItem
  • Model/Job/FitParameterItem
  • Model/Job/FitParameterLinkItem
  • Model/Job/FitParameterContainerItem
  • Model/Job/MinimizerItem
  • Model/Device/AxesItems
  • Model/Data/DataItem [C]
  • Model/BaseItem/JobRealBase (<= JobItem and RealItem) [C]
  • Model/Job/JobItem [C]
  • Model/Data/SpecularDataItem [C]
  • Model/Data/RealItem [C]
  • Model/Device/MaskItems [C]
  • Model/Data/ProjectionItems (=> MaskItems) [C]
  • Model/Data/IntensityDataItem (=> MaskItems) [C]

Phase III: Elimination of the SessionModel Mechanism

The next major phase (phase III) is to eliminate the closely-related SessionModel mechanism from the code. After the completion of phase III, a new BA release will be in order.

  • Discarding unneed code
    After the removal of the SessionModel mechanism, the implementation of SessionItem and SessionModel classes as well as the related material (e.g. ApplicationModels, SessionModelView, SessionDecorationModel, SessionItemController, PropertyItem and Descriptor) can be discarded from the code-base.

  • Adapting to modifications
    It's very likely that there are a lot of adaptions necessary to make the code compile again. Handling of item creation changed, so the creation within ItemCatalog will have to be removed. Accessing may have changed, copying, comparing, lifetime etc. Check all this.

  • Adapting unit tests
    Once the code can be compiled again, run the unit tests. It's very likely they have to be adapted as well.

A final re-organization and clean-up will be performed afterwards.

Currently known bugs:

  • The mechanism for sending forward/backward leads to SEGFAULTs (see MaskEditorActions::changeMaskStackingOrder).
  • "Mask properties" sometimes does not display the properties for the selected mask (can't reproduce)
  • Masks are not serialized
  • Masks and projections are seen in both Projections and Masks presentations
  • After adding a projection it is not shown on projections plot, but after moving the projection it appears on plot.
  • Masks are not applied to simulation
  • Delete projection in Projection presentation --> segfault. But projections can be deleted from Mask presentation.
  • If line is added in Mask presentation, then it will be seen in Presentation view but without corresponding plot
  • Sometimes switching to Mask presentation after adding a projection leads to segfault (can't reproduce)
Edited by Mikhail Svechnikov