> Huh? Doesn't happen here. Obviously you have plugins... have you made any
> of your own that might cause this?
None, don't even know (yet) how to do that...
> Could you configure with
> --enable-debug, then export DEBUGGER=gdb, then run it and see where it
> crashes?
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x405f88f3 in strlen () from /lib/libc.so.6
(gdb) #0 0x405f88f3 in strlen () from /lib/libc.so.6
#1 0x080d8098 in charconv_utf8_to_local8 (utf=0x0) at charconv.c:182
#2 0x080904b2 in get_plugin_manager () at plugin-manager.c:276
#3 0x0809071b in file_plugins_callback (data=0x0, action=0,
widget=0x84eae04) at plugin-manager.c:306
#4 0x08084341 in dia_menu_signal_proxy (widget=0x84eae04,
uiinfo=0x80ef470) at menus.c:611
#5 0x402f63c3 in gtk_marshal_NONE__NONE () from /usr/lib/libgtk-1.2.so.0
#6 0x40328268 in gtk_handlers_run () from /usr/lib/libgtk-1.2.so.0
#7 0x4032763f in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#8 0x40325597 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#9 0x4035e64f in gtk_widget_activate () from /usr/lib/libgtk-1.2.so.0
#10 0x402feefc in gtk_menu_shell_activate_item () from
/usr/lib/libgtk-1.2.so.0
#11 0x402fe121 in gtk_menu_shell_button_release () from
/usr/lib/libgtk-1.2.so.0
#12 0x402f5f2f in gtk_marshal_BOOL__POINTER () from
/usr/lib/libgtk-1.2.so.0
#13 0x4032767d in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#14 0x40325597 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#15 0x4035e4ec in gtk_widget_event () from /usr/lib/libgtk-1.2.so.0
#16 0x402f5e65 in gtk_propagate_event () from /usr/lib/libgtk-1.2.so.0
#17 0x402f4eaf in gtk_main_do_event () from /usr/lib/libgtk-1.2.so.0
#18 0x403aadd4 in gdk_event_dispatch () from /usr/lib/libgdk-1.2.so.0
#19 0x403dcc46 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#20 0x403dd273 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#21 0x403dd43c in g_main_run () from /usr/lib/libglib-1.2.so.0
#22 0x402f476c in gtk_main () from /usr/lib/libgtk-1.2.so.0
---Type <return> to continue, or q <return> to quit---#23 0x080a9548 in
main (argc=1, argv=0xbffff814) at main.c:42
#24 0x4059c7ee in __libc_start_main () from /lib/libc.so.6
> > Next, I am pretty sure there's a way to change Dia's default parameters,
> > like line thickness, (basis) font size, text padding (common for all
> > objects), but I couldn't find this in docs / mailing list...
>
> There is no session-to-session setting, but line thickness can be set from
> the tool box (the five parallel lines). Global default font size and
> padding is not settable, but it can be set per-object.
Ok, as a first approximation, I created dia_defaults.h with
DEFAULT_LINE_WIDTH, DEFAULT_FONT_HEIGHT,... and replaced 0.1 where I could
find it (yes, best would be to grep the whole source tree, but sometimes
it's hidden behind 0.05 * 2:-))...) with DEFAULT_LINE_WIDTH, etc.,
#including <dia_defaults.h> in respective .c / .h files. This is just a
quick (I really have VERY little time for this, sorry), dirty hack to get
something at least approximately into shape (why such huge defaults
anyway? You can't fit more than a couple of flow-chart boxes on a page
with them...) I can create a patch and send it to you, but you'll
definitely have to work through it, but it should be easy. Ideally, as I
said before, I would like to see defaults set in a config file AND be
dynamically modifiable at run-time, e.g. with a fall-down list of
font-sizes, line-widths, fonts, etc. - as is done in most text-processors,
or selectable from preferences dialog. Also, why there's no include
directory in dia tree?... and all global header-files are just kept in the
root directory... errgh...
> > (now I DO have a freetype support configured in
> > - and yes, it does help to reduce the padding, but you should really in
> > configure.in check not just for freetype-config, but for a version >
> > x.y.z, where FT_Get_Postscript_Name is already supported:-))
>
> That would be 2.0.5, which is the version we already check for.
Hm, but I had it fail to link with unresolved symbol
FT_Get_Postscript_Name (I think my version was < 2.0.5, so, the test
didn't work properly).
> > Sorry about this flood, I am trying to pursuade my company to use an
> > "open-technology" (XML / UML - based) tool, rather than Visio, and Dia
> > seems to be the best candidate for a replacement, but these small
> > problems, most of which, I am sure, are simple to fix, make it
> > difficult...
>
> I hope you are successfull. Some of the bugs, while seemingly simple, may
> be deeper than you think.
Don't know, seems to be quite a few problems still...
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany