Re: [XBoard-devel] Menu organization

[h.g. muller]

> > File menu:
> > New Game
> > New Shuffle Game...
> > New Variant...
>
> can't we just have one entry here (new game) and set the variant in the
> mode menu? That is have a Mode entry: "Variant/Type..." and you can
> choose there what type of game you play.

Well, I am not sure that would be better. New Variant implies New Game,
so I think it would be logical to have the two next to each other. I perceive
the same difference as that between Save and Save As... I don't think it
would be a good idea to have the user set a file-name in the Options -> Save
menu first if he wants to save on another file as the current. Likewise here.
You want to start a new game.Most of the time in the same variant as
the previous game, but sometimes in another variant. So then you get
a dialog first, just like with Save As you get a dialog to enter the 
fiename first.
Similarly (and even more so) for New Shuffle Game. I would not associate
merely starting a new Chess960 game with another setup as changing
to another mode.

> > ------------------------
> > Load Game...
> > Load Position...
> > ------------------------
> > Save Game...
> > Save Position...
> > ------------------------
>
> in the long run it would be nice to just have a load/save and load
> determines if it's a game or position on the content of the file or the
> file extension. Similar for saving it would be nice to have an option in
> the saving window to select game or position (and for example
> automatically choose position if there is no history,etc) instead of
> having two entries in this menu...

For Paste Game/Position this unification has already been acheived;
although here are stll two menu items, they call the same code
(at least in WB, PasteAny). Officially XBoard does not attach any
meaning to extensions, so we would have to go by file contents.
But this is how Paste has to do it as well, of course. What I do
is use ParseFEN on the clipboard contents, and if it produces an
error message, parse it as a game. (FENs have a better defined
format than games, as we want to allow pasting of non-PGN games,
like simple move lists..)

But you are right: this involves more programming than just shuffling
the menus, so I don't want to do it at this stage.

I don't think there exists such a solution for saving, though. It
is fundamentally impossible for XBoard to know what the user wants
to save. For exactly the same XBoard state you could want to save
the game or just the current position.

> > ICS Input Box (XBoard-only)
> > Open Chat Window
> > Type In Move
>
> I would get rid of the "Show" and "Open", since they are already in the
> View I would just say "Engine Output", "Move History", etc. makes it
> more consistent IMHO...

Well, for now I want to leave that, because changing it would also mess up
the translations. (and lots of other stuff, see below). I agree that the 'Show'
has always struck me as odd, as when you click it when the window is already
open, you actually _hide_ it. (I changed this for the Game List in WB, btw,
where it now just gives focus to the Game List, rather than popping it down,
because there was no other way to reach the Game List through the keyboard.)

>  can we combine ICS Input Box with type in move?
> I guess you could type in a move into ICS box and it does the move and
> sends it to the ICS and everything else would be handled as ICS input
> (if in ICS mode), else just do the move test.

I think this is possible. In WinBoard when you type in ICS mode the
ICS Interaction Window input widget, which is the equivalent of the move
type-in, is automaticallly given focus to receive any typed text when you
type in ICS mode. What you type then is sent as text to the ICS, but
an ICS accepts text moves, and sends a new board to WB in response,
which is then added to WB to the game. So although you don't type
the move to WB, the effect is the same. (This is how the blind use WB.)
When not in ICS mode, WB pops up the move type-in, which differs from
the ICS Interaction window because there is no output text widget. But
in the current XBoard the ICS input box doesn't currently have an output
idget either, so we can make them the same. If in the future we abandon
the X-term, and divert the output to a text widget in the ICS Input Box,
like WB does, we can simply make the output widget optional. I think
I already dd it that way in the git side-branch that stalled on the
colorization problem.


> > Options menu:
> > Flip View
> > Swap Clocks
> > Mute all Sounds
>
> are these really the 3 most needed options? Else I would put them into
> general or somewhere else... flip view I can understand, but the other
> two I for example never use, switching the clocks, I actually find
> confusing ;)

Mute Sounds was added on specific request to provide a quick way
to switch off sounds, because all alternative ways are hidden very deep
in the menus now. (E.g. when you receive a telephone call when you
were observing an ICS blitz game.) That you don't use it might not be
very significant, as:
1) You never use WinBoard, and XBoard does not have it.
2) Do you even use sounds in XBoard (E.g. what sound do you hear
on receiving a tell, what sound on a shout?)

Flip View is a View option, of course, and I have moved it to there.
The same holds for Swap Clocks. This might not be used that much,
but since its function is very similar to Flip View (except horizontally
in stead of vertically), I would like to keep the two next to each other.
I guess you never operate engines at Over-The-Board events, or you
would know that it is very confusing NOT to have this option...

> > Time Control...
> > Adjudications...
> > Common Engine...
>
> Perhaps the engine setting from the engine menu should go into here...
> and then we would have an engine section here (separted by ------)
> or this should go into the engine settings

In the old organization this was the case. But I think it would be better
to have a separate engine menu. What is called Common Engine is
not really engine options: they are GUI settings that are only relevant
during engine play (like Time Control is also only relevant during
engine play). Such as where to find the GUI opening book, the
tablebase files. Indeed time-control is greyed out in -ncp mode (to my
extreme annoyance, I can add...), but still I think it would be confusing
to put it in the Engine menu.

> > Save Settings Now
> > Save Settings on Exit
>
> save settings on exit should go into general I would say

I guess that this is where it logically belongs. But would it be wise
to separate these two?

> > English
> > Español
> > Deutsch
>
> Not sure if we really want an entry for each language.. I know that we
> don't support that many at the moment, but in principle this could
> become a very long list ;)

You would see only the languages for which you would actually have
the tanslation file. So presumably people would select only zero or
one languages during installation, and then that is the one (next to
English) that would appear in the menu. If they have none, not even
English is in the menu.



I have made trial patches with new menus for WinBoard and XBoard
in my git hgm6 branch. In XBoard, this is an orde of magnitude more
dfficult (and error-prone) than I anticipated, though. Unlike WinBoard,
which references the menu items by a symbolic reference (which
moves the pain to when you have to define these references when
creating a new menu item), XBoard references all menu items by
their (hierarchical) name. So spread all over the code (in many
files) there are calls to enable/disable or check/uncheck menu items,
which no longer work (and even cause segfaulting) when you change
the menu text or move it to another sub-menu. (This is one of the
reasons translation would totally break XBoard, even if we ever found
out how to switch on gettext.) I think I have fxed them all, but I
cannot be 100% sure, and testing is desirable.

There are a few other points that deserve attenton:

The Comment and Tags popups come in two flavors, that are
controlled through a single menu item: CommentPopup /
EditCommentPopup, and TagsPopup / EditTagsPopup.
There are menu items to pop up the edit version, and these
get checkmarked when it is up. The non-editable version
pops up automatically when new tags or a comment is
encountered. If the editable version was up at that time,
it is closed, and the menu item is unchecked. The non-
editable version contains an edit button that closes it,
and pops up the editable version(and checkmarks the menu).

This is all a bit contrived; it would be better if there was just
one version, with buttons in the popup to enable / disable editing.
(Or make them always editable, and have a "Save" button.)
I don't see any reason why it should be indicated in the menu
if the popup is editable or not. So I would like to have items
in the View Menu which get checkmarked depending on if the
window is up (like all other entries there), which can be used
to open / close them. And have duplicate entries in the Edit
Menu to bring them up for editing, which do not get
checkmarked, and cannot be used to close them.
(For now, these entries invoke the same routine.)

Similarly, duplicats of Edit Game / Edit Position are in
the Edit menu, but checkmarking only occurs in the Mode
menu. The philosophy is that the Mode and View menu also
have the function of indicating the current state, but that this
is pointless in the Edit menu, which does not exhaustively
list all windows or modes.

What in particular needs testing is the enabling and
checkmarking of menu items in the various modes and
window constellations.