Code organization

An understanding of how the code is organized and what the classes do are only necessary for users who wish to modify the code. This documentation assumes a good understanding of MATLAB and object-oriented programming.

Finding your way around

Overview

All code is in the code directory. tests contains a little some unit-testing code. The SETTINGS directory will be used to store your rig settings once BakingTray has been run for the first time. It is suggested that you keep backups of these in SETTINGS_BACKUP, or anywhere else of your choosing. The two settings directories are excluded from version control. The ChangeLog.txt file lists the major modifications made to the software.

The code directory

We make using of packages to keep things neat and avoid namespace issues with function and class names. A model/view (also see) is used to separate the logic from the GUIs. In this framework the BT class is the "model" which controls acquisition. An instance of BT can be created at the command-line and a full acquisition can be set up and run purely using this class without the GUI. This is like the hSI object, if you're familiar with the ScanImage API. The BakingTray.m function starts the API and then builds the GUI. This is how you will typically be starting BakingTray. The resources directory contains a small number of helper functions. The components directory contains code used to drive hardware (laser, motion, and cutting) and interact with other software (scanning). The recipe class handles creation, reading, and processing of sample-specific preferences. e.g. Things like the number of tiles, the sample name, the image resolution, etc. The logger component is used to build detailed log files of the actions undertaken during acquisition. This is used for debugging in scenarios where an unattended acquisition stops seemingly random. The BakingTray package contains the GUIs and other functions directly involved in acquisition.