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.
