Re: [XBoard-devel] Menu organization

[h.g. muller]

> yes, so my suggestion is to only have one menu
> entry and then a
> prominten checkbox in the save-dialog... e.g. save position/game or
> determine it by the file extension the user puts in. This would
> declutter the menu a bit and would make it more consistent in case
> we
> only have one load function... so probably something to do when we
> merge
> the load functions

I don't see that as an improvement at all. It woud require the user to
indicate
by 2 actions what he wants done in stead of one. Recognizing
something
from the screen is an order of magnitude faster than clicking
something.
So adding another level of selection would only be an improvement 
if
it reduces the number of items at least 10-fold. E.g. having a single
menu
wth 9 items is highly preferable over 3 sub-menus with 3 items.
Especially if the 9 items were already ordered as 3 groups of three
through a menu break. Then making two levels would simply double
the work for zero compensation. And the proposed File menu only
has 10 items.

Last night a reason occurred to me why we should have separate
Load Game and Load Position menu items: When the file browser 
dialog
pops up, you would want it to display *.PGN / *.GAM files in one
case,
and *.FEN / *.EPD files in the other. Requiring the user to first
type
that first is an absurdly high price for elimination of a single menu
item
(i.e. for no real gain whatsoever).

> >>  can we combine ICS Input Box
> with type in move?
> > 
> > I think this is possible. 
>
> so we can get rid of one of them? And perhaps rename them to just input
> box?

At the current stage there is nothing to get rid of, as WinBoard has no
ICS Input Box
(or at least no menu for it, since it is always integrated in the ICS
Interaction window),
and XBoard does not have any move type-in. So this would only become an
issue
for how to implement future enhancements.

I am not sure if this menu item should have any future at all, though. I
would like
ICS play in XBoard to work as WinBoard works now, i.e. with the input box
a fixed
mandatory element of the ICS output window. So that would eliminate any
function
for an ICS Input Box item. And I severely doubt the usefulness of the
Move Type-In
menu item in WinBoard, as this type-in pops up automatically when you
start typing.


> sounds like it would be good to add some
> #define statements, so that we
> can easily change things in one place...

Either that, or write a higher-level routine for checkmarking and
disabling.
Currently it is one everywhere directly at the API level, like 
this:

    j = 0;
    XtSetArg(args[j], XtNleftBitmap, xMarkPixmap);
j++;
    XtSetValues(XtNameToWidget(menuBarWidget,
"menuMode.ICS Input Box"), args, j);

The X-name of the menu, "menuMode", is built in
CreateMenuBar() by prefixing
the text of the menu item with "menu". I see that we are
responsible
for picking the X-name of menus and entries, so perhaps we should
switch
to the system of symbolic references in XBoard as well: in stead of
defining
MenuItem as a struct with the text and the callback function, define
a
third member "name" that will not be translated, and used in
the rest of the
code to refer to it. And rather than referring to it hierarchically, we
could
make a routine that searches through all menus to find the symbolic
name,
rather than having to specify the menu it occurs in. Like:

    MenuItem modeMenu[]=
{
      { N_("ICS Input Box"),
"typeIn", IcsInputBoxProc },
    };

    CheckMark("typeIn", TRUE); // put mark
    EnableItem("typeIn", FALSE); //
grey-out