headers
Tim Mann | 1 Jul 2009 05:03

Re: Re: webpages for xboard

On Tue, 30 Jun 2009 11:52:00 +0200, "h.g. muller" <h.g.muller <at> hccnet.nl> wrote:
> At 00:35 30-6-2009 -0700, Tim Mann wrote:
> >Actually, looking at the recent messages, people are still coming there
> >to ask about the protocol sometimes.  Let's keep the group around
> >and keep a link to it from whatever page(s) we end up having for engine
> >authors.  We should point them to the WinBoard Forum too, though, since
> >that's more active.
> 
> I think that is a very bad idea. I never visited the yahoo chess-engines group,
> and do not intend to do so in the future. I want to keep any discussion as
> centralized as possible. Even if the developers would always be at both sites,
> it would be very undesirable to have disjoint groups of engine authors
> discussing without knowing about each other, and each other's proposals.
> The usefulness of discussion grows as the square of the number of participants.
> 
> It seems unfair to send people to a place where their remarks and proposals 
> will
> be utterly ignored. So I think it should be clearly specified that if they post
> something at yahoo, no one will look at it for months, while if they post 
> at WB
> forum, they might have 24-hour service for downloading a new alpha version
> implementing their suggestion. Only if every link to yahoo goes accompanied by
> such a warning, I would be in favor of including such links,

Well, people have not been making proposals on that list, just asking
"how do I do this?" or "what does this mean?" questions, and they
usually get a quick answer from someone else on the list or from me.

However, I'm fine with putting a notice on the Yahoo group that people
should go to the WinBoard forum instead.  I'll do that.
(Continue reading)

Permalink | Reply | 0 comments |
headers
h.g. muller | 4 Jul 2009 12:34
Picon

Button-bar focus

I hope Tim can answer this:

We uncovered some mysterious behavior when testing WB for JAWS,
where one is completely dependent on key strokes to operate it, as the blind
cannot use a pointing device like a mouse. The behavior is not specific
to the JAWS version, but likely unnoticed by normal (mouse) users.

It seems WB makes a lot of effort to put focus on the button bar when
you leave the ICS interaction console with a TAB command. There is
a special event handler ButtonProc(), to make sure that Left and Right
Arrow keys cycle through the buttons in this state, and that Enter 
activates the
selected one. There is no direct provision to get out of this mode and get 
focus
back onto the main window (although you can TAB back to the ICS window),
e.g. to activate the main menu bar for changing option settings.
The only other exit from this state is through invoking the move type-in 
dialog,
(by typing an alpha-numeric character) and then quitting it.

Why does this feature exist at all? We have accelerator keys defined for
the buttons (Alt + Left / Right / Up / Down in the standard version).
It seems much simpler to have TAB from the ICS console give focus
to the main window, and use these key strokes to activate the step functions
directly than to use the arrows to navigate through the buttons before you can
activate them.

Can I savely remove all code for this, "inter-button navigation" or do you 
recall
special reasons why it was introduced and should better be kept?
(Continue reading)

Permalink | Reply | 26 comments |
headers
Tim Mann | 4 Jul 2009 19:40

Re: Button-bar focus

The general idea was to have a tab chain like other Windows apps.  In
4.2.7 and earlier, though, there's not much you can control with the
keyboard in the main window -- just the button bar, the menu bar, and
of course accelerator keys.  The tab chain doesn't include the menu bar
because (iirc) Windows apps don't normally include that in the tab
chain -- you can always get to the menu bar with Alt+Space, and that
works in WinBoard too.  So tabbing to (or in) the main window just gets
you to the button bar.  As you noted, this is not super useful, since
accelerator keys exist too.  However, I think the tab chain is a good
feature to keep since it's consistent with Windows standards.  I think
the idea of this standard is that you can operate the app from the
keyboard without having to know what its unique accelerator keys are.
You only have to know about the Windows standard keys Tab, arrow,
space/enter, and Alt+Space.

WinBoard does add an extra twist to the standard by making the same tab
chain cycle through two different windows if the ICS interaction window
is up.  I didn't make tabbing across select the new window and bring
it to the top because (at least on smaller screens) one sometimes
keeps the board window on top of most of the ICS interaction window,
with only the bottom part of the ICS window sticking out.  I didn't
want tabbing to the interaction window to raise and and possibly cover
up the board, though on the other hand I guess there's some argument
that tabbing to the board *should* bring it to the top.  However, you
can use the Windows standard Alt+Tab to switch windows and bring the
new one to the top.

Does WinBoard for JFW (and/or 4.3.*/4.4.0) have a way to move pieces by
moving the selection highlight around the board with the arrow keys and
picking up or putting down a piece with the space bar or Enter?  If so,
(Continue reading)

Permalink | Reply | 25 comments |
headers
h.g. muller | 4 Jul 2009 23:12
Picon

Re: Button-bar focus

OK, thanks for the explanation. Now I see the logic.

Indeed the JAWS version allowed you to move an 'active square'  over
the board with the arrow keys, and the board was not in the chain.

In the light of what yo tell me there might be a logical problem with
the JAWS version of 4.4.0. This has a few extra windows (engine output,
evaluation graph) that are just for display, where there is nothing to do,
either with the mouse or the keyboard, and so it is logical that they
should not be part of the chain.

Except that with JAWS, you sometimes want pure output elements to
have focus, because that is when the screen reader starts reading them.
Perhaps something other than tab should be provided for this.

I guess that the fact that these windows do get focus after you pop them
up should be considered a bug then in the normal version of 4.4.0. Especially
since there is no way there to pass focus back to anything else by means of
the keyboard, other than closing them. At the very least tab should be 
recognized
as a command to re-enter the proper chain in these windows.
Permalink | Reply | 24 comments |
headers
Tim Mann | 5 Jul 2009 01:10

Re: Button-bar focus

I guess the tab chain could go through all the windows, even the ones
where there is nothing you can do other than screen-read text and
perhaps select it and copy it with Ctrl+C.

Windows probably has an accessibility standard document that says how
apps with multiple windows are supposed to work, in order to play well
with screen readers and such.  Maybe googling or searching on
microsoft.com would find it....

On Sat, 04 Jul 2009 23:12:40 +0200, "h.g. muller" <h.g.muller <at> hccnet.nl> wrote:
> OK, thanks for the explanation. Now I see the logic.
> 
> Indeed the JAWS version allowed you to move an 'active square'  over
> the board with the arrow keys, and the board was not in the chain.
> 
> In the light of what yo tell me there might be a logical problem with
> the JAWS version of 4.4.0. This has a few extra windows (engine output,
> evaluation graph) that are just for display, where there is nothing to do,
> either with the mouse or the keyboard, and so it is logical that they
> should not be part of the chain.
> 
> Except that with JAWS, you sometimes want pure output elements to
> have focus, because that is when the screen reader starts reading them.
> Perhaps something other than tab should be provided for this.
> 
> I guess that the fact that these windows do get focus after you pop them
> up should be considered a bug then in the normal version of 4.4.0. Especially
> since there is no way there to pass focus back to anything else by means of
> the keyboard, other than closing them. At the very least tab should be 
> recognized
(Continue reading)

Permalink | Reply | 0 comments |
headers
h.g. muller | 5 Jul 2009 14:17
Picon

accelerator keys

OK, the tabbing between windows now seems to work in a compliant way

One other point I wnted to bring up for discussion. This work on WinBoard
for JAWS forced me to critically look at the key assignments, as relying
on the default handling by the OS quicky leads to infinitely cumbersome
operation in something as complex as WinBoard.

In the JAWS version I now added accelerator keys for almost every item
in the pull-down menus. The problem with so many keys is of course
to assign them such they are easily remembered, or it would be pointless.
I figured out a good system, though:

The File menu already contained some standard items like "New", "Open"
and "Save", which conventionally are represented by Crtl+N, Ctrl+O, Ctrl+S.
(Well, "Open" is called "Load" in the menu, but it is the same thing.)
Loading and Saving have to distinguish between games and positions in WB,
and the convention that positions use an extra shift key seemed to be
adopted in the copy-paste stuff. So I added Ctrl+Shift+L and Ctrl+Shift+O
for opning and saving position files. Copy / paste are Alt+C/V or Alt+Shift+C/V
for games and positions, respectively. The more conventional Ctrl+C/V also
work, except in I C S mode, where they are needed to copy and paste text
in the interaction window.

The "Action" menu was already taken care of by the use of Function keys.

The "Mode" menu had almost no shortcuts at all, but most items were used
very frequently. In line with the simpe Ctrl sequences for menu items "Open"
and "Save", I therefore added:
Ctrl+W Machine White
Ctrl+B Machine Black
(Continue reading)

Permalink | Reply | 22 comments |
headers
Eric Mullins | 5 Jul 2009 20:53
Picon
Favicon

HLP file / make / packaging

Recent posts at the Winboard Forum have exposed an issue building the 
latest version.

I'm not sure how far we should go to accommodate users who want to build 
from source, but it shouldn't be hard to have the project compile with 
just the bare minimum of tools.

For those that do not have the Help Compiler  package, it's probably a 
good idea to allow the project to compile without that tool.  There are 
a couple of ways to deal with that problem:
  1) supply a prebuilt HLP file in the package. As mentioned in the 
thread that exposed this issue, we should make sure that the included 
file is at least as new as the RTF file used to generate it.
  2) remove the dependency completely so that you can build winboard 
without generating the HLP file.  Devs could still build the help file 
by issuing something like 'make -f makefile.gcc winboard.hlp'

Also, as mentioned in the thread, using HLP is fairly dated, not even 
working in Vista (I haven't verified this, but believe it).  Maybe we 
want to explore some other method eventually.
Permalink | Reply | 12 comments |
headers
h.g. muller | 5 Jul 2009 21:03
Picon

Re: HLP file / make / packaging

Is there a way to make it a non-fatal error in the make procedure
that the help cannot be built, so that people will get a working winboard.exe,
but just no .hlp file with it (and a friendly warning)?

I would prefer that over supplying a pre-compiled help. WinBoard users
hardly ever build from source. (They only do it now because we do not
supply any binaries on the GNU site.) When they do, they don't do
it because they want to generate a help. But we frequently build new
.hlp files, and I do think it is a good thing we are using the same makefiles
as we distribute.
Permalink | Reply | 11 comments |
headers
h.g. muller | 5 Jul 2009 21:15
Picon

Re: HLP file / make / packaging

Wouldn't this do it?

$(PROJ).hlp : $(PROJ).rtf
	$(HC) $(PROJ).hpj && cp /dev/null $(PROJ).hlp
Permalink | Reply | 10 comments |
headers
h.g. muller | 5 Jul 2009 21:52
Picon

Re: HLP file / make / packaging

You misunderstand me. I don'want to test if the help file exists,
I want to test if Help Workshop exists.
Permalink | Reply | 9 comments |

Gmane