- "cap_label" was an old typo, that we kept for compatibility with legacy layouts. "shift_label" might be better, though all of these modifier labels were deprecated long ago. There not going to be removed, though.
I can replace all of the occurrences of "cap_label" with "shift_label" with ease but... if this approach is deprecated, probably we'd better use the suggested, current approach. Which is what?
- Did run it through an XML formatter? It's hard to diff the changes and all the empty lines are gone. Looks more consistent, though.
No. I just edited it with Atom. You can see a copy of this file here, as well:
- There's no ₩ character in the korean keymap here, so we probably can't get it with keycode keys. Char keys would work. Trunk has a bunch off currency symbols, including ₩ in a new character palette. Those are all char keys. However, char keys don't support modifiers, IIRC.
I'll have a look at this palette and make some experiment.
- Is it different when you type into Gtk2 applications like Firefox?
No. I still have to click twice the button to actually get the capitalized letter (actually, a so-called "double consonant").
- Maybe take a look at the keyboard definitions in libhangul.
apt-get source libhangul1
in hangul/hangulkeyboard.h
These tables translate "ASCII" (I suppose keysyms of the English Korean keyboard) to Hangul Unicode. I believe Hangul_keyboard_table_2 is the Dubeolsik default.
I'll have a look.
- Does it work with Onboard and multipress? It does here.
GTK_IM_MODULE=multipress libreoffice
then press any key on the number pad
Do you mean this?
alex@Lenovo $ export GTK_IM_MODULE=multipress libreoffice
alex@Lenovo $ libreoffice
In this case, it does not make any difference. I still just get western text, no matter what font I use (hangul font...). The numeric pad just outputs numbers (no ALT-numbers ASCII code...).
@marmuta
- "cap_label" was an old typo, that we kept for compatibility with legacy layouts. "shift_label" might be better, though all of these modifier labels were deprecated long ago. There not going to be removed, though.
I can replace all of the occurrences of "cap_label" with "shift_label" with ease but... if this approach is deprecated, probably we'd better use the suggested, current approach. Which is what?
- Did run it through an XML formatter? It's hard to diff the changes and all the empty lines are gone. Looks more consistent, though.
No. I just edited it with Atom. You can see a copy of this file here, as well:
https:/ /gist.github. com/alexbottoni /677f7568eaa7fd 3cb00b8d1529445 ed4
- There's no ₩ character in the korean keymap here, so we probably can't get it with keycode keys. Char keys would work. Trunk has a bunch off currency symbols, including ₩ in a new character palette. Those are all char keys. However, char keys don't support modifiers, IIRC.
I'll have a look at this palette and make some experiment.
- Is it different when you type into Gtk2 applications like Firefox?
No. I still have to click twice the button to actually get the capitalized letter (actually, a so-called "double consonant").
- Maybe take a look at the keyboard definitions in libhangul. hangulkeyboard. h keyboard_ table_2 is the Dubeolsik default.
apt-get source libhangul1
in hangul/
These tables translate "ASCII" (I suppose keysyms of the English Korean keyboard) to Hangul Unicode. I believe Hangul_
I'll have a look.
- Does it work with Onboard and multipress? It does here. MODULE= multipress libreoffice
GTK_IM_
then press any key on the number pad
Do you mean this? MODULE= multipress libreoffice
alex@Lenovo $ export GTK_IM_
alex@Lenovo $ libreoffice
In this case, it does not make any difference. I still just get western text, no matter what font I use (hangul font...). The numeric pad just outputs numbers (no ALT-numbers ASCII code...).