GNOME Bugzilla – Bug 168638
UML Class Goes Bold
Last modified: 2005-04-10 04:07:36 UTC
Version details: 0.94 also has bug Distribution/Version: Fedora Core 3 In a UML class diagram, sometimes when you select a new class from the tablet, a previously-added class in the diagram goes bold in the font (class name). It goes back to normal if you left click on it. Why is it going bold in the first place? How does selecting it fix it? I will also post this bug to the dev list and see if any one is working on it. If not, I will fix it and submit the fix/patch.
It appears that objects outside the 'active area' lose their prettiness sometimes. Possibly some antialias info in the fonts particularly is lost. I have had no luck finding it yet.
Ya.... ...two additions: 1) with antialias selected (right click-> View -> AntiAliased), the bug goes away. 2) however, with antialias selected, after a few right clicks, the program will abort on the following assertion: ** ERROR **: file font.c: line 340 (dia_font_get_style): assertion failed: (PANGO_WEIGHT_ULTRALIGHT <= pango_weight && pango_weight <= PANGO_WEIGHT_HEAVY) aborting... its getting good... fun program...
lib/prop_text.c, line 479 call to glib g_strdelimit (gchar *string, const gchar *delimiters, gchar new_delim) with a null string ("name") seems to be our culprit. the function in prop_text.c which makes the call to g_strdelimit is line 456, gchar *object_get_displayname (DiaObject* object). ...might be a null property... more coming.... FYI - std err: (lt-dia:32646): GLib-CRITICAL **: file gstrfuncs.c: line 1915 (g_strdelimit): assertion `string != NULL' failed
FYI - still working on this, noticed same behavior in flow diagram. ...looking at pango calls, font.c and objects/UML... ...monitoring font params (in and out of pango)... soon I will crack open gtk...
FYI - hack-o-mania... ...nightly... ...much learned... ...still working... because this bug occurs on more than one diagram type, and because it occurs right after a right click, i have been living in disp_callbacks.c display_canvas_events(). my current focus is on ddisp->diagram->data->active_layer->objects... god forbid i should have to learn the complexities of mutliple layers! 8-| i have been doing a lot of intrumentation... but i still don't feel that i have discovered the type of data that the error is associated with... ...my current hunch is leading me to monitor the native member types versus the pango types associated with fonts in structs like UMLClass. any thoughts -- great -- but i am also hopping to crack this one myself... i hope i am not holding anyone up...
Ray o light PangoWeight is fluctuating when it should not and I am seeing changes in PangoWeight associated with the bug... ...that is a good thing... ;-) I think I saw some equations for going in and out of pango metrics.... I will look there. Also going in and out of the object properties menu seems to effect PangoWeight in unexpected ways.... Thanks for letting me work on this. ;-)
> Thanks for letting me work on this. ;-) This is open source. Thank you for taking an interest. Tweaking some settings, and assigning the bug to you.
I have no deep insights, I just want to say that the entries read almost like a Lovecraft story, one with a diary found left over after somebody has met a horrible death. I'm happy you're looking at it. Are you instrumenting mainly or using gdb?
hehehehe ...thanks alan, lars. i am not using gdb -- all std out, std err. do you prefer to use gdb for these type of bugs? hpl
Whatever works for you, but I'd expect better results from GDB.
I do prefer using gdb. It cuts down on the amount of recompilation required, though some bugs behave differently under gdb, especially memory corruption bugs. I've found gdb to be a great help in debugging. If you want to use it, do: export DEBUGGER=gdb app/run_dia.sh Best of luck on your hunt!
gdb is a good thing, thnx i have recompiled glitzlibpixmancairoatkpangogtk+ and am ready to follow dash g where she leads 8-| the error appears to hail from the bad lands... i am focusing on the gtk execution after display_canvas_events (GDK_BUTTON_PRESS bevent==3) and before 263:gtk_menu_popup() returns. clearly, there are various cases where the prettiness fades and the smut sets in... any salient concern about latest versions of glitzlibpixmancairoatkpangogtk+ as dependencies for production dia? tk
Created attachment 39697 [details] [review] patch for color intensity error in text fields see Bug#168638 --this is my first patch, all coaching on best practies much appreciated-- the deprecated gdk function gdk_pixbuf_render_to_drawable_alpha() which transfers the GdkPixbuf to the drawable GdkPixmap is increasing the color intensity for un-invalidated text regions. two possible fixes are 1) invalidate all text areas without killing performance (approach like a microtile array?) to clear the related regions in the pixbuf or 2) use the recommended GDK function for rendering a pixbuf: gdk_draw_pixbuf(). the recommended function gdk_draw_pixbuf() does not increase the intensity of pixbuf regions which are being redrawn with the same values that exist in the current drawable. this patch implements the later. ...strange, the recommended function (the one in this patch) was in the existing cvs head, commented out... reason not used? gdk_draw_pixbuf() has been in GDK since 2.2 (see 'since 2.2' in api doc ref. below), if this patch is accepted, will the dia dependency on GTK need to be increased from version 2.0.0+ to version 2.2+? references: gdk deprecation - http://developer.gnome.org/doc/API/2.0/gdk/gdk-Pixbufs.html#id2953518 dia dependency info in FAQ - http://www.gnome.org/projects/dia/
an alternate might be to create the drawable (renderer->pixmap) with the colormap or call gdk_drawable_set_colormap(renderer->pixmap, renderer->gc) ...interested in avoiding the gtk 2.2+ dependency? or would you just as soon move off of an 'obsolete' gtk function? here is the gtk 2.6 implementation of gdk_pixbuf_render_to_drawable_alpha(). all that my patch is doing is calling gdk_draw_pixbuf with a non-null colormap... void gdk_pixbuf_render_to_drawable_alpha (GdkPixbuf *pixbuf, GdkDrawable *drawable, int src_x, int src_y, int dest_x, int dest_y, int width, int height, GdkPixbufAlphaMode alpha_mode, int alpha_threshold, GdkRgbDither dither, int x_dither, int y_dither) { gdk_draw_pixbuf (drawable, NULL, pixbuf, src_x, src_y, dest_x, dest_y, width, height, dither, x_dither, y_dither); }
Using Gtk 2.2 is fine, CVS is already using 2.4 for the file selector. As for the patch, I don't know what you've done, but that is not a patch. If you use anoncvs, just do cvs diff -uw >/tmp/dia-patch in the base Dia directory and then attach the file /tmp/dia-patch. Don't try to compress it or anything. And make sure your debugging code is taken out.
thanks - i was following the bit on the faq... i will submit another patch... btw "all that my patch is doing is calling gdk_draw_pixbuf with a non-null colormap..." meant to say: "all that my patch is doing is calling gdk_draw_pixbuf with a non-null graphics context...
Created attachment 39698 [details] [review] no gzip (see previous attachment) (see previous attachment)
Applies cleanly, now in CVS. Thank you! Now it should be a piece of cake to find out why the libart renderer (app/render_libart.c) does exactly the same, but doesn't call gdk_pixbuf_render_to_drawable_alpha:)
thank you lars. i will look into app/render_libart.c right away. is there a bug# for it (did not see one)? also, should i/how do i close this one (#168638)? thanks again