USEPA / EPA_MOVES_Model

Estimating emissions for mobile sources
Other
80 stars 20 forks source link

MOVES GUI does not track whether the runspec document is dirty (requiring save) #56

Closed DEQjpowell closed 11 months ago

DEQjpowell commented 1 year ago

To reproduce:

  1. open MOVES 3.1 GUI
    1. choose File/Exit

What I expect:

The window closes and the MOVES process terminates.

What happens instead:

A modal dialog reading

"Do you want to save the run specification before ending?" with buttons "Yes", "No", "Cancel" appears.

Commentary:

The human interface guidelines for graphical user interfaces declare that in a document model, the system should never surprise the user by trying to save a document that has not been modified.

It should be extremely easy to add a global "bool g_Dirty = FALSE" flag and check it before triggering that modal dialog.

You should be using gettors and settors on all of the components of the runspec document that is being edited by the MOVES GUI. Please make the settors change g_Dirty to TRUE.

This has been an issue since MOVES 2014b at least. It is extremely easy to fix. The bug has been the source of a lot of confusion and delay as file system timestamps are meaninglessly stomped on, losing context. Also, this analyst at least pauses in consternation too often because it's so easy to accidentally change some parameter in the GUI. Did the cat land on the keyboard while I was making tea? This is exactly the kind of thing computers are good at tracking, while people are terrible at it. An example from today: I return to a MOVES window I left open on a remote desktop system several weeks ago. MOVES asks to save the runspec. Did I forget to save some change last time? I don't think so… but how can I be sure? Make the computer track this for me please.

danielbizercox commented 11 months ago

Hi James,

I agree, this is a common source of confusion. I looked into your suggestion, but unfortunately, the RunSpec object held in memory does not necessarily update with every selection made. It is only guaranteed to be updated when you switch to a different panel or when it displays the save dialog. Updating to a getters/setters paradigm would require a major refactor of the GUI, which is currently out of scope for this project.

Since the RunSpec object in memory won't necessarily have all changes made on the active panel, the current behavior of always asking if you want to save before you start a run, load a new RunSpec, or close the GUI is the only way to guarantee that any changes made on the active panel are actually observed by the model.