Mailing List Archive

Support open source code!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XIM, kinput2 & Tk

"Stephen J. Turnbull" <> writes:

> >>>>> "Mike" == Mike Fabian <> writes:
>     Mike> I think several applications look for LC_CTYPE to decide
>     Mike> whether they should use XIM or not.
> This is broken.  Locale in general is about external representations.
> Try: info libc "chararcter set handling" "generic charset conversion"
> to see the kinds of problems you get into if you use it for internal /
> conversion purposes.

kterm doesn't use if for conversion purposes, it just uses it to
decide whether to use XIM:

kterm 6.2.0, xim.c, line 174:

    char	*localelist;
            char **locales;

            for (locales = ParseList(localelist); *locales; locales++) {
                    if (setlocale(LC_CTYPE, *locales) && XSupportsLocale()) return;

            fprintf(stderr, "Couldn't set locale: %s\n", localelist);

There are no setlocale() calls in kterm using LANG. I this wrong? 

I patched it with the following patch to make it work with glibc 2.2:

--- kterm-6.2.0/xim.c.orig	Tue Nov 14 21:04:13 2000
+++ kterm-6.2.0/xim.c	Tue Nov 14 21:13:23 2000
@@ -175,6 +175,10 @@
 char	*localelist;
+#if (defined (__GLIBC__) && ((__GLIBC__ > 2) || (__GLIBC__ == 2) && (__GLIBC_MINOR__ >= 2)))
+	if (setlocale(LC_CTYPE,"") && XSupportsLocale()) return;
+	fprintf(stderr, "Couldn't set locale: %s\n",setlocale(LC_CTYPE,NULL));
 	char **locales;
 	for (locales = ParseList(localelist); *locales; locales++) {
@@ -182,6 +186,7 @@
 	fprintf(stderr, "Couldn't set locale: %s\n", localelist);
 static XIMStyle

But I didn't change the use of LC_CTYPE.

    ~$ LANG=ja_JP LC_CTYPE=de_DE kterm

will not turn on XIM in kterm. Is this really wrong?

Should I change it? Why did the kterm developers use LC_CTYPE?

RedHat (6.2 and 7.0) checks in /etc/X11/xinit/xinitrc.d/xinput
for the value of LC_CTYPE to decide whether to start kinput2.

Is this wrong?

>     Mike> Christopher SEKIYA <> writes:
>     >> The keybindings are modified via Xdefaults, IIRC.
>     Mike> For kinput2. For other XIM servers it may be different.
>     Mike> nicolatter for example has the keybindings in it's own
>     Mike> config files in ~/.nicolatter/ when it works together with
>     Mike> Wnn, but uses the keybindings from ~/.canna if it works
>     Mike> together with Canna.
> Are you sure nicolatter is an XIM input manager?

Yes, it is an alternative to kinput2. Nicolatter's homepage
is here:

> If so, that is _even more disgusting_ than the hack I didn't describe
> for kinput2.  X apps should never be dependent on host-local config
> files, even the X Consortium eventually figured that out.
> Sheesh, you might as well use Windows.  Why bother having a network
> protocol at all if you're doing bondage with a single machine like
> that?

Is it that bad? Aren't the keybindings to start XIM a user specific
setup? So why not put in into $HOME? if $HOME is nfs mounted,
you have it available on all machines. If you don't like


you usually do the changes also to ~/.Xresources or something like
that. If you don't have root privileges, what else can you do?

I only thought that it was very confusing that nicolatter did put the
keybindings to start XIM in case of Wnn into the file
~/.nicolatter/global, but in case of Canna reads them from ~/.canna. I
couldn't find that in nicolatters documentation, so I was surprised
why changes to ~/.nicolatter/global didn't work in case of Canna.

Mike Fabian   <>

Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links