Re: [XBoard-devel] Menu organization

[Arun Persaud]

Hi

On 11/24/2010 01:22 PM, h.g. muller wrote:
> [...]
> 
>> > ------------------------
>> > Load Game...
>> > Load Position...
>> > ------------------------
>> > Save Game...
>> > Save Position...
>> > ------------------------
>[...]
> 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.

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

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

In that case I would rather update the translation, which I think is a
minor thing if it wouldn't be for the coding effort... (see comments below)

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

so we can get rid of one of them? And perhaps rename them to just input box?

>> > 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?

I would say yes... this is something you probably only change once and
then you don't touch it again for a long time... I think it should go
into general settings

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

ok.

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

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

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

will do (but I'm gone for a week starting tomorrow), so I can only test
after that...

> 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 like the "save" options

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

agreed.

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

cheers
        ARUN