Re: [XBoard-devel] gtk-branch

[John Cheetham]

> 
>T he gtk branch is really progressing at an enormous rate!
> Most things seem to work now, good job! I toyed a bit with it,
> to see what worked, and what notor only partially. I will report
> my findings below, in the hope this will be helpful.
>

Yes this is very useful. Hopefully we will get round to to looking at these.
 
> The crash on switching variant after moving is now indeed cured.
> 

The X code and X11 headers are gone now. We shouldn't get any more of the 
badpixmap type errors.

> The button for Spartan Chess in the new-variant dialog has mysteriously
> grown a lot larger than the buttons for the other variants.
> 

It doesn't seem to like the fact there are an odd number of buttons. Should be 
easy to fix.

> The animation of explosions in Atomic chess are not centered on the
> capture square, and the piece that captured seems to jump back to
> the from square before the explosion. The latter could be a general fault
> of animate moving, which still does work erratically.
> 

Yes the move animations don't work. Fixing it should fix some things like the 
piece jumping back to from square.

> The piece menu does pop up in Edit Position (with -pieceMenu true),
> but none of the items in it does anything. Sweep-selection of pieces
> (with -pieceMenu false) does not work at all; the first middle click
> produces a white Pawn, the right click a black Elephant (?!), which
> then stay unchanged when you move the mouse. It seems that the
> mose-move event is not yet connected to the corresponding handler
> in the back-end.
> 

It should work with  -pieceMenu true. The thing is though after the menu has 
come up you need to left click the piece to add it to the board. This is 
different to the normal xboard where you keep the right or middle button 
pressed and move the mouse down to the piece to select it. I haven't tried 
sweep seelction yet.

> Promotion menu works perfectly; in Suicide a King button appears,
> in Gothic even Archbishop and Chancellor buttons. All buttons work here.
> Chosing promotion the piece from holdings, as in Superchess, also works.
> Sweep promotions ('Almost always promote to Queen') donot work at all,
> however. The Pawn does change into a Queen when you pickit up,
> but even when you drag it directly to the promotion square the move is
> refused. Dragging it backwards does not alter the Queen in aything else.
> Also here thismight just be a matter of connecting the mousemove event
> to the proper handler.
> 
> When 'gating in' a piece in Seirawan Chess (i.e. selecting the piece 
> from
> the holdings, and then doing a drag-drop move with a back-rank piece)
> doesplacethe selectedpiece on the from-square after the move, but it does
> not 'uncover' it when you move it away. So probably unstacking a 
> multiply
> captured piece in Crazyhouse would not work either (I did not try that, but
> it is the same code that does it).
> 

I hadn't spotted these. There hasn't been much testing on the variants yet. As 
you say it's probably an issue with the mouse event handler.

> The EvalGraph window does not remember its position in the next session.
> Also, the expose event does not seemto redraw it.
> 
> Sizing the main window does not alter the size of the elements above the
> board (clocks, message and menu bar, including the fonts these use),
> like WinBoard does. As a result you cannot go nearly as small as what
> WinBoard can, because the menu bar will start determining the width.
> Perhaps we need something like 'tinyLayout' here, shortening the menu
> texts to go really small without making the font unreadable. But the clock
> font should really adapt to board size.
> 
> It would be nice if width and height of the main window were locked to
> each other during sizing,so you don't create white margins around the board.
> Or at least let them jump back when you are done sizing, as in WinBoard.
> 

We should be able to do something with the board sizing and the size of the 
clock fonts etc.
We can use gtk_window_set_geometry_hints to constrain the board size. When I 
tried this though the results weren't that good. 
Or maybe after the user has finished resizing the board we could manually 
resize the board to a slighlty smaller size which removes the white borders.
The problem is that these methods generate signals which can cause the board to 
get resized again and it doesn't end up the size you wanted. I'm sure we can 
fix that though.

> The board texture still seems to be rendered like every square is a complete
> board. I still think that making the texture scalable gives an excessively 
> ugly
> effect; we really should find something better for this.

The textures are not scaled now. They were scaled in the earlier versions which 
made them look a bit blurred but hopefully they look a bit sharper now. The 
other problem is that every board square looks identical so we should be able 
to improve it by introducing some random variations into the positioning when 
they are loaded onto each square.

I noticed that you can still use the old pixmaps for pieces and board textures. 
Doing this though makes the board resizing very slow.

>