Re: [Bug-XBoard] "-pieceMenu true" argument, don't works.

[H.G. Muller]

Sorry for the late response.

Context menus were never implemented in the GTK version of XBoard; the 
Piece Menu was considered deprecated in favor of sweep selection, and 
the -pieceMenu option was only kept for the benefit of the Xaw version.


Sweep selection turns out not to be so easy on touchpad devices as it is 
with a mouse, though. So in the development version (currently only at 
http://hgm.nubati.net/cgi-bin/gitweb.cgi , the v4.9.x branch) I have 
been experimenting with an alternative (currently selected by -pieceMenu 
true). This would not pop up the old-style piece menu on a right-click, 
but instead a note that explains all the things you can do to edit the 
position with this new method. Basically it amounts to clicking the 
clock once to call up a 'palette board' containing each piece once, and 
snatch pieces from that with a right-click for repeatedly dropping them 
on empty squares by left-clicking. (But if you only need a single copy 
of that piece, you can simply move it to the disired location as well.) 
Extra (left-)clicks on pieces for which this is relevant can be used to 
grant or revoke (castling or e.p.) rights.


Op 3/30/2019 om 12:40 PM schreef Γιώργος Κωστόπουλος:

Hi! :-)

I'm giving at console "xboard -pieceMenu true" and XBoard starts.
Going at Edit -> Edit Position -> right (or left or double) click on
an empty (or not) square -> Nothing happens. No menu.

Last stable version (4.9.1) from repositories at Devuan ASCII (stable)
x64 KDE (Debian stable based).

Bye!
G.

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

---
This email has been checked for viruses by AVG.
https://www.avg.com




___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] No sounds on XBoard running on FreeBSD 11.1-amd64

[H.G. Muller]

XBoard invokes an external sound-player program to produce sounds. In 
the Options -> Sounds dialog it can be selected which one. So the first 
step would be to look there to see what sound-player XBoard is 
configured to use. Then you can check if that sound-player command works 
from the command line (e.g. with one of the .wav files that come wth 
XBoard).



Op 8/3/2018 om 3:04 PM schreef Paramaribo Ahues:
I have installed XBoard 4.8.0.20151020 on my operational system 
GhostBSD 11.1-amd64, all is OK, the program plays, analyses etc., but 
I do not hear any sound. There are NVIDIA driver ver.390.77 and 
Realtec AC-97 built-in sound driver on my machine. PLayers work, so as 
WEB browser, I can listen music and watch films, but XBoard (and Scid 
too!) is silent. What to do?


    Sincerely yours, Stanley.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

---
This email has been checked for viruses by AVG.
https://www.avg.com



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #53053] Crash when using ru_RU locale

[H.G. Muller]

That an engine is crashing is never the fault of XBoard.

It just means the engine is buggy or incorrectly installed.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Xboard 4.9.1 bug

[H.G. Muller]

To get the promotion popup you should make sure that "(Almost) always 
promote to Queen" is not ticked. When it is ticked you, must select 
other pieces by first dragging the 7th-rank Pawn backwards until you get 
the desired piece. This is why it says "Pull Pawn backwards to 
under-promote".


In setup mode the piece is selected by the amount of (vertical) movement 
between the button press and release; you just move until you see the 
piece you want, and release then. It should also be possible to step 
through the piece type by repeatedly right-clicking the same square.


This method of setting up a position is only recommended for late 
end-games, with just a hand full of pieces. For complex position it is 
much more convenient to click the active clock until the 'palette board' 
appears, where each piece type occurs exactly once. You can then drag 
the pieces where you want them (or off board when you don't need them), 
using Ctrl to duplicate what you need twice (and add Pawns by simple 
right-clicks).



Op 1/12/2018 om 5:51 AM schreef Roy Prasad:


Another bug:  I can only promote a pawn into a queen. I don’t get the 
choice to promote into anything else.


Roy Prasad

*From: *Roy Prasad 
*Date: *Thursday, January 11, 2018 at 8:44 PM
*To: *
*Subject: *Xboard 4.9.1 bug

I have Xboard 4.9.1 running on my MacBook Pro with High Sierra. When I 
am in the Edit Position mode, the right mouse click does not work. In 
the older Windows version, I could clear a board, then right click on 
any square. That would bring up a menu of pieces I could place on that 
square. On my MacBook, any time I right click on a square, a White 
Pawn inserted there (e.g., see screen shot below).


Roy Prasad


 
	Virus-free. www.avg.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] xboard doesn't detect a server side disconnection in ics-mode

[H.G. Muller]

Does this also happen in the latest version of the  v4.9.x branch of the 
repository at hgm.nubati.net ?


There is a commit in there that solves a problem of not detecting an 
engine crash in the GTK  build,
which sounds similar to not detecting the termination of an icshelper. I 
have not pushed that to

Savanah yet.

Op 1/13/2017 om 11:14 AM schreef diffset:

Hi,

when using xboard in ics-mode it doesn't detect a server side
disconnect. E.g. if you write „logout“ in the ics input box or the
attached terminal the logout out screen from fics is displayed and
xboard keeps running with a 100% processor load. Any commands sent to
fics by xboard (e.g. by clicking on the board to see the seek graph)
result is a crash (broken pipe).

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #48600] Xboard didnt start

[H.G. Muller]

I have seen this complaint before, and it turned out to be due to a line

-firstChessProgram

in the master settings file (/etc/xboard.conf), which packagers for some 
distros seem to have added.
Removing that line should solve the problem. I have no idea why 
packagers would wreck XBoard
before distributing it; perhaps you should submit a bug report about 
that to the applicable Linux distro.


If you install XBoard from source, from the tar ball supplied at GNU 
Savannah (or from git),

you should not have this problem.

Op 7/23/2016 om 10:22 AM schreef Szentpétery Csaba:

URL:
   

  Summary: Xboard didnt start
  Project: XBoard
 Submitted by: szcsaba
 Submitted on: Sat 23 Jul 2016 08:22:30 AM GMT
 Category: XBoard (X11)
 Severity: 3 - Normal
   Item Group: Crash
   Status: None
  Assigned to: None
  Open/Closed: Open
  Discussion Lock: Any
  Release: None

 ___

Details:

Hi I installed xboard from appcafe and it doesnt start. I get this message
when I start in terminal:
No value provided for argument -firstChessProgram





 ___

Reply to this item at:

   

___
   Message sent via/by Savannah
   http://savannah.gnu.org/


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard




___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Help for accessibility.

[H.G. Muller]

There should already exist an accessible version of XBoard, in the gtk3 
branch of the XBoard repository.


This should work under Linux in combination with the Orca screen reader. 
Unfortunately this screen reader does not seem to work on the Mac, and 
the native Mac screen reader seems to completely ignore non-native 
applications such as XBoard. It is not clear how this problem could be 
solved.



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Some bugs while compiling on OS X 10.10.5

[H.G. Muller]

Op 12/10/2015 om 2:58 AM schreef global667:

Hello,

I got many, many warnings, while building the sources under OS X 
10.10.5 with clang (see attachment), but it works.


Just to check if some of these warnings are really errors, could you try 
the following?


1) Start XBoard as "xboard -ncp -showTargetSquares true -testLegality true"
2) Select Chu Shogi from the File -> New Variant menu (lower-right button)
3) Play the white Lion from f3 to e5
4) Play the black Lion from g10 to e8
5) Play the white Lion from e5 to d6
6) Click the black Lion on e8

Clicking the Lion should highlight the squares it can move to by colored 
dots.
The question now is whether after (6) the square of the white Lion (d6) 
is highlighted this way in red

(allowing the black Lion to capture the white one) or whether it isn't.

H.G.
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] xboard startproblem,20150906.1

[H.G. Muller]

Op 9/6/2015 om 9:25 PM schreef aaabbcc:


xboard -v
xboard version 4.8.0

  configure options: prefix=/usr; datarootdir=/usr/share; 
datadir=/usr/share; gamedatadir=/usr/share/games/xboard; 
desktopdir=/usr/share/applications; mimedir=/usr/share/mime/packages; 
iconsdir=/usr/share/icons/hicolor/48x48/apps; 
svgiconsdir=/usr/share/icons/hicolor/scalable/apps; 
infodir=/usr/share/info; sysconfigdir=; update_mimedb=no; NLS=yes; 
GKT=no; Xaw3d=no; Xaw=yes; ptys=pipes; zippy=yes; sigint=yes


Note that from XBoard 4.8 on the GTK build is the preferred one, and the 
Xaw build is sort of obsolete. (Not that this has anything to do with 
the problems you report...)





Hi,

>> I have installed both  programms, gnuchess & xboard.

>>
>> If I start xboard alone, I get an error window
>>  "error:first chess programm (fairymax) has finished 
unexpected"


Fairy-Max is the default engine for XBoard, so normally it should work 
when you have installed xboard and fairymax, and invoke xboard without 
arguments.
If the fairymax package would not have been installed, I would have 
expected the error message from XBoard:


failed to start first chess program fairymax on localhost: no such file 
or directory


The error message you show implies that Fairy-Max was present, but 
somehow crashed after XBoard's attempt to start it. This points to a 
problem in the installation of the fairymax package. What happens if you 
type the command "fairymax" on the command line (and if it starts then 
the commands "xboard" and "protover 2" (all without the quotes))?



>> In the window "edit engine list" there are only listed:
>>  GnuChess, Crafty, Fruit 2.1
>> (no fairymax).
>> Is that a bug ore a feature?


This must be a left-over from some earlier version? We distribute XBoard 
4.8.0 with in its master settings file the setting


-firstChessProgramNames {fairymax
"Fruit 2.1" -fcp fruit -fUCI
"Crafty" -fcp crafty
"GNU Chess" -fcp gnuchess
}

which then becomes the default engine list. Fairy-Max is obviously there 
as first item; also the order of the remaining engines is different from 
what you see. This can have no effect on running Fairy-Max as default 
engine, btw. It merely means that you would not be able to select 
Fairy-Max through the Load 1st/2nd Engine menu items. You can check in 
/etc/xboard/xboard.conf what the install default of the engine list is; 
however, if that was later changed by editing the engine list, this 
change is saved in the "persistence file" with user settings 
(~/.xboardrc), which overrules the install defaults and is inherited 
from previous XBoard versions. (Some people have long engine lists, and 
would not want to lose those when they upgrade XBoard...) So I am pretty 
sure that there the list is defined as what you actually see. The 
question is only how it got to be different from the master settings file.



>>
>> If I load the engine "crafty", I get the error message
>>  "error:first chess programm (crafty) has finished unexpected"


Again, this is strange. If you do have Crafty installed, "xboard -fcp 
crafty", or selecting Crafty from the Engine menu, should work. And if 
you don't have it, you should get another error message. Again, what 
happens if you run Crafty from a terminal (in the same way as fairymax 
above)? This error message points to a problem in the engine, where 
XBoard managed to find the engine binary and start it, but then receives 
an 'End Of File' when listening to the engine, indicating that the 
engine somehow died. There is nothing XBoard can do to prevent an engine 
from committing suicide. To know exactly what goes on between XBoard and 
the engine you can start XBoard with the extra argument -debug: "xboard 
-fcp crafty -debug". It will then create a file xboard.debug in the 
current directory, which contains a complete log of everything the 
engine and XBoard said to each other. Sometimes this points out why an 
engine died, if it is friendly enough to print a reason before doing so. 
(E.g. if its hash-table memory requirement exceeds the amount of memory 
your system has available.)



>>
>> If I load "fruit" ,I get the error messAGE
>>  "error:first chess programm (polyglot -noini -ec "fruit"
>>  -ed "." -uci  NalimovCache=4 -pg ShowTbHits=true)
>>  has finished unexpected"


Well, Fruit is a UCI engine, so it can only run through the Polyglot 
adapter. So you must have the polyglot package installed (and obviously 
the fruit package) to be able to run Fruit. Again, it is strange 
Polyglot, which as far as XBoard is concerned is the engine, seems to 
start and then die. Polyglot is usually very helpful in popping up error 
messages as to why it exits, when it experiences a fatal error. But I 
guess if we can diagnose and solve the problems with Fairy-Max and 
Crafty, this one will disappear as well.



>> Loading "Gnu Chess", I can play 

[Bug-XBoard] librsvg and ./configure

[H.G. Muller]

It seems ./configure does not check for the presence of librsvg, so that 
some people get cryptic error messages on the -lrsvg-2 argument during 
linking. E.g. see


http://www.open-aurec.com:8080/wbforum/viewtopic.php?f=19t=53478



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #45599] Xaw frontend build failure in OS X

[H.G. Muller]

I suppose this is a consequence of the gtkosx integration patches being 
activated when compiling on OS X,
even if the desire is not to compile for the integrated version, but for 
a version intended to run on the

Unix-compatible OS X interface (XQuartz?)?

I suppose we should surround the OS X specific patches not by #ifdef 
__APPLE__, but by a compiler switch
set in the configure process, through an option --with-gtkosx, so that 
people could still compile the Linux

version of XBoard on OS X?

H.G.

Carlos Sánchez de La Lama schreef op 7/22/2015 om 9:19 AM:

URL:
   http://savannah.gnu.org/bugs/?45599

  Summary: Xaw frontend build failure in OS X
  Project: XBoard
 Submitted by: csanchez
 Submitted on: mié 22 jul 2015 07:19:43 GMT
 Category: XBoard (X11)
 Severity: 3 - Normal
   Item Group: Installation/Configuration/Packaging
   Status: None
  Assigned to: None
  Open/Closed: Open
  Discussion Lock: Any
  Release: None

 ___

Details:

Xboard build process failed during in Xaw/xboard.c, due to XK_Meta_L symbol
not being defined (along with many other XK_* symbols).

Seems X11/keysym.h (which in turn includes X11/keysymdef.h) was missing. I do
not know if it gets included by some other header in other platforms, but in
my OS X (powerpc-apple-darwin8.11.0) it did not.

Attached patch fixes the problem.



 ___

File Attachments:


---
Date: mié 22 jul 2015 07:19:43 GMT  Name: xboard-4.8.0.patch  Size: 360B
By: csanchez
Patch to enable build in OS X
http://savannah.gnu.org/bugs/download.php?file_id=34483

 ___

Reply to this item at:

   http://savannah.gnu.org/bugs/?45599

___
   Mensaje enviado vía/por Savannah
   http://savannah.gnu.org/


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Freeze

[H.G. Muller]

Tom schreef op 4/13/2015 om 5:19 PM:

Hi the game freeze`s early on.   Thanks


Which game?
XBoard or WinBoard?
Which version?
Which build (Xaw or GTK)?
Which engine?



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard




___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Accessibilty request.

[H.G. Muller]

If there is no screen reader to read out the text of the currently 
selected dialog item, and no way to navigate between the items though 
keystrokes, an application is basically useless to visually impaired 
people. I don't know how much of that the Gtkosx integration provides. I 
guess it would in theory be possible to associate an event handler with 
every dialog item, which is called when the item receives focus. This 
could send the name of the item to some speech synthesizer, and remember 
the item. A key event handler could intercept the keystrokes intended 
for navigation, and then request the next or previous item to receive focus.


If we do this ourselves we would have to create a lot of infrastructure 
for this. But because we do actually have an extra 'layer' between GTK 
and the XBoard 'business logic' in the form of the generic dialog 
creator, it would be possible to put the required infrastructure in the 
latter, so it automatically works for all dialogs.


Joshua Pettus schreef op 1/15/2015 om 4:26 PM:

I was imagining such an extra program or perhaps just a command line switch that can 
be triggered via a “shortcut.

We can have xboard relay stuff to the terminal app which is Cocoa based. I 
wonder how that would work...

But I fear I am not really a programer.  Just a fairly knowledgable tinkerer.  
Hence why there isn’t a cocoa version in the first place. Although VO aside 
this hasn’t been much of a problem with OSX integration and has made 
maintainability much easier.  I’m working on learning, but I don’t see getting 
to C/C+ for a long time. Harm is really the person to talk to, If he isn’t too 
busy.  But he doesn’t have a mac.

Josh


On Jan 15, 2015, at 10:09 AM, Gabriele Battaglia iz4...@libero.it wrote:


Joshua Pettus, alle 16:05 del 15/01/2015, digitò:

Perhaps there is some kind of signal from the OS, unfortunately without 
gtkmacintegration’s help, there is no way to detect if VO is running.



Oh, sorry for that.
And provide a switch to launch the app with?
Maybe just blind people could launch the app with a special swithcer into a 
command line, or they maybe set up a checkbox within options.
Or You maybe start a new, small project called XBoard4 Blinds or accessible 
XBoard, with just a little graphics on it that's provide a simple way to 
comunicate, in terminal style, with UCI and WB engine.
That's a bit out of your duty, I'm aware of it, but it could be exciting too, 
surely a new experience for you coders, why not?
Gabriel.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Chinese Chess on xboard

[H.G. Muller]

Do you already have an engine in mind? Both UCI and UCCI Xiangqi engines 
exist. Most are closed source, but many are free. But alas, only 
available as Windows binary. Elephant Eye is an intermediately strong 
open-source UCCI engine that can be compiled for Linux.


The way to run UCCI engines is use the uci2wb adapter (obtainable from 
the git repository at  hgm.nubati.net), with an -x flag. So you would 
have something like


xboard -fcp uci2wb -x eleeye

assuming that uci2wb and eleeye are in your search path (e.g. in 
/usr/games/). If not you would have to specify the directory, e.g.


xboard -fcp ./uci2wb -x ./eleeye EleeyeDirectory  -fd uci2wbDirectory

I guess you could run Windows binaries by invoking wine (using two 
levels of quoting)


xboard -fcp {uci2wb -x wine someWindowsXQengine}

but I have never tried that. I remember Kou was a pretty strong free XQ 
engine. For UCI engines you would not have to use the -x flag with uci2wb.


If you plan to run many different UCCI engines you can configure XBoard 
to make the -fUCCI flag work. To this end you must run XBoard once as


xboard -uxiAdapter {uci2wb -x %fcp %fd}

and after that you can use

xboard -fcp anyUCCIengine -fUCCI

to automatically invoke uci2wb (which must be in the system's search 
path, or you should have given the full pathname in the -uxiAdapter command.

Regards,
H.G.

Loic Duros schreef op 11/6/2014 6:55 PM:

Hi:

I'd like to run the newest version of xboard with a Chinese Chess 
engine. Is there a step by step guide on how to do this? Also, I 
noticed from the page when the chinese chess engines are available 
that the most powerful one is closed-sourced (so nonfree?) as it is 
stated in the page linked from gnu.org/s/xboard 
http://gnu.org/s/xboard. What is the recommended free engine for 
chinese chess?


Apologies if this has been discussed previously, but I haven't found 
it (yet) in the archives.



Thanks,

Loic


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #43323] -scp won't invoke engine with options

[H.G. Muller]

To start XBoard in a specific mode, you can use

xboard -initialMode MachineWhite

(or whatever other mode you want to start it in).

H.G.


Dario Niedermann schreef op 11/3/2014 7:27 PM:

Follow-up Comment #3, bug #43323 (project xboard):

Ermm... Scratch that last paragraph. I was trying to get XBoard to start in
'Machine *White*' mode (since it starts in 'Machine Black' mode when I call it
normally i.e. with -fcp).

 ___

Reply to this item at:

   http://savannah.gnu.org/bugs/?43323

___
   Message sent via/by Savannah
   http://savannah.gnu.org/


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard




___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] FICS seekgraph auto-refresh doesn't remove dots

[H.G. Muller]

Apparently there is no solution to this problem:

The ivar that needs to be set on FICS to control the sending of 
seek-removal is locked at the start of the session. It can only be 
changed by logging off and on again.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Make non supported variant for engine non fatal

[H.G. Muller]

Joshua Pettus schreef op 9/25/2014 5:20 PM:

Anyway we can make the non supported variant error for an engine, non fatal for 
xboard?
What error exactly do you mean? You should not be able to switch to a 
variant the current first engine does not support. The second engine is 
only woken up when you hit Two Machines. But this gives me a non-fatal 
error popup, saying the second engine does not support the variant. 
(Minor bug: the Two Macines menu remains check-marked after this, in 
addition to Edit Game, which is the mode it leaves me in.)


When XBoard is set for 'normal', and I load HaChu (which does not play 
'normal') as first engine, it does not give me an error. (Just a 
rejection of my move by HaChu when I start playing, which probably also 
should be considered a bug.) I did not get anything fatal.


I guess it should have switched to a variant that HaChu does play (the 
first one of its variants-feature list) when it was loaded as first 
engine. XBoard already does that when you would load HaChu from the 
command line without explicit -variant specification:


xboard -fcp hachu

would start up in Chu Shogi (and the second engine would also be hachu!).

OTOH, when an engine does not support 'normal', it was sort of expected 
you would install it with a -variant option that would specify a variant 
it does play. It would then appear in the Load Engine listbox as hachu 
(chu) (say). In this case it would auomatically switch variant on 
loading it, and there would not be a problem.




___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] FICS seekgraph auto-refresh doesn't remove dots

[H.G. Muller]

Joshua Pettus schreef op 9/24/2014 6:52 PM:

Hi,

I just noticed that the seekgraph dots don’t automatically remove dots anymore 
when the seek ends,  this is in FICS.
I see seek dots disappear from the graph when I logon to FICS. Are you 
sure Auto-refresh Seek Graph is ticked? It could also be a FICS problem; 
you need some support available only through ivars to be informed of 
seek-ad expiration. But I think XBoard should set the required ivar 
automatically when the auto-refresh option is on.


You remark led me to a WinBoard bug, however! 8-)

Turns out when you display the board with a border around it (unlike 
XBoard, WinBoard can do that), the seek graph is not aware of the 
border, and is drawn starting in the upper left corner, with the size of 
the board, rather than the size of the board+border. I guess I should 
scale it up to cover board+border, rather than shift it to just cover 
the board. No reason I can see to keep displaying a border around the 
seek graph.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] FICS seekgraph auto-refresh doesn't remove dots

[H.G. Muller]

It seems that this problem should both exist in XBoard and WinBoard.
It definitely is sub-standard behavior that this would need a restart. 
It is not very

easy to fix, however, as what you have to send to the ICS to get the removal
notification is different on FICS and ICS. And I guess a good fix should 
really also

switch the feature off again when the user unticks it interactively.

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #43138] engineoutput alignment issue

[H.G. Muller]

Thanks for your suggested patch. But I think  with current engine speeds 
it would be
better to introduce an abbreviation 'G', to be used exactly like 'M' 
would be for 1000x

lower node count, whenever the node count reaches 1000M or higher.
To have extra digits when the count is below 100M is a good idea, though.

djoot schreef op 9/4/2014 2:31 AM:

There is an alignment issue when searched nodes  1000M, padding code inserted
two spaces after a value like 1000.1M, making the field too wide.

Attached images and a proposed patch.



 ___

File Attachments:


---
Date: Thu 04 Sep 2014 12:31:40 AM GMT  Name: 0003-ValueFormat.patch  Size: 3kB
   By: djoot

http://savannah.gnu.org/bugs/download.php?file_id=32020
---
Date: Thu 04 Sep 2014 12:31:40 AM GMT  Name: engineoutput.png  Size: 122kB
By: djoot

http://savannah.gnu.org/bugs/download.php?file_id=32021
---
Date: Thu 04 Sep 2014 12:31:40 AM GMT  Name: engineoutput-patched.png  Size:
119kB   By: djoot

http://savannah.gnu.org/bugs/download.php?file_id=32022

 ___

Reply to this item at:

   http://savannah.gnu.org/bugs/?43138

___
   Message sent via/by Savannah
   http://savannah.gnu.org/


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard




___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] a Segmentation fault bug

[H.G. Muller]

Binbin Zhang schreef op 7/23/2014 6:14 PM:

3. Click buttons  in this order

Edit  -- Game-list tag -- Players
4.Oops, xboard quits abnormally

Ah yes, when you double-click Players (or in fact any item in the 
listbox), it makes XBoard segfault in any mode.


This went so far undetected, because you are not supposed to do this! ;-)

The problem is that the first Option in the discriptor of the dialog 
(listOptions[] in dialogs.c) has  initialized for its textValue field, 
rather than NULL. For a ListBox Option the textValue is (ab)used as a 
pointer to an optional user-supplied callback for double-click events. 
As double-clicks have no function in this listbox, no such callback 
exists, and the way to tell the system that is having textValue=NULL. As 
it was, the code would try to execute the empty string as if it were 
code, jumping into the data segment...


Thanks for spotting this.
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Disappearing pieces and figures.

[h.g. muller]

OK, I found the problem. Dragging a piece clears it from its original square,
but that square was not marked as 'damaged' to prevent the piece (which in
reality is still there) to be drawn when the highlights are drawn when you
release it (which would make it flash on that square before you see the new
position). This backfired for illegal moves, though, where the piece should
be re-drawn on its original square. I now let the move error order a complete
redraw, in stead of a selective one (that only repairs damage).

For now the fixed version is only available at 
http://hgm.nubati.net/cgi-bin/gitweb.cgi .


Thanks for reporting the problem.

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] gettext problem?

[h.g. muller]

Someone reported on TalkChess the inability to compile the latest master
and cairo versions. It seems there is a missing xboard.pot, so that it
tries to look for lots .gmo files, which aren't there either.

http://www.talkchess.com/forum/viewtopic.php?t=45508

I don't know eough about gettext to give any advice, though.

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Fwd: winboard problem

[h.g. muller]

I don't have Windows 7, so I cannot test this.

If I understand correctly, you installed WinBoard 4.6.2 by running the
installer, and when you start it through the start menu, select
playing against an engine (the default choice), and in the first-engine
combobox Fairy-Max, you get this error message?

Did you install WinBoard in the default folder (C:\WinBoard-4.6.2\WinBoard)?
Can you mail us exactly what the error message says?
Can you mail us what is in the first-engine combobox of the startup menu
before you pressed OK and got the error?
Can you tell us what is inside the folders C:\WinBoard-4.6.2\ and
C:\WinBoard-4.6.2\Fairy-Max\ ?


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Latest developments

[h.g. muller]

At 22:08 11-4-2012 -0700, Tim Mann wrote:

The second board, with clocks that count down, would be super for bughouse.


Indeed. That was the original motivation for adding the dual-board option.
But it can be used for observing any game while playing. (Not sure why you
would ever want such a distraction. Perhaps to observe how your main competitor
is doing in the last round of a tourney. Although the regular 
'backgroundObserve'

should be good enough for that.)

Like the old implementation, the condition that the boards should have the same
format still holds. (I.e. you cannot play a normal game in the main window,
and bughouse in the other.) This because the format of the secondary window
is simply cloned from that of the main one.

In the latest master version, the clocks of the secondary board now count.
The implementation is still a bit flaky w.r.t. redrawing of the secondary board
(e.g. flip-view during a game).



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Infinite recursion

[h.g. muller]

If Xboard is dependent on untranslated error messages from libc, it should 
run the engines in the C locale. It can be done by calling 
putenv(LANGUAGE=C) in the child proces before the exec() call.


It is not that simple. One would want the engines to run in the same locale 
as XBoard, in order to get translation of the engine-defined options in the 
Engine Settings dialogs. The libc messages that are recognized by XBoard 
are supposed to come from intermediaries like ssh, which you typically use 
when you run the engines on a remote machine (using -firstHost, 
-secondHost). This is needed because such interediaries might not exit when 
they fail to execute the engine binary. The engine itself, when run 
locally, can inform XBoard of its failure to start by simply quitting. 
Failure to exectute the engine is announced by XBoard to itself (i.e. from 
the child process to the main process through the pipe) using perror(), 
which presumably would use the current locale. So perhaps we should make 
the child switch to the C locale after exec failure, before using perror(). 
Is that possible?


If the engine really runs on a remote machine, I don't think it would pay 
attention to any environment variables on the local one. Or would it?




___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Latest developments

[h.g. muller]

At 14:41 10-4-2012 -0700, Arun Persaud wrote:

didn't have time to test, but a second window with clocks and move
highlight sounds better... does this automatically open if you play or
observe a bughouse game or a simul-game on FICS? That would be great!


It behaves like the old dual-board option (except that it displays the second
board in a separate window, rather than both in the same). That is, it 
automatically

pops up the window when you receive a board from the ICS while you are playing
a game, which is not from that game, when background-observe and dual-board
are both on.

It should not be too difficult to have the active clock count down as well,
handling that from the timer callback that decrements your own clock.
(The clocks of the dual board does not require msec accuracy, so there
is little harm in decrementing them simultaneously. In ICS mode clocks
are only an indication anyway.) The point is that this would have to be done
from the back-end, so it would affect WinBoard, and I would have to provide
(dummy?) support in WB for the calls to update the second set of clocks there.

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Infinite recursion

[h.g. muller]

However if start xboard in my normal Danish locale the error error does 
not come up, and the engine setting menu item are enabled. If I click on 
Engine #1 settings, xboard will crash.

...
But the point is that the behavoir depends on the locale in a way it 
shouldn't.


I guess the problem is that XBoard (as described in the protocol specs) 
triggers on receiving a message containing No such file from the engine 
process, and that the engine probably sent a translated version of that 
message. That is a bit hard to fix. We could translate the system standard 
error messages it compares to in backend.c. But that is tricky; they really 
would have to be translated to the exact messages that the system in that 
locale would produce. We could of course let XBoard request the messages by 
error number in its own locale, and use those in the comparison. But also 
that will not always do what we need, because you could be running the 
engine on a machine with a different locale as wher XBoard is running.


One problem, which I have just been fixing even before I saw your report on 
this, is that the master version that does this is indeed a bit broken: it 
ignores pipe breaks before engine initialization is complete. While in fact 
detection of EOF while reading from the engine process would have been a 
good alternative method to produce an error popup and trigger the switch 
back to -ncp mode. (It would be a different error popup, engine exited 
unexpectedly in stead of failed to start engine, but I could live with 
that.) This problem came up when starting non-existent UCI engines, as 
Polyglot wraps the error message in a tellusererror command, which 
effectively hides it from XBoard, so that the only signal to go on is 
Polyglot exiting.


I have fixed that with the most-recent commit. This should prevent the 
other problem, because it would disable the menu you had to click to cause 
it. I guess it was not so much caused by recursion as well as repetitive 
triggering of the same error condition ('broken pipe'), and failure to make 
that trigger the required action to solve the problem.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Latest developments

[h.g. muller]

I have no problem with wrong windows having focus. Never happened for me.


OK, good Then we can leave out this rather complex patch. The GhostView 
file browser is kind of a special window anyway, since it has its own event 
loop, and seems to bypass Xaw. This probably prevents the problems I had 
now with Xaw windows. I reember I hd similar problems when the GhostView 
browser always popped up as a child of the main window, (focus returning to 
the main window,instead of to the dialog that invoked the browser), but I 
guess that this is in fact just what it should do, and the problem 
disappeared when I made the browser a child of the dialog. I also could not 
get any wrong behavior there, no matter how I tried, so it seems we are OK 
there.


I found a bad memory corruption bug in 4.6.x (freeing allocated memory to 
which a live pointer still existed), when replacing the second engine. This 
makes it even more compelling to release a 4.6.1 quickly.


A completely different thing: in my refactor branch I now have a version 
that pops up a second board window (with just board, message and clocks; no 
menu or button bars) when you use the backgroundObserve + dualBoard options 
in ICS mode. (The old version just doebled the width of the window to show 
two boards side by side, which was less flexible. It also did not support 
extra clocks or highlighting of the moves in this board.) Please comment if 
this is useful, or if the old method was better.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] The clock stops if the board window is moved with stickyWindows on

[h.g. muller]

While I am able to stop the clock occasionally by moving the board, it 
doesn't happen often. It is much easier to reproduce by iconifying/ 
deiconifying the board window.


I have not been able to reproduce this (since I fixed the earlier bug of 
not clearing the pending timeout when it occurred). What exactly are the 
conditions under which you observe this? (which board size, which windows 
open, which mode). I tried in two-machines mode, with the Move list open, 
clicking on the taskbar to iconify. (Other windows have their own icon, and 
don't react. Only the Move List is enslaved to the main window.) I also 
cannot find anything suspect in the code.


If I cannot reproduce it, the only hope to debug it is if Byrial trie it 
himself. A good method would be to put a printf at every place where there 
is an XtAppAddTimeOut or XtRemoveTimeOut call, printing the timer XID, and 
one in the callback routine to see if the event actually occurs (and for 
which timer XID). This is how I found the previous bug in this area. Just 
try until the clock stops, and then look if there was a clock timeout 
pending which simply never occurred (which would be an X11 bug), or if the 
timeout is erroneously removed by some other event.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Xboard-4.5.3a bug: windows sliding

[h.g. muller]

At 15:49 25-2-2012 +0100, Hans Aberg wrote:
If I try xwininfo on the command line (example below), and compare the 
data of different windows, then the parameters have the same value as follows:

  -frameX  -  Relative upper-left X
  -frameY  -  Relative upper-left Y

There is a source file xwininfo.c for this program.


Hans, did anyone ever tell you you are a genious! :-)

Not only does the routine XGetWindowAttributes they use there provide the 
info about frame size we need; it also seems to work much more reliably for 
getting the actual coordinates.


I pushed a new version now to the http://hgm.nubati.net/cgi-bin/gitweb.cgi 
repository (master branch). I removed the -frameX/Y options there, and used 
the new routine.


I also made a first attempt to implement the -stickyWindows options: the 
auxiliary windows Engine Output, Move List, Eval Graph and Game List will 
then move together with the main window, if you drag the latter. (That is, 
until they bump into the edge; the window manage is really very reluctant 
to do as it is told...) A checkbox in the General Options dialog can switch 
it on or off. In WInBoard the option is a bit smartr, and only co-moves 
auxiliarry windows that actually touch the main window In WB it is also 
smart enough to move attached windows when the main board resizes (e.g. 
wnhen you switch from normal to gothic), doesn't do that here yet either.


I still have the problem when I position in (0,0). This works fine if the 
background is the desk top, but if there is another window behind, it moves 
to (0,25).


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Xboard-4.5.3a bug: windows sliding

[h.g. muller]

At 14:43 25-2-2012 +0100, Hans Åberg wrote:


I forgot to mention that 'make install-pdf' didn't work:
# make install-pdf
Making install-pdf in po
make[1]: *** No rule to make target `install-pdf'.  Stop.
make: *** [install-pdf-recursive] Error 1

It does work on xboard-4.5.3a:
# make install-pdf
test -z /usr/local/share/doc/xboard || ./install-sh -c -d 
/usr/local/share/doc/xboard

 /usr/bin/install -c -m 644 xboard.pdf '/usr/local/share/doc/xboard'


Perhaps Arun kan have a look at this. I don't reall know anything about the 
Linux make process.



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Xboard-4.5.3a bug: windows sliding

[h.g. muller]

Windows slide exactly 4 pixels to the left from session to session. That 
is, open some windows so that there is a margin to the left on the screen. 
Then quit, and start another session. Then all new windows have moved 
exactly 4 pixels to the left relative to the position from the previous 
session.


The problem is that the X-server lies to the application about the 
positioning of the windows. When you request the position, and then on a 
later popup position it the same way, it has moved quite a lot. It sems 
this has to do with the width of the frame and title bar, added to it by 
the windows manager: in one case they are counted, but not in the other. So 
I tried to compensate by adding a constant to the coordinates to account 
for the widths of the ornaments.


The problem is that the width might not be the same on every system. For 
you it seems it is 4 pixels wider than what I actually add.


Another problem is that on my Ubuntu 8.04 it was not reproducible either. 
Whatever constant I added, when I aligned them so they touched, closing 
XBoard and restarting it would sometimes still have them touch, but often 
create a 1-pixel gap or a 1-pixel overlap between the formerly touching 
windows. So I kind of gave up on this, and never got to port the 
-stickyWindows feature (which really attaches paramount importance to 
whether windows exactly touch or not) from WinBoard to XBoard.


To alleviate the problem a bit, I could make the addition configrable, 
rather than a hard constant. E.g. have -fudgeX and -fudgeY options, so that 
in your case you could solve it by increasing the -fudgeX value by 4.





___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #35000] Temporary previous position ('.' key, former Ctrl) conflicts with start of Type a move

[h.g. muller]

Would it be an idea to use the auto-repeat by having the piece jump back 
and forth,
rather than suppress later events? I am not sure what exactly the sequence 
of events
is in Xt on auto-repeat. In Windows there would be one key-down event, one 
or more
char events, and finally a key-up event. The key-down event could be used 
to set a
flag and call Forward, the char events could then be used to call either 
Forward or

Backward depending on the state of the flag, before toggling the latter.

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #35000] Temporary previous position ('.' key, former Ctrl) conflicts with start of Type a move

[h.g. muller]

I tried it in WinBoard now, and I think I also found the ideal key for this.

Enter in WinBoard as already taken, because it is forwarded to the ICS 
console.
(The XBoard equivalent would be to make it trigger sending the message 
currently

in the ICS input box.)

I tried Tab, but there the system already intercepts the key-down events, 
as it

is a standard binding for changing between input field.

But then I noticed the Backspace key. It is larger than most, universally 
present

on keyboards it had no binding yet, and its name ideally matches the function!

Making the auto-repeat move the piece back and forth also looks quite nice.

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #35181] Shortened menunames in tinymode not translated

[h.g. muller]

1) It may be necessary to have a minimum width, so small texts will not 
show less an a letter. Modus in German in size -tiny is close to show less 
than an M. It could be worse in other languages.


This suggest tome you would be using too-large a font.

2) When you have enough space the menu buttons will be enlarged to fill 
the whole width of the window. That breaks the -titleInWindow option.


A possible solution might be to create the buttons first without width 
speficication, then messaure if they are too wide and make the widest 
buttons narrower.


OK, this is feasible (and better). I pushed the patch again to hgm.nubati.net.

Future improvement would be to put this scaling in a separate routine, and 
also call that on board-width changes (currently only due to variant changes).
I already store the menuButton widgets and their nominal size in the 
menuBar struct during reation to facilitate this.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #35181] Shortened menunames in tinymode not translated

[h.g. muller]

I see 3 ways to fix that:
1) Extract the first character from the localized name using mbtowc(). (mbtowc
stands for Multi Byte char TO Wide Char). It is easy to do, but the method may
not be available for all as mbtowc() is a C99 function.
2) Extract the first character from the localized name using some library for
handling multibyte chars. That could be a fallback solution if 1) fails, but
means that the library have to be installed or distributed together with
xboard.
3) Let the translators translate all the 1 letter abbreviations. Requires no
extra configuration, and let the translators choose something else than the
first letter if that is more appropriate for their language, so this is
probably the best solution, I think.

What do you think?


Actually I remember making patch where the number of characters shown
for each item was dependent on the board width in pixels, and could be 
different
from just 1 or all. I still have to look into itwhythis is notin the master 
branch now
(could beit is a WinBoard-only patch, could also be that it is in the 
aliennew branch).


The current 'tiny-layout' scheme does not work satifactorily anymore:
1) Now we reorganized the menus, the main menu bar has more items, and is wider
2) Translation can make the meu bar arbitrary wide (e.g. try German on 
-size middling)
3) It does not take the number of board files into account; in xiangqi, 
gothic or courier

   the same -size would allow a ider menu bar
4) (I have never sen this, but I think it must be:) the font size is not 
taken into account,

while the -messageFont is also used for the menu bar, AFAIK.

So the current scheme is a total mess. I would prefer to replace it by 
something that
takes everything into account. E.g. calculate the width of the menu bar in 
pixels, taking
into account the font used to render it, and then clip the texts to an 
increasingly shorter
number of characters until it is no longer larger than the board. This 
should be redone

whenever the window width changes.

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #35181] Shortened menunames in tinymode not translated

[h.g. muller]

However
1) I tested the numeric values given with the -size options, and it didn't 
work for linegap and fontsizes


Oh, it could be that my changes to save font size in the settings file have 
broken this. I never paid any
attention to the extra -size parameters (WinBord does not have that). I 
will check it.
Beware that for the linegap to be effective -overrideLinegap has to be -1, 
or it ould be intentionally overruled.



2) The default values should always work


It is debatable what that means, because the default language is English. 
So any translation is by definition
non-default. But I agree it is preferable if things would work 'out of the 
box' in ay language. But it is up to

the translators to see to it that size-critical translations do fit.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #35181] Shortened menunames in tinymode not translated

[h.g. muller]

Yes, as said before in this thread you have to use the C99 function 
mbtowc() or some library dedicated to handle multibyte char strings.


Well, I admit had not thought of that, but this is completely trivial to 
code even without using any libraries.The high bits of UTF8 immediately 
tell you the
grouping pattern. (IIRC any byte that starts with10 binary is a 
continuation byte, all others are start bytes.)


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #34990] Use of Mono mode once permanently swictces to bitmap pieces

[h.g. muller]

You are right about that. However when I tried I got a segfault!


Oh yes, now I remember that occurred to me too. The patch that fixed the 
animation masks on swithing back to color mode fixes that too.


A string constant (DEF_BITMAP_DIR) is assigned to appData.bitmapDirectory 
when you change to monoMode if it was NULL.


So when I try to change bitmap directory later DEF_BITMAP_DIR is attempted 
free()'ed, and xboard crashes.


Add a strdup() at xboard.c:1946.



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #34990] Use of Mono mode once permanently swictces to bitmap pieces

[h.g. muller]

At 20:23 22-12-2011 +0100, Byrial Jensen wrote:

Den 22-12-2011 10:41, h.g. muller skrev:



You are right about that. However when I tried I got a segfault!


Oh yes, now I remember that occurred to me too. The patch that fixed the
animation masks on swithing back to color mode fixes that too.


Fine, but where is the patch?


In hgm.nubati.net (hgmaster branch)



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #34991] Load engine doesn't work in localized xboard

[h.g. muller]

OK, I pushed a potential fix for the button alignment to hgm.nubti.net 
(hgmaster),
but I did not know how to test it, as the languages that I could get to 
work (de_DE.utf8)
do not translate browse, I did not know how to select Danish, and 
changing de.po

to add a translatior for browse was not noticed by make.

At 18:31 16-12-2011 +0100, h.g.mul...@hccnet.nl wrote:

Well, I know how to fix that, when I will be back home.



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #35000] Temporary previous position ('.' key, former Ctrl) conflicts with start of Type a move

[h.g. muller]

If input notation can be localized at some point in the future, as I think 
it should, then the first character of a move will not necessary be a 
ASCII letter (A-Z) or number.


You mean it can be a code 127?

Then we shouldonly exclude the keys we want to use for binding.
'.' could be an unlucky choice, however: besies poppig up the move type-in,
a key hit when the board has focus now also pops up the ICS input box in 
ICS mode.

And ICS commands can very frequently start with '.' (= tell to same).

I think we should use a single key, but better not '.'
How about Enter? This has no binding, and is unshifted in any language.



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #34972] Several issues regarding lokalization

[h.g. muller]

Some quick remarks:

At 23:09 2-12-2011 +, Byrial Jensen wrote:

1) My testing shows several untranslatable strings:

Unrecognized argument
shuffle (in File  New Shuffle Game)
randomize (in File  New Shuffle Game)
pick fixed (in File  New Shuffle Game)


I think in 4.6 this dialog is now done by the generic popup, so this 
probably means
we forgot to put the N_() macro around the strings in the defiing table 
(shuffleOptions ?)



Browse (title for File  Load/Save Game/Position)
Filter on extensions: (in File  Load/Save Game/Position)
OK (in File  Load/Save Game/Position)
Cancel (in File  Load/Save Game/Position)


The above are all in the Ghostview file browser, which might not have been 
gettextized yet



save changes (in Edit Tags + Comment)
clear (in Edit Comment)
Polyglot book not valid
Engine (in Engine Output)
Game-list options (window title)
Hidden tags (in Game-list options)


The latter is one of the entries in the listbox. In general these must not 
be translated,
because they are names of tags in the PGN standard. But this one could be 
an exception.
we must make sure that it would still be recognized as the separator on 
reading it back

from the listbox to create the tag-order string, though.


Stalemate (one of multiple game results)
Black mates (one more of multiple game results)
Xboard adjudication: Something (multiple strings)


Some of these strings might come from the engine or a PGN file.
The 'XBoard' adjudication' strings are tricky. They are used both for printing
in the messge field above the board, as well as for writing into the PGN file.
I discussed this on TalkChess, and the conclusion was that it is undesirable
to have the messages translated in PGN, as this is supposed to be a format
for interchanging files, and the one who cretes it will not always use the same
laguage as the one who reads it.

There is no harm in translating the strings just before they are printed in 
the message
field. (This is whatWinBoard currently does.) But when the original 
result-details string

comes from a PGN file made by an appliation other than XBoard, or directly from
the engine, there is no limit to the variation such messages can take.


Everything in Engine #1/#2 Settings (Seems unfinished with dummy examples)


The options shown in the Engine Settigs dialogs are defined by the engine
To get them translated you would have to use a translated version of the 
engine.

Nothing XBoard can do about that; there are may hundreds of engines,
and new ones emerge every day, and there is no way to predict what option
names they wil try to display in the settings dialogs.


Tourney participants (in Match Options)
Everything in About Xboard window


I figured that for legal reasons copyright notices should better not be 
translated



Direct command
Send to chess program:
P (pause button in board window)
%s vs. %s (board title when playing)
Game list not loaded or empty
first (engineNames value)
second (engineNames value)

There may be more untranslatable strings. The strings above is just what I
found in a test run.

2) The browse buttons in all windows are not resized to be able hold the
translated text for the word browse.


They are all generated by the generic popup, which gives them a pre-defined 
width.
I subtract that width from the preceeding text widget to get good alignment 
at the right margin.
Xaw does not seem to support automatic sizing of the widget to align both 
margins;
the only way I could get a non-ragged right margin is specify the size of 
every element.
This makes it difficult to adapt the size of the browse buttons to the text 
they contain.
It seems to need a two-step process, where we first realize the widget with 
a ragged right
margin, but auto-sized browse buttons, and then adjust the width of the 
preceeding text
widgets accordingly. This might ot be too difficult, though, as I seem to 
recall I do a second
pass anyway for adjusting the width of the preceeding text labels to that 
of the longest.
Presumably I could read otthe width of an auto-sized browse button before 
that, and

then also adjustthe width of the text widgets acordingly in that second pass.



3) Move notation is not translatable. The letter used for pieces in algebraic
notation depends on the language.


It would require major changes in XBoard to do anything about that. Moves 
are not
only used for display, but also saved on PGN, communicated with engines, 
and with ICS.
I think using other move notation in PGN is acceptable, but require an 
extra tag redefining
the notation, which is currently not implemented. But engines and ICS would 
not accept

foreign notation (for promotion piece or FEN).
  XBoard already has a -pieceToCharTable option which can be used to set 
other piece IDs,
which could be used to read foreign PGN in game viewer mode, but these IDs 
are then used
globally throughout XBoard, which would break it for using engines or ICS. 
To avoid that,
XBoard would have to be re-written 

Re: [Bug-XBoard] [bug #34972] Several issues regarding lokalization

[h.g. muller]

At 11:00 3-12-2011 +, Byrial Jensen wrote:

Follow-up Comment #3, bug #34972 (project xboard):

Thanks, that was fast.

PGN files should not be changed. The PGN specification does not allow for
that, and it would not be portable.

But I think the move notation should be changed in the Move list window and
other places where a move is shown to the user. And it should also be changed
for typing in the Type a move window.


I agree. But this is something that transcends the normal localization by 
string translation by far,
and would require the XBoard routines for parsing and generating moves to 
use different

pieceToCharTables depending on the source and intended destination of the move.
Even the -pieceNickNames option is now applied globally to all input moves.
This means you can only use it to define nick names that do not collide 
with existing

names fromother sources. So it would be OK to define B and N as nicknames for
E and H in Xiangqi. But defining Dutch names OPLTD.opltd. with it would 
make any P
be interpreted as Knight rather than Pawn, interfering with reading FENs 
from PGN.


It is a hard problem, because changing variant has to redefine the 
pieceToCharTable anyway,
so to make it work would require XBoard to have a national version of the 
pieceToCharTable

for every variant, to be used as a default there.

I don't expect this could be fixed on ay short term, mainly for lack of 
ideas how it should be done.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #34972] Several issues regarding lokalization

[h.g. muller]

At 20:38 3-12-2011 +0100, Byrial Jensen wrote:

Well, if you are able to use or convert the po-file, you are welcome. If 
would be difficult for me to make a winboard file, as I don't use 
MSWindows, and thus cannot even test if I messed up the file by some accident.


Unfortunately I have only a WinBoard .lng fileto .po coverter,and not the 
other way around. The conversion is non-trivial, because may of the English 
strings are ust a bit different (e.g. menu keys separated from item text by 
tabs, in stead of spaces).


And if I should make a translation for Winboard, I wouldn't even know what 
charset to use. UTF-8 or ISO-8859-1 or some non-standard MS charset which 
I don't know?


That is not very critical, as there are converters for that. That is also 
how I do the conversion .lng to .po: use an ed script to change the format 
without altering the translated strings, and then run the converter on the 
.pofiletomake it UTF-8. I don't know what a Danish Windows would use as 
charset, but I would guess it is Latin-1 (like all of Western Europe)


I think a much more sound approach would be to also make Winboard use 
gettext.


Unfortunately gettext does not work at all on WinBoard, because all menu 
and dialog texts are not in the C code, but in a Windows 'resource' file, 
which has to be compiled by the resource compiler, which does not 
understand gettext stuff. But the WinBoard system is not bad at all. You 
cannot damage anything, because the translation is just a data file, loaded 
by WinBoard when you select the language. So you can change language during 
the session, by simply picking another language from the menu. You don't 
even have to recompile for adding a new laguage. Just put the .lng file in 
the directory, and the next session the laguage will appear in the menu.


H.G.

The po file format is much easier to work with for a translator as we can 
use special po file editor programs that make sure that only the 
translation and translation comments can edited, while the original text 
and the file structure cannot be accidentially damaged. These programs 
normally also have translation memory used to propose translations based 
on similar texts in the same or other po files, good search and replace 
functions etc.


- Byrial



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #34980] Promotion in play at ICS fails with localized Xboard

[h.g. muller]

At 21:49 3-12-2011 +, Byrial Jensen wrote:

Anyway I looked at the function PromotionCallback() in xboard.c and found this
code:

if (strcmp(name, _(Knight)) == 0) {
promoChar = 'n';
} else if (strcmp(name, _(Promote)) == 0) {
promoChar = '+';
} else if (strcmp(name, _(Defer)) == 0) {
promoChar = '=';
} else {
promoChar = ToLower(name[0]);
}


Indeed. And it is not just sent to the ICS, but would be used by XBoard 
internally
in any mode, most likely meaning the move would be refused, or give you a 
wrong piece.


This is one of the reasons I want to get rid of the promotion popup. 
(Remember there
are 22 different piece types for each color, and most of them are known 
under several

different names and ID letters depending on the variant they appear in.)

If it is up to me, the promotion popup can be considered deprecated, or 
even completely
removed from XBoard, so that the only choice left is between 'Almost always 
Queen'

and 'Always Queen'...

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] Two bug reports

[h.g. muller]

I received two bug reports on forums, which I am not sure how to fix:

One ( http://www.open-aurec.com/wbforum/viewtopic.php?f=19t=52035 ) is on Mac,
where 4.6.0 produces a stream of spurious run-time warnings:
   Warning: No type converter registered for '(null)' to 'FontSet' 
conversion.

and then uses another font then Helvetica.

The  other I received as a PM, reproduced below. I am not even sure this is
an XBoard problem. I have heard people complaining about Unity and Ubuntu
11.04 / 11.10 display handling in general; I am also in e-mail contact with
someone who experiences a 20-sec startup delay in 4.5.x which he does
not have with 4.2.7 (but in the mean time he established it also happens
in 4.4.3). Despite that he already turned away from Unity. When he runs
the same binary on other Linux distributions, there is no such delay.


Hi H.G.

Over the last few weeks I've been noticing some odd behavior with the Ubuntu
11.10 xboard package (4.5.2) running under the default Unity desktop. I've 
been

experiencing a lot of strange drawing issues, anywhere from menu hiccups (the
reverse-video mouseover fails to erase completely when mousing over a new menu
items) to pieces disappearing completely from the board. My guess is that this
is a Unity/compiz issue, but the previous combination of xboard 4.4.4 and 
Ubuntu

11.04 (w/ Unity) worked perfectly.

I can reproduce the menu drawing issue on two different computers, but the 
piece

disappearing act seems to happen at random. Here's an example from a recent
1 0 game (I was played white):

[d]r1bq1rk1/pp1nnppp/3p4/3Np3/4P3/5N2/PPP2PPP/R2Q1RK1 b

In this position black played Nxd5 after which following position was 
displayed

on the board:

[d]r1bq1rk1/pp1n1ppp/3p4/3Np3/4P3/5N2/PPP2PPP/R2Q1RK1 w

Notice how the knight on d5 is still white. I eventually replied Qxd5 which
xboard accepted and the game progressed uneventfully. Being 1 0, I didn't have
time to snap a screenshot, but I did try to refocus the window and even 
dragged

another window over xboard to force a damage update, but the knight on d5 was
still displayed as a white knight.

Not sure if this is xboard issue, a Unity issue, or a combination of the 
two. I just thought

I'd bring it to your attention.



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] chess-formula

[h.g. muller]

At 18:53 8-10-2011 +0300, venko ganev wrote:

Hello you! I registered in the freechess.org.
 I am interested in how to create a formula whereby using the command
seek not I invite users with a rating lower than 1600 as my score is
over 1600. I would be very grateful if I describe in detail the
creation of such a formula as leading to the auxiliary fail something
not working, perhaps I can not figure it out. Use winboard 4.5.2 jaws
if it matters. Thank you!


Well, this has nothing to do with XBoard, and certainly is not a bug in it.
Consult the documentation of freechess.org to learn how their server works,
or ask help from one of their admins on the servers help channel...

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #34457] xboard: no fonts match pattern -*-helvetica-bold-r-normal--*-*-*-*-*-*-*-*

[h.g. muller]

I guess this bug-report will keep recurring forever...

Install the font!

And make sure it is loaded in the X-server font cache.

This is the only solution. There is no way XBoard could possibly work
if you have no fonts: all the menus and dialogs would be blank.
So printing this error message is the only logical solution.

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #34202] xboard has a 20-second startup delay running with Ubuntu 11.04

[h.g. muller]

One important difference between the previously reported bug
and what you report now would be that you now find this behavior
also in 4.2.x, while before it only manifested itself in 4.4.0.
I am not sure that taking a binary from one distribution, and
plugging that into another, is a valid procedure, though.
To be really sure, the old 4.2.7 sources would have to be
loaded, and XBoard would have to be configured and installed
from source.

If old XBoards, which previously worked, now show this pathological
behavior, it would be a strong indication that the problem lies outside
XBoard, and hence cannot be fixed from within it. If ancient versions
do not have this problem, though, someone experiencing the problem
could identify the earliest version that suffered from it, and the change
that apparently triggers this could inspire a work-around.

But as I don't have this problem at all, (I alsodon't have Ubuntu 11.04),
that approach is not open to me, and nothing can or will be done
until someone that does have the problem would be willing to help
us debug it (which could be a tedious process).


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] chess set

[h.g. muller]

The piece symbols can be changed by specifying a true-type Chess font.
The file ChessMark.ini in the standard install shows an examply how to do this,
using the option /renderPiecesWithFont=

The README html file accessible from the Start menu contains a link to a page
that explains how to do this in more details.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [XBoard-devel] Winboard

[h.g. muller]

Are there any plans to make Winboard/Xboard compatible with the iPad?
An app would be appreciated. The diagram .bmp saver is indispensable.


No plans whatsoever. I don't have an iPad / iPhone, and probably never will.
I am thinking about purchasing an Android smart-phone, though.

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Xboard installation problem.

[h.g. muller]

If no makefile is found, I would say that the configure appeared to work 
incorrectly.

Because it is the very purpose of ./configure to create a makefile...
If configure terminates with error messages, it is not joking!

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #33241] xboard quits with 'Unable to create font set.'

[h.g. muller]

OK, I am back from Greece, so I had access to my Linux system again.
I started pushing all the WinBoard fixes I had accumulated in the mean time
to hgm.nubati.net (hgmaster branch), after syncing with Savannah.

There seems to e a problem, though, with the file browser. I suspect this
is a side effect of some of the general changes of the text widget settings
done for the internationalization, as the git log shows now changes in the
browser file, and the probem is definitely new:

If I use the browser through a browse button in another popup, (e.g. the
for setting the tournament file in the Match Options dialog), it seems to only
copy the first character of the selected file name to the file-name field.
I put some debug prints in the browser, and it seems the problem occurs
in SFsetText() in path.c, in this piece of code:

text.firstPos = 0;
text.length = strlen(path);
text.ptr = path;
text.format = FMT8BIT;

XawTextReplace(selFileField, 0, strlen(SFtextBuffer), text);
XawTextSetInsertionPoint(selFileField, strlen(SFtextBuffer));

This code is called when one clicks a filename in the lists in the browser 
window,
the clicked text being passed to it as 'path'. selFileField is the 
uppermost text widget

in the browser window, and the purpose is to load it with the clicked text.
Now what happens is that 'path' is OK: when I print it, it prints the 
complete clicked text,
and acknowledges the correct length of it in text.length. However, when I 
print the
contents of SFtextBuffer after the XawTextReplace, it only prints the first 
character.
Now SFtextBuffer is the 'use-in-place' string that is supposed to be in 
selFileField.
On the display I see that the selFileField widget contains the complete 
filename,
but it seems to be stored in the provided buffer array in a format that the 
rest of the
code no longer understands. The InsertionPoint is set after the first 
character, which is
aready suspicious. It seems like the buffer does not store the text in an 
8-bit encoding,
leading to null bytes in between the characters, which the rest of the code 
interprets as

end-of-string.

Other minor weirdnesses I observed are:
*) The browser seems to use a fixed-width font in its lists (but not in the 
text widgets).
*) The background of the font in all text widgets of al dialogs is now 
light gray. (I don't know
if this was intentional or even if it is desirable; I just noticed that it 
was different than before.)
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] XBoard file-type associations?

[h.g. muller]

I was wondering if it would be possible to do the same kind of stuff
on a Linux XBoard install as we do now with WinBoard: associate
file types with some specific XBoard command, so that clicking a
file of that type would automatically start up an XBoard in the required
mode. And of course it wold be nice if the files of those types would be
reresented by an icon advertizing their association with XBoard, rather
than as a general text document.

In particular, *.pgn files could get a chess-board icon, and clicking them
should issue a command

xboard -ncp -lgf $1

(perhaps setting some other options as well), where $1 is the clicked file,
so that XBoard is started in game-viewer mode on the file by ust clicking
the latter. Similarly, *.fen files should issue

xboard -ncp -lpf $1

and they could have the same icon (like in WB). For a tournament file (*.trn).
the required command would be

xboard -mm -tf $1

to make XBoard start up in match mode according to the tourney specs in
the tournament file. In WinBoard this works realy great now, and I did design
a new icon for the *.trn files there.

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #33241] xboard quits with Unable to create font set.

[h.g. muller]

At 22:42 17-5-2011 -0700, Tim Mann wrote:
It looks like we need to change FindFont to just return the fontset, then 
change the rest of the code to set fontSet resources using that value 
instead of setting font resources.  That looks like it will be a fair 
amount of work to carry through fully. Maybe it's best to nuke all the old 
code in the process instead of trying to carry it around and make it still 
work if compiling without ENABLE_NLS defined.


Would this really require a lot of work? The current version uses 3 fonts: 
clocks, board coordinates, and the rest. clockFont is used in only two 
widgets, which explicitly mention an XtNfont arg at their creation. The 
coordFont is only used for rendering text in the graphical board widget, 
for which it is turned into a GC (coordGC). All the other stuff seems to be 
handled in bulk, by the single call:


XrmPutStringResource(xdb, *font, appData.font);

Couldn't we simply change that call to

XrmPutStringResource(xdb, *fontSet, fntSet);

to acheive what we want? (And of course make sure fntSet used in FindFont 
is a global variable.)___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #33241] xboard quits with Unable to create font set.

[h.g. muller]

At 01:13 17-5-2011 -0700, Tim Mann wrote:
p.s. I just tried, and editing the .xboardrc file to change the fonts from 
iso8846 to iso10646 did NOT fix the broken umlauts. So there is more to 
that problem.


I don't really know anything about X-fonts, but apparently iso10646 and 
such stands for an encodings, and neither encoding is apparently UTF-8.


To get it working, two conditions must be satisfied:
*) The font must define the relevant glyphs
*) The strings must be presented to the renderng agent in the encoding the 
latter expects (presumably defined by the selected font).


I get the impression that the fonts defining the relevant glyphs for some 
languages are only available in encodings different from UTF-8. This does 
not need to be fatal; it merely means that the po files should be adapted 
to use the encodings available in one of the fonts available for the target 
language, and that the user should be advised to specify that font with XBoard.


It should be easy enough to obtain a po file in another encoding. There are 
several inconveniences though: different strings in the po files will use 
different fonts, and thus might need different encodings. Window titles, 
for instance, are rendered by the window manager, which apparently is using 
UTF-8 (considering the screenshots of the Russian translation on WinBoard 
forum, http://www.open-aurec.com/wbforum/viewtopic.php?f=19t=51772 ). So 
we would have to figure out which messages are window titles, and put those 
in different encodings in the po file. The same potentially holds for 
strings rendered in the clock and coords font, but there are only a handful 
of those.


It would be much nicer if we could select a font based on the availability 
of glyphs, let XBoard note what encoding it is in, and then let it apply a 
recoding to it before the font is rendered. I.e. redefine the _(s) macro 
not as gettext(s), but as recode(fromEncoding, toEncoding, gettext(s)) . 
Where the fromEncoding would always be UTF-8, so the po files could be 
maintained in UTF-8.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #33241] xboard quits with Unable to create font set.

[h.g. muller]

At 16:35 6-5-2011 +, Tim Mann wrote:

I had a different problem: I'm on Ubuntu 10.04 with gettext-tools 0.17, but
Arun checked in stuff built with 0.18.  When trying to build, I got an error
about Makefile.in.in being the wrong version until I did this:

gettextize -f
./autogen.sh
./configure
make

I don't know if that will help you because your symptom is different from
mine.


Oh, but that will help me! Because I have exactly the same problem
(using Ubuntu 8.04). Thanks!

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] problem winboard-russia

[h.g. muller]

The Russian versions of WinBoard are not produced by us.
Neither was the original WinBoard JAWS version, which was derived from a 
very old WinBoard (4.0.2).

As far as I know that JAWS version did not work for I C S play at all.
The first version where we got that working was WinBoard 4.4.0.
Is that the version you have been using?

We just released WinBoard 4.5.0, and the plan was to release a JAWS version 
of that as well,
but there were some bugs that needed immediate fixing, so we are releasing 
4.5.1 any moment,

and I will then makea JAWS version of that.
WinBoard 4.5.1 offers language choice from the menu, based on translation 
files that can be put in the same folder.
But we have no Russian translation yet, as no one has offered to make one 
for us.


The best solution would be to switch to using the WinBoard 4.5.1 JAWS version,
whichwill appear within a week or so,
and have someone who understands both English and Russian make a Russian 
language file for it.

Perhaps based on the most recent translation of a WinBoard that does exist.
I have no idea which version that would be; before WinBoard 4.5 we never 
were involved in any translations.


It makes no sense to invest time in debugging obsolete versions.

At 14:55 20-2-2011 +0200, venko ganev wrote:

all!
 I'm glad I'm already a member of this mailing list.
 I have a problem with winboard (Russian version of jaws) which is
adapted for non-sighted users, and hopefully help me to decide, give
me some idea.
 When I play on the internet namely freechess.org if relevant, after
10 15-minute game was released the following
winboard.exe close
error report contents
the following information about your process will be report ed: code:
06c005 flags: 06 record: 06000
address: 0x004312ff system information windows nt 5.1 build:
2600 cpu vendor
code 756 e6547  - 49656e69 - 6c65746e  cpu version: 0f41 cpu feature
 code: bfebfbff cpu amd feuture
code: 00f3e824
the following information about your process will pe reported
module 1 winboard.exe image base: 0x040 image size: 0x checksum:
0x time stamp: 0x40eaf75a version information signature:
 strucver: filever: (0.0:0.0)prodver:
(0.0:0.0)flagmask:  flags:  os:000 0filetype:
 subtype: 
the following files will be inclutet in this error report : c:
/windows/ temp /8a39_appcompat.txt
module 2 ntdll.dll image base: 067c90 image size: 0x

Then I installed winboard 4.4.1 jaws and found that this problem
does not appear
 but I prefer to play through ruswinboard because unfortunately I do
not understand much English.
For information, perhaps it is important to note that use windows xp, 
jaws 11

If you have any supplementary questions you can ask me to help you easily.
 You can contact me and Russian.
 Thank you.

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #31756] crash resizing engine window

[h.g. muller]

At 18:10 2-12-2010 +, Vincent Legout wrote:

A bug has been reported in Debian. See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604610

I thought that it is fixed in the development version, but I was wrong, I can
reproduce it with the latest git. It only happens when xboard is built with
xaw3d enabled.


Ah, this explains why I could never reproduce that bug... :-)

I don't think this is our bug, though. Resizing of windows is done by the
windows manager, or the Xaw library. We don't have any callbacks on
that window that would be triggered on resize, so none of our code is
activewhen the crash occurs. The window consists of only a few simple
standard widgets: two text edits and a few label widgets.

Last week in the Dutch Open in Leiden someone using XBoard showed
me some very sick behavior here (in an attempt to provoke the crash).
He did not succeed in making in crash, but while he was doing this
the window was in two-pane mode. Normally the panes for both
engines should be equally large. As the upper-most top and lower-most
bottom of the text edits are chained to the window edges, and the middle
is not chained (which should leave it at the default XtRubber setting),
they should always stay equal in height. However, when repeatedly
resizing the window vertically, one pane was growing w.r.t. the other,
until it covered more than 75% of the window area, and the other has
almost shrunk to nothing.

According to the specs this should not be possible. Xaw3d is just sick.

Now it could be that an actual crash only occurs when the window is
in single-pane mode. (Could someone please test this hypothesis?)
It is true that XBoard uses an un usual trick in this mode, as the two
panes are always there, but the upper one is resized such that it
pushes the lower one out of view. I don't think the specs forbid this,
however, and with plain Xaw it works like a charm.

So my guess is that the crash is due to the Xaw3d bug that manifests
itself in disproportional resizing of the individual panes, which at some
point creates an impossible value (like negative height for the lower,
out-of-view pane), which makes Xaw3d choke.

So it seems Xaw3d needs fixing, and there is little we can do about it.
Just don't build with Xaw3d. Unless the board size is very large Xaw3d
looks very ugly anyway.

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #31634] Bad path results in segmentation fault

[h.g. muller]

I don't think this is the correct patch.

The true problem is the *strchr(buf, '/') = 0; statement in the else part.
This assumes that in any pathname starting with ~ there will be a slash,
and causes the segfault if there is none. The patch merely diverts control
to the else part in case there happens to be a space after the ~,
but there are plenty cases with neither space nor slash, and they would
keep segfaulting.

I am a bit surprised to find this code anyway: I am not a Linux man, and
I thought that ~ was a standard filename convention handled by the kernel,
like it handles / as root. I was not aware that every application has to make
the translation to home directory by itself. Yet this is what the code seems
to be for.

If this code indeed has to be kept, the proper solution would be to skip
the assignment if there is no /, i.e.

{ char *p; if(p = strchr(buf, '/')) *p = 0; }___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #31634] Bad path results in segmentation fault

[h.g. muller]

At 15:18 12-11-2010 -0800, Adrian Petrescu wrote:
I believe the ~ shorthand is something that the shells expand, not 
something the kernel inherently knows about. Indeed, I doubt the kernel 
knows anything about something that high-level at all. But there may 
be  some standard function to do this translation.


Well, the kernel knows for instance which devices are mounted, and does not 
leave it to the shell too figure out that /C: actually means /dev/sda1 when 
you mounted the latter on /C:. In my mind this was a similar thing, where 
you have to look in the password file rather than in the mount table.


But even if it is no kernel funtion, it could of course be implemented in 
the library call for fopen.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Xboard doesn't compile with --disable-zippy

[h.g. muller]

At 21:36 3-8-2010 -0400, Adrian Petrescu wrote:
If I run configure with the --disable-zippy flag (which successfully shows 
zippy:  no in the configuration summary), trying to make fails with the 
following errors:


In file included from xboard.c:1347:
args.h:597: error: 'AppData' has no member named 'zippyLines'
It looks like an easy enough thing to fix, probably just have to #ifdef 
out some things from args.h?


Adrian is spot on. The problem is actually that there was an #ifdef ZIPPY 
in args.h, but it should have been an #if ZIPPY to have any effect.
I found the same error in 4 other places in the code (backend.c, xboard.c, 
winboard.c 2x), and changed it all.
All these errors were inherited from 4.4.x, where I fixed them too. (args.h 
was part of winboard.c then.)
XBoard compiles now with the --disable-zippy flag. Haven't tried WinBoard, 
I would not even know how to disable zippy there.
I guess no one has been compiling without zippy for a very long time. I 
found #ifdef ZIPPYs in winboard.c of 4.2.7...


Fixes are uploaded to the hgm.nubati.net repository.

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] xboard: Error: second chess program exited unexpectedly

[h.g. muller]

At 11:45 31-10-2009 -0700, Tim Mann wrote:

The double free worries me more than the XtRemoveGrab error.  Of course
they could be related, and it would be best to fix both even if they aren't.


OK, for the record: I had some more e-mail exchanges with the reporter of 
this bug,
and it turned out we were dealing with a combination of problems here. For 
one, he
was using 4.4.0~beta1, and what he showed was not the debug file but the 
console
output. The 'StartChildProcess' messages thus go to the wrong output 
channel, I think.
This made me misunderstand when the crash actually happened; in fact it did 
not occur
at startup of the engines at all, but after a game, when the user was 
trying to open the

Engine #N Settings dialog. The unlisted-widget problem was an already-fixed bug
(sept 30 commit) that tried to set focus to a text-edit in the dialog while 
there were none.
(And there were none for Toga2, because the user was using an obsolete 
Polyglot that

did not transmit any engine options.)

Now the third problem was that the bitbase implemetation of Toga2 is buggy, 
and that
the user was using it with bitbases, so we were also dealing with genuine 
Toga2 crashes
during the game. This of course cannot be blamed on XBoard, but the error 
exit seemed
to be unclean, and kept printing the free() complaint and stack trace in 
the console. I could
trace that to the second engine dying while the first is thinking. The 
dying engine causes an
immediate read error, which triggers a fatal-error popup. But as long as 
the user does not
close the popup, the second engine keeps thinking, and sooner or later 
spits out a move.
This now hit a bug from my hand: The dying engine had set 
gameInfo.resultDetails to point
to a local buffer, and a move coming in tries to free() the resultDetails 
and set result to *,
because the game is obviously still continuing. This crashed XBoard; 
resultDetails
must only be assigned through strdup, or the free() chokes, and I did not 
know it...


If I assign engine exited unexpectedly to resultDetails using strdup, 
XBoard no longer
crashes. But then the behavior is not really the desired behavior anymore. 
(In fact a
crash was close to the desired behavior; we were working on an error exit, 
after all...)


In stead of automatically terminating, XBoard now pops up a _second_ fatal 
error:
After receiving the move from the opponent it tries to send it to the dead 
engine,

which leads to a broken-pipe error. XBoard hangs until the user closes both
error popups. The double error is undesirable, and in fact now messes up proper
error reporting in the PGN. This will have to be re-thought a little bit. A 
move coming

in from an opponent of an already dead engine should not be added to the PGN,
so some form of flagging the alive status of engines must be implemented.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] xboard: Error: second chess program exited unexpectedly

[h.g. muller]

At 18:21 31-10-2009 +0200, matrix one wrote:

Hi,

Is happend only with toga2



Linux s3 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 
x86_64 GNU/Linux


xboard -debug -size huge -coords -scp 'polyglot 
/home/matrix/.polyglot/toga2.ini' -fcp 'polyglot 
/home/matrix/.polyglot/stockfish.ini'

StartChildProcess (dir=.) polyglot /home/matrix/.polyglot/stockfish.ini
StartChildProcess (dir=.) polyglot /home/matrix/.polyglot/toga2.ini
Warning: XtRemoveGrab asked to remove a widget not on the list
xboard: Error: second chess program (polyglot 
/home/matrix/.polyglot/toga2.ini) exited unexpectedly
*** glibc detected *** xboard: double free or corruption (out): 
0x7fff12a1af40 ***


Hmm, the RemoveGrab warning makes it a bit suspect. I could find only one 
call to XtRemoveGrab()
in the entire source, and this is in ThawUI(). Apparently XBoard uses the 
kludge to let a deaf-and-dumb
widget (the messageWidget) grab focus while waiting for the engine to 
complete initialization.


I am not sure if we are dealing here with a bug in the error exit procedure 
triggered by toga2 crashing,
or that something is badly wrong in XBoard that makes it unjustly believe 
toga2 exits. I suspect
the former, as that would explain why this only happens with toga2, and not 
with other engines.
Is this a reproducible error? If so, it would help to see the Polyglot log 
file (which can be obtained
by setting PolyglotLog=true in the toga2.ini file), which mght indicate if 
the trouble starts there.


H.G.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #8847] Moving backward while examining on FICS not reported to engine

[h.g. muller]

I found this code in parse_board12():

/* [DM] If we found takebacks during icsEngineAnalyze try send to 
engine */

if (!newGame  appData.icsEngineAnalyze  moveNum  forwardMostMove) {
takeback = forwardMostMove - moveNum;
for (i = 0; i  takeback; i++) {
 if (appData.debugMode) fprintf(debugFP, take back move\n);
 SendToProgram(undo\n, first);
}
}

This seems aimed at fixing the reported problem, so it seems Daniel
has been working on it already. I don't see any flaws in the code;
(well, perhaps if the number of undos was very large, it would make
more sense to start a new game and load it from the begining...),
so if the problem occurs despite of it, it must be because the ICS
does not send a board.___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #27666] misc shogi on FICS

[h.g. muller]

The problems with bsetup and castling takeback in examine mode
should now have been solved in the server. The bsetup case
required some additions to XBoard, to make it switch variant
during the setup when the ICS changes board size.

When you enter bsetup from idle mode you now get an empty 8x8
board (in stead of 0x0). Once in setup mode you can enter
bsetup category board, or bsetup category, and this will set up
the initial position of the variant loaded from the file category/board
or category/0. This means that commands like bsetup shogi,
bsetup gothic or bsetup capablanca bird work without problems,
and XBoard adapts variant and board size accordingly.

The problem of taking back castlings in examine mode should be
fixed now; it was due to a new internal representation of castling
in the ICS I had implemented to unambiguously specify Chess960
castling, but which was not recognized by the take-back routine
yet.

More bug reports on this are welcome, as I don't really know how
setting up boards is supposd to work. Is one supposed to use
edit-position mode in XBoard to setup the position?


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #27630] Black fairy pieces partly transparent

[h.g. muller]

Maybe we should consider providing a way at compile time to choose which 
way it's built?  I think including an additional directory for the bitmap 
differences shouldn't cause much size increase to the source tarball.  Or 
maybe it would-- how do we get lzma's soliid archive feature into the 
tarball?  Anyway, something to think about.


The XBoard pixmaps are in fact totally ridiculous. Each pixmap comes in two 
practically identical copies. That is, the picture is exactly the same, but 
it just assigns a different color to the . character (which indicats the 
backgrund in all cases). This could have been trivially done at run time. 
In fact the same character strings describing the four colors now occur in 
every pixmap. Perhaps the compiler is smart enough to collapse all those 
copies of the same string to one in initialized read-only data, but perhaps 
it is not.


It would be much more efficient to initialize the color indications with 
NULL in all the pixmap source files, and put the pointer to the actual 
strings there only before converting them to internal format (i.e before 
feeding them to XpmCreatePixmapFromData). That would make the dl  ll 
pixmaps truly identical to the dd and ld pixmaps, reducing the number of 
pixmaps by 2. If this system is used, the black pixmaps can be included as 
3-color pixmaps, using a different character for the square color and the 
details, but under control of a transparancy option, the color for the 
details could be set to the square color in stead of the white-piece color.



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #26127] Enhancement: XBoard support for MiniChess 2009

[h.g. muller]

This patch as given is inompatible with the latest source, as the code it 
patched

has mostly been changed beyod recognition, because it has been already patched
to do similar things as this patch aims to do (changing board size and such).

The up side is that the new code can be patched really easily to implement this
variant. The promoted archbishop (indicated by 'I' in variant fairy) could 
be used

to represent the augmented Bishop, and moves could be added for it in the move
generator.

It is probably better to wait a bit with this until after some code 
refactoring: this
variant has deviating gme-end rules for stalemate, and I would really like 
to indicate
such rule modification by global flags that could be set from 
InitPosition(), so that
the rest of the code could test them in a variant-independent was. 
Currently the code

is littered with conditionals like
if(gameInfo.variant == VariantShatranj || gameInfo.variant == VariantXiangi 
|| ...)

to dish out the variants where, say, stalemated counts as a loss, which have
been accumulating complexity as I added more variants, and it would be really
good to clean that up as a part of the MiniChess patch.


At 02:02 3-10-2009 +, Arun Persaud wrote:


Update of bug #26127 (project xboard):

  Status:None = Need Info
 Assigned to:None = apersaud

___

Follow-up Comment #1:

can you please test if the patch still works against the latest source...
there has been tons of changes. If it is still ok, let me know and I'll apply
it.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?26127

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard




___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #17234] Bogus en-passant capture

[h.g. muller]

At 02:10 3-10-2009 +, Tim Mann wrote:


Follow-up Comment #2, bug #17234 (project xboard):

Did HGM fix this in 4.4.x?


Indeed, this should be fully fixed. We even understand e.p. capture of 
Berolina Pawns now. :-)))



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Xboard 4.3.15 bugs Mac OS X 10.5.8 PPC

[h.g. muller]

But then the 'xboard -variant capablanca', machines playing against
each other, gives an error:
  {False draw claim: 'Stalemate'} 0-1 [1]W+0.00 a8a8
Error happens also when playing white against machine, for example:
  Illegal  move f4 (rejected by first chess program)
This happens also in Edit Game mode.


Was this false draw claim on the first move?

It sounds like fairymax is not working properly, despite the fact that it
compiled without errors. Apparently it finds no moves, and thus declares
stalemate if it is its own move, and refuses every input move from an
opponent.

As this is not an XBoard, but a Fairy-Max problem, I guess it would be
best to continue the discussion outside this mailing list. Could you
try 'xboard -variant capablanca -debug' and then e-mail me the
xboard.debug file that will be made? Perhaps that will tell me some
more.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #27153] Pre-move does not work on xboard 4.4beta1

[h.g. muller]

Can you provide us with an executable that has the premove problem?
I identified some problems with premove in WinBoard (due to lack of
refresh of the display the premove highlights were not always visible
there), and fixed them. But XBoard did not have the same bug, and
for me seems to work as it should on Ubuntu Hardy. So I would like
to try your executable, to see if it is a compilation or an environment
problem.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Please Help

[h.g. muller]

ok... how about aiming for 4.4 to get all the changes from Allessandro
and you in (in case we can get a hold of Allessandro) and then for 5.0
to port everything to gtk and combine winboard and xboard.


I don't know what strategy the Savannah project was using before for
stepping up the numbers, but the diffrence to the merging of 4.3.15
and '4.2.7+' (the internationalized version is a so far unrealeased one,
correct? Perhaps we should refer to it as 4.2.8?) and the existing 4.3.15
will basically be only the internationalization. I.e., for the average
(=Anglophone) user, no difference at all. So stepping up the version number
for this seems like overdoing it. That would even hold if we would use
my current 4.3.16 alpha source as a basis for merging, as compared to
4.3.15 I have not really changed much (engine logos, but only in WinBoard,
and diverting the opponent's engine kibbitz to the engine-output window
in ICS mode, and some iprovement of the Xiangqi support the average
user would not care about at all).

But if you feel that it is better to step to 4.4 as a signal that the forks
are now unified again, I admit that would be a valid reason, even if the
actual code advance does not justify it and would suggest 4.3.16.


Another question: Since I have to admit that I never really looked at
winboard, how much does it differ from xboard? Are most of the files the
same and only a few different and if they differ, do they differ just
because you added/fixed things in winboard or are there big differences
apart from the GUI code?


WinBoard and XBoard differ only in the GUI code, although for some
unfathomable reason the command-line-option definitions are considered
GUI code. Originally this was only winboard.c (I suppose), but patches
for GUI enhancement have put some of it in separate files, all starting
with 'w' in the name (whistory.c, wedittags.c, wengineo.c, woptions.c).
Especially Allessandro has been very active in the GUI area, and I
back-ported some of his changes to XBoard, making the corresponding
'x' files (xengineo.c, xoptions.c), while others (e.g. xhistory.c) already
existed in the Savannah version. In particuar the eval-graph auxiliary
window (wevalgraph.c) still has to be done, while there are some important
GUI enhancements in winboard.c as well. (The bitmap board textures and
the rendering of pieces with true-type fonts. And I am adding engine-logo
bitmaps to that, while I also added an option to save the current board display
as bitmap file for making diagrams.)


cheers
ARUN




___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard

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 

Fwd: Re: [Bug-XBoard] Please Help

[h.g. muller]

Date: Fri, 10 Apr 2009 00:42:02 +0200
To: Arun Persaud apers...@lbl.gov
From: h.g. muller h.g.mul...@hccnet.nl
Subject: Re: [Bug-XBoard] Please Help



that sounds very promising. I emailed Allessandro and if he already
signed the forms than we could go right ahead... If it is ok, I'll
forward your email address to the gnu-guys, so that they can start the
process to get you all set up.


OK, no problem.


 From then on basically all changes and new code in the back end and
 front end
 files where from my hand, with one exception: I based the code for the
 GUI book on code from Michel van den Bergh, which was already released
 in the public domain. So I guess he already abdicated his rights
 (the code is published on his website, see
 http://alpha.uhasselt.be/Research/Algebra/Toga/book_format.html ,
 which also makes a comment on the legal status.)

so that's for the GUI? I guess, if we change to gtk we would rewrite
that code anyway... (btw: is gtk ok with you? I got the feeling it is,
but I guess the question never really came up ;))


Why would you want to rewrite it? This is pure back-end code, not?
(I put it in the file book.c, which goes in both the WinBoard and XBoard 
build.)
My knowledge of gtk is zero, so I don't feel qualified to have any opinion 
on it

at all. I understand that it is something that would compile both on Linux and
WinBoard.


that should be ok... I think the rule of thumb is if you add more than
15 lines of code they want to get a form signed. This doesn't include
similar changes as adding a #define in every file or so...


Then I think it is OK.



Do we really need backward compatibility, if we provide a SVG version of
all the graphics? Since changing to gtk and getting all the changes you
did into Savannah, we change so many things and introduce new
dependencies for gtk anyway, I would think that this would be a good
point to clean things up and through all the Xt/Xaw stuff out completely
and perhaps other things too.


The point is that there are people who are using XBoard with customized
graphics, e.g. like this: 
http://linuz.sns.it/~monge/wiki/index.php/Chess_pieces .

They won't be happy when they download the new XBoard executable, and
it turns out it does not understand the pixmaps they took so much effort to
design anymore.



 do you have your code in version control? would be nice to keep the
 history of all the changes for example

 Unfortunately not, as I haven't the slightest idea what version 
control is,

 and what it is good for...

this is my take on version control: it basically allows you to take a
snapshot of the code whenever you want and add a comment to it. So
whenever you add a feature you would take a new snapshot and add a
comment: added feature foobar. It also makes it very easy to get a
diff from version abc compared to version xyz, so you can easily see
what was changed or to revert changes you made. The main advantage is
that it makes it easy for people to work on the same project at the same
time, since it can keep track of who changed what and what was changed
when, which makes debugging easier. It also helped resolves merge
conflicts in case several people changed similar things. There are a lot
of different programs out there that can be used to do this. Xboard on
Savannah uses CVS, which feels a bit outdated to me (but Tim would like
to keep it, since he is very familiar with it). I use git
(http://git-scm.com/) for most of my stuff nowadays. But using just
tar-balls is fine with me too... I can upload the stuff to Savannah and
handle the CVS part of it, that way you can do more coding, which I
guess would be more productive ;)


OK, I will definitely have to gt acquainted with this. I have never programmed
anything as part of a team, so I had never to deal with some of the problems
you sketch, but I can imagine they exist.

If I work on my own I keep very few 'snapshots', basically only the versions
that I release. And they usually contain many new features, as I typically 
work

on many features at the same time. And often they are not even finished when
I release, e.g. when I postpone creating menu items for them to a later 
release,

and initilly only have them accessible through command-line options. There
has been no plan or grand design; I add features as I need them (or people
request them), and then I slowly polish them to perfection.


As far as I can see it we should do the following:
* get you signed up for the gnu-project
* get Allessandro's signature
* keep you working on winboard
* keep me working on gtk


Sounds like a good plan. Note that in expanding the capabilities of WinBoard,
I also extended WinBoard protocol with some sorely needed new commands.
Documenttion will probably also have to be put on the agenda.

I am currently working on what will become 4.3.16; this includes fixing some
bugs people complained about. In the WinBoard branch I am currently working
on the displaying of engine logos (next to the clocks

Re: [Bug-XBoard] small bug

[h.g. muller]

Andrew Schultz wrote:

 Found a small bug--maybe someone saw it before. If you start a new game 
and try
 to move a pawn from a2 to a8, the promotion dialogue pops up before you 
are informed
 it is an illegal move. In any case, it's an excuse to write to say 
thanks for something

 that can let me look at a game quickly when I need a short work break.

Hi,

note that I fixed this bug in WinBoard 4.3.12 and higher. There, if 
legality testing is on,
WinBoard first checks if the move is legal, and only when it passes the 
test, pops up
the promotion menu. Especially in Shogi, where the promotion zone is not 
just last rank,
and it is not only Pawns that promote, getting the premature popup was 
extremely annoying.


I don't really agree with Tim's answer: Most variants are played with 
legality checking on,
and there is no need in that case for xboard to consult the engine in order 
to know that
the move was illegal. So it is not too big an effort to at least suppress 
the promotion
popup in those cases where xboard is aware from the start that the move is 
illegal, and will

not even pass it on to the engine no matter what piece you select.

If legallty testing is off, there is no alternative to the old behavior. 
People switch off legality
testing for the purpose of playing variants for whcih the rules are not 
known to xoard,
and it is conceivable that there are variants in which the legality of a 
move depends on
which piece you promote to. (e.g. suppose that a ' Rook'  represents an 
'Immobilizer' ,

freezing the opponent's neighboring piece that was checking you.)

Regards,
H.G.Muller



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard