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 <[email protected]> wrote: > > > > > Op ma., nov. 8, 2021 om 16:53, Simon Scatton <[email protected]> > 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. > > > > > > >
