My name is Simon and I’m the new maintainer/admin of the XBoard project.
Also, I would like to merge Winboard and GNU XBoard back together.
This has been proposed before. XBoard can of course already be used on Windows,
but the problem is that it would require a massive amount of run-time libraries
that are not present on WinBoard by default (GTK, Cairo, Glib).
Cygwin would for instance provide such libraries.
So unlike WinBoard, which has a front-end that uses the native Windows API,
a Windows package of XBoard that would be ready to run out-of-the-box on
a fresh Windows install, would not be 'light weight', which seems to be the most
important reason people like WinBoard.
I don't see how this dilemma could be solved in a way different from how it already is solved:
have a separate front-end for WinBoard. Of course we could write a new front-end
for WinBoard that uses more of the XBoard code. Like generating 'legacy dialogs'
through the general dialog generator routine, rather than having their appearance
hard-coded in a 'resource file'. An exuivalent to XBoard's dialog generator using
the Windows API already exists in WinBoard, and some of the dialogs are already
generated by it. I am not sure this would result in an improvement of WinBoard, though.
This is why I wanted to propose a couple of things to achieve this:
1. Drop support for legacy X Window System and use GTK3/4 for everything.
In practice this has already happened. The latest few releases did not address the Xaw version,
and some of the features do not work there anymore.
2. Update the visuals and the feel of the application.
Right now XBoard feels like legacy software when used, and I get that
it should be functional before being pretty but a little rework on the
interface would not hurt. I think that would attract more people to
free software and this is a good thing!
This is the interesting part, but I have no idea what you have in mind.
Perhaps I am old fashioned, but I have always liked XBoard's look,
while GUIs like Arena or Fritz make me want to puke.
3. Move to C++ instead of C.
Well, since this is a language I do not know, and do not aspire to learn,
it would mean I am out of the GNU project. I probably would keep
maintaining a C-based fork for satisfying my own needs (mostly variant
support), and continue to share it.