Winboard Forum

Some time ago I decided to migrate to Ubuntu and I lost interest on winboard, as its version for linux was way outdated.

But today i read that the work in making Xboard as powerfull as winboard is nearly done. I would like to know if I can download this version, even if it is unstable.

I would like to know aswell if it will support UCI engines via polyglot (afaik it is windows code) and if it will work in a 64 bits OS.

Any bit of help regarding getting an UCI engine (namely Rybka) working on a 64 bits operating system (ubuntu) with Xboard will be very very welcome, as for now, this is the last thing that keeps me from deleting my windows partition, i could not get anything reasonable working on linux.

Many thx.

Ok, i find the source of xboard 4.4.0beta8 but i could not figure out how to compile it :S

Indeed, the automake process for these alpha versions seems a bit complicated, especially for a non-experienced Linux user like me.

I remember some combination of autoconf, automake --add-missing, and perhaps autoheader was needed before ./configure and make. I don't remember in what order, though.

I think alpha8 should be pretty stable for XBoard. Since then I have only been messing with the WinBoard-specific sources. Except for a tiny cange in backend.c, to play a different sound on moves rejected by an I C S as for regular moves of the game. (I am not even sure if XBoard plays these sounds...)

To run Rybka you should have the polyglot package installed. Then you should be able to run Rybka with the command

xboard -fcp rybka -fUCI

If Rybka is installed as a Linux binary in a compliant way, that is. Otherwise you might have to specify a directory. Not all new XBoard commands might be supported by Polyglot in the standard package, as this is also a very obsolete version, I think. But it should be able to run it.

H.G.Muller wrote:Except for a tiny cange in backend.c, to play a different sound on moves rejected by an I C S as for regular moves of the game. (I am not even sure if XBoard plays these sounds...)

xboard 4.2.7 can play sounds by running the external program "play" on the sound file. I doubt anyone uses this feature much, though. Also "play" is kind of outdated and many distros probably don't install it by default -- I notice Ubuntu doesn't. So sound support could use some improvement, but it does exist. (I didn't check whether anyone has already improved this feature for 4.4.0.)

Nothing was changed in this area. In fact the XBoard front end has hardly been changed compared to 4.2.7. Almost all enhancements of XBoard in 4.4.0 come from making back-end features available that were added in WinBoard, through adding command-line options or menu items. The only true changes are the addition of the engine output window and some enhancements of the board graphics and mouse driver for handling the crazyhouse holdings.

It seems the play command is available for Ubuntu in the sox package, and this was indeed not installed by default on my Ubuntu hardy.

There was another program installed called aplay, though, which was able to play the .wav files. I see that the sound driver can be set in XBoard by a command-line option -soundProgram. Perhaps we should make "aplay -q" the default value for this option.

We must also see to it that the Debian package contains the dependency on the sox or aplay package; this does currently not seem to be the case (for xboard 4.2.7). The Ubuntu install for package xboard does not even contain the sound files, although it does contain a set of bitmaps in the directory /usr/share/games/xboard/bitmaps.xchess.

Having Rybka in a binary is done (through microwine).

I'm an ubuntu user, so I know nearly anything about compiling packages, as it all install itself quite easy. So I hope somebody remembers step by step how to install this alpha.

And well, the engine output is the one most important part of the GUI apart from the board itself. If i want to play on FICS, with the board and the command "seek 3 0" im doing fine. But if i need to analyse positions, i will need the engine output too!

I posted a compiled xboard 4.4.0-alpha8 at

http://home.hccnet.nl/h.g.muller/xboard.gz

You could simply copy that (after running gunzip on it) over the existing /usr/games/xboard you have from a 4.2.7 xboard install.

rigao To compile for 64 bit is quite easy. First you need to install a few things with the synaptic package manager as follows(I am assuming you use jaunty 9.04 64 bit OS). g++,Flex,makeinfo,autoconf,xorg-dev 1.7.4. Next unpack xboard alpha8 to a directory in your path ie. /home/yourname. Once unpacked go to the dir and click on autogen.sh this will create the configure file ,make file and do a few other things.Let it do its thing.If it does not do anything make the autogen file executable and try again. Next start the terminal and cd to the xboard directory then simply type ./configure wait a bit, at the prompt type make wait a bit, at the prompt type sudo make install.Your done
The next step is polyglot.I had an issue here.The newer polyglot I compiled unset the .ini file settings I had.You are suppose to be able to avoid this by creating yet another .ini file called global.ini but I found insufficient info on the exact syntax for things like nalimov,path etc and it was more work than I cared to do so I simply downloaded the repository polyglot 1.4-3 with synaptic.It does not understand the General Settings tab in xboard 4.40 but for me all settings done through the polyglot.ini is a sufficient method for xboard since each engine requires its own .ini file anyway.The setup with the new polyglot requires the documentation to catch up a little here so one can create an accurate Global.ini file for polyglot to read.Once I downloaded this and created a rybka.ini I was away to the races. Then in terminal I invoked using xboard -fcp 'polyglot rybka.ini' -fd /home/myname/engines -size 72.I use glaurung and Rybka 960 64 bit. In the rybka.ini file which you will make simply put EngineComand = ./microwine rybka.exe. I renamed Rybka960 to rybka .
As far as I know everything works well except in Fischerandom the king often disappears after castling.The pgn file is fine and the king is still noted.He will reappear when you click on him.This happens both in ics or play against an engine. Since my skills are basic I do not know if it is something unique to my 64 bit build or not.It does not bother me anyway . If all goes well for you up to here then you will have to tell linux to allow more shared memory or rybka/glaurung/crafty will crash.Allow logging in the .ini file and it will tell you why the crash occurred and how to correct.But to correct permanently so that at each start up you do not have to think about it you need to edit the sysctl file found in the root directory etc.Be careful here as you can foul things up badly. This line inserted into the file allows up to 512 megs of hash providing you have enough ram. kernel.shmmax = 536879104.If you have 2gigs or more this is fine I think otherwise work within your hardware limits and using the log file it will give you the correct entry for shmmax. Good luck and I hope this helps. Many have contributed a lot to this good program so I hope this little thing is of some use.Its the only way I can say thank you for the hard work of others that is slightly beyond mere words.

Shiloh wrote: As far as I know everything works well except in Fischerandom the king often disappears after castling.The pgn file is fine and the king is still noted.He will reappear when you click on him.This happens both in ics or play against an engine. Since my skills are basic I do not know if it is something unique to my 64 bit build or not.It does not bother me anyway .

Hmm, this sounds like a pretty serious bug in the display routines to me...

Have other people noticed this?

I just compiled from git tree and started testing:

None of the dialogs work when entering text. I can click buttons (and paste using mouse), but I can't type into the dialogs like load game, General Settings..., etc.

Version displayed at FICS is: Interface: " 4.4.0j." instead of "xboard 4.4.0j."

An earlier problem I had with Rybka leaving zombie microwine processes after closing seems to be fixed though.

Sound seems to work fine. (I use aplay -q, defined in .Xdefaults)

I recommend using "./configure --with-Xaw3d" if you have Xaw3d widget library.

Hi Eric.If you minimize the terminal put the cursor over the dialogue box then it will accept your input.Also do not try Show Moves History it will crash xboard at least it did my version.What does --with-Xaw3d do? thxs

Shiloh wrote:Hi Eric.If you minimize the terminal put the cursor over the dialogue box then it will accept your input.

This works. But I have to pretty much minimize EVERYTHING, including browser windows and non-related terminal windows. Not convenient at all.

Shiloh wrote:What does --with-Xaw3d do? thxs

It enables the Xaw3d wiget library. If you have it, it will make xboard look better. It's an outdated widget kit, but still looks better than default, IMO. It's also customizable by changing your .Xdefaults file.

I vaguely remember that we had this problem of not being able to type in input fields with Xaw3d before.

The Xaw3d text controls seem to be defined too small to contain even a single line of text, so it automatically ' scrolls' anything you type out of view. The layout of the dialogs was designed for Xaw, not Xaw3d...

Eric Mullins wrote:This works. But I have to pretty much minimize EVERYTHING, including browser windows and non-related terminal windows. Not convenient at all.

I see what you mean.

H.G.Muller wrote:I vaguely remember that we had this problem of not being able to type in input fields with Xaw3d before.

The Xaw3d text controls seem to be defined too small to contain even a single line of text, so it automatically ' scrolls' anything you type out of view. The layout of the dialogs was designed for Xaw, not Xaw3d...

I did not use xaw3d in fact I could not even get it to work.I simply used ./configure but still I have this problem as well.The xaw3d package is installed but I did not invoke it.Could configure use this package automatically?

While we are at it there are a few other little things I noticed HG that might help (probably create need for Tylenol) . First is when I am playing against an engine the clock flashes in sync with the changing seconds.Very irritating.It does not do this in ics mode. Additionally I have to hold the mouse button down when I click the menu then scroll to the item and release.I do not know if this has always been the case or for that matter if it is just my build,but the menu does not stay up if I release the mouse button.Finally when I choose variant FRC then new shuffle game then random the numbers that appear are not the normal 960 start positions until after I press OK then recheck the new shuffle game menu at which point it tells me correctly which start position I have currently.My system is Linux jaunty 9.04 64 bit on dual core amd 64 bit 1.6ghz laptop. Perhaps Eric or other knowledgeable users can confirm or refute these few issues. Thanks for your efforts

H.G.Muller wrote:I vaguely remember that we had this problem of not being able to type in input fields with Xaw3d before.

The Xaw3d text controls seem to be defined too small to contain even a single line of text, so it automatically ' scrolls' anything you type out of view. The layout of the dialogs was designed for Xaw, not Xaw3d...

As Shiloh points out, this issue isn't related to Xaw3d. I get the same problem either way.

Shiloh wrote:I did not use xaw3d in fact I could not even get it to work.I simply used ./configure but still I have this problem as well.The xaw3d package is installed but I did not invoke it.Could configure use this package automatically?

In order for it to work at all, you need the Xaw3d and Xaw3d-dev. On Ubuntu, search for Xaw3d in package manager and install both the widget set and the dev package. (xaw3dg & xaw3dg-dev)

Unfortunately, dialogs do not get this enhancement because of some recent change in either the headers or compiler, at least on my machine. There's a note about this if you scrutinize the configure output (or config.log).

I see what the problem is-- you can't focus xboard anymore. I was trying to produce a couple images to illustrate the difference with and without Xaw3d, and simply was unable to focus xboard without minimizing everything else.

Just for reference, here's the difference between Xaw3d and Xaw:

Xaw


Xaw3d


Keep in mind, you can customize the Xaw3d one pretty heavily. I like fairly flat buttons, but you can make the borders much bigger, for a more full 3d effect.

Are you using something called "desktop functions" or someting similar? Michel van den Bergh once told me that he could not run XBoard 4.3.15 at all when this was switched on.

If the focusing is a problem, this might be relevant:

In general I program by cloning existing features that already do something similar to what I want to do, and then modify them for my purpose. This because my knowledge of APIs is about zero, and I had never even heard of a widget before I looked at the XBoard code.

But the only dialogs XBoard had were simple filename type-ins. They were made of a pre-cooked widget, that you could add buttons to, but nothing else. I needed dialogs with multiple text inputs, so I had to build them myself, and there was no example of how to do it in the code. My first attempt of making the dialogs I needed with elementary widgets did result in the desired layout, but had the very weird behavior that I could only type in text fields when the mouse cursor was over it. Not at all like the filename type-ins. This is how I learned about the concept of focus.

So what I did was add a callback to every text input field triggerred by a mouse click, which then used XtSetKeyboardFocus() to set focus to the clicked input field. Although shockingly low-level, this in principle seemed the way the problem should be handled. If you now say focussing does not work, it suggests that something interferes with proper operation of XtSetKeyboardFocus().

All these dialogs are programmed in xoptions.c.

Disabling desktop effects (compiz) solves it. The behavior is like if I use the "window rules" plugin and set xboard for "no focus", except I don't use that plugin, nor do I have any settings specific to this program.

4.2.7 doesn't exhibit this issue at all though.

4.2.7 did not call the XtSetKeyboardFocus() at all. The simple type-in dialogs did automatically assign keyboard focus to the text edit in them, without the user having to do anything for it. No ide how it did it, for the application it was an atomic thing.

Could it be that I have to do something explicit to return KB focus to the parent window when a dialog is closed? I don''t think I do that now, because it always seemed to happen automatically. But with this desktop stuff on, it might snatch the focus in stead of the previously focused window. (Just guessing...)