Re: [Gnushogi-devel] gnushogi xboard support

[h . g . muller]

Op Di, 22 oktober, 2013 11:27 pm schreef Yann Dirson:
>
> A couple of .xbo files / profiles / whatever as we previously
> discussed, to avoid usage of a shogi theme to "bleed" onto subsequent
> non-shogi games, could be a good addition to the list.
>
Perhaps I should port the WinBoard View->Themes dialog to XBoard after
all. This should be very little work, as all the back-end support is
already in place, and the front-end is basically a cloned version of the
Load Engine dialog, using the -themeNames list in stead of the
-firstChessProgramNames list. This could go into 4.8 as well, then.

But I am not sure how to best do the configuration. For WinBoard the
installer creates menu items in a new menu group for starting WinBoard in
various modes, and a lot of .xop (which stands for 'XBoard options', btw,
a mime type that did not seem to be in use yet) files in the folder of the
winboard.exe. Windows people either use the system Start menu, or go to
the install folder to click the .xop files there. Unfortunately neither of
these methods seems very suitable for XBoard. I understand some Linux
distros have deprecated the system menu, meaning that they will ignore the
.desktop files we supply when installing XBoard.And you cannot expect
people to first go to /usr/share/games/xboard to click installed .xop
files there. As for command-line argument shortcuts, like "xboard
@minishogi", XBoard would look in the current directory for the
minishogi.ini file with options. If people would have to type "xboard
@/usr/share/games/xboard/minishogi" it would sort of lose its convenience.
I use the convention now that settings files that do not have an extension
specified will get .ini appended (a very Windows-like thing)

Perhaps I should change that for XBoard, into that they get
"/usr/share/games/xboard/configs/" prefixed as well. Or force people to
type "./foo" if they mean foo.ini in the current directory, and otherwise
look for foo.ini in $(datadir)/configs/. Then we could install settings
files shogi.ini etc. there, and people could invoke them by simply typing
"xboard @shogi". (The shogi.ini file there would contain a line "-variant
shogi", as well as "-fcp gnushogi" and "-scp gnushogi", to change the
default engine, which they can always be overruled by typing "xboard
@shogi -fcp bonanza", provided they take care to specify the engine after
the settings file. The supplied shogi.ini would also redirect the file for
saving and loading settings, so that shogi settings would not leak to
other games.

That doesn't sound so bad. We could supply settings files shogi, xiangqi,
and chu, which each would specify their own save file (~/.xboard_chu_rc
etc.) to prevent leakage between them. Simpler settings files (just
containing the minor, volatile tweeks needed to play. e.g. mini-Shogi)
could be included for inclusion with installed engines, or on the command
line ("xboard @shogi @mini -fcp shokidoki" or "xboard @chu @sho -fcp
hachu", where @chu and @shogi would take care of display theme and specify
which settings file to save on, while @mini and @sho would take care of
volatile board-size overrides, .fen file with initial setup etc.)

> OYAOH, the minishogi patches can probably be merged anyway, since they
> don't have any impact on the code outside of ifdefs.  We could include them
> for convenience, that would just make packaging easier, while giving a
> "heads up" to other people and pushing out the fixes ; 1.5
> could then include both xboard protocol and a properly integrated minishogi
> using the "variant" command.

Well, it would be indeed great if GNU Shogi could be switched between
Shogi and mini-Shogi at run time. I don't know if this would be feasible,
though. Did you know there also is a 6x6 mini version compatible with
regular Shogi (Judkins Shogi)?
>
> Note I just pushed a new patch, about this ElapsedTime/polling issues,
> for comment.  To win32 branch just because it does not commute to master
> without conflict, and will be rewritten anyway.
>
This does seem closer to the original FIONREAD stuff. I guess I should
have put the WIN32 polling there in the first place, except that I
originally had no idea that Elapsed time would already do the polling I
needed to get out of ponder. I am kind of used to engines not immediately
responding to 'quit', when they are thinking. XBoard sends a SIGKILL a
configurable delay after 'quit', which handsomely takes care of that
problem. :-) It seems that GNU Shogi mainly has this because it has a
'both' mode where it plays itself, and would thus always be thinking.

In XBoard protocol interrupting thinking (as opposed to pondering or
analysis) could be useful for receiving "force" and "?" (move now)
commands. GNU Shogi does not have a "move now", I think, but in the future
we might want to make one.

Regards,
H.G.