I am dumping them rawer and rawer on you guys!
I am now experimenting with replacing the Xt/Xaw widget set by GTK in the latest version of XBoard. This has now reached a stage were I have something that is vaguely working:
The layout and formatting of many dialogs (including the main board) is still completely wrong; this is being worked on. But is should be operational inmost other senses.
If there are people that want to help testing it: the sources are in my on-line repository, the gtk2 branch: http://hgm.nubati.net/cgi-bin/gitweb.cg ... heads/gtk2 . Just load the latest snapshot.
XBoard (GtkBoard?) pre-alpha
Moderators: hgm, Rebel, chrisw
-
- Posts: 27809
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: XBoard (GtkBoard?) pre-alpha
raw indeed I just compiled it on my mac but when I try to execute i get a segmentation fault 11. I did receive a bunch of warnings during the make process that might have something to do with it. I know this all is still very pre-alpha. Would you still want to see them?
-
- Posts: 3232
- Joined: Mon May 31, 2010 1:29 pm
- Full name: lucasart
Re: XBoard (GtkBoard?) pre-alpha
Woaw, that's starting to look really nice. If you code in C, GTK is really the way to go, and using X-window API directly is a penance.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
-
- Posts: 27809
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: XBoard (GtkBoard?) pre-alpha
Yes, please! It should never segfault. It is just that some click or key signals will still be ignored. What I did is removing all old Xt/Xaw code (turning it into comment, so I would still see what it was supposed to do), so that all routines containing such code either turned into no-ops or where removed completely. Then I went on by putting in the corresponding GTK replacement code step by step. As a source for this I had the gtk-xt branch on which Arun Persaud ad John Cheetham have been working. This could supply about 60% of what I needed. The remaining part is code for new things that were added to XBoard since the version they had been porting.JoshPettus wrote:raw indeed I just compiled it on my mac but when I try to execute i get a segmentation fault 11. I did receive a bunch of warnings during the make process that might have something to do with it. I know this all is still very pre-alpha. Would you still want to see them?
It is normal that you ill get a bunch of warnings during building. Mostly about unused variable, as taking out Xt/Xaw code sections caused many of the variables to not be used, or many routines not be called.
-
- Posts: 27809
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: XBoard (GtkBoard?) pre-alpha
Well, the code is not significantly simpler than the old Xt/Xaw code. It is true that some things that had to be explicitly programmed in Xt/Xaw (like giving keyboard focus to a clicked widget, letting the mouse wheel operate scrolling etc.) are automatic in GTK, so that the associated code can simply be eliminated. But OTOH some things are very cumbersome in GTK, like handling a simple listbox, because you have to use a very complex treeview widget, and have to deal with view models, selections, columns, iters etc.lucasart wrote:Woaw, that's starting to look really nice. If you code in C, GTK is really the way to go, and using X-window API directly is a penance.
The main problem I had with Xt/Xaw was poor documentation, and the fact that things sometimes did not work as advertized. (But it seems this was at least partly due to a MetaCity window manager bug, which you then had to improvise workarounds for.) There are virtually no tutorials around for it. But eventually I learned how to do everything that was needed. GTK has much better documentation, but I am still starting with zero knowledge, which makes it far tougher for me to do things in GTK than in Xt/Xaw.
So from the viewpoint of coding, this operation isn't really worth it. The only incentive for doing this is the cosmetic improvement of the widgets.
-
- Posts: 2272
- Joined: Mon Sep 29, 2008 1:50 am
Re: XBoard (GtkBoard?) pre-alpha
Segfaults for me too. Here are some backtraces
#0 0x0000003ccf216a8b in cairo_image_surface_get_width ()
from /usr/lib64/libcairo.so.2
#1 0x0000000000466c0d in ScaleOnePiece (color=0, piece=0) at draw.c:302
#2 0x0000000000466f71 in CreatePNGPieces () at draw.c:340
#3 0x0000000000466fa1 in CreateAnyPieces () at draw.c:348
#4 0x0000000000463e3f in main (argc=1, argv=0x7fffffffe228) at xboard.c:1358
==21015== Memcheck, a memory error detector
==21015== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==21015== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==21015== Command: ./xboard
==21015==
Unrecognized argument -pixmapDirectory in settings file
Unrecognized argument -bitmapDirectory in settings file
Unrecognized argument -pixmapDirectory in settings file
Unrecognized argument -bitmapDirectory in settings file
GenericPopUp: unexpected case in switch. i=25 type=9 name=menuW.
GenericPopUp: unexpected case in switch. i=26 type=9 name=menuB.
GenericPopUp: unexpected case in switch. i=27 type=9 name=menuD.
==21015== Invalid read of size 8
==21015== at 0x3CCF216A8B: cairo_image_surface_get_width (in /usr/lib64/libcairo.so.2.10800.8)
==21015== by 0x466C0C: ScaleOnePiece (draw.c:302)
==21015== by 0x466F70: CreatePNGPieces (draw.c:340)
==21015== by 0x466FA0: CreateAnyPieces (draw.c:348)
==21015== by 0x463E3E: main (xboard.c:1358)
==21015== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==21015==
==21015==
==21015== Process terminating with default action of signal 11 (SIGSEGV)
==21015== Access not within mapped region at address 0x0
==21015== at 0x3CCF216A8B: cairo_image_surface_get_width (in /usr/lib64/libcairo.so.2.10800.8)
==21015== by 0x466C0C: ScaleOnePiece (draw.c:302)
==21015== by 0x466F70: CreatePNGPieces (draw.c:340)
==21015== by 0x466FA0: CreateAnyPieces (draw.c:348)
==21015== by 0x463E3E: main (xboard.c:1358)
==21015== If you believe this happened as a result of a stack
==21015== overflow in your program's main thread (unlikely but
==21015== possible), you can try to increase the size of the
==21015== main thread stack using the --main-stacksize= flag.
==21015== The main thread stack size used in this run was 10485760.
==21015==
==21015== HEAP SUMMARY:
==21015== in use at exit: 1,497,455 bytes in 8,525 blocks
==21015== total heap usage: 20,919 allocs, 12,394 frees, 4,254,820 bytes allocated
==21015==
==21015== LEAK SUMMARY:
==21015== definitely lost: 4,877 bytes in 33 blocks
==21015== indirectly lost: 12,096 bytes in 376 blocks
==21015== possibly lost: 306,997 bytes in 1,624 blocks
==21015== still reachable: 1,173,485 bytes in 6,492 blocks
==21015== suppressed: 0 bytes in 0 blocks
==21015== Rerun with --leak-check=full to see details of leaked memory
==21015==
==21015== For counts of detected and suppressed errors, rerun with: -v
==21015== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 8 from 8)
Segmentation fault (core dumped)
-
- Posts: 27809
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: XBoard (GtkBoard?) pre-alpha
It seems you have a problem with reading the piece-image files (not GTK related). Are you sure the svg piece files are properly installed? (e.g. in /usr/local/share/games/xboard/themes/default/*.svg)
The code where this happens is
It seems 'img' is a NULL pointer here, which seems only possible if LoadSVG returned a NULL pointer
The code where this happens is
Code: Select all
if(!svgPieces[color][piece]) { // try to freshly render cached svg pieces first, to supply the source bitmap
svgPieces[color][piece] = LoadSVG("", color, piece); // this fills pngPieceImages if we had cached svg with bitmap of wanted size
}
if(!pngPieceImages[color][piece]) { // we don't have cached bitmap (implying we did not have cached svg)
if(*appData.pieceDirectory) { // user specified piece directory
snprintf(buf, MSG_SIZ, "%s/%s%s.png", appData.pieceDirectory, color ? "Black" : "White", pngPieceNames[piece]);
pngPieceImages[color][piece] = img = cairo_image_surface_create_from_png (buf); // try if there are png pieces there
if(cairo_surface_status(img) != CAIRO_STATUS_SUCCESS) { // there were not
svgPieces[color][piece] = LoadSVG(appData.pieceDirectory, color, piece); // so try if he has svg there
}
}
}
if(!pngPieceImages[color][piece]) { // we still did not manage to acquire a piece bitmap
if(!(svgPieces[color][piece] = LoadSVG(SVGDIR, color, piece))) // try to fall back on installed svg
DisplayError(_("No default pieces installed\nSelect your own -pieceImageDirectory"), 0); // give up
}
img = pngPieceImages[color][piece];
// create new bitmap to hold scaled piece image (and remove any old)
if(pngPieceBitmaps2[color][piece]) cairo_surface_destroy (pngPieceBitmaps2[color][piece]);
pngPieceBitmaps2[color][piece] = cs = cairo_image_surface_create (CAIRO_FORMAT_ARGB32, squareSize, squareSize);
if(piece <= WhiteKing) pngPieceBitmaps[color][piece] = cs;
// scaled copying of the raw png image
cr = cairo_create(cs);
w = cairo_image_surface_get_width (img); // <------------------------------ Line 302
h = cairo_image_surface_get_height (img);
cairo_scale(cr, squareSize/w, squareSize/h);
cairo_set_source_surface (cr, img, 0, 0);
cairo_paint (cr);
cairo_destroy (cr);
Code: Select all
RsvgHandle *
LoadSVG (char *dir, int color, int piece)
{
char buf[MSG_SIZ];
RsvgHandle *svg=svgPieces[color][piece];
RsvgDimensionData svg_dimensions;
GError **svgerror=NULL;
cairo_surface_t *img;
cairo_t *cr;
snprintf(buf, MSG_SIZ, "%s/%s%s.svg", dir, color ? "Black" : "White", pngPieceNames[piece]);
if(svg || *dir && (svg = rsvg_handle_new_from_file(buf,svgerror))) {
rsvg_handle_get_dimensions(svg, &svg_dimensions);
img = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, squareSize, squareSize);
cr = cairo_create(img);
cairo_scale(cr, squareSize/(double) svg_dimensions.width, squareSize/(double) svg_dimensions.height);
rsvg_handle_render_cairo(svg, cr);
if(cairo_surface_status(img) == CAIRO_STATUS_SUCCESS) {
if(pngPieceImages[color][piece]) cairo_surface_destroy(pngPieceImages[color][piece]);
pngPieceImages[color][piece] = img;
}
cairo_destroy(cr);
return svg;
}
return NULL;
}
-
- Posts: 2949
- Joined: Mon May 05, 2008 12:16 pm
- Location: Bordeaux (France)
- Full name: Julien Marcel
Re: XBoard (GtkBoard?) pre-alpha
Wow, now that looks much better, fresher, H.G.! Keep up the good work!
Last edited by JuLieN on Fri Oct 19, 2012 11:46 am, edited 1 time in total.
"The only good bug is a dead bug." (Don Dailey)
[Blog: http://tinyurl.com/predateur ] [Facebook: http://tinyurl.com/fbpredateur ] [MacEngines: http://tinyurl.com/macengines ]
[Blog: http://tinyurl.com/predateur ] [Facebook: http://tinyurl.com/fbpredateur ] [MacEngines: http://tinyurl.com/macengines ]
-
- Posts: 2272
- Joined: Mon Sep 29, 2008 1:50 am
Re: XBoard (GtkBoard?) pre-alpha
It seems you have a problem with reading the piece-image files (not GTK related). Are you sure the svg piece files are properly installed? (e.g. in /usr/local/share/games/xboard/themes/default/*.svg)
You are right. I did not do make install (for the previous xboard versions this was not
necessary). After make install it did not segfault anymore.
I guess in the "production quality" version of this xboard will not segfault but print a nice error message
-
- Posts: 27809
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: XBoard (GtkBoard?) pre-alpha
I suppose it would. An alternative would be to have built-in svg images, so loading them can never fail. But Arun was against that.