Bug 2002199
| Summary: | German neo2 layout sticks when switching to typing-booster or m17n, no emoji found | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Andy <andy> |
| Component: | ibus-typing-booster | Assignee: | Mike FABIAN <mfabian> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 35 | CC: | anish.developer, i18n-bugs, mfabian |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | ibus-typing-booster-2.14.12-1.fc36 ibus-typing-booster-2.14.12-1.fc35 ibus-typing-booster-2.14.12-1.fc34 ibus-typing-booster-2.14.12-1.fc33 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-09-16 12:18:27 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Andy
2021-09-08 08:40:30 UTC
1) That the neo2 keyboard layout *sticks* when switching to most input methods is the expected behaviour. Most input methods do not enforce a specific layout. For example, when you switch to the Japanese input method ibus-anthy and want to type Japanese using phonetics, for example typing “nihon” to get 日本, it would not be nice if the input method forced you to type the “nihon” using a QWERTY layout. Only non-phonetic input methods, for example https://en.wikipedia.org/wiki/Cangjie_input_method need to force a specific keyboard layout, usually the US English layout. ibus-typing-booster does not force a layout either, you should be able to use your neo2 layout with ibus-typing-booster, so it is good that it “sticks”. Makes it possible for you to type “cat” the way you are used to do it on the neo2 layout. 2) That the underscore does not trigger the emoji input but commits the preedit instead when using the neo2 layout is a but in my opinion. I think I have a fix for this, coming soon ... ⏳ Test build for Fedora 35 with the fix: https://copr.fedorainfracloud.org/coprs/mfabian/ibus-typing-booster/build/2725692/ Thank you very much for testing ibus-typing-booster with the Neo2 keyboard layout! The change https://github.com/mike-fabian/ibus-typing-booster/commit/0da5d094c89435553e3f77e8d4f6e8a3e56dbd59 fixes the problem that _ didn’t trigger emoji lookup when using the Neo2 layout. But I noticed a few other difference when using the Neo2 layout. For example: When typing characters like []=&$ using the Neo2 layout, they are on the 3rd level i.e. they are typed with “CapsLock” + something (where CapsLock is the key used for CapsLock on most QWERTY layouts, but it is ISO_Level3_Shift on the Neo2 layout). ISO_Level3_Shift is on AltGr (Right Alt key) on many other layouts. In m17n-db, which ibus-typing-booster uses for transliteration, ISO_Level3_Shift/AltGr is the “msymbol” “G-”. So _ is typed as “G-_” with the Neo2 layout. I added “G-_” as another exception in my patch, because it is important to be able to type _ into the preedit to trigger the emoji lookup. But I did **not** yet add someting like “G-&” as an exception. That means, they when typing a & using Neo2 while a preedit is open, the preedit is committed and the & appended. That is probably no big problem because completing stuff ending with & probably does not make much sense anyway. But it is a slightly different behaviour compared to using typing booster with a “normal” QWERTY layout. When typing & on a normal QWERTY layout, the & is inserted into the preedit instead of committing the preedit and appending on Neo2. I think in these cases, this difference does not matter much. But if you think it matters and especially if you find other, more important problems while using typing booster with the Neo2 layout, please tell me and I’ll think what I can do about it. FEDORA-2021-ef2364190c has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2021-ef2364190c FEDORA-2021-ef2364190c has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2021-18b3844265 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-18b3844265 FEDORA-2021-d0ecb6d7a0 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-d0ecb6d7a0 FEDORA-2021-02c8c9a130 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-02c8c9a130 FEDORA-2021-02c8c9a130 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-02c8c9a130` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-02c8c9a130 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2021-d0ecb6d7a0 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-d0ecb6d7a0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-d0ecb6d7a0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2021-18b3844265 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-18b3844265` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-18b3844265 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2021-02c8c9a130 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2021-d0ecb6d7a0 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2021-18b3844265 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. |