Re: gtk version status

>hmm, when you do this, do you actually use calls do X-functions in the
>backend?

Of course not; that would completely break WinBoard. The point is that
the mouse handler of both XBoard and WinBoard contained lot of duplicate
code, for figuring out what action should be taken on the mouse click
(which depends on tha variant, the game mode, who is to move, what is
on the square you click, etc.) As XBoard and WinBoard must behave
the same, most of that code is identical. Only some actions involve
the front end (like popping up a menu), and those need to be done
differently. So what I do is move the common code to the back end,
let the primary interrupt handlers call that code with the information
that has to be passed (e.g. coordinates of the click) casted in universal
form. This back-end code then calls back on the front-end for the
most elementary actions.

But when all decisions about what actually has to be done are taken in
the back-end, it becomes very easy to bypass the menus (simply remove
the calls back into the front end), and do something else in stead.

If you take a quick look at the latest commits in the promopopup branch
you will see what I mean. I am done with the refactoring; currently all
Right-clicks on the board invoke the back-end routine RightClick,
like I had already donw for LeftClicks when repairing premove.
Promotion selection is done by leftclicking the piece of choice on
the board. I am now trying to do the same for Edit Position, but
it is a bit more tricky there, as you call up the menu with a right-click
(while a promotion was triggered by releasing a piece on a promotion
rank). So the mouse button is initially down. You can of course