Re: [Bug-XBoard] Please Help

[h.g. muller]

At 16:35 8-4-2009 -0700, Arun Persaud wrote:

> hmm, yes I see that that would be a problem ;) Nevertheless I think we
> could try to work on getting features from your prog into savannah and
> start closing the gap, if that's fine with you...

I am not sure what exactly you have in mind. If you would add the features
one by one by isolating the code changes and additions I made (assuming this
could be done, which is probably already not the case), and putting those
in the Savannah code, by the time the gap is completely closed, the Savannah
code would have become identical to my code. So why not start from my code
in the first place?

transferring the features one by one only makes sense if they would not simply
be copied, but recoded. Now I am the first to admit that many of the changes
I made would benifit from recoding them from scratch. In the begining I did not
really know what I was doing, had only a very vague notion on how XBoard
worked, had never written anything other than a console application,
was completely unfamiliar with the Windows API, and had never run Linux.
So I had to program very defensively, making changes in a way that I could
be sure would not break anything, which in hindsight look very silly now
that I know the code pretty well.

For instance, I implemented the castling rights and e.p. status in separate
arrays, while logically they should have been part of the boards[] array
(e.g. they could have been stored in a dummy rank). And the bughouse
holdings are implemented as if they are part of the board, so that the front
end could be largely unaware of the fact that there were holdings, and
allows dragging pieces between the board proper and the holdings
just like betwen any other squares. The price is that the internal file numbers
as used in the back end is different from what you would expect. (e.g. the
lower-left corner is not (0,0) but (0,2) in a variant with holdings). This has
resulted in changes that pervade the entire code. (Not only in castling tests,
but everywhere where transgression of a board edge could be involved.
This was of course unavoidable for the right board edge or last rank,
now that even the board size proper is not fixed at a constant, but
also to the left edge.)

All this could benefit from recoding, but it would be a major job, and very
bug prone. While the code I have now, although kludgey, does work and
is well tested to the point that I believe it is bug free.

> One (small) issue is
> that xboard is a gnu project and whoever wrote the code would have to
> sign a form to give up his copyright on the code. The process takes a
> while, but is pretty harmless apart from that...
> ...
> hmm, my problem is that I'm on linux, so I never really looked at
> Winboard ;) Do you know if your code runs under wine? Guess I'll just
> give it a try...

I am quite a novice to Linux, and have never used wine. So I simply don't know.

> hmm, wondering what would be the best way to coordinate this. My plan
> was to convert xboard to gtk and then include winboard... perhaps I keep
> on working on that and once I have that, we can look into a way of
> merging features from your code into it?

If I understand you correctly, this conversion involves only changes in the
file xboard.c. Now this a file where I try to stay away from as much as 
possible.
But for adding all the new menus and auxiliary windows this was of course the
place they had to be implemented. And all such changes of course directly
involve the Xt/Xaw interface, or the graphics handling. So it will not do to
make the conversion Xaw->gtk in the Savannah xboard.c and then incorporate
my changes, as this would throw you back to Xaw for all the changes, as much
of the code you already would have converted might be replaced again by my
code using Xaw. Or worse yet, it might not be possible to recognize the place
where a patch would have to be made, because the code that was originally 
patched
by me was replaced and is now done in a diferent way.

So the most efficient way to do this might be to actually repeat the 
Xaw->gtk conversion
on the xboard.c from my 4.3.15 code, rather than repeat the 4.2.7 -> 4.3.15 
conversion
on a gtk-based version of 4.2.7.

> I also will try to separate the
> interface code as much as possible from the rest, so that using
> different widget sets should be easier... I'll also have a look at a
> diff of the codebase in the next few weeks to get a better feeling of
> how many changes have been made ;)

Well, one of the thing that most annoyed me in terms of front-end/back-end 
separation
is the fact that the definition of the command-line options is in the 
platform-dependent
files. Logically it belongs in the back-end; there is no reason why XBoard 
and WinBoard
should not support the same command-line options, and in the rare case 
where one
option is meaningless on a given platform it could simply be ignored. A 
file with default
option settings, like the winboard.ini, which remembers the settings from 
one invocation
to the next, is sorely missed in XBoard. It would be very convenient if 
XBoard could
use the same InitAppData() as WinBoard does. The only good thing about the 
way XBoard
defines command-line options is that it defines a default value with them. 
(But this is more
than spoiled by the fact that you have to define them in two different 
arrays...)

> yes, my plan is to convert all graphics to svg, which would make
> everything nice scalable and they can be easily handled by gtk.

OK, good! Will there be an automated way to convert existing pixmaps to the new
format that is needed? Note that XBoard 4.3.15 uses 22 different piece types,
rather than 6. It would be really nice if WinBoard and XBoard would use a
common graphics format here, so that piece symbos designed on one platform
could easily be used in the other platform as well.


> I hacked a few lines of code and now when I start a bughouse game (or
> obeserve one) a second xboard is started that logs in as a guest and
> observes automatically all games of the partner of that player. That
> board is then shutdown once I stop observing or stop playing bughouse by
> un-setting partner.
>
> This works very well for me, but I don't think it's portable across
> platforms.

It might also not be portable between ICS. Especially ICC is difficult with 
guest
accounts. I guess a viable solution would have to limit itself to only 
using a single
session, most likely meaning that one instance of XBoard would have to handle
all communication with the ICS, and then dispatch the messages as needed
to possible other instances.


> My problem is that I can't spend too much time on xboard... originally I
> only wanted to add a few small things to it, but somehow I ended up
> porting it now to gtk (or at least trying to).

Yes, I know. It is very addictive... ;-)

> Also I have to say that
> I'm not very good at coding ;) I normally can get things done, but it's
> more try and error over here than knowing what I'm doing :)

Same here. Especially when the API is involved I almost exclusively code
through the 'clone and mutate' method: I look for  feature (pop-up dialog,
menu) that is similar to what I need, duplicate it, rename all the external
variables, and then start tailoring it to my specific needs by trial and error.

> Anyway, I have my code in git:
>
> http://nubati.net/cgi-bin/gitweb.cgi?p=xboard.git;a=summary
>
> in case you want to have a look at it.

OK, I will. Not that the most recent (alpha) version of my code is at
http://home.hccnet.nl/h.g.muller/XB16.tar.gz
Perhaps you could have a look at the xboard.c it contains to get an impression
on how big the difference is, and if this poses a severe problem. Note that
when I started to backport the Winboard_x functionality to XBoard, I created
other front-end files as well, keeping the same subdivision of the code as in
the WinBoard front-end. So I have created xoptions.c and xengineo.c analogues
to woptions.c and wengineo.c, just like there already existed an xhistory.c
analoge to whistory.c in 4.2.7. All these 'x-files' would have to be 
converted to
gtk use.

> BTW: are you playing on FICS or ICS? I only play on FICS and have no way
> of testing on ICS, neither can I test on Windows, which would both be
> helpful at one point... in case you need someone to test xboard on
> linux, let me know ;)

I suppose you mean ICC here. I have a computer account on ICC, but my
engine is not regularly on line, and I only use it for participating in on-line
tournaments like CCT or WCRCC. I don't really play Chess myself, my main
interest is to develop engines for it (and many variants). Testing on ICC is
indeed a problem, as I don't have two accounts, computers cannot challenge
Humans, and virtually all computers all refuse challenges by other computers.
And I have no time to wait for someone to challenge me, especally not in 
variants
such as Shatranj where I would have to wait for ever anyway.

Fortunately I also have hacked the Lasker ICS code, so I can run my own ICS
and test on that ith as many accounts as I want. And it even handles variants
like Xiangqi and Gothic Chess, which are not provided on any other ICS.

Regards,
H.G.

> cheers
>      ARUN

P.S. is it still proper to send copies of this discussion to bug-xboard? It 
seems
more fit for the xboard-devel mailing list (to which I have not subscribed, 
but I
suppose that I can do that, and mail to it anyway.)