Any GTK programmers out there?

[hgm]

I am trying to port XBoard from Xt/Xaw to the GTK+ widget set (see other thread). But I have zero experience with GTK, and have some problems getting decent behavior when the user resizes the dialogs.

The code I started with (which was not mine) used a table widget to put all the control widgets in, so you would have nice alignment: the option's name goes into the first column as a label, then follows a text entry in the second, and finally a browse button in the third. If there is no browse button, the text edit (or spin) occupies both 2nd and 3rd column; if there also is no name, it extends over all 3 columns.

So far so good, and the results are really nice. Until you start to vertically resize the window. Then everything gets proportionally taller. Now there are many dialogs in XBoard that consist of a big text edit or listbox, with just one or two rows of buttons or labels below or above it. (E.g. the Engine Output window, the Game List.) In general the user would want to resize those over a very large range, and all vertical size change should go into the large textview or listbox. But in stead it makes the labels or buttons next to it ridiculously high as well if you originally created the window with a small height, and if you created them with a large height (using gtk_widget_set_size_request) it completely prevents you from sizing it smaller.

What would be the recommended way in GTK to solve this problem? All my attempts to fix the height of a widget or table row have come up with nothing, and I am at a complete loss. I found you can do this with hbox and vbox widges, but if I make every row a hbox and pack them inside a vbox, I don't know any method to align the contents of different hboxes with each other.

Any help is welcome!

[Michel]

It's been a long time since I have done any gtk programming so I do not know the precise answer but is seems to me that if you want _both_ horizontal
and vertical alignment (such precise control is often not necessary) you should use a table. See e.g.

http://zetcode.com/tutorials/gtktutoria ... anagement/

Here is something about tables (for pyGTK but that is the same)

http://www.pygtk.org/pygtk2tutorial/sec ... ables.html

[hgm]

OK, thanks! The Python link helped. At least I could get it such that when I have label (option name) + text-edit + browse button on one line, and the user increases the width, the label and browse button keep the same width, and only the text-edit expands.

I was already using a table, but what was wrong is that the GTK_EXPAND property is by default set on any table cell. So if I want one row to take up all size change, I must clear it on all OTHER rows. Only playing with the settings of the row itself, as I was doing, has virtually no effect.

[hgm]

Oh man, this is awful! The alignment table in general has 3 rows: label + text-edit + browse-button. But if the option is not a file or path name, there is o browse button, and the text-edit (or spin, or combobox) spans column 2 and 3.

It turns out now that if none of the options has a browse button, GTK gets confused, and no longer pays attention to the fact that I did not set GTK_EXPAND for any of the labels in column 1. So it divides the extra horizontal size between label and text-edit anyway.

I really have to scan the list of options in advance, to see if there are browse buttons, and decide if I need to allocate a table with 2 or 3 colums. (And adapt the rest of the code to the actual number of columns). Hideous!

[hgm]

I still have some trouble with GTK formatting. The generic dialog constructor usese gtk_dialog_new_with_buttons to create the window, and then puts a gtk_table in the 'content area' (a vbox). The various other elements then go into this table. For the main window this leads to:



As you can see, there is extra unused space beneath the last element packed in the table, the gtk_drawing_area for the board. I set a size_request for that widget equal to the board height. But it allocates more. (This is allocated in the table row; when I put more elements in the dialog, which end up in the same table, it leaves a similar gap between them and the bottom of the board.)

The extra space is 'compressible': I can vertically resize the window until the frame touches the originally requested drawng_area. (The current code reacts to that by drawing the board even smaller, because it is based on keeping the width of the surrounding 'window frame' constant.) Like this:



why does GTK randomly put extra space in the dialog? Is this a known GTK bug?

[JuLieN]

why does GTK randomly put extra space in the dialog? Is this a known GTK bug?

GTK is so old (I remember reading some tutorials in 1998/99 IIRC), that it's probably not a bug, H.G. IMHO you must be doing something wrong. Sorry I can't help you: my knowledge of GTK is in the same state as it was in 1998 ^^

[hgm]

It is hard for me to believe this is an error of mine. I now do the most simple thing possible: pack the drawing-area widget into a frame, so you can see a border around it. It is my understanding that in this case the frame should cling to the edges of the drawing-area like a rubber band.

But in the screen shot it clearly shows it leaves extra space at the bottom, like the graph widget has a margin there. This extra space can be squeezed out, though, when I start down sizing the height of the window, until the frame and window touch. (After that it resists further downsizing). Drawing-area widgets seem the only widgets that suffer from this.

[hgm]

Well, I do have a version now that seems to work reasonably well (for me). Source code at the latest snapshot at:

http://hgm.nubati.net/cgi-bin/gitweb.cg ... heads/gtk2

But the only way to get it to work is by subtracting 25 pixels from the total height of the window that it gets on automatic sizing, assuming that this is the size of the unjustly allocated space. As I have no idea why that space is allocated, this might not work at all on other systems...

[Evert]

Not a direct help, but a quick google turned up http://stackoverflow.com/questions/2269 ... gtk-widget. This is for Haskell, and the eventual answer isn't all that clear to me, but perhaps it gives some relevant keywords for further search.[/url]

[Michel]

It seems you use gtk_widget_set_allocation for the drawing_area. The documentation
says you cannot call this method directly.

Code: Select all

gtk_widget_set_allocation ()

void                gtk_widget_set_allocation           (GtkWidget *widget,
                                                         const GtkAllocation *allocation);

Sets the widget's allocation. This should not be used directly, but from within a widget's size_allocate method. 

It was not clear if you were actually doing this. I generated a coredump and it seemed to me you were indeed calling it directly.