Skip to content

Refactoring capture module | process extraction

This step extract a significant amount of business logic from Capture and moves it all to the new class CaptureProcess. The idea behind is that all actions and processes for preparation and execution of capture sequence jobs moves to CaptureProcess and Capture holds all the UI related logic, i.e. updating UI elements due to the results of the execution of process steps.

The general pattern for this is that processes are initiated from central methods like Capture::start() and communicate their results through events. The following table shows the major activities of this refactoring:

new in CaptureProcess Capture counterpart Event Comment
startNextJob() -- -- determines which job to be started next
prepareJob() jobPrepared() jobPrepared()
prepareActiveJobStage() -- -- two methods
processPreCaptureCalibrationStage() -- -- two methods
prepareJobExecution() jobExecutionPreparationStarted() jobExecutionPreparationStarted()
executeJob() execute() renamed from execute()
checkLightFramePendingTasks() -- --
checkNextExposure() -- --
startNextExposure() -- -- calls checkLightFramePendingTasks()
scriptFinished() scriptFinished()
captureImage() captureImageStarted() captureImageStarted()
imageCapturingCompleted() -- -- renamed from setCaptureComplete()
processFITSData() processingFITSfinished() processingFITSfinished()
resumeSequence() -- --
processJobCompletion() -- -- two methods, renamed from processJobCompletionState..()
checkPausing() -- -- pause handling moved to CaptureProcess
processCaptureError() -- --
processCaptureTimeout() -- --

The extraction shows how complicated and sometimes confusing the methods and their interaction is. After this extraction it should be possible to clean up these methods and use a state model instead of a very complicated calling structure.

Edited by Wolfgang Reissenberger

Merge request reports