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