2015-12-02 Meeting notes

Date

Dec 02, 2015

Attendees

John Clyne, scott, alanNotes

vaporgui settings

We reviewed Alan's changes to the Settings tabs: VizFeatures, AppSettings, and Startup, whose descriptions are as follows:

VizFeatures:These are misc. parameter settings that will be stored in the current session file

App Settings: These are misc. parameter settings that are NOT saved in the session file (they are data independent), but can optionally be saved as default values in the user preferences file by clicking "Make Default". A change to an App Setting takes effect immediately.

Startup: These are similar to App Settings. However, a change does not take effect until vaporgui is restarted

Alan noted a few items related to parameter settings and other areas that are not complete:

• some of the Setting parameters are no-ops that can't be implemented until more capability has been added to the prototype.
• the color bar settings have not yet been moved to individual renderer tabs
• A "make default" button needs to be added to the Viz Features tab for those parameters that are not data dependent
• the region tab is still a stand alone tab with global effect. We had discussed moving this to individual renderer tabs so that each renderer instance could have a different ROI

Error handling

Also discussed was how to handle errors (message logging, status, and user notification). We reviewed the document Error handling policy and were in general agreement with it's guidelines for logging error messages and indicating an error condition. Not addressed by this document is how to notify the user of an error. A particular gripe of error notification in 2.x is the proliferation of annoying error popups.

We agreed to consolidate error messages logged for a single paint event into a single popup.

Scott inquired whether messages should be recursively reported when deep in a call stack or whether it was sufficient to rely on the fact that for class objects derived by MyBase the first (deepest) occurrence of an error would result in an error log. While it might be more informative to report an error all of the way up the call stack, this is a programming burden. The agreed upon approach was to use your best judgement when not at the deepest level in the call stack, adding an error message if thought to be useful.

We also discussed the 2.x error control mechanism that determines how many notifications of an error message should be sent, and how many messages should go to a log file. It was decided that this much control was overkill and could be simplified as follows:

• Send all error, diag, and warning messages to a single log file (if one is defined), prefixing the messages with their type (e.g. ERROR, WARN, DIAG)
• Replace the ability to specify a number of popups to be displayed with a "silence" button on each notification popup that silences future matching messages.
• Add a mechanism to un-silence all messages.

We also discussed whether to introduce a 'warning" message into MyBase. It was decided not to for now because of the complexity introduced in detecting whether an abnormal return code is an error or a warning, and then figuring out what should be done.

We closed by agreeing that it was time to review the current look and feel of the GUI from top to bottom before moving further forward. Alan noted that we need more sample VDC3 data sets, and that it would be helpful to fix the bug in the WRF data converter.

Action items