|
After a hair raising tour of the themes, I decided to get my feet wet
in the test/ demos. :-) These are now my second impressions. src/fltk_theme.cxx Around line 37... Notice that fltk_theme IS defined below. #if USEX11 extern "C" bool fltk_theme() {return false; /* true? */} /* Maybe _WIN32 should use the Windows version anyway? It would work! */ # include "x11/fltk_theme.cxx" #elif defined(_WIN32) ... And x11/fltk_theme.cxx (as it turns out) redefines fltk_theme() at around line 322 Since we are using X11 and only those who are will enter this logic branch, Remove this around line 37 of src/fltk_them.cxx //extern "C" bool fltk_theme() {return false; /* true? */} No guarantee that the file will work after this, but at least it will compile. ----------------- In x.h the following logic is VERY counterintuitive. When is USE_X11 defined? This notice that USE_X11 is not simply defined, it's a value. One would assume that this file will cause errors unless it loads itself recursively.... or something. Should this be checking "! defined(USE_X11)" instead of simply "!USE_X11"? #ifndef fltk_x_h # define fltk_x_h # if defined(_WIN32) && !USE_X11 # include "win32.h" # elif defined(__APPLE__) && !USE_X11 # include "osx.h" # else # define USE_X11 1 # include "x11.h" # endif #endif ----------------- There are apparently two jpeg_image demos in the test folder. I removed fl_jpeg_image.cxx test for now. It needs compat/FL stuff and recurses terribly either before or after I messed with it. But unless or until the compat stuff is bullet proof this one is a mess. ----------------- dnd needs a more conclusive demo to show that it's not simply copy/pasting to/from the (main) clipboard which should not be at all involved in DND. ----------------- Re. test/exception. We Linux folks CAN do structured error handling, by the way. It involves reading a struct that is cleverly hidden in the mess of junk above a signal callback in order to extract the pointers to the cpu registers that are apparently pushed during a setjmp() longjmp(). (Assuming intel cpu type...) By modifying the eip (or xip, for 64 bitters), you can control where the program resumes -- probably to a normal try - catch block. (Other cpu's? You're on your own.) I have done this (very reliably) on a 32-bit system, but have not tested it on 64. For those not aware of what possibilities this opens up, I should say that probably the most common usage would be for for testing whether memory is ours or not, and for checking if a memory location is write-protected. for example.. char* memlocation = (char*)test_address; testid = TEST_READ; char a = *memlocation; // will dump if it's not ours. Could be a null ptr, etc. testid = TEST_WRITE; *memlocation = a; // will dump if it's write protected This method of exception handling (fully taking over handling of low-level exceptions) is not simply a try - catch or assert function. It fully handles serious errors the way glib handles double-free, etc., but allows us to continue IF we know what caused the error. (So these are inserted and removed after one-time use.) My tkf Forths, console version, and QT4 version use it. Hopefully these are the right links, if you want to get ahead of me on this. http://rainbowsally.net/tkf/tkf-02.52-installer.tar.gz // see tkf.f file and find 'except' or even 'obj' might take you there. http://rainbowsally.net/tkf/tester/09-07-17/tkf-qt4-test.tar.gz // I forget where I hid it in this one but I think it's part of the array of // signals we intercept. I'd grep 'SIG' and see what shows up. No apologies for the amaturish C/C++ code. I wasn't interested in a professional looking C application. I am not accustomed to the interpreter not being part of the compiler in these systems. I like it, but it still seems ODD! :-) Some assembly required, but not much. But this is not for strictly high-level coders or for newbies. It's the real thing and can hang very badly if you don't understand what it's about or enjoy living dangerously.  More later... |
_______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
