Re: [Gnushogi-devel] gnushogi xboard support

[Yann Dirson]

On Wed, Oct 23, 2013 at 11:50:11PM +0200, address@hidden wrote:
> Op Wo, 23 oktober, 2013 10:40 pm schreef Yann Dirson:
> 
> > I'd say using a default search path, which may include several dirs
> > including ".", when there is no "/" in the name, and if there is one just
> > look for a relative path, would be OK.
> 
> Well, that i basically what I have done now: first search ".", then search
> $(datadir)/games/xboard/themes/conf . I could extend that to searching
> ~/.xboard in between, if you think that is useful. (I don't know if there
> is any Debian standard for where applications should store user-specific
> settings.)

Well, there's no Debian-specific standard on this that I know of, only
the traditionnal "everything in one basket" ~/.whatever, and the
freedesktop "basedir" spec suggesting ${XDG_CONFIG_HOME:~/.config/whatever}

http://standards.freedesktop.org/basedir-spec/latest/

> > Could be good as well - even better would be providing bash/zsh
> > completion scripts to propose those settings.
> >
> I have no idea how that would work. You should realize my Linux knowledge
> is limited, and I almost exclusively use Windows myself. On Cygwin I
> basically only use gcc, make, grep and ed.

I have only limited experience with that one myself, but well, it
would just be a nice goodie :)


> Perhaps I should make XBoard such that if the engine does explicitly say
> it does not support variant normal, by sending a variants feature that
> omits it from the list, it should automatically switch to a variant that
> it does play? I cannot quickly think of an argument against that. It
> certainly seems better than exiting XBoard with a fatal error, as it would
> now.

It is indeed something that would have probably surprised me less than
the current behaviour.  Requesting less flags from the user for a
reasonable default is usually a good idea.


> > Btw, I'm not
> > sure using just "sho" and "chu" for names is a good idea, few people will
> > understand before looking, that they are shogi variants.
> 
> Actually the problem seems bigger than that. How would they even know that
> these files existed? They won't go to /usr/hare/games/xboard/themes/conf
> to give it a good look, and no one ever reads manuals. Wondering what they
> do seems a minor problem compared to that. I am sure that people who do no
> Chu Shogi would immediately realize what 'chu' means. And if they don't,
> they probably won't care whether it is a shogi variant or makruk.

Indeed, that's the problem the shell completion would address -
assuming we're just talking about shell users here, since people
launching xboard from a GUI would rather use .desktop or other menu
entries.


> > Nothing's impossible, and I guess that one is not so hard.  Basically
> > lots of global constants to move under the umbrella of a single struct, to
> > be exchanged at will to change the variant.
> >
> > * availability of lance and knight are easy to turn dynamic, kinda
> > replace some ifndefs with if (game->has_knight); those [NO_PIECES] arrays
> > will need some thought, but once for all; once for loops on piecetype
> > index too; a number of #ifdef that are just here because those pieces were
> > suppressed for simplicity, will just vanish
> 
> There should be no need for explicitly removing those pieces from the
> program. I don't do that in Shokidoki either. It just starts from an
> initial position where they are not on the board or in the hand, and they
> won't ever appear from out of nothing. (In Chess they could, when a Pawn
> promotes!)

In the case of the minishogi port, it was a shortcut making things
much simpler: the current code is not designed at all to cope with
unused piece types in the list.

> >
> > * board-size changes are easy too, some hardcoded strings could even
> > be generated, some silly ones like direc and max_steps *should have* been
> > generated in the beginning; many static arrays to calloc instead
> 
> In Shokidoki I don't really change the size of the board, but just use a
> smaller part of it. I used a board with a rim of 'edge guards' around it
> that made off-board squares inaccessible, and just put two more rings of
> edge guards inside the 9x9 area. Note that this also gets the promotion
> zone right for mini-Shogi. I don't know if a similar thing could be done
> with GNU Shogi; I never looked at its data structures.

It's quite similar indeed, that could work, and avoid to change things
like direc and max_steps - good point.