Re: New maintainer, plans for the future of XBoard

[Tim Mann]

I have pretty similar thoughts to HG.

Removing the Xaw code from the codebase would be a good cleanup now that the GTK port has caught up and it's now Xaw that is lagging behind in feature support.

I'm not sure either what merging xboard and winboard back together would be. Requiring GTK on Windows does sound problematic, but I haven't really tried it myself. I basically don't use or program for Windows at all anymore.

I am not a C++ fan and have trouble imagining what problems moving to C++ would solve. I can program in C++ but have not kept up with developments there and don't know what good C++ style is thought to look like today. I'm not dead set against C++, but I would rather continue to enable HG to contribute since he's done so much great work.

On Mon, Nov 8, 2021 at 9:37 AM <h.g.muller@hccnet.nl> wrote:

Op ma., nov. 8, 2021 om 16:53, Simon Scatton <simon.scatton@outlook.fr> schreef:

Hello everyone,

My name is Simon and I’m the new maintainer/admin of the XBoard project.

Welcome!

 

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.

Regards,

H.G.