Richard's notes

Things that I am working on

• Completing region implementation (see Development Ideas below)
• FieldML - requirements gathering (dependency on regions).

Tracker

"Cmgui tracker items":https://tracker.physiomeproject.org/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=cmgui

"My tracker items":https://tracker.physiomeproject.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailreporter1=1&emailtype1=exact&email1=r.christie%40auckland.ac.nz&field0-0-0=bug_status&type0-0-0=notequals&value0-0-0=UNCONFIRMED&field0-0-1=reporter&type0-0-1=equals&value0-0-1=r.christie%40auckland.ac.nz

"FieldML specification tracker":https://tracker.physiomeproject.org/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=FieldML%20specification

CMGUI Development Proposals

• Completion of region implementation (feedback wanted: put on linked pages):
  • Fields Owned By Region (supercedes Single Field List)
  • Selection In Regions
  • Remove Special Data Regions
  • Merge Regions And Scenes

Other CMGUI Ideas

• Remove evaluation of element derivatives from Computed field APIs. Prefer a separate field; can possibly specify field the derivative is with respect to.
• Stop writing function name in display_message and ENTER() macro, as these are wrong much of the time. Use __FUNCTION__ or __func__ instead - possibly done automatically by failure reporting Macros. Determine if ENTER() and LEAVE() are needed / possible uses?
• Possibly create object for recording failure messages, capable of collating multiple identical messages, handling multiple threads, able to be inspected by dialogs and zinc applications for custom presentation of warnings.
• Built-in tests. It occurred to me that we could build test code into the main cmgui executable and invoke it with a 'gfx test ...' command, or even run it automatically in the background. Reasoning: (1) Tests are guaranteed to be built and more likely to be run on others' OS configurations; could even be an installation step (2) Can test non-exported functions on the final executable (3) Test code overhead likely to remain small compared to current executable sizes; if that changes we can at least say we have lots of tests! Note I see this as more suitable for small/unit tests, not "big data" stress tests.

Useful links

• "Overview Of Test Examples":http://www.cmiss.org/cm/wiki/OverviewOfTestExamples