ibus works in libreoffice 4.4 running on plasma 5 (kde) but ibus-hangul does nothing at all. I know there is something detected because right alt gets mapped to hangul/"english" key and when pressed does not register as right alt and does not call up menu bar. But when in Hangul input and I hit the hangul/"english" button, and type there are problems. The input method system does not come up and if I type where the "g" key is on a US english keyboard I get "g" and not ㅎ. The hangul/"english" switching key does not affect global settings either (it should). To help explain, the hangul input method for ibus has two nested input methods. Koreans often use mixed script. Where the right alt button is on a keyboard or on a special key on a dedicated keyboard there is a hangul/"english" button. When in Windows or using ibus, the keys are mapped to a "US-English" keymap within ibus-hangul or to a hangul keyampping within ibus-hangul. If I want dvorak or anything I would have to switch out of ibus-hangul. When writing Korean, one is switching in and out of romanization. The roman alphabet is almost universally set to US-English. I can change the hangul keymapping, but every Korean will expect that the key under the left index finger will always be "f" in "english" mode and 99% of the time will be "ㄹ" in hangul mode. ibus-hangul does become the input method editor, but it stays locked as "ibus-hangul in 'english' mode" and cannot switch to "ibus-hangul in hangul mode" Arch: x86-64 processor Software arch: all x86-32 Linux: 3.18.13 Distribution: Manjaro (rolling) Desktop: KDE Plasma (5.3.0) Qt: 4.8.6, 5.4.1 Gtk: 2.24.28, 3.16.3 ibus: 1.5.10 ibus-hangul: 1.5.0 ibus-qt: 1.3.3 python: 2.7.9, 3.4.3 dbus: 1.8.16 python-dbus: 1.2.0 Application: libreoffice (4.4.3) Hangul input method editors highlight the current block and dynamically show the character being composed piece-by-piece. Hangul is an alphabet, but letters are stacked by root form and by syllable. It would be like writing "foxes" as "fox es" with the f-o-x stacked vertically in one space and e-s stacked vertically in the next space. "Today" would be "to" stacked vertically and "day" written horizontally but narrowly so as to fit in one space. So when I want to type gan 간 I type ㄱㅏㄴ and the input method editor arranges them as 간. If I want to write ㄱㅏㄴ as separate characters for demonstration, I hit ㄱ(>)ㅏ(>)ㄴ . As another example, ganda 간다 or wang 왕 or gwi 귀 or hyu 휴 or de 데 or al 알. Every step of the way the display and input method editor are actually showing pre-composed Unicode characters. Until I finalize the input, the flashing block mimics dynamic composition. (note: the Unicode characters for compositional elements of hangul are almost never used. The displayed character and finalized characters are always a pre-composed character. For latin scripts, the analogue would be entering é and having a highlighted e be flashing, then entering a ◌́. Yet the output would be a pre-composed é (U+00E9) and never é made of U+0065 and U+0301 together.)
Is bug 72330 the same problem in your opinion? You can set this as resolved duplicate, if it is.
It's a different thing. I am running manjaro, which is essentially Arch, which itself is very vanilla. The Ubuntu family which I used to use, and Xubuntu and Kubuntu, which I had been using for the past few years, was always touch and go. It would drop out suddenyl and come back on. The problem I have did not affect 4.3 at all. 4.3 works perfectly minus poor desktop integration. 4.4 is the only version to have the issue. This issue, I think, may be tied to the VCL toolkit and it's partial integration with GTK3 (in transition from GTK2). Debian and ubuntu do a lot of modifications to their software, which I generally like, but this can introduce new bugs, or cover up upstream bugs. The problem only affects complex input methods. There are outstanding issues with LTR and RTL (why, on an Right to Left line with only RTL text, does the right arrow key go left and make right arrow merely become "next"?), but I don't use arabic enough to help diagnose that and in any case, the input itself is fine. Ibus that remaps keys is fine. The problem is that I don't get that flashing block for complex input methods which are entering non-finalized character components.
The fact that the bug doesn't appear in 4.3 (which has incomplete desktop environment integration under kde4 or plasma 5) but does appear in 4.4 (which has near perfect integration) is what is odd. I think it's due to the transition to gtk3 coupled with the underlying alien toolkit. The other bug to which you linked is probably caused by something else and I've found ibus and libreoffice to be finicky since day one in the ubuntu family. They modify quite a bit. This causes ibus to mostly work in wine (instead of being completely ignored), but it also causes other bugs to manifest in very different ways or introduce some new bugs. Thank you for the quick and polit response, too, by the way.
Thanks. I have Manjaro w/ KDE on a laptop and I will make a note to test this later.
Ok, finally was able to test this (had a flu for 2 weeks right after I promised to test). Installed ibus and ibus-hangul. Started the graphical ibus preferences and added Korean (hangul) as an input method. First I tested with Russian and the switching did indeed work. With Korean the switching did not affect LibreOffice. Manjaro 64-bit, KDE Plasma 5 LibO 4.4.3.2
My guess is that would have any other editor with complex input (provisional characters are displayed and then finalized as one composed character. Finalizing and then moving cursor and hitting backspace or delete would delete an entire composed character). Complex text layout (arabic, abugidas) seems to work as does RTL. I tested with some other input methods and it seems to be limited to complex input methods.
Migrating Whiteboard tags to Keywords: (bibisectRequest) [NinjaEdit]
*** Bug 72330 has been marked as a duplicate of this bug. ***
*** Bug 99833 has been marked as a duplicate of this bug. ***
*** Bug 100320 has been marked as a duplicate of this bug. ***
Reading this https://bugs.documentfoundation.org/show_bug.cgi?id=100320#c13, I wonder if it may be considered as NOTOURBUG. But since I don't know anything about ibus, I can't tell.
In debian jessie(main), the following 5 packages were updated today. libibus-1.0-5 i386 1.5.9-1 [309 kB] gir1.2-ibus-1.0 i386 1.5.9-1 [257 kB] ibus i386 1.5.9-1 [483 kB] ibus-gtk i386 1.5.9-1 [207 kB] ibus-gtk3 i386 1.5.9-1 [207 kB] And this bug is resolved. Thank ibus team for fixing. :)
(In reply to suzukiyos0 from comment #12) > And this bug is resolved. Thank ibus team for fixing. :) The above is wrong. After rebooting the debian, the problem took place again. The patched package installed by "dpkg -i" is replaced with the same (version) package in debian repository, which is not patched, by executing "apt update;apt upgrade" or "apt update;apt full-upgrade". Thus, I use apt-pinning to avoid installation of the following packages: ibus, libibus-1.0-5, gir1.2-ibus-1.0, ibus-gtk and ibus-gtk3
"aptitude" can prevent the same version as the patched one overwriting the patched one, and helped me. But I really hope libreoffice will be fixed soon.