Now that we're using matplotlib as a viewing backend and generating images based on id/property maps, many of the view updates which used to require calls into OpenMC can now be done by modifying the data we're storing in place in the GUI.
While this creates an opportunity to make the GUI run more smoothly, it also blurs the lines between the "active view" (the updated, but unapplied view) and the "current view" (the view on screen) in the plotting model. Where before, any change to the current view would require plot regeneration we can now limit this to parameters being passed to the get_id_map/get_property_map function and do all other updates on the current set of data stored on the model. We now need to distinguish between these items to do it properly throughout the model, view, and controller. As part of this effort, I'm going to attempt to only enable the Apply Changes buttons when new id/property map generation is necessary to update the view to ensure this isn't being hit unnecessarily by users.
Now that we're using
matplotlibas a viewing backend and generating images based on id/property maps, many of the view updates which used to require calls into OpenMC can now be done by modifying the data we're storing in place in the GUI.While this creates an opportunity to make the GUI run more smoothly, it also blurs the lines between the "active view" (the updated, but unapplied view) and the "current view" (the view on screen) in the plotting model. Where before, any change to the current view would require plot regeneration we can now limit this to parameters being passed to the
get_id_map/get_property_mapfunction and do all other updates on the current set of data stored on the model. We now need to distinguish between these items to do it properly throughout the model, view, and controller. As part of this effort, I'm going to attempt to only enable theApply Changesbuttons when new id/property map generation is necessary to update the view to ensure this isn't being hit unnecessarily by users.