Winboard bug : auto size-up while moving the window

[Mathieu]

Hi!
As I mainly try winboard for variants, I found some strange behaviour while selecting xiangqi or shogi (must be true for other non standard sizes I guess):
I open winboard in edit mode with a rather smal size (middling for exemple as it as the pieces needed for the cited variants), but every time I move the window (by clicking then dragging the window upper bar) the size gets bigger (and then, I lose the embeded pieces). For xiangqi, it grows up until I moved the window enough times to reach the "huge" size, while for shogi, it grows up 3 times then stabilizes (but also with the "huge limit if I started with a big enough size).

Another minor problem occurs if I use textures for the squares : when I switch from normal chess to the variant, there are some squares ok and some with flat colors. The textures become all ok after a resize (while moving the window for example :P).

[H.G.Muller]

I noticed the latter too. I guess I will have to dive into Allessandro's code to see how this can be fixed. For now, the work-around is to start up in the variant you want, using the command-line option.

What OS are you using? On my XP, dragging the Window by its title bar does not lead to rescaling it. (Dragging the lower right corner does.) Does anyone know if this can be a Windows option that can be switched on or off, that it automatically rescales the window on dragging the title bar, like it was pulled in the lower-right corner to screen-filling size?

[Mathieu]

I'm using XP.

For the lower-right corner, I don't think it's a bug. It's the usual way to resize a windows, and I then think it was intended (I always obtain that way the biggest predifined size that fits inside the new rectangle I designed).

The size-up bug I experience occurs only if I switch from normal to a variant with a different board size (noticed with shogi and xiangqi, and just tried with capablanca -> same bug), absolutely no problem when moving the windows with a 8x8 board.

EDIT : Just trying the command line.
on start up, I checked "additional options" and wrote /variant xiangqi. Is that way you meant with using command line? If yes, not a solution for me : it opens a xiangqi board, but I still have the size-up bug when dragging the title bar...
I must be missing something... I'll post if I find.

[H.G.Muller]

The command-line option was only supposed to help against the incomplete coloring of the board with a choen texture.

I was indeed able to evoke the same effect here: If I elect xiangqi with boardSize small, and move the window, it changes the size to mediocre. That should enable me to find out what causes it. I will give it a look.

[H.G.Muller]

OK, I found out what the problem is. After moving (with the title bar) or sizing (lower corner) it is intentional that WinBoard goes through the sizing code again. But after moving, this should stay without effect, as the window size did not change. So it picks the size that was already in force.

Problem, however, it that to judge what fits, it takes the sizes from a able, that was made at startup, when the variant was normal and the board 8x8. So in xiangqi it has a big window after moving, and when it consults the sizes table, it discovers that an 8x8 board of a larger board size fits the current window. And then it switches to that size. Only to discover when it actuall displays the board, that it requires a larger window, of course.

In the current alpha.tst I have fixed it such now that the rescaling function does not on the board sizes left in a table (that might be leftovers from the wrong variant), but explicitly recompute all the sizes until one fits. Unfortunately, this has a visible side effect: after moving, it now takes ~0.5 sec while you see the board shrinking from maximum size to what it was before. But at least it ens at the correct size now.

[Mathieu]

Wow! Impressed by how quick you've been able to find where came the bug.
I confirm that starting with command line causes no texture problem.