Discussions among XBoard and WinBoard developers ()

h.g. muller | 19 Jan 2010 16:37

Re: gtk version status

OK, I started a new branch "promopopup" on hgm.nubati.net.
In that brnch, I eliminated the promoton popup altogether.
Like already was the case for Great Shatranj and SuperChess,
there is no popup when you promote, but XBoard just waits
until you click a piece (displaying a message in the message
field that you should do so).

For the mmentioned variants, the choice was limited to what
you had in your holdings, which wre always displayed. In other
variants, the piece you want might not be on the board, however.
So what I had to add is that it stuffs a temporary board with all
the pieces you can promote to. (It gets those from the pieceToChar
table.) It then displays that board, waiting for you to click it.

So the whole thing is now completely handled in the back-end,
so merging it with the gtk branch will make it work there without
any changes! If we rather have a true popup, the board that
is now displayed in the main window would need to appear
as a mini-board in a popup, with a cancel button added.
(If people want to cancel now, they can click an empty square.)
But this is merely a cosmetic refinement now.

I cannot do the same thing for the Edit Position menu entirely
in the back-end, because that popup is called from the front-end
to start with. I could only do it here because the mouse driver for
left clicks was moved to the back-end. So my next step will
be to similarly move the mouse driver for right clicks to the
back-end, and then address the Edit-Position menu. (Which
is then just a matter of cloning what I have done for the
promotion popup, except that you decide a little differently

(Continue reading)

headers

Arun Persaud | 19 Jan 2010 21:17

Re: gtk version status

Hi

> Migrating the right-click mouse driver to the back-end will
> also make the PV display feature work in the gtk branch,
> (once the gtk front-end hooks into this).

hmm, when you do this, do you actually use calls do X-functions in the
backend? Would be good to avoid that to make porting to GTK easier... if
not, just ignore this email ;)

ARUN

headers

h.g. muller | 20 Jan 2010 00:18

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

(Continue reading)