This sounds like a task for the "themes" list. Currently the window configuration is not amongst the options that would be included in a new theme you create, but it would be easy to do so. Perhaps the View->Board dialog should have a checkbox "include window configuration", which, when checked, would also save the options that control opening of the main auxiliary windows (Engine Output, Move History and Eval Graph), and perhaps their geometry.Evert wrote:I have "save settings on exit" switched off. I want XBoard to start in a reasonable default state, and if I do something to the windows for something particular I want to do, I don't want that to be remembered. What would be useful is the ability to store different settings as a "profile" and let me pick the one I need from a list.
This both has advantages and disadvantages. I run WinBoard with different settings files for different tasks, so that each of the tasks can use its own persistent settigs. E.g. as ICS client I want it to look completely different as for engine matches, (not to mention doing Chess vs Chu Shogi), and I don't want to have to reconfigure it every time I switch to another task. As it is now, each task can have its own engine list.Storing the engine list as part of the settings is understandable from a design point of view, but a mistake from a user point of view. It should be separate.
I guess it would still be possible to store engine lists separately for different tasks, by making the name of the list file a persistent option. Then different settings files used for different tasks could still refer to the same list, but they could also use different lists. So this is even more flexible than having the engine list stored in the settings file.
So a (persistent) option -engineList <FILENAME> could behave exactly the same as the option -settingsFile (-ini) does now, except that the filename gets remembered separately, and will then be used for all operations on the engine list, rather than for saving the persistent settings. The option -firstChessProgramNames would then no longer be persistent, and thus not get into the settings file. Manipulation of the engine list would then occur on opening/closing the Load Engine (and Edit Engine List) dialogs, rather than on starting / quitting XBoard. This would also solve the synchronization problem you describe below, at least for the engine list. And of course I would make a similar option for the themes list.
This would make some of the solutions I described in the previous posting much cleaner: I would not have to read a settings file without processing the options, just to hunt for the engine list and either process only that, or replace it by an updated version. It just can read or overwrite the entire file it currenly uses as engine list. And I cannot imagine any downside yet. I really like this.
I don't think there is a way to synchronise different instances, unless you make them aware of eachother and have them share data explicitly. In the case of the engine list, the problem could be ameliorated by having an explicit "reload" option. Or you do that if, on gaining focus, the engine list has been updated since it was last read.