Re: [XBoard-devel] 4.9.0 what's new

[H.G. Muller]

Op 3/29/2016 om 7:06 PM schreef Joshua Pettus:
> Sorry to hear that. :-( 
Well, good for XBoard. :-)  And we had some sun too.

> Sorry I didn’t think to try it out.  I so rarely use pre move, except by 
> accident, as it can so easily get me into trouble.  I know some people who like 
> really fast times absolutely depend on it.
This is the problem. There are so many things XBoard can do now, that 
many of them I don't do at all. The Shuffle dialog was another one, I 
accidentally discovered because I was adapting the man help for it. I 
never open that dialog... Because I was not even sure anymore what the 
buttons did, and had to describe it in the manual, I had to press them 
to find out. And then it turned out they did not do anything at all! The 
adding of the 'Fischer castling' checkbox a year ago had broken them, 
because they were updating the value of another option, which used to be 
number 1, but had been shifted to number 2 now. This makes me really 
wonder how many errors there still are that we have no idea of.
> I have however found one more thing that maybe we should look into.  If it’s 
> not to late.  It looks like one click moving is fairly broken.
Yeah, that is another good example. Funny enough I just discovered it 
before reading your mail, while fooling around a bit with WinBoard, to 
see if the latest changes in the XBoard board drawing had not broken 
anything.
>   Far too often it is assuming moves that I did not intend when there are other 
> legal moves available  (usually the assumed move is really bad).  For instance 
> as white as first move I click on the Knight and it automatically moves to f3, 
> not a bad move in this case, but I don’t have the option to move to h3. Is this 
> intended?  If it is too late then don’t worry.  It’s been like this in 4.8 and 
> no one appears to have complained.
That was the most shocking part: it was totally broken in an official 
reelase 1.5 yr old, and no one complained!
I had broken it when doing the Betza-defined move generator. In Betza 
descriptions you often mention moves twice. E.g. a Rook that can jump to 
the second square would be RD, but if the first square is empty the 
normal Rook part could already reach the D square. But the move 
disambiguation originally just counted the number of generated moves 
that matched the move description. Since there would be two, it would 
then refuse the move Ra3 (with the R at a1 and a2 empty) because it 
considered it ambiguous. So I ignored duplicates by testing if a 
generated move had the same from-square as the one already found. For 
SAN moves that was good enough, as the to-square is always given. But 
for one-click moving XBoard uses disambiguation with given from-square 
and unknown to-square. And this extra test now considered all the moves 
of the same piece duplicats, leading to the conclusion that the first 
move was the only one!
> I would like another dev release if just to get the  “Browse” button translated 
> :) but it’s not a big deal I suppose.
Shouldn't it already be translated? In xoptions.c there is a _(...) 
around it, where we create the browse button for file and path text entries.