Compilation with debugging symbols is usually OFF by default. If you would like to change that, then just add the -g option inside of the CFLAGS variable in the main ``Makefile''. Different versions differ in policy about that. Along with debugging, there is an option in the help menu, under debugging, that is for you to be able to dump core if you want to. That's something I've used on and off, and it can be useful, so it was added in. I'm trying to force people to use that if they want a corefile, since hopefully it's set up so you can't get it to dump core any other way. :)
If you would like to compile with all debugging enabled, make sure that the symbol ``PROD'' is not defined in the Makefile, and recompile with ``make static''. (Note: Before you can ``make static'', you have to run ``make obscure'' which copies your static libraries into the foo/ directory, where it will link against them. If your static libraries are in different places, you'll need to copy them into that location.) With ``make static'', GTKeyboard will compile with static libraries, with calls like g_mem_profile() compiled in. (You did compile your glib/GTK+ with memory profiling, didn't you?) It will also print the result of various memory macros that are located in the include/ directory in mem_header.h. This causes quite verbose output, but in the end you get a total of how much memory has been allocated/freed by GTKeyboard. The g_mem_profile() call of course includes statistics on memory allocated by GTK+ as well.
Note that in the file include/memheader.h there are
several macros for tracking memory usage which won't really expanded
to much if debugging is not on, but if it is, sometimes to multiple
statements. Particularly the glib calls that end with an
underscore. Because they are multiexpression macros, you really don't
want to do something like:
if(mem)
g_free_(mem);
But rather do this:
if(mem)
{
g_free_(mem);
}
To account for the fact that it may or may not be a single replacement
line macro.
Also of interest to developers are the files INTERNALS and gtkeyboard-arch.txt located in the main directory of the source tree. They explain parts of the way the source works, to facilitate others in hacking on GTKeyboard. At the moment, that documentation isn't really all that great, but at least it's there, and it's something. If you would like to see any more specific information in that document, please write the section and submit it to s2mdalle@titan.vcu.edu for inclusion in the next version or let me know and I'll do the write up myself when time becomes available.