| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3131
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Image Support |
|---|
| Summary: | Preview of XBM-images in filechooser broken |
|---|
| Version: | 1.3-current |
|---|
| Created By: | chris |
|---|
| Assigned To: | manolo |
|---|
| Fix Version: | 1.3.4 (SVN: v10561) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
No files
Trouble Report Comments:
| |
| #1 | chris
05:10 Sep 09, 2014 |
| Test with pixmap_browser in test folder.
Enable preview and move to pixmap subdir.
None of the XBM images shows up in the preview, instead a big X is displayed.
An older version of FLTK 1.3.2 on the same machine corretly displays the images. | |
| |
| #2 | chris
09:25 Sep 09, 2014 |
| I tracked down the commit that introduced the bug with svn-bisect:
Regression found!
Last good revision: r10003
First bad revision:
------------------------------------------------------------------------
r10004 | greg.ercolano | 2013-10-21 06:58:43 +0200 (Mon, 21. Okt 2013) | 4 Zeilen
Fixes STR#2991: prevents crash when file browser
encounters an image that can't be loaded. | |
| |
| #3 | chris
11:20 Sep 09, 2014 |
| Bitmap images were filtered out with image->d()<=0! I corrected to image->d()<0 and added a check for image->count(), leading to the following change in Fl_File_Chooser2.cxx to fix this issue:
svn diff src/Fl_File_Chooser2.cxx
Index: src/Fl_File_Chooser2.cxx
===================================================================
--- src/Fl_File_Chooser2.cxx (Revision 10299)
+++ src/Fl_File_Chooser2.cxx (Arbeitskopie)
@@ -1425,7 +1425,8 @@
}
} else if (image && ( (image->w() <= 0) ||
(image->h() <= 0) ||
- (image->d() <= 0) )) {
+ (image->d() < 0) ||
+ (image->count() <= 0) )) {
// Image has errors? Show big 'X'
previewBox->label("X");
previewBox->align(FL_ALIGN_CLIP);
Tested with the images from STR #2991 ==> they still behave as they should. | |
| |
| #4 | AlbrechtS
06:10 Sep 19, 2014 |
| Patch looks good, but I'd like to wait for Greg to weigh in, since he committed r1004 and may have better insights. | |
| |
| #5 | manolo
11:32 Feb 08, 2015 |
| Fixed in Subversion repository. | |
| |
| #6 | greg.ercolano
11:33 Feb 08, 2015 |
| Sorry, I missed the request for my followup.
Yes, I'd suggest going with Chris's patch which:
a) checks if d() less than zero
b) adds a new check if count() is zero (seems reasonable)
When I committed r10004, I wasn't aware that a value of 0 for d()
could be "valid" for a loaded image, but it is; the docs for
Fl_Image's constructor says:
"The depth is 0 for bitmaps, 1 for pixmap (colormap) images,
and 1 to 4 for color images."
(I'd offer in my defense that 'depth' is therefore a misnomer;
the value is not really a "depth" (bit count), since a bitmap's
actual "depth" is 1, not zero. It's more of a 'type'; the value
being symbolic, like an enum)
Be that as it may, the if() statement is trying to determine if the image is 'bad' (could not be loaded), so the test should only
check values that are documented for an invalid/unloaded image, and
I'd say chris's code does that right. | |
| |
| #7 | greg.ercolano
11:34 Feb 08, 2015 |
| Ah, OK, manolo already applied chris's patch; my comment and manolo's
commit crossed in time. | |
| |
| #8 | manolo
23:28 Mar 10, 2015 |
| Fixed in Subversion repository. | |
[ Return to Bugs & Features ]
|
| |
