michiguel wrote:The traditional build is fine. The GTK is the one with this problem.
I have Ubuntu 12.04 LTS.
I have Ubuntu 12.04 installed now on a virtual machine. I managed to build the XBoard GTK version, (finding out how to open a terminal is actually the most difficult part there), but I cannot reproduce the problem. For me it opens fine, without having to size it by hand, and the board fitting perfectly inside the window.
Can it be that it is a 32-bit / 64-bit issue? What architecture are you running?
michiguel wrote:The traditional build is fine. The GTK is the one with this problem.
I have Ubuntu 12.04 LTS.
I have Ubuntu 12.04 installed now on a virtual machine. I managed to build the XBoard GTK version, (finding out how to open a terminal is actually the most difficult part there), but I cannot reproduce the problem. For me it opens fine, without having to size it by hand, and the board fitting perfectly inside the window.
Can it be that it is a 32-bit / 64-bit issue? What architecture are you running?
It is 64 bits, AMD quad. I do not have Unity (I tossed that long time ago) and I kept the old gnome 3.
Hmm, that makes it very hard to reproduce for me. The good news is that perhaps also makes it hard to reproduce for anyone else. But of course that doesn't help you.
hgm wrote:Hmm, that makes it very hard to reproduce for me. The good news is that perhaps also makes it hard to reproduce for anyone else. But of course that doesn't help you.
I will have a hard think about what we can do.
I have a 64 bit Linux machine (Intel, but if that matters I'll eat my foot). However, I don't have Gnome and everything seems to work just fine for me under KDE.
If it doesn't take long to install gnome3 I may be able to give that a go to see if I can reproduce the problem.
/* Using gtk_window_resize by itself is wrong because it does not take
* into account the space occupied by other widgets in the window.
*
* Using gtk_widget_set_size_request by itself is also insufficient as it
* sets the *minimum* size. If the socket widget was already larger then
* it would do nothing.
*/
gtk_window_resize(GTK_WINDOW(d->gtk->gtkwindow), w, h);
gtk_widget_set_size_request(d->gtk->gtksocket, w, h);
From what I can tell, XBoard doesn't do anything similar, but I don't know enough about Gtk (or XBoard's code) to propose a direct fix, but hopefully this is something that can help someone who does know more about gtk and XBoard to work something out.
That is indeed interesting. It did not occur to me that the size_request could be removed again. So when I used size_request on the board widget to give it ste startup size, it displayed nicely, but it became impossible to shrink it. But window_resize seemed only to work on the top-level window, so I could not apply it to the board widget, but have to pull on the board widget by resizing the outer window, as it were. But to know how large I have to make that to achieve a certain board size, I have to know the margins.
The strategy here would force GTK to calculate the initial size of the outer window as to make the board fit. And then removing the size_request would allow the user to shrink the window again. I guess in the latter case I could calculate the maximum board that fits in the new window, set that as a size request to the board widget, then order a resize on the outer window for something small (like the board size itself) which will respect the board's size_request to give the smallest fit, and then remove the size_request again to become receptive for further shrinking of the window by the user.
The underlying problem is of course that I hardly know anything about GTK, so I am just meddling a bit until I have something that works for me.
hgm wrote:Miquel, could you try the GTK build of the latest commit in the hgm.nubati.net repository?
I applied the method Evert suggested, there.
Now I do not get and empty board at the beginning, I get the full board, but still clipped.
In a different computer (still with 12.04 LTS) I installed 4.8.0 and I seemed to work with xboard -ncp. I got the empty board, I resized it, and it looked fine. Then, I used a script to log on with Gaviota in winboard.nl and I went directly to see a board... but clipped. From that point on, whatever I do I see a clipped board. Is it possible that it is because I am sending a particular -size option? How do I reset the options? (where is the .xboardrc file that remembers all this?)
.xboardrc is in your home directory. But I would be surprised if this is dependent of the requested -size (unless, perhaps, this exceeds the screen size and triggers an automatic resize that introduces this problem).
Are you by any chance using logos? Is the clock displayed as one line or two? (I ask because it could be that the vertical expansion of the clock when it switches to two lines pushes the board partly out of view.)
hgm wrote:Well, at least we solved half the problem!
.xboardrc is in your home directory. But I would be surprised if this is dependent of the requested -size (unless, perhaps, this exceeds the screen size and triggers an automatic resize that introduces this problem).
Are you by any chance using logos? Is the clock displayed as one line or two? (I ask because it could be that the vertical expansion of the clock when it switches to two lines pushes the board partly out of view.)
No, I am not using logos.
I erased .xboardrc and executed xboard -ncp. I resized it and it looks fine. As soon as I move it, it automatically resizes it and clips it again.
The amount of clippling looks suspiciously similar to the size of the clocks or the buttons line.
