DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2364 Version: 2.0-current See also 2361 and download the version that makes it possible to do this kind of debugging work. Ladies and gentlemen. Could it be time for the champaign? Let me start by saying that for all it's reputation for cleverness polymorphism has a HUGE down side. Future docs modification suggested below. ----------------- In fltk_theme.cxx Themes were such a mess... and I'm not sure what to do about the docs except this, for now. Starting at around line 5 note the following editorials. --------------------------------------------------------------------- /*! \fn bool fltk_theme(); [NOTE: This never worked. There were several definitions of fltk_theme and they all were dead, ultimately returning a hard-coded flag that couldn't be changed. See another note on this below. -rs] This is the default value of fltk::theme(). This is declared as a "C" function to allow it to be replaced with a function from a loaded plugin. If you are statically linking fltk you can also override this by declaring a fltk_theme() function in your own code (some Unix systems, but not Linux, will do this even if fltk is a shared library). [NOTE: This has been changed. Now the c++ version is 'fltk::fltk_theme()' and is a jump pointer variable and the extern "C" fltk_theme is only a name used to load the plugin main function address. Syntactically and functionally this should be identical to previous plans about how themes might work with the main difference being that it works because jump pointer variables are how extern "C" handles overrides anyway. --------------------------------------------------------------------- This was a fairly simple yet pretty involved modification due to more mixed up names than you can imagine. In any case, by the time we sorted out the C++ and extern "C" names, it all started working. But this polymorphism stuff can really be a pain in the NECK when it's used, apparently for no real reason other than to show that C++ (not the programmers, mind you, just the programming language) can handle untangling the Gordion effortlessly. Anyway, this themes mess has spun me out for almost a month. And it might not be over YET!! I'll upload the mod for the hacker's version as soon as I'm sure this really won't break existing code, at least for x11, the Windows fixups if any are required, will have to be done by someone that likes Windows. Let me reiterate the most recent problem I encountered in themes: Unnecessary polymorphism. The name of a plugin function was also the name of an internal function. Think about it. How bad is it when you even try objdump (137 files, just in the src dir) to figure out why the compiler thinks there are multiple definitions of "fltk_theme"? So wish me luck. Could this crazy polymorphism puzzle really be solved? ;-) PS. Of the two, the name most easily changed is the name of the pointer variable. But that's apparently why it could never work. "theme_" was the name of the old variable but it could never execute because of the other TWO "fltk_theme()" functions. Anyway, you get my point, I'm sure. I may in fact change the name of that variable anyway, now that there's just one. And if that breaks anyone's themes, well, that's one of you that had working themes until polymorphism was removed from that particular part of fltk functionality. (Why in the world.... one was local and the other lived in a plugin! What a debugging nightmare.) . Link: http://www.fltk.org/str.php?L2364 Version: 2.0-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
