2011-01-08
After years of uncertainty, GNU/Linux systems for now seem to have converged towards using SCIM as input method platform for their X11 desktops, where it has proven a capable and flexible solution.
Solaris 10, on the other hand, uses iiim, which also does a fine job and is integrated with GNOME as well as CDE. Solaris generally offers well-maintained support for a very large number of locales, and, given the sysadmin decides to install them, putting oneself through the hassle of compiling SCIM when iiim is there to be used would certainly seem a dumb thing to do.
However, Solaris systems are often maintained through multiple layers of service providers, and getting anyone to install a package that isn't part of a machine's default profile is, if even possible, a tiresome endeavour.
A situation such as this is usually resolved by users compiling software themselves and putting it in a shared NFS directory, or even their home directory.
This particular example covers installing SCIM, scim-anthy, and scim-bridge in the home directory.
The environment in question was a Fujitsu SPARC machine where GNOME/JDS and its iiim-panel were not installed. However, iiim with CDE support was installed, and a UTF-8 locale was available as well (oddly enough, en_CA.UTF-8 when the machine was located in Germany – the way such systems are deployed never fails to surprise me, really). I didn't want to use GNOME on that machine anyway, but I neither wanted to use CDE (meaning I run a custom window manager from dtlogin). CDE's iiim support does not work really well without CDE, because the iiim panel would try to attach itself to a nonexistent CDE statusbar, resulting in borderless little windows floating around the screen.
On that Solaris 10 system, neither the X11 libraries nor the GTK build were very recent. Because of that, I had built the Xorg 7.4 libraries (including libXrender) and GTK 2.18.2 at an earlier opportunity. These libraries build without any problems on Solaris 10. I assume that these libraries are available and in the PKG_CONFIG_PATH. (If not, you might find yourself forced to build them at some point.)
The SCIM source code needs a few changes to make it compile on Solaris:
E. g., use the following commands in the top-level directory of the unzipped tarball:
echo '$a
#endif
.
0a
#if 0
.
w'|/usr/bin/ed src/scim_chartraits.cpp
echo '0a
#define SUN_LEN(su) \
(sizeof(*(su))-sizeof((su)->sun_path)+strlen((su)->sun_path))
.
w'|/usr/bin/ed src/scim_socket.cpp
Also, the build shouldn't assume gethostbyname_r because its signature is different on Solaris. Configuration and installation is then as follows:
ac_cv_func_gethostbyname_r=no \ LDFLAGS="-lsocket -lnsl -R$HOME/lib" \ ./configure --prefix=$HOME gmake gmake install
This builds without problems:
./configure --prefix=$HOME gmake gmake install
This also builds without problems:
./configure --prefix=$HOME \
CPPFLAGS="-I$HOME/include"
gmake
gmake install
scim-bridge is a tool that can be used in UI toolkits in place of the default IM plugins. It supports GTK and Qt. According to my experience with GTK, this approach is more robust than using SCIM's plugin. (Note: Another possibility is to use XIM and no plugin at all, but this can be very unstable when used with SCIM.)
The following adjustments are necessary:
Here is a patch which contains all changes. It includes a BSD-licensed implementation of daemon as well as a LGPL-licensed implementation of vasprintf.
Configuration and installation is then as follows:
gpatch -p1 < scim-bridge-1.4.16-sol10.patch
./configure --prefix=$HOME --disable-debug --disable-documents \
CPPFLAGS=-DMSG_NOSIGNAL=0
gmake
gmake install
Now everything is there, the last step is to register the IM engine with GTK.
Add the following to ~/etc/gtk-2.0/gtk.immodules (if GTK is installed in the home directory; otherwise, use your respective GTK IM configuration file):
"/home/YOUR_USER/lib/gtk-2.0/immodules/im-scim-bridge.so" "scim-bridge" "SCIM Bridge Input Method" "" "" ""
Note: In case you do not have write access to your default GTK IM configuration file, the environment variable GTK_IM_MODULE_FILE, or the configuration variable im_module_file, should provide an alternative.
This way, scim-bridge's plugin is available to GTK applications. The environment variable GTK_IM_MODULE should be set before starting such applications, in case they should make use of SCIM. On Solaris, a good place for this would be ~/.dtprofile.
Last update 2011-03-07