I have seen that in the actual code (including beta-11) two lists do not show correct values.
First case is the "Load model" list. A new (unconfigured) model does not have a name set in the modelXX.ini - the entry simply does not exist. The code sets the name to "NONE" when loading such a model and in a second step it is changed to "ModelXX" which is displayed as name - but it is not saved. When you want to load a new model in the list the actual model name still shows "NONE" and not the "ModelXX" (RBE #50).
The second case is: when you change the icon of a model and try to load another model (same list as above) the icon is shown correctly until you select another line in the list and the original line. You will see the old icon, not the new one (RBE #51).
I have changed this behavior in recent commits but I am unsure if the way is correct.
I have used the "feature" of a not saved model config to change the config and save it with "Copy to" to another model config slot. This was nice because when I do some tests I could save them with a new name without changing the original config - and I can decide to do that when I did some changes, not only before I start.
When doing some research how the above issues could be solved alternatively I have seen that since a long time when you change a model's name the config is saved immediately. This is what I have implemented to solve the above issues.
But I also have another solution (in my save_model-branch) where the lists / icons are displayed correctly without saving the model - the values from memory are shown instead those read from the model config file.
Question:
Which way is better?
(1) Save the model immediately (and often) when certain changes are done?
(2) Save the model only when the tx is shut down or a new model is selected?
(2) will give the above described possibility to decide later if the config shall be copied to a new model config or written back to the actual one. (1) might reduce the chance of loosing configuration steps (but only if the tx resets or shuts off unexpected).
I can live with both but prefer (2) (as you might have read between the lines...). I only think we should handle it the same way all over the code.
