Refactor for increased maintainability

[digitaltrails]

Vdu_controls started as a script, but is now too large to be considered a script. It could benefit from refactoring into sub-components. That said, a modern IDE that shows structure can be used to successfully navigate the source, so it's less of an issue than one might think.

At this point it's functionally relatively complete (within the limits of what's possible) and relatively stable. The main incentive for refactoring is to improve the developers perspective. But I don't think there is a major developer held back by its current state :-)

Now the general requirements are known, a totally new effort with a more appropriate underlying structure would be desirable. The original code was not intended to support multiple independent threads, such as a GUI, a scheduler, and a light-meter, all making changes to the same hardware controls.

The original unit of abstraction was heavily oriented around sets of VDU slider-controls and dropdown-controls. Now that there are multiple independent threads in action, it would be better if VDU hardware, current values, and available commands was abstracted into a separately threaded hardware layer. A GUI thread, scheduling threads, and light-metering could then be provided better coordinated access to the same underlying hardware.

The other avenue to explore is whether a QML based UI could support a similar dynamically configured interface with a significant reduction in the amount of code required.

I feel cross desktop support (system tray, etc) is of major importance, that may place some restrictions on what technologies can be employed.

All of the above is something to consider because the code base has become a limitation for any future major enhancements (but I'm not anticipating anything at this time).

[digitaltrails]

The parsing and help associated with command line arguments and settings options needs full unification. This would the reduce duplicated code efforts in each of these areas.

[digitaltrails]

Any effort at modularisation should include test-coverage considerations. The paths need to be exercised through the UI as well as individually - so a Qt aware UI test tool would be ideal.

[digitaltrails]

The parsing and help associated with command line arguments and settings options needs full unification. This would the reduce duplicated code efforts in each of these areas.

I've tackled this, but in doing so the additional abstrations added up. As of the latest commit for this, the script is exactly the same size :-(. At least adding/maintaining options should be much easier.

[digitaltrails]

Perhaps lux adjustment might be treated as a preset change, potentially reducing the amount of code related to adjusting for Lux. Or vice versa.

[digitaltrails]

The parsing and help associated with command line arguments and settings options needs full unification. This would the reduce duplicated code efforts in each of these areas.

Commit a30739f probably completes the tidy up of the command line arguments and settings config file code.