Re: [XBoard-devel] beta version

[Eric Mullins]

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
> code.
>
> 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.