Hangul (Korean) support

Looking forward to your layout, alexbottoni.

I've been digging around and found how to get the current layout id from ibus-hangul. Sample script attached. If we somehow (tbd) make this accessible to Onboard's layout files, we could switch key labels in sync with the layout setting in ibus-setup_hangul.

Question is still where the key labels come from. There doesn't seem to exist a standardized way to get them from IBus, but libhangul can apparently provide them. libhangul I believe is the engine behind im-hangul, imhangul-gtk3, etc. It defines the six keyboard layouts available in ibus-setup-hangul. I think we'd be able to translate English to Hangul key labels with it. I'm not too happy with adding libhangul as a required dependency, though. Hopefully there's a way around that.

Here a first (still incomplete) prototype, just to have something to play with and something to push on the discussion.

Screenshot: http://i61.photobucket.com/albums/h65/alexbottoni/hangul-onboard-keyboard-prototype-test_zpsraffkwi0.png

XML .onboard layout file: https://gist.github.com/alexbottoni/ec897b80348871ceb10836c9e03a1b50

(also attached here)

A couple of comments:

1) I'm trying to copy this keyboard:

https://cdn-standard4.discourse.org/uploads/memrise/original/2X/6/60f68ebd3d40b3ef1bea885bbcb4896baaa17833.png

2) When you use capslock, OnBoard does not output capital-sized characters. You have to click twice on the key to get the corresponding character capitalized. I cannot understand if this behavior is correct (maybe related to the syllable-assembly mechanism) or is an error.

Just to add the previous screenshot as an attachement...

Complete Hangul layout

XML layout config file: attached

Screenshot: http://i61.photobucket.com/albums/h65/alexbottoni/atom-and-onboard-with-hangul_zps46pmtlwj.png

As you can see from the screenshot, OnBoard works fine with Atom Editor (and Gedit). I was unable to use it with LibreOffice 5.x, instead.

I tried to use the LSGT key to host the Won symbol (₩) but... it does not work. OnBoard always outputs a less-than/great-than symbol instead.

Given that the < and > character are already represented on the standard Hangul layout, I'm looking for ideas/proposal regarding how to use this LSGT key.

Try this layout, play with it and let me know your comments and requests.

I had a quick look, will have more time on the weekend.

I'm amazed how you figured it all out so quickly. That looks like a usable Keyboard.
Some nitpicks:
- "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.
- 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.

> I tried to use the LSGT key to host the Won symbol (₩) but...
> it does not work. OnBoard always outputs a less-than/great-than
> symbol instead.
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.

> 2) When you use capslock, OnBoard does not output capital-sized characters.
Can't imagine why at the moment. Is it different when you type into Gtk2 applications like Firefox?

> I'm looking for ideas/proposal regarding how to use this LSGT key.
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 was unable to use it with LibreOffice 5.x, instead.
Does it work with Onboard and multipress? It does here.
GTK_IM_MODULE=multipress libreoffice
then press any key on the number pad

@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/677f7568eaa7fd3cb00b8d1529445ed4

- 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...).

Won symbol ("₩") working (more or less...)

See screenshot here:

http://i61.photobucket.com/albums/h65/alexbottoni/won-symbol-in-hangul-onboard-keyboard-layout_zpsz6prfrwt.png

I just changed this line in the XML file:

<key group="alphanumeric" id="LSGT"/>

to:

<key group="alphanumeric" id="LSGT" char="₩" label="₩"/>

I have to click the key twice to get the Won symbol. Dunno why...

>>There not going to be removed, though.
s/There/They're/
>if this approach is deprecated, probably we'd better use the
>suggested, current approach. Which is what?
I had dynamic generation of labels in mind when I wrote that. That's what is already happening for most keycode keys across all of Onboard's layouts. Whenever the Xkb keymap changes, the labels change and that is what I think should happen for input methods too. I mentioned getting them from libhangul before.

However, what I should have remembered are keysym rules (tag "keysym_rule"). These rules can replace arbitrary attributes, including the label, wherever the given keysym would be generated. Keysyms are one step up in the translation from keycodes ("keycode" key) to printable characters ("char" key) and that translation has all modifiers already applied, no need to explicitly target individual modifiers with shift_label, etc.
The existing keysym_rules in key_defs.xml switch labels of the number pads when NumLock is active - without having to specify the NumLock modifier.

Actually, in your case, a keysym rule should work for the Won symbol ("₩") too. That would take the shift modifier into account. You should be able to find the keysym to target by typing into xev.

The currency keys in trunk have to stay "char", because they are not part of the system keymap and have no keycode to translate from.

However, as I wrote before, we're not going to remove the <modifier>_label attributes.

> Do you mean this?
> alex@Lenovo $ export GTK_IM_MODULE=multipress libreoffice
Just this should already do:
GTK_IM_MODULE=multipress libreoffice
I then picked writer and the number pad would switch through multiple letters.
Configuration is in
/etc/gtk-3.0/im-multipress.conf

Is it installed?
ll /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules | grep multipress
-rw-r--r-- 1 root root 15K Mai 1 05:03 im-multipress.so

It's from the libgtk-3-0 package, so it probably is.

Does it work in gedit?
GTK_IM_MODULE=multipress gedit

If yes then there might be something iffy about libreoffice in Mint.

multipress is installed:

alex@Lenovo $ ll /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules | grep
multipress
-rw-r--r-- 1 root root 14616 ott 26 2014 im-multipress.so

And it works fine with Gedit (any key switches through a fixed set of
letters and numbers when you hit it).

It does not work at all in LibreOffice 5.3.2 (Ubuntu official release).

2017-05-18 11:07 GMT+02:00 marmuta <email address hidden>:

> > Do you mean this?
> > alex@Lenovo $ export GTK_IM_MODULE=multipress libreoffice
> Just this should already do:
> GTK_IM_MODULE=multipress libreoffice
> I then picked writer and the number pad would switch through multiple
> letters.
> Configuration is in
> /etc/gtk-3.0/im-multipress.conf
>
> Is it installed?
> ll /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules | grep multipress
> -rw-r--r-- 1 root root 15K Mai 1 05:03 im-multipress.so
>
> It's from the libgtk-3-0 package, so it probably is.
>
> Does it work in gedit?
> GTK_IM_MODULE=multipress gedit
>
> If yes then there might be something iffy about libreoffice in Mint.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1691115
>
> Title:
> Hangul (Korean) support
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/onboard/+bug/1691115/+subscriptions
>

--
--
Alessandro Bottoni

I'll have a look at keysym_rule(s) and see if I can use them.

Meanwhile, I think we can use the existing layout.

2017-05-18 10:48 GMT+02:00 marmuta <email address hidden>:

> >>There not going to be removed, though.
> s/There/They're/
> >if this approach is deprecated, probably we'd better use the
> >suggested, current approach. Which is what?
> I had dynamic generation of labels in mind when I wrote that. That's what
> is already happening for most keycode keys across all of Onboard's layouts.
> Whenever the Xkb keymap changes, the labels change and that is what I think
> should happen for input methods too. I mentioned getting them from
> libhangul before.
>
> However, what I should have remembered are keysym rules (tag
> "keysym_rule"). These rules can replace arbitrary attributes, including the
> label, wherever the given keysym would be generated. Keysyms are one step
> up in the translation from keycodes ("keycode" key) to printable characters
> ("char" key) and that translation has all modifiers already applied, no
> need to explicitly target individual modifiers with shift_label, etc.
> The existing keysym_rules in key_defs.xml switch labels of the number pads
> when NumLock is active - without having to specify the NumLock modifier.
>
> Actually, in your case, a keysym rule should work for the Won symbol
> ("₩") too. That would take the shift modifier into account. You should
> be able to find the keysym to target by typing into xev.
>
> The currency keys in trunk have to stay "char", because they are not
> part of the system keymap and have no keycode to translate from.
>
> However, as I wrote before, we're not going to remove the
> <modifier>_label attributes.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1691115
>
> Title:
> Hangul (Korean) support
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/onboard/+bug/1691115/+subscriptions
>

--
--
Alessandro Bottoni