[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XBoard-devel] beta version

From: h.g. muller
Subject: Re: [XBoard-devel] beta version
Date: Tue, 14 Jul 2009 09:55:46 +0200

At 00:34 14-7-2009 -0600, Eric Mullins wrote:
There's 2 things I'd like to see before we release:

1) Instead of having a jaws and non-jaws binaries, I'd like to have just one that does JAWS if it finds the jaws dll, otherwise behaving regularly. I mentioned this to HGM in a private email, but haven't heard back. I can do this fairly quickly though.

I was still thinking about this one, but the more I think about it the less desirable it seems. The JAWS code is very specialized, and interferes with the normal logic of the program by suppressing some focus switches. Even making that of the JAWS code conditional on a run-time switch would confuse future programmers as to how things are supposed
to work.

I consider it a good thing that the JAWS version refuses to work if the jfwapi32.dll is not present. People that downoad it by mistake will immediately discover their error, and people that loaded in intentionally will not be confused as to why their supposedly speaking version does not speak when they happen to have jfwapi32.dll not in the right place.

We can question it if we should offer a download for the JAWS binary at all. Perhaps
we should leave that for specialized websites.

2) create a small gui-script to act as a startup dialog for xboard.
This I don't know how to do, but someone else might, and it can't be that hard. Basically something that works like winetricks if you've ever seen that in action.

I am not sure about this either. How do you envision this script to be used? Should it go in usr/games in stead of the xboard binary, so that people, when they give the command "xboard" start up the script rather than the executable? Should the menu items that are
installed refer to it?

I agree that XBoard does not yet behave at all like a user-friendly program at all. But remedying this with a script is tantamount to distributing the code of XBoard over two levels, of different implementation. If we really want this behavior we should program this into XBoard, and not go to a hybrid implementation of scripts and C code. That is a kludge that people would employ because they have no access to the source

I could add to that that I think the WinBoard startup dialog is an abomination. It is very bad to have features that can only be selected at startup time. There is no reason at all why people should not be allowed to switch engine without restarting. The engine choice should happen in the normal menus, not in some startup dialog. Eliminating the startup
menu is definitely an item on my to-do list.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]