Any GTK programmers out there?

[hgm]

Well, I tried several methods, and the latest version does not make any attempt to set the size of the widget. I do use gtk_widget_get_allocation to read out the size, though.

But when I was using gtk_widget_set_allocation, it worked fine. That is, the widget would respond visually, and the get_allocation would read back the same size as I set. The problem is not in the size of the widget. The problem is that the surrounding widget allocates more size than is needed to contain the inner widget. No matter what method was used to define the size of that inner widget (using gtk_widget_set_size_request or gtk_widget_set_allocation, or just leaving it to the autosizing of GTK itself).

It behaves like the widget has specified a margin beyond its own size. But as far as I could check, in the version of GTK I am using, margins are not a property of drawing-area widgets. And in any case, that margin is 'soft': it can be compressed out by sizing the window by hand. This is also not what I would expect for a margin that was requested on purpose.

[Michel]

Well, I tried several methods, and the latest version does not make any attempt to set the size of the widget.

Yes I see the set_allocation call is between if(0){...}. I had not noticed that.

[hgm]

Main thing that is still missing in the current version is key bindings. Is there an 'external' system for key bindings in GTK like the .Xrecoures method that existed for X11, where the user can define his own bindings? If so, I must submit my own bindings as requests to that handler, in order not to break it. If not, I could simply handle it in the key-press-event handler that I already have for popping up the move type-in, by searching the menu tables for occurrence of that key as accellerator in any of the item texts.

[Michel]

There is still an invalid read. This is what valgrind reports

Code: Select all

==14223== Invalid read of size 8
==14223==    at 0x3CC3A8891A: __GI___strncasecmp_l (in /lib64/libc-2.12.so)
==14223==    by 0x3CC3A3B5EF: ____strtod_l_internal (in /lib64/libc-2.12.so)
==14223==    by 0x3CC5259FC0: g_ascii_strtod (in /lib64/libglib-2.0.so.0.2200.5)
==14223==    by 0x3F3CA0A636: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==14223==    by 0x3F3CA21AA7: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==14223==    by 0x3F3CA2200F: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==14223==    by 0x3F3CA22775: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==14223==    by 0x3F3CA27CA0: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==14223==    by 0x3F3CA2863A: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==14223==    by 0x3F39A4679A: xmlParseStartTag (in /usr/lib64/libxml2.so.2.7.6)
==14223==    by 0x3F39A4C8BE: ??? (in /usr/lib64/libxml2.so.2.7.6)
==14223==    by 0x3F39A4D5FE: xmlParseChunk (in /usr/lib64/libxml2.so.2.7.6)
==14223==  Address 0xcc30ef0 is 16 bytes inside a block of size 22 alloc'd
==14223==    at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==14223==    by 0x3CC52417D2: g_malloc (in /lib64/libglib-2.0.so.0.2200.5)
==14223==    by 0x3F3CA21FE4: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==14223==    by 0x3F3CA22775: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==14223==    by 0x3F3CA27CA0: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==14223==    by 0x3F3CA2863A: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==14223==    by 0x3F39A4679A: xmlParseStartTag (in /usr/lib64/libxml2.so.2.7.6)
==14223==    by 0x3F39A4C8BE: ??? (in /usr/lib64/libxml2.so.2.7.6)
==14223==    by 0x3F39A4D5FE: xmlParseChunk (in /usr/lib64/libxml2.so.2.7.6)
==14223==    by 0x3F3CA269C1: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==14223==    by 0x3F3CA0EC3C: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==14223==    by 0x3F3CA0ECF0: rsvg_handle_new_from_file (in /usr/lib64/librsvg-2.so.2.26.0)
==14223== 

On Linux it does not seem to cause a crash.

[Michel]

Actually, running valgrind with the recommended command line for gtk debugging

G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=20 --log-file=vgdump ./xboard -fcp gnuchess

makes the "invalid read" go away.

[Michel]

Actually the invalid read did not go away but was dumped into a logfile. Here is a much more extensive stack trace. Hopefully this will make it possible to fix it.

EDIT: The file that causes this seems to be

/usr/local/share/games/xboard/themes/default/WhiteLance.svg

EDIT2: Other tools can't find anything wrong with this file... So perhaps it is a red herring.

Code: Select all

==24013== Invalid read of size 8
==24013==    at 0x3CC3A8891A: __GI___strncasecmp_l (in /lib64/libc-2.12.so)
==24013==    by 0x3CC3A3B5EF: ____strtod_l_internal (in /lib64/libc-2.12.so)
==24013==    by 0x3CC5259FC0: g_ascii_strtod (in /lib64/libglib-2.0.so.0.2200.5)
==24013==    by 0x3F3CA0A636: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==24013==    by 0x3F3CA21AA7: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==24013==    by 0x3F3CA2200F: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==24013==    by 0x3F3CA22775: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==24013==    by 0x3F3CA27CA0: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==24013==    by 0x3F3CA2863A: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==24013==    by 0x3F39A4679A: xmlParseStartTag (in /usr/lib64/libxml2.so.2.7.6)
==24013==    by 0x3F39A4C8BE: ??? (in /usr/lib64/libxml2.so.2.7.6)
==24013==    by 0x3F39A4D5FE: xmlParseChunk (in /usr/lib64/libxml2.so.2.7.6)
==24013==    by 0x3F3CA269C1: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==24013==    by 0x3F3CA0EC3C: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==24013==    by 0x3F3CA0ECF0: rsvg_handle_new_from_file (in /usr/lib64/librsvg-2.so.2.26.0)
==24013==    by 0x464DAD: LoadSVG (draw.c:252)
==24013==    by 0x46513B: ScaleOnePiece (draw.c:294)
==24013==    by 0x465615: CreatePNGPieces (draw.c:344)
==24013==    by 0x465652: CreateAnyPieces (draw.c:353)
==24013==    by 0x476A45: main (xboard.c:1075)
==24013==  Address 0xcdecec0 is 16 bytes inside a block of size 22 alloc'd
==24013==    at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==24013==    by 0x3CC52417D2: g_malloc (in /lib64/libglib-2.0.so.0.2200.5)
==24013==    by 0x3F3CA21FE4: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==24013==    by 0x3F3CA22775: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==24013==    by 0x3F3CA27CA0: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==24013==    by 0x3F3CA2863A: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==24013==    by 0x3F39A4679A: xmlParseStartTag (in /usr/lib64/libxml2.so.2.7.6)
==24013==    by 0x3F39A4C8BE: ??? (in /usr/lib64/libxml2.so.2.7.6)
==24013==    by 0x3F39A4D5FE: xmlParseChunk (in /usr/lib64/libxml2.so.2.7.6)
==24013==    by 0x3F3CA269C1: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==24013==    by 0x3F3CA0EC3C: ??? (in /usr/lib64/librsvg-2.so.2.26.0)
==24013==    by 0x3F3CA0ECF0: rsvg_handle_new_from_file (in /usr/lib64/librsvg-2.so.2.26.0)
==24013==    by 0x464DAD: LoadSVG (draw.c:252)
==24013==    by 0x46513B: ScaleOnePiece (draw.c:294)
==24013==    by 0x465615: CreatePNGPieces (draw.c:344)
==24013==    by 0x465652: CreateAnyPieces (draw.c:353)
==24013==    by 0x476A45: main (xboard.c:1075)
==24013

[Michel]

Nonetheless it is WhiteLance.svg which trips up libsrvg since I got the same invalid read when I replaced WhitePawn.svg with WhiteLance.svg. I think to continue it is best to use a debug build of librsvg.

[hgm]

Thanks for figuring this out. I think I will leave it to Arun to fix this, however (he was responsible for all the SVG stuff), and will communicate this to him. He is on a business trip now, however.

I made a news/progress page for the GTK version at http://hgm.nubati.net/gtk . It contains screen shots of all dialogs XBoard has, as the are currently generated.