Hello there,

I've been doing a lot a searching on this problem, but with no luck.

I have two computers at home: a "fat" one, big enough to run lots of stuff, an a "thin" one (cheap, old thing), that I basically use to run the OpenBox WM and then ssh to the fat machine.
My wife uses the fat PC directly, and I run most thing remotely on it too.

I have pretty much ironed out all problems, and it's running fairly smoothly. However, I can't type accents with dead keys on my remote computer. Dead keys work fine (with the US International layout) on both the thin and the fat machine, but only locally.
When I try to type dead keys on the thin PC onto the fat PC, they are ignored. So if I really want to type accents, I need to do so locally in a text editor, then copy-paste. A bit of a pain, really

Well, I hope somebody can help.

Thanks,

Ben

What do you use to login to your "fat" system? SSH? the problems is there if that is the case. Sometimes i have the same problem too

Hi loesgb,

(Sorry about not replying sooner, I didn't realize I didn't activate email notification)

Yes, I use SSH, so that seems to be the problem.
I have found a bit more, actually: the problem occurs in programs runs directly from the thin client through SSH (I'll call this level 1). Whereas some programs, if I start them from the command line from a console on the server (I'll call this level 2), handle accents properly: xterm and OOo work fine this way (but konsole, gvim or thunderbird don't).

And I have also noticed that on a level 1 xterm or konsole, file names with accented characters are not displayed properly, whereas on a level 2 console they are.
So I would agree, it is a problem with SSH.

Any idea how to work around this?

I've tried starting programs from a key mapping program on the server (bbkeys) instead of starting them from epistrophy on the client, but this didn't change anything. I thought that, being launched by a server process, the programs would behave as level 2, but no, they still behave as level 1.