As for --vieweroptions that acts like a section in an ini file, perhaps this is a good indication that we should rethink our ini-file structure. Perhaps we should adapt the Windows ini-style syntax, which AFAIK is also used in gnome for example and probably other places, and use it also for XBoard/Winboard. This would have the advantage that it _would_ have sections,
The advantage of the current system, where a 'section' is itself a string option,
is that it can be easily set from the command line. The disadvantage is that it does not automaticaly adapt to setting changes the user made during the session. So it is sort of a read-only section.Having different sets of persistent settings in the current system is implemented by simply using a different user settings file, specified through the -ini option. In XBoard this is currently not used, but for WinBoard I install it with menu items
for FICS and ICC that share a separate ICS settings file. But in XBoard we do not supply any ICS menu items / shortcuts with the install. I don't know enough of how the ini-style syntax is supposed to work to form an opinion about this. It seems to me that it would require a quite large effort to make something that is not highly inferior to the existing system, and that it is not clear it would offer any observable advantage to the user (who is not suposed to look in the ini file). Btw, in Linux dragging a document on top of a binary does not seem to work. (In gnome, at least.)
also I would believe that many people are very familiar with it and don't have to learn a special XBoard ini-style... Furthermore I believe there are good libraries that can be used to read and write ini-files or just get a key out of an ini-file, so that we don't have to write our own code.
XBoard never does that, (get a specific key), actually. It just bulk-reads
the entire ini file or command line. I don't think there is anything to learn
about 'XBoard ini-style'. At least anything that would take ore than 10 sec
to learn. Options all start with a dash, and can have a value behind them,
separated from it by whitespace. Strings arguments can be quoted by
"souble quotes", 'single quotes' or {braces}. That pretty much sums it up.
I also find the @syntax very strange, is that a windows standard? I much rather have a -f --ini-file or something like that which can be called several times if needed. Perhaps also something that could be unified.
I don't know where the @ syntax came from. It seems a PDP-11 assembly language thing, where '@' in an addressing mode indicates indirect addressing.It was in fact causing big problems in Windows shortcuts, which would not display the @ sign and everything on the line behind it in the Properties dialog, so that
people opening it for examining, and inadvertantly clicking OK without changing anything would destroy the shortcut. For this reason I already supplied alternatives -at and -opt. Not sure how the syntax with a double option name, -f as well as --ini-file is supposed to work, but it would be easy enough to supply -f or --ini-file as an alternative.(Although the latter might be a bit confusing, as there already is an option -ini,
short for -settingsFile, which not only reads the file like @ does, but thenautomatically also redirects saving of user settings to it. So we really have three kind of options now: {@, -opt, -at} which only read settings, {-settingsFile, -ini}
which read the file, and makes it the place for saving if it existed, and -saveSettingsFile, which only makes it the place for saving (even if it doesn't exist, without checking if the name would be valid).
