This is not so different from what happens in WinBoard. The only difference with what you propose is how the settings file (your .xboardrc) is made. Rather than preparing it with a text editor, WinBoard itself can be used (through the point and click mechanism) to alter the settings, and save them back onto the settings file (by clicking "save settings"). I would say this definitely is a more user-friendly way to do it, as you can actually see what you are doing. Having to position the various windows on the screen by typing in screen coordinates is not something I would wish even on my worst enemies.bob wrote:I think the idea of "remembering" is bad. _really_ bad. And I'd bet that this causes more problems than any other issue. Position learning in chess engines has led to more errors, false reports, false claims about quick solution times and such than I care to remember.
I would prefer this be done with a more traditional approach, such as .xboardrc or whatever so that the user is responsible for setting up the defaults, and changing the defaults whenever desirable.
There is a definite hierarchy for this. You first parse the .xboardrc file, then you parse the command-line options which override the .xboardrc if given, then you let the usere point and click to override both if they so choose. Which is how most other application packages work. This gives the same effect without the confusion of long-term memory that a user might not be aware of.
Just my $.02...
The problem starts because people can also click an option "save settings on exit", which, (because of the saving), then becomes permanent. But people apparently want this option; no one forces them to use it.
And what you propose would not solve the reported problem. If the normal way XBoard is used is with incremental TC, that will presumably in your .xboardrc file. And then passing only an -mps parameter without a new -inc would still leave the old -inc from the settings file in force, with the effect that the given -mps will be suppressed.