[Top][All Lists]

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

Re: [XBoard-devel] beta version

From: Eric Mullins
Subject: Re: [XBoard-devel] beta version
Date: Tue, 14 Jul 2009 06:45:25 -0600
User-agent: Thunderbird (X11/20090608)

h.g. muller wrote:
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.

I like the idea of just supporting it. The impaired don't have to jump through additional hoops. We have only one binary to support (users amazingly, never include this information in bug reports), and we don't have to do the extra step of making a JAWS binary every time we release.

The issue of people d/l by mistake disappears, and people with JAWS software are always going to have the DLL in the right place.

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.

I sort of agree the startup dialog is an abomination. But it does make the program more friendly too. I just envision an extra script included with the xboard package. Say 'xboard-startup', which we could recommend to people having trouble running xboard proper. It would gather information about how the user wants to run, and then invoke xboard with the appropriate command line arguments to achieve this. It could also add features the xboard program doesn't have such as remembering board size preferences, fonts, etc. It could become quite elaborate, though that wasn't my original vision.

reply via email to

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