Hi Carlos,
>I was trying i18n support in CVS gschem.
>
>If I tried to add a text with =E4 (a with diaeresis), CVS gschem doesn't
>know it, but 20030525 gschem (the last debian package) know it and
>places it correctly. The only difference in the environment between the
>two gschems is the definition of the variables PATH, LD_LIBRARY_PATH,
>and PKG_CONFIG_PATH to include the directories where I have installed
>the CVS version. I run both from the same terminal: I open the terminal,
>run 20030525 gschem, which does it fine, change the definition of those
>variables, and then run CVS gschem.
20030525 did not support gtk2. This is a new problem with
20030901 and the new gtk2 support. The problem you are seeing is
non-ascii (char value > 127) have to be in unicode for gtk2 to work right.
The fix for this is to go through the code and where ever there is a
gtk2 call which takes locale text, call the proper conversion functions.
I haven't figured out exactly what the conversion would be (probably
locale -> utf8). Likewise any text coming from a text entry needs to
be converted back into locale from utf8. I think this will work, but
don't quote me on that. There might be a simpler solution than this,
I haven't spent too much time thinking about it. Ideally, all of gschem
would be rewritten to use utf8 internally, however, I would need a large
supply of time to do that. :-)
[snip]
>Also, previous gschem was loading libgeda at runtime, but the CVS one is
>linked statically against libgeda. I don't wonder about this, I'm just
>telling this in case this isn't the liked behaviour:
>
>$ ldd gschem
Curious, ldd on my machine returns (it should be dynamically
linked):
libstroke.so.0 => /usr/local/lib/libstroke.so.0 (0x40021000)
libgeda.so.20 => /home/ahvezda/geda/lib/libgeda.so.20 (0x40024000)
libguile.so.12 => /usr/local/lib/libguile.so.12 (0x4005d000)
libguile-ltdl.so.1 => /usr/local/lib/libguile-ltdl.so.1 (0x400f0000)
[snip]
Do you have a $prefix/lib/libgeda.so.20 or only a
$prefix/lib/libgeda.a file?
-Ales
