From Van Essen Lab

Revision as of 00:13, 14 September 2011 by Tim (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.
  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, Jon, ETC:9/2/2011, Status:In-Progress) NiftiWriter - Writing of NIFTI files should all the user to pass in the NIFTI header and NIFTI extensions which are then written and the data offset is properly set. Once the header and extensions have been written, users can then write the data.
  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, Caret5/6/New, Jon ETC:???, Status: In-Progress) NiftiReader - Implement reading that reads the NIFTI header (version 1 or 2) and any extensions. The extensions 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.
  8. (EventManager, Caret7, Tim/Jon ETC:8/29/2011, Status: DONE): Implement prototype EventManager.
  9. (SessionManager, Caret7, John, Status: in development): Investigate feasibility and implement prototype SessionManager for Caret7.
  10. (CommandLine, John, Status: DONE) Command that generates header and implementation files for a class.
  11. (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.
  12. (Common) Implement or remove any stubbed functions.
  13. (Common, Caret6, John, Status: in development) 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.
  14. (Common, Caret6) Enumerated types for species, structure, stereotaxic space are needed.
  15. (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.
  16. (Common, Caret5/6/New) An abstract Algorithm class is needed.
  17. (Common, New?) 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.
  18. (Files, GIFTI-based, Caret5/6/New, Jon ETC:???, Status:In-Progress) SurfaceFile - Combines CoordinateFile and TopologyFile from Caret5.
  19. (Files, GIFTI-based, Caret5/6/New, Jon ETC:???, Status:In-Progress) LabelFile
  20. (Files, GIFTI-based, Caret5/6/New, Jon ETC:???, Status:In-Progress) MetricFIle
  21. (Files, GIFTI-based, Caret5/6/New, Jon ETC:???, Status:In-Progress) RGBA File
  22. (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.
  23. (Files, Caret6/New) Volume/VolumeFile.
  24. (Files, New) For low priority files, create a skeleton for use by the DataFileReader.
  25. (Helpers, New, Tim, done) TopologyHelper
  26. (Common, New, Tim, done) Mutexes - CaretMutex and CaretMutexLocker are a bridge to QMutex and QMutexLocker
  27. (Helpers, New, Tim, in progress) 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