Bugfix/monitor tab refactor

Dylan Oliver Teague requested to merge bugfix/monitor_tab_refactor into develop


This MR is devoted to two purposes:

  1. Refactoring the GEMMonitor class
  2. Removing the monitoring page tab

(btw, I haven't run clang-format on the files, so formatting issues might be present...)


This class allowed for lots of flexibility when first devised, but its use case now means it is overly complicated. In essence, it is a timer for an InfoSpace that one can store variables in that InfoSpace for convenience. This class is also only used by GEMSupervisor and DaqMonitor, but is a parent class for a huge portion of the code unnecessarily! To combat this, a new class, GEMTimer (to emphasize it is just a holder for a timed event on the InfoSpace) was created that is only included by the above classes.

Different from the other MR, the new class is kept in the gembase folder. We might move away from using this class in GEMSupervisor (and hopefully this refactoring will assist in any change to that effect), but for now, it is kept centrally.

The commits were split specifically to adding the new class at different stages, so hopefully issues can be resolved much easier. I did cursor tests over all the widgets, but because I'm lack of usage of everything besides the monitoring suite, I could only compare on a visual level without exhaustive tests.

Monitoring Page

There is a monitoring page tab in all widgets that is unnecessary as the monitoring matures. This can be removed whole-cloth to reduce code clutter, favoring the "Application Page" instead. To do this, the xdaq-tab div has to be moved into the actual page function (so it isn't created) and the virtual function has to be defined so widgets that don't need it don't need to define the unnecessary page.

This can similarly be applied to the expertPage since some don't use it now, but that was not implemented (but it would be trivially easy to do if this is wanted!)

Related Issue

This was talked about in issue #53 (closed) and the previous MR attempt was !29 (closed)

How Has This Been Tested?

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)


  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

Merge request reports