Status: Closed
| Item | File | Description | Consensus? | Who? | Status | Notes |
|---|---|---|---|---|---|---|
| 1 | arrowparams.h | Make use of doxygen \copydoc when documenting pure virtual methods. E.g. ArrowParams::Validate(), ArrowParams::IsOpaque() | y | Done | ||
| 2 | arrowparams.h | Make calcDefaultScale() private if possible | y | Done | ||
| 3 | arrowparams.h | GetMapperFunc() returns a MapperFunction *, but there is no documentation for the MapperFunction class. Document (with doxygen) MapperFunction class. | y | Done | MapperFunction is to be re-factored. | |
| 4 | arrowparams.cpp | Remove superfluous blockCapture()/unblockCapture() calls from constructor (redundantly called inside of restart()) | y | Done | ||
| 5 | arrowparams.cpp | Document ParamsBase::GetDataMgr() | ? | Done | ||
| 6 | renderparams.h | Document protected methods. E.g. validatePrimaryVar, validateFieldVars, setupFidelity(), etc. | y | Done | ||
| 7 | arrowparams.cpp | Potential memory leak or poor memory mgt practice with allocation of Box and TransferFunction classes in restart() | ? | post-poned | XmlNode class would need refactoring. | |
| 8 | arrowparams.cpp | Consider moving boiler plate in Validate and restart methods into parent class, and making Validate and restart methods protected methods (e.g. _Validate and _restart) as done with _paintGL | n | closed | The Boiler Plate (common) parts of these methods is so small that there is little value in this change. | |
| 9 | arrowrenderer.cpp | Split performRendering() into into two or more functions to improve readability/maintainability. E.g. renderAligned() and renderUnaligned() | y | Done | ||
| 10 | arroweventrouter.h | Several parent class (eventrouter) methods generate asserts if not reimplemented. Should these be pure virtual? E.g. captureMouse*(), sessionLoadTF() | n | closed | ||
| 11 | arroweventrouter.h | Use \copydoc for implementations of parent class pure virtual methods. E.g. _confirmText(), _updateTab() | y | Done | ||
| 12 | arroweventrouter.cpp | _variables allocated in constructor but not freed in destructor | y | Done | ||
| 13 | arroweventrouter.cpp | ForceRender() needed? Appears to bypass ControlExec:: Paint | ? | Done
| discuss. ForceRender calls VizWin::reallyUpdate() which calls ControlExec:Paint() | |
| 14 | arroweventrouter.cpp arrowrenderer.cpp | Eliminate use of global data: DataStatus | y | Done | ||
| 15 | arrowparams.h | Eliminate one of the following terms: TransferFunction, or MapperFunction (GetMapperFunc() -> GetTransferFunc()) | y | Done | Need to evaluate. Do if not to much effort. Probably a day's effort. Will be done as part of MapperFunction refactoring | |
| 16 | arrowparams.h | Is there a GetColor() function that is distinct from GetConstColor()? For clarity, either all functions that return const values should have "Const" in their name, or none of them should. | n | closed | ||
| 17 | arrowparams.h | If IsOpaque is a required virtual function, shouldn't it be pure? | n | closed | ||
| 18 | arrowparams.h | Should we avoid function definitions in header files? | n | closed | ||
| 19 | arrowrenderer.h | ArrowRenderer: erformRendering() should be pure? | n | closed | ||
| 20 | arrowrenderer.h | Are there any preconditions that should be in place before _initializeGL gets called? | n | closed | ||
| 21 | arroweventrouter.h | Rename the following??? VariableWidget -> VariableFrame ArrowAppearance -> AppearanceFrame LayoutWidget -> LayoutFrame | y | done | Need discussion on what names should be. This discussion should include a discussion of the class structure of sub-tabs. | |
| 22 | arroweventrouter.h | Make virtual? ArrowReturnPressed() -> virtual ReturnPressed() barbLoadTF() -> virtual loadTF() barbSaveTF() -> virtual saveTF() | n | closed | Need to explore possiblity. Problem is that these are slots, which cannot be virtual.Alan will do UI restructuring to support subtabs. Scott will explore replacing some of gui layout currently done with code with UI files. | |
| 23 | arroweventrouter.h | toggleColorInterpType(bool) should take an int to support linear, discrete, and divergent color maps | y | in-progress | Should be done when divergent color maps are specified in the gui. |