xffm crash report

[Olivier Fourdan]

Edscott,

I removed all xffm libs, checked out 5 minutes ago, recompiled and the
problem remains, so does the font resize btw.

Cheers,
Olivier.

On Thu, 2003-09-04 at 02:28, edscott wilson garcia wrote:
> Hey Olivier,
> 
> On Wed, 2003-09-03 at 17:21, Olivier Fourdan wrote:
> > Edscott,
> > 
> > I'm experiencing a crash (sig 11) with latest xffm (bt attached)
> > 
> > What's puzzling me is that it seems you added features as the font now
> > scale with the view size (and the crash seems to be related to fonts and
> > pango). We are supposed to be in feature freeze for a couple of months,
> > focusing exclusively on bug fixes.
> 
> Yes, to the best of my knowledge, I have been focusing on bug fixes. The
> font resize with iconsize changes was not working (a minor bug) because
> it was commented out. So I uncommented it. The other changes are with
> the history list not working as supposed to (another bug) or not working
> on all combos it was set to work (a third bug). That was fixed. Also, a
> minor cosmetic bug was that some menu items did not have a little icon
> when they were supposed to, for overall coherence.
> 
> > 
> > I'm a bit worried with the current state of xffm. Such errors should not
> > happen in a RC cycle... Looks like a regression to me. That problem was
> > not showing previously.
> 
> The font resizing code was in there, but for some reason it was
> commented out. I don't remember why, but I think it was because I was in
> the "single font size mood" and forgot to uncomment before commit to
> CVS. The reason for the font resize is that when icons grow smaller more
> columns will fit in the same window. The font resize code was created
> along with the icon resize code. 
> 
> Anyways, I will comment out the font resize so you can be sure the crash
> is not related to the font resize (now committing to CVS...). Although I
> could bet you a bottle of cognac (or tequila) that the font resize
> routine has nothing to do. The bottle could be delivered overnight if
> you wish to take the bet... ;-)
> 
> > 
> > Btw, here is how to reproduce the problem: I have a folder with
> > pictures, but some don't show the preview (why? no idea) So I left click
> 
> Previews are not generated for files of less than XFFM_MAX_PREVIEW_SIZE
> (set in mcs, for performance reasons on slower boxes) and only for files
> of the following extensions, as defined in libs/constants.h:
> 
> #define IS_IMAGE(x)	(strstr(x, ".tif") || strstr(x, ".TIF") ||  \
> 			 strstr(x, ".png") || strstr(x, ".PNG") || \
> 			 strstr(x, ".GIF") || strstr(x, ".gif") || \
> 			 strstr(x, ".JPG") || strstr(x, ".jpg") || \
> 			 strstr(x, ".JPEG") || strstr(x, ".jpeg") || \
> 			 strstr(x, ".XPM") || strstr(x, ".xpm") || \
> 			 strstr(x, ".pm") || strstr(x, ".PM") || \
> 			 strstr(x, ".bmp") || strstr(x, ".BMP")) 
> 
> Should others be added? I believe all these are supported by the gtk
> function  gdk_pixbuf_new_from_file().
> 
> (In 4.2 strstr() should be replaced by a regexp evaluation with a $ at
> the end, sometime in the future, to avoid a very small bug nobody has
> noticed, nor probably will, but can be seen in the above code).
> 
> > on one of these pictures to get the contectual menu and xffm cores.
> > 
> > Backtrace attached.
> 
> I cannot reproduce it here. From the backtrace it looks like the issue
> is with a menu_image_item that has got an invalid pointer for text in
> the accelerator field...  
> 
> A couple days ago I did convert a menu_item to menu_image_item so that
> it would have a little icon (like the other menu entries). It should not
> produce any problems unless there is a library mixup since the
> menu_image_item is created by xffm but accessed one of the xffm
> libraries for the do_popup function (which appears in traceback).
> I still have not figured out how to avoid "make uninstall && make
> install" without introducing unnecessary library version numbering.  
> 
> Please check again without font resizing (but without make uninstall)
> and then again with "make uninstall && make install". 
> 
> O, and I remember, I also added an extra column to the treemodel which
> is not used, but will be used in 4.2. That column I can remove if you
> want. It does no good nor harm at the moment. 
> 
> regards,
> 
> Edscott
>  
> 
> 
> > Cheers,
> 
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> http://moongroup.com/mailman/listinfo/xfce4-dev
-- 
Olivier Fourdan - fourdan at xfce.org
   
   Interoperability is the keyword, uniformity is a dead end. 
   http://www.xfce.org