François Patte wrote:
I installed scim to write some exotic scrips and it works quite good but
there is a problem that took me a long time to understand (and solve):
the assignation of the variable GTK_IM_MODULE to scim.
This is done when scim is running (for me at start time) and this makes
some applications crash: acroread, gxine (but not xine), realplayer....
I had to modify (or create) a script for these apps which unset first
My question is: why scim cannot run smoothly with other applications?
Long saga of the C++ library conflict that occurs with certain
applications (usually proprietary) built with an earlier version of
libstdc++, which cannot co-exist peacefully in the same process as
another version of libstdc++.
FC5 attempted to solve this issue with SCIM in FC5 built against
libstdc++so7. Unlike the previous attempts used upstream, in Fedora
Extras 4 and at Novell that relied upon symbol export hiding,
libstdc++so7 actually did work with acroread at the time of testing
during the development of FC5. I don't know what might have changed
since then that subsequently makes libstdc++so7 fail to avoid the C++
library conflict. I haven't seen any other user reports like your post
For the long-term we were dissatisfied by the libstdc++so7 solution
because it was a horribly ugly hack. Eventually Ryo Dairiki wrote
scim-bridge where the gtkimmodule was rewritten in C with an abstraction
over a socket, thereby solving this C++ conflict problem in an elegant way.
scim-bridge ships as the default gtkimmodule in FC6. Stuff should be
working a lot better with SCIM in FC6+ by default.
I have another question, maybe off topics (but scim commes with
is there a keyboard in scim for transliteration of other scripts in
roman script? I mean a virtual keyboard which allow you to add letter
with diacritical marks (macron, underdots, overdots and so on.
No, although it would be theoretically possible to operate through the
SCIM framework if someone wrote one.