DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2388 Version: 2.0-current Righto, this was an absolute _bitch_ to fix. So I think the problem started inside the docs. More specifically, when I read the documentation about SharedImage::get(), "The get() function can determine the type of the file or block of data and create the correct subclass." suggested, to me, that get() can also load jpeg/png/other image types. Oh boy, was that a bad assumption to make. Given that png, jpeg and zlib are all built into FLTK2.0 (and probably 1.x, but I don't use 1.x), I figured that these really should also be supported inside SharedImage's get(). SharedImage also has the guess_image() function, so I decided to incorporate guess_image() into get() just to save a bit of work. I very quickly found out why nobody had bothered to do this before. Whoever set up the original libfltk2 and libfltk2_images perhaps wasn't catering for this issue, but this forced a massive circular-linking-dependency issue. To the point where just adding if (!img){ ImageType *type = guess_image((const char*)n, (const uchar*)0); img = type->get((const char*)n, (const uchar*)0); } would render the majority of the programs inside the test/ directory useless, unless they had -lfltk2_images -lfltk2 -lfltk2_images -lfltk2. Whilst this is probably one valid fix for the problem, I decided that having to link in each library twice was rather stupid, and so set about fixing more things. Eventually, after bashing my head into the desk, the solution was moving SharedImage (and all the other *Image classes that resemble image creation classes) into fltk2_images. Once I had that working, things were so much simpler. ....Until I forgot the "svn revert && svn add" required to create the proper patchfile. And promptly lost everything. Not to mention the countless crashes I encountered. The attached patch fixes the stupid circular dependency issues (if you can be bothered, objdump -xC shows what's wrong; items in libfltk2_images depend on items in libfltk2 which, in turn, depend on items in libfltk2_images (especially with the above few lines of code tacked in). It also fixes the first half of STR #2296 (I could force memcpy to overlap, but not an invalid read), further streamlines get() by turning the bmp and gif checks into the actual test() functions from bmpImage and gifImage. It then fixes up a few issues that can force segfaults (often, size checking wasn't done correctly, so for a file that was too small boundaries could be run over, and at one point someone forgot to bracket a ternary which lead to unintended behaviour), and streamlines all of the test() functions. It should also fix up STR #2033 by adding a simple #ifdef to check for a windows absolute-path (or at least, what's left of STR #2033. It seemed that things were working like they should anyway, but this looked like a silly oversight). Whilst I'm aware fltk tries to link against already-built versions of libjpeg and libpng, I also changed the deprecation problems (STR #2363) with libpng, on the odd chance that someone _doesn't_ have these libraries. Finally, I dug up a somewhat strange bug (http://dl.dropbox.com/u/4316675/fltk.png) when setting an image to a widget box(). The above patch should fix that. .....I can't remember how I fixed that one though..... Whilst I perhaps don't expect that this patch will be applied (I'm assuming there's a reason SharedImage, bmpImage, gifImage, and x(p|b)mImage were stuck into fltk2 _other_ than the fact that things initially felt nicer that way) given the dormancy that is fltk2 (I can swear there are cobwebs in some parts of the code), I'll leave this patch here anyway. I certainly wouldn't be complaining if it made its way into the svn though. I'll have to have a look, but I'm not certain the test/ programs compile with shared libraries. They probably all need to be re-linked against either LINKSHARED (perhaps a conditional or two will help fix this). I'd do it myself, but I'm not much of a librarian :) I'll see if I can't slowly work my way through some more of the STRs. It won't be active development so much as _inactive_, but it can't hurt to knock some of these (rather old) STRs over. Link: http://www.fltk.org/str.php?L2388 Version: 2.0-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
