Re: [XBoard-devel] Thoughts...

[Tim Mann]

On Wed, 10 Mar 2004 16:19:19 -0600, "Dan Jenkins" <address@hidden> wrote:
> Anyway, I got to thinking of a couple of things and was wondering what 
> others opinions are.  For the 3d models, I have some pieces that I threw 
> together in Blender, and wrote an export script to export them to my own 
> custom format, and then I have code that reads in that format.  These are 
> data files that aren't compiled into the executable as resources, and as 
> such, the app needs to know the path to look for them.  It appears that all 
> of the graphics for xboard currently are included into the code as arrays, 
> and thus, they are not loaded from disk at run-time as my 3d models would 
> be.  I could write a utility to convert the models and textures to do 
> something similar, but I don't like that idea, because I would like to 
> eventually add code to allow users to import their own 3d chess sets.

The default pieces are compiled in, but there is code in xboard (not
WinBoard, though, unfortunately) to let the user load other piece sets.
You could do that if you want, but having the pieces always be loaded
from a file seems fine to me.

> So... what I was thinking is that there could be a central path somewhere to 
> the files for all users, but the app could also check a directory in the 
> user's home directory, so that users could get their own sets and wouldn't 
> need root access to "install" them.

That's a fine idea.

> What I'm not sure about is what the 
> best way to go about determining the central path would be.

There's an easy, standard way to do that with autoconf.  If you look at
the generated Makefile.in, it has stuff like this in it:

prefix = @prefix@
exec_prefix = @exec_prefix@
bindir = @bindir@
mandir = @mandir@
...
CFLAGS = @CFLAGS@ @CPPFLAGS@ -DINFODIR=\"$(infodir)\"

When you run configure to generate the Makefile, it changes that to:

prefix = /usr/local
exec_prefix = ${prefix}
bindir = ${exec_prefix}/bin
mandir = ${prefix}/man
...
CFLAGS = -g -Wall -pedantic   -I/usr/X11R6/include -DINFODIR=\"$(infodir)\"

The prefix is set up by the user when he runs configure.  The default is
/usr/local, but Linux distros that ship xboard as a standard package
configure it with "./configure --prefix=/usr" to put stuff right under
/usr instead.

I believe the pieces would qualify as read-only architecture-independent
data, so they should go in datadir.  To get this defined in the
makefile, add the following to Makefile.in:

datadir = @datadir@

and change CFLAGS to:

CFLAGS = @CFLAGS@ @CPPFLAGS@ -DINFODIR=\"$(infodir)\" -DDATADIR=\"$(datadir)\"

Then within the program, the preprocessor symbol DATADIR will be defined
to be the name of the directory to look in, just as INFODIR is defined
to be the name of the directory where the Help / Info menu command looks
for the info file.

> Another thought I had was that, since it'd be nice to allow users to select 
> their own chess sets, it'd also be nice to be able to save that information 
> in something like a .xboardrc so that when they choose a different set, 
> shutdown, and restart xboard, their latest settings are loaded again.  This 
> could be nice not only for things like which chess set, but current options 
> like the "highlight last move" option etc.  Currently, I know you can 
> probably specify the options you want for everything on the command-line, 
> and possibly by using the .Xdefaults file, but it seems it would be more 
> user friendly to setup your options, and know that they will stay that way 
> until you change them again.  But then, maybe that's just me being used to 
> many Windows apps doing this...  What do you guys think?

That would be a nice feature too.  WinBoard does all its own command
line argument processing, and it has a slick way to load options from
files and save them to files as well as loading them from the command
line.  xboard uses Xlib's provided command line parsing, which gives it
the ability to load options from the X resource database (.Xdefaults,
~/XBoard, etc.), but no way to save options.

One idea for saving options would be to backport the WinBoard command
line option code and share it.  This could have some advantages in
uniformity between xboard and WinBoard, but it would lose the ability to
work with standard X resources.  Also, it's not as straightforward as it
sounds, because Windows gives us the command line as an unparsed string,
while Unix gives it after parsing by the shell.

Another idea would be to keep what we have now for xboard and just add
something that would write out the current values of interesting
resources to ~/XBoard.  That may be better, as it would keep xboard a
good X citizen and wouldn't involve trying to wedge a Windows model of
the command line onto Unix.

-- 
Tim Mann  address@hidden  http://tim-mann.org/