WinBoard 4.4.3 released

[hgm]

WinBoard / XBoard 4.4.3 source code is now available as tar ball from the GNU xboard website. A Windows installer can be obtained from WinBoard forum.

This is again a bugfix version (perhaps the last, as bug reports are awfully scarce, lately). For the really new stuff, you have to use the development version, see http://hgm.nubati.net/news.html .

[muxecoid]

Thanks for your hard work.

I'm a bit confused. What is the status of your repository? Is it a fork of win/xboard or the new "official" repository? I tried reading xboard page at gnu.org but it makes me even more confused.

[hgm]

My repository should be considered a preview of what will be in the GNU repository later. At least the hgm4 and hgm4.4.3 branch correspond to the GNU master and v4.4.x, respectively. I think currently the GNU repository is entirely up to date.

Note he GNU deveopment itself is currently forked: the v4.4.x branch incorporates only bugfixes, while all new features and large-scale rewrites of code only go into the master branch. In the not-too-distant future the master branch will become 4.5.0, which will then be designated 'stable version'.

[muxecoid]

I just compiled xboard from git. Last time I tried to use xboard was in 2005. What can I say... I still hate xboard... The program still looks like it is year 1994. Selecting operating mode from command line and being unable to switch from playing on ICS to analyzing with engine with menu in 2010 feels so awkward.

I appreciate your effort and the effort of all the other developers. I know that it is extremely hard to modify 20-years old legacy code. xboard is not bad, it is probably good. And I can only imagine how awesome it felt in 1992 . I guess I'm just too young for xboard and it is not my thing.

[hgm]

Well, this is definitely something that is annoying me as well. It is still on my to-do list to allow loading and unloading of engines at any time during the session, through the menu. WinBoard has the start-up dialog where you can select an engine, but I also hate that. I once tried to make a version that could summon up the start-up dialog from the File menu. But that did not work satisfactorily. One problem is that the code for initializing the engine-related settings would have to be clearly separated from the code initializing the GUI settings, so that you can redo the former without losing the latter. That will require a lot of code refactoring.

[alpha123]

Well, this is definitely something that is annoying me as well. It is still on my to-do list to allow loading and unloading of engines at any time during the session, through the menu. WinBoard has the start-up dialog where you can select an engine, but I also hate that. I once tried to make a version that could summon up the start-up dialog from the File menu. But that did not work satisfactorily. One problem is that the code for initializing the engine-related settings would have to be clearly separated from the code initializing the GUI settings, so that you can redo the former without losing the latter. That will require a lot of code refactoring.

This sounds like a headache.

Perhaps it's about time to rewrite WinBoard/XBoard with C++ and a new GUI toolkit like wxWidgets..... I can imagine that code from 1991 isn't too easy to maintain..... Though that would take tons of effort.

Peter

[hgm]

Well, transforming exisiting code is still a lot less work than re-writing it from scratch. Arun Persaud is currently writing a new front-end for XBoard based on GTK+. This would allow some things that are currently not possible in XBoard. For instance scalable vector graphics for the pieces would make the board size continuously adjustable. Problem is that all the pieces would have to be redone as SVG. Currently only the 6 orthodox piece types work in Arun's version.

Working with the od Xaw widget set is not too painful, now I know how to do things. The main problem is that some things seem simply impossible. Like having letters of different colors in the same text widget.

[jdart]

Getting Xboard and winboard on the same UI technology would probably help with maintenance.

Someday I'll get the Arasan UI updated - its backend protocol is basically Winboard but with a few addons. So in theory it could be used with other engines. It needs a look and feel upgrade and some key missing features. But I'm not very keen to take on the project of making it a full blown all features UI like Arena or Winboard. It has always been small/fast/light.

[muxecoid]

There were many ambitious free like in freedom chess GUIs in development, most of them never reached maturity. Knights was very promising but it died in late alpha stage. Eboard is mature but it is limited on features. xboard is rich on features but you need to fight the counter-intuitive GUI to use even the basic features. xboard is extremely lightweight, but 15 years old hardware limitations are no longer relevant today.

Looks like commercial Shredder GUI is the only cross platform interface that just works. Java eats some memory but it is neglectible on modern computers.

[ilari]

For instance scalable vector graphics for the pieces would make the board size continuously adjustable.

It's possible to have adjustable board size with bitmaps too - Arena does this. It just doesn't look pretty.

Problem is that all the pieces would have to be redone as SVG.

That is not a big problem compared to all the coding. And there are freely available sets of SVG pieces, eg here: http://commons.wikimedia.org/wiki/Categ ... svg_pieces

Getting Xboard and winboard on the same UI technology would probably help with maintenance.

That's what Peter C is suggesting, and I agree, though I think Qt is far superior to wxWidgets.

There were many ambitious free like in freedom chess GUIs in development, most of them never reached maturity. Knights was very promising but it died in late alpha stage. Eboard is mature but it is limited on features. xboard is rich on features but you need to fight the counter-intuitive GUI to use even the basic features. xboard is extremely lightweight, but 15 years old hardware limitations are no longer relevant today.

True, there are no decent modern-looking cross-platform chess GUIs. We're trying to fill that gap with Cute Chess. The reason I think we'll succeed is because we're designing a really solid base (libcutechess) before creating fancy GUI widgets like 3D boards. When we have an easy-to-use, powerful, extensible and flexible base, it will be easy to implement features very quickly.