Re: [Bug-XBoard] The clock stops if the board window is moved with stickyWindows on

[h.g. muller]

> I would say cleaning up the code is always a good thing... if you need
> it later you can still get it back easily by looking at old git versions.

Indeed, but deleting a 1-statement unused but potentially useful function
is the least of our concerns in that respect. Now that 4.6.0 is released,
it might be a good time for a major code overhaul in master. Perhaps we
should still wait for this until after the major bugs in 4.6.0 are fixed.
There already were a number of complaints in reaction to the 4.6.0 release,
so I guess it would be a good idea to release a 4.6.1 not too long after it,
with all the fixes. What I fixed so far is:

1) In XBoard the splitting of a path-name of an engine obtained through 
browsing
   in the Load Engine dialog into an -fcp engine command and an -fd directory
   does not work, because Linux refuses to execute plain filenames in the 
current
   directory, but insists they must be prefixed with ./
2) In WinBoard file browsing for a save file in the Tournament Options 
dialog did
   not allow you to type a not-yet-existing file name.
3) It was impossible for people in the new EditPosition mode -pieceMenu false
    to guess how they should clear the board without reading the manual.
4) The transition to -ncp mode for people that referenced a non-existing engine
    (basically those not having installed fairymax) was not entirely 
smooth, and
    involved waiting out the engine feature time-out of 10 sec while the 
UI was frozen.
5) The clock problem noticed by Byrial.

The first four are already fixed in master. I will cherry-pick them into 
v4.6.x later,
because I already pushed some new stuff to master that is not mature enough
to qualify for 4.6.1.

As for a code cleanup, it might be good to split off some reasonably 
self-contained
parts from backend.c, which is really getting awkwardly big. I was thinking 
about
the following split:

ics.c: all the stuff directly related to -ics mode (receive_from_ics, 
parse_board12 etc.)
engine.c: the basic stuff for using an engine (HandleMachineMove, 
InitChessProgram)
match.c: stuff for loading engines and running tournaments
usermove.c: high-level mouse handler (LeftClick, RightClick)
pgnsearch.c: stuff for loading game files, and searching positions in them

For porting XBoard to Android, it seems also useful to extensively refactor 
the
X11 front-end, basically bleeding it dry for any sharable code. I already 
made some
preliminary attempts for that in my hgmaster branch, but I will probably 
redo it in a
cleaner way, drawing on that experience. In any case it means that all 
X11-independent
code will be cleansed from xoptions.c, which will then only contain 
GenericPopup(),
and a number of wrappers to access control elements in it. The rest (all dialog
description tables and dialog-specific callbacks) will go to a new file 
dialogs.c.

From xboard.c I will extract the menu descriptor table and overall menu logic,
(leaving only wrappers for creating menus and menu items) and relocate it 
to a new
file menus.c. This could mean I will change the .xresource interface, which now
can define X-translations for zillions of 'MenuProcs', like 'FlipViewProc', 
where it would
code-wise be really far more efficient and portable to specify that as 
'MenuItem(Flip View)',
where a single X-specific routine 'MenuItem' would take care of all, and 
the item name
is passed on to it as a string (i.e. in a portable format, that can be 
related to the
back-end action from the menu tables by platform-independent user code.)
And the board-drawing logic will be moved to a new file board.c, leaving 
only a
DrawSquare(piece, squarecolor, inscription, inscriptionPlacement) wrapper 
in xboard.c.