LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Lost compose key after changing to utf-8 (http://www.linuxquestions.org/questions/slackware-14/lost-compose-key-after-changing-to-utf-8-a-917632/)

BroX 12-07-2011 05:13 PM

Lost compose key after changing to utf-8
 
I changed my system from iso-8859-1 to utf-8 so that Amarok would play files with special characters. But now I lost my compose key in some applications. For example yakuake console, kate, and libreoffice. It still works fine in for example firefox (look: ), thunderbird, and gimp, so it seems to be a 'gtk thing'?

I defined the compose key in ~/.Xmodmap with the following line
Code:

keycode 108 = Multi_key
Why is this not honoured by all applications after changing to utf-8?

I tried to solve it by also enabling the compose key in KDE System Setting's keyboard options, but that had no effect.

I'm at a loss. Any tips?

BroX 12-22-2011 05:25 PM

*bump*

No one? That's unbelievable in this forum! ;)

BroX 03-03-2012 06:59 PM

Order matters
 
Following up on my own post, since I finally solved this annoying mystery.

In qt applications, order matters!

So, in order to type , one needs to type <composekey> ' a, in that order. Before changing to utf-8, the order of the characters did not matter. gtk applications do not care about the order.

GazL 03-04-2012 04:15 AM

Keymapping/locale support is a bit of an ugly topic and not really well understood. It also tends to change with the specific locale and keyboard/country layout you are using so I'm not surprised people are either unable to help or shy away from the subject.

If you look at the files in /usr/share/X11/locale for your specific locale then you'll be able to see a list of accepted compose sequences. Some characters have alternative sequence combinations/orders and some don't.

Also, bear in mind that your keyboard layout might also have its own deadkeys defined to provide accented characters or direct access to certain characters via use of the AltGr key. On the gb layout I use, AltGr+punctuation keys to the left of 'enter' act as deadkeys to attach basic accents to a subsequent letter, and AltGr+C gives a copyright symbol and this is completely outside of the multi_key/compose system (which uses compose+O+c for the same character).


Rather than use xmodmap to set the Multi_key I think most folks these days use the XKB compose option either through xorg.conf or the setxkbmap command. e.g.
setxkbmap -option compose:rctrl
'rwin' is also a popular choice, but I find I never press the right control key so I use that and reserve the windows keys for my window manager functions.

Personally, I never let things like the Desktop Environment get anywhere near the keyboard settings, preferring to set such things at a lower level in xorg.conf..


I don't know why Qt would be acting differently to any other toolkit in this regard though as I'd have expected the compose functionality to all happen inside the XServer and be invisible to higher layers, but maybe that isn't the case and Qt implements its own compose sequence handler or somesuch..

As I said, it's all a bit ugly, and the above is only to the best of my understanding and I'm no expert, but I hope it helped a little, if belatedly. :)


P.S. I still use ISO8859-1 rather than utf8, so the key sequences I mentioned above may be different to those of a utf8 locale.

BroX 03-04-2012 10:30 AM

Thanks for some clarification GazL. I changed to using setxkbmap, with the same result with respect to the order of the characters. Not really a problem (once you know).


All times are GMT -5. The time now is 11:24 AM.