Re: [XBoard-devel] file associations / positional arguments

[h.g. muller]

>  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 then
automatically 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).