From Van Essen Lab

Revision as of 21:57, 6 October 2011 by Jschindl (Talk | contribs)
Jump to: navigation, search


Development Sequence

Procedure for Development

  1. All developers should add this page to their watch list so that they are alerted to any additional items or changes. Others are encouraged to sign up as well.
  2. When taking a task, put your inititials, an ETC (estimated time of completion), and status for that item (either in-progress or DONE).
  3. Please do not take a task that another developer is working on without following the suggestions below. Additionally, do not start a task before indicating that you are taking it.
  4. If an item's requirements, design, or implementation are unclear or controversial, then create an RT ticket, and put a link to it in the particular wiki item. For example, EventManager will require us to form a consensus, which is difficult to do with a wiki page, but easy to do by having a discussion on RT.
  5. If the design of a group of features (such as the names of objects, or GUI design) are un-decided, then an RT ticket should be clear labeled and put under the Design issues heading. This will facilitate the discussion of design related issues outside of meetings and allow us to better coordinate our efforts.
  6. In general, unless an item is a very large task, one developer should perform the implementation, and any concerns about how it is being done should be discussed through RT. (EventManager will hopefully be the last exception to this rule.)
  7. Opening an RT ticket related to a development item is possible at any time, including after a task is marked DONE. If there are issues with an item, discussion is encouraged.

Design and Development Issues

  1. Begin design of graphical-user interface. Create mockup user interfaces using drawings or QtDesigner/QtQuick. Examine Caret5 and Caret6. Determine what MUST be in the user-interface. What can be moved to the command line. Compare Caret5's many menus to Caret6's operation dialogs.
  2. Should Mac version be more Mac-Like? Mac windows normally do not include a close button and are closed by the red circle in the top left corner.
  3. Begin creating a list of commands for command line processing.
  4. Begin writing user documentation.
  5. Icons
  6. File Naming Convention

Development Environment

  1. 64-bit only as a goal. We will be doing 32-bit builds in house currently, and will test user reaction in October. If needed we can do a 32 bit release, or drop 32 bit support completely at that point.
  2. A build system that runs as files are checked into source control needs to be created. If there compilation or testing errors, emails are sent to developers.
  3. Investigate CTest, CDash, and CPack for use with build system. - TSC: CTest is now in use, but not connected to a dashboard
  4. Examine CppTest for unit testing.
  5. Minimize usage of third party libraries and their components. When possible, encapsulate code from the third party so that users of the class never see the third party library. For example, the base class for XML parsing is abstract. A concrete class for XML parsing is implemented using QT's XML parsing library. Users call a factory method in abstract XML parser class that returns a parsers. Delegates that receive the SAX XML tags and characters have no knowledge about the actual implementation of the XML parser. If fact, the QT XML parser could be replaced with a different XML parser and the delegates will not see any difference.

Coding (Complete by September 15, 2011)

  1. (DONE, JS) STRING (new) The prototype code uses std::string which must be replaced. std::string cannot be used because it does not support unicode. std::wstring does support unicode but it uses a wide character which varies in size and encoding depending upon the platform. In addition, using std::wstring requires all text string be prefaced with the letter L (L"wide string") which is very inconvenient. One option is to use QString but this would scatter QString throughout the source code and present a major problem if the code was ported to a platform that did not support Qt. A better option is to encapsulate QString in a class that contains the same methods as QString and simply calls the identically names methods in QString (Bridge). It would also allow the addition of additional methods and eliminate StringUtilities (Decorator).
  2. (DONE, John) (CommandLine) Commands need to be in a project separate from the command line "main" program so that commands can be called from within Caret at a later time.
  3. (AString, Jon, ETC: 8/24/2011, Status:DONE) Add operators to AString for conversion between types and compatibility with streams. The following types should have compatibility with operator=, operator+, operator+=, operator<< and operator>>. The above operators should be able to take an std::string, iostream (for << and >>), double, float, byte, short, int, long, long long, unsigned byte, unsigned short, unsigned int, unsigned long, and unsigned long long.
  4. (Nifti Header Reader, Jon, ETC:10/06/2011, Status:DONE) Handles reading of Nifti Header.
  5. (Cifti, Jon, ETC:8/26/2011, Status:DONE) Implement CIFTI.
  6. (Gifti, Jon, ETC:9/2/2011, Status:In-Progrss) Separate read of MetaData, LabelTable, and other elements that are present in multiple files. These implementation should be moved to the NIFTI library so that they can be used by NIFTI, GIFTI, CIFTI, and Caret XML files.
  7. (Nifti Header Writer, Caret5/6/New, Jon ETC:, Status: DONE) NiftiReader - Implement reading that reads the NIFTI header (version 1 or 2) and any extensions.
  8. (Nifti Volume File Extension, Jon, ETC: 10/06/2011, Status:In-Progress) - The extension should be placed into a class that contains the extension code. The extensions data (perhaps in a vector), and the size of the extension. A method to read all or parts of the data is also needed. There will be no flipping of NIFTI volumes. As long as a correct transform is present, it should be displayed properly.
  9. (EventManager, Caret7, Tim/Jon ETC:8/29/2011, Status: DONE): Implement prototype EventManager.
  10. (SessionManager, Caret7, John, Status: Done): Investigate feasibility and implement prototype SessionManager for Caret7.
  11. (CommandLine, John, Status: DONE) Command that generates header and implementation files for a class.
  12. (Common, CommandLine, John, Status: DONE) Can a template be created for enumerated types? Otherwise, add a command line operation for generating header and implementation files for enumerated types. Result: Command implemented.
  13. (Common) Implement or remove any stubbed functions.
  14. (Common, Caret6, John, Status: Done) Logger - A logger class similar to Java's Logger class would be helpful and preferable to print statements. The logger could direct message to the console, a file, or into a structure in memory for viewing in Caret.
  15. (Common, Caret6, John, Status: Done) Enumerated types for species, structure.
  16. (Common, Caret6, John, Status: In work) Enumerated type for stereotaxic space
  17. (Common or ?, Caret6, John, Status: Done) Create a DataFileType enumerated type that can be used to identify data files, provide the file's extension, file filter for use in a file selection dialog, spec file tag, etc.
  18. (Common, Caret5/6/New, Tim, DONE) An abstract Algorithm class is needed. - requires a progress object (can be ignored and passed through to child algorithms if you are lazy), does not require a BrainSet or the like, drops separate execute() method (constructor does all the work, to reduce the number of mandatory member variables)
  19. (Common, New, Tim, implemented) All binary input and output should be performed using the C++ standard library. It may be helpful to have a BinaryFile class that can be used by NIFTI, CIFTI, GIFTI external binary and other files for sequential and random reading and writing. Result: BinaryFile class written, not currently in use.
  20. (Files, GIFTI-based, Caret5/6/New, Jon Status: DONE) SurfaceFile - Combines CoordinateFile and TopologyFile from Caret5.
  21. (Files, GIFTI-based, Caret5/6/New, Jon Status: DONE) LabelFile
  22. (Files, GIFTI-based, Caret5/6/New, Jon Status: DONE) MetricFIle
  23. (Files, GIFTI-based, Caret5/6/New, Jon Status: DONE) RGBA File
  24. (Files, Caret XML, Caret6) SpecFile (is there a better name, DataSet, DataInventory, DataFileList??? Also write its SAXReader. For each surface-based data file listed, there will be an attribute that identifies its structure.
  25. (Files, Caret6/New, Tim, implemented VolumeFile) Volume/VolumeFile. Implemented VolumeFile in new, waiting for NiftiReader/Writer to be able to load data from a file.
  26. (Files, New) For low priority files, create a skeleton for use by the DataFileReader.
  27. (Helpers, New, Tim, DONE) TopologyHelper
  28. (Common, New, Tim, DONE) Mutexes - CaretMutex and CaretMutexLocker are a bridge to QMutex and QMutexLocker
  29. (Helpers, New, Tim, DONE) GeodesicHelper - needed changes and is required for a lot of needed algorithms

Until the messaging system is defined, the following tasks may need substantial redesign (The messaging system is done, 8/31, JS):

  1. (Brain, Caret6 John, Status: in development) Brain will organize all data loaded into Caret. It will contain multiple brain structures. Files that are structure independent are kept within the Brain. Multiple subjects, which require a one spec file per subject, will require a SessionManager.
  2. (Brain, Caret6 John, Status: in development) BrainStructure will contain data for a specific brain structure. At this time it is used for surface-based data related to the cerebral cortices and the cerebellum. In the future, it could contain models of sub-cortical structures. Files are associated with a brain structure by the structure attribute and the number of nodes. The brain structure will contain all of its surface-based files.
  3. (Brain, Caret6 John, Status: in development) Surface extends the SurfaceFile class and contains methods for some surface operations.
  4. (Brain, Caret6) DisplaySettings (perhaps DataController) and its subclasses are needed to manage the display status of different data types.
  5. (Brain, Caret6/New, John, Status: in development) Controllers (formerly Viewers) control the display of surfaces, volumes, etc. in the Main and Viewing Window graphics areas.
  6. (Brain, Caret6) DataFileReader Uses Files project classes to read a file.
  7. (Brain, Caret6) SpecFileReader Reads the selected files into Caret from a SpecFile.
  8. (Brain, CIFTI, Files, Caret5/6/New) Connectivity data loading and processing.
  9. (GuiQt, New John, Status: in development) Main Window, toolbar, and menus.
  10. (GuiQt, Caret5/New) Spec File Dialog.
  11. (GuiQt, Caret6) A window manager class that launches and updates all open windows.
  12. (GuiQt, New) Viewing Windows and yoking.
  13. (GuiQt, Caret5/New) One file selection dialog for all files types (including SpecFile). It defaults to spec file for the filter. If additional information is needed, it appear in another dialog.
  14. (GuiQt, Caret5/6/New) Manage Loaded Files Window.
  15. (GuiQt, Caret6/New) A multi-page window for use by Display Control and the various operation windows.
  16. (Brain, Caret6) SurfaceOverlay Maintains data related to a single surface overlay.
  17. (Brain, Caret6) SurfaceOverlayColoring Colors brain structure nodes for specific windows using a set of surface overlays.
  18. (Brain, Caret6) SurfaceOverlaySet Maintains a set of surface overlays for a specific window.
  19. (Brain, Caret5/Caret6/New) OpenGL rendering, selection. Initially support fixed pipeline but provide interface that will allow programmable pipeline in the future.
  20. (Brain/GuiQt, New) Create mouse and keyboard processing mechanism. Active one receives input events and provides labels for status bar.
  21. (GuiQt, Caret6/New) Display Control Window.
  22. (GuiQt. Caret5/6/New) Identification Window.
  23. (GuiQt, New) Help system that may use Qt's WebKit implementation.
  24. (GuiQt, Brain, Files, Caret6/New) Interface to Connectome DataBase.
  25. (GuiQt, New) Capture image(s) dialog.
  26. (GuiQt) Animation system (rotation, time point sequencing, etc).

Starting in October

  1. (Common) Preferences - This will likely encapsulate Qt's preferences class.
  2. (Files, GIFTI-based) SurfaceRegionOfInterest
  3. (Command Line) Begin writing command line operations.
  4. (Command Line) Command that converts a coordinate and a topology file to a surface file.
  5. (GuiQt) Metric Operations Window (uses multi-page windows).
  6. (GuiQt) Label Operations Window (uses multi-page windows).
  7. (GuiQt) Shape Operations Window (uses multi-page windows).
  8. (GuiQt) Surface Region of Interest Window (Wizard)
  9. (GuiQt) BrainTips.
  10. (Files, Caret XML) The coordinate of border point or a focus is one or more of stereotaxic (cartesian), barycentric, or "van essen". As a result, a common object that supports each of these coordinates is extended or encapsulated. When the coordinate is stereotaxic, the file is essentially a Caret5 BorderFile or FociFile. In addition this object will also include a structure attributes. When a focus projects ambiguously, it will contain two or more of these objects.
  11. (Files, Caret XML) BorderProjection and its SAXReader.
  12. (Files, Caret XML) FociProjection and its SAXReader.
  13. (Files) Point location algorithm.
  14. (Files) Point projection algorithm.
  15. (Files) Algorithm SurfaceProjector for Foci and Borders.
  16. (Files) Algorithm SurfaceUnprojector for Foci and Borders.
  17. (Files, Caret XML) Annotation and its SAXReader.
  18. (Files, Caret XML) FociSearch and its SAXReader.
  19. (Files, Caret XML) Study (and its related elements) and its SAXReader.
  20. (Files, Caret XML) StudyCollection and its SAXReader.
  21. (GuiQt) Border Operations Window (uses multi-page windows).
  22. (GuiQt) Foci Operations Window (uses multi-page windows).
  23. (GuiQt) Study Operations Window (uses multi-page windows).
  24. (GuiQt) Vocabulary Operations Window (uses multi-page windows).
  25. (Brain) Mapping Surface Data to Volumes.
  26. (GuiQt) Gui for mapping surface data to volumes.
  27. (Brain) Mapping Volume (Atlas) Data to Surfaces.
  28. (GuiQt) Gui for Mapping Volume (Atlas) Data to Surfaces.
  29. (Brain) Mapping Volume (Individual) Data to Surfaces.
  30. (GuiQt) Gui for Mapping Volume (Individual) Data to Surfaces.
  31. (Brain) Multiresolution morphing.
  32. (Brain) Surface Smoothing.
  33. (Brain) Surface-based Registration.
  34. (GuiQt) Geometry Operations Window.
  35. (GuiQt) Topology Operations Window.
  36. (GuiQt) Registration Operations Window.
  37. (Gifti) For statistics randomization, a special GIFTI reader that allows sequential reading of data arrays is needed. This means that after an array is read, the data is passed to a callback or interface method that processes the data. These operations are repeated until all data has been read. Similar functionality is also needed for writing of GIFTI files.
  38. (Statistics) Implement inferential and significance statistical algorithms.
  39. (Statistics) Use GLM for inferential statistics?
  40. (Caret5) Add ability or caret_command (carert5) to write Caret6 format data files including spec file.
  41. (Files) Add ability to read legacy file formats. Possibly command line only.
  42. SureFit an optional library that may require VTK.


  • Command classes should be callable from within Caret7 (as in Caret6).
  • Encapsulate Qt when possible.
  • Do not use QThread, use OpenMP.
Personal tools
Sums Database