Re: [Bug-XBoard] Please Help

[h.g. muller]

At 13:40 8-4-2009 -0700, you wrote:
> Hi
>
> > Well, if that is the case, peraps Steve could also try one of the
> > WinBoard 4.3 downloads
> > from the WinBoard forum. (
> > http://www.open-aurec.com/wbforum/viewtopic.php?f=19&t=49439 ).
>
> I just started to work a bit on XBoard (on Savannah) (porting it to gtk+
> to merge xboard/winboard, better bughouse support and some other small
> things). Didn't know that people did a winboard fork. Is there any
> reason not to apply your changes upstream to XBoard/Winboard?
>
> cheers
>      ARUN

Not really. Except that  have no idea what exactly the changes are, as I 
started
working from the Winboard_x sources, which at that time where already quite 
advanced
compared to 4.2.7, especially in graphics capabilities. And the diff 
listing would probably
be longer than the source code itself by now.

Merging WinBoard and XBoard would be a very good idea, as it is a real pain 
that everything
has to be done in duplicate. And in an ultra-cumbersome way, both in 
WinBoard and XBoard.
The practical problem I see is that WinBoard is graphically so much more 
advanced than
XBoard, that just upgrading XBoard to a widget set / graphics package that 
is cross-platform
would not be sufficient: it would essentialy throw WinBoard back into the 
stone age. So the
problem is how to backport WinBoard to XBoard, and that is not easy, as 
WinBoard is
based on very low-level Windows API calling.

I have started about six month ago with closing the development gap between 
XBoard and
WinBoard, (before that I was only paying attention to WinBoard), and 
already made some progress;
in particular with the engine-output window, and making many of the 
back-end features accessible
through the menus. The largest remaining problems are the use of those 
silly pixmaps in XBoard,
which contain both piece symbol and square background, and thus block the 
back-porting of
the board texture, and the lack of scalable piece symbols through some 
Linux equivalent of true-type
fonts. I also did not get to implementing the evaluation-graph window, as 
this is a graphics window,
and I would first have to learn how to operate the graphics package that 
XBoard is using. The
WinBoard code for this has unfortunately extremely poor front-end / 
back-end separation, calling
a Windows graphics routine nearly every other line. And of course it is a 
pain that Xt/Xaw does not
have a decent file-selector widget class.

I am very intersted in how you plan to implement the bughouse support. 
Perhaps XBoard should
be equiped with a new -slave mode, which would make it preserve its stdin 
and stdout file descriptors,
and create an input source based on them, like it does now when it fires up 
an engine, so that
a reverse startup (engine forking off a GUI, rather than the other way 
around) becomes possible.
The WinBoard instance running in ICS mode in a bughouse game could then 
handle all commnication
with the ICS, issue an observe command on the partner game, and relay the 
moves in that game
to a second instance of XBoard like it was a WB engine. (This would also 
require a new mode
'Machine Both' next to Machine White and Machine Black, where the 
firstChessProgram plays
both colors, which I wanted to add for other reasons anyway.)

Regards,
H.G.