Bug 1690326
Summary: | Input with ibus-bogo-0.4-19.fc30 repeatedly deletes text chars before the cursor | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | sandeep shedmake <sshedmak> | ||||
Component: | ibus-bogo | Assignee: | Truong Anh Tuan <tuanta> | ||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 35 | CC: | i18n-bugs, mfabian, psatpute, sshedmak, tfujiwar, tuanta | ||||
Target Milestone: | --- | Keywords: | i18n | ||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2022-12-13 15:12:51 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: | |||||||
Attachments: |
|
Description
sandeep shedmake
2019-03-19 09:54:40 UTC
ibus-bogo has a problem in Wayland to send the wrong keycodes. I'd suggest to use preedit instead of forwarding key events or ibus-unikey instead. (In reply to fujiwara from comment #1) > ibus-bogo has a problem in Wayland to send the wrong keycodes. > I'd suggest to use preedit instead of forwarding key events or ibus-unikey > instead. Reported problem persists with f31 (ibus-bogo-0.4-20.fc31). Yep, 'ibus-unikey' works as an alternative Vietnamese IME for ibus. I am still using both fine on my F30 Workstation. Let me check this more details later. What is the difference between ibus-bogo, ibus-unikey, and the Vietnamese input methods available in m17n-db (which are also available in ibus-typing-booster)? $ ls /usr/share/m17n/vi-*.mim /usr/share/m17n/vi-base.mim /usr/share/m17n/vi-nom.mim /usr/share/m17n/vi-viqr.mim /usr/share/m17n/vi-han.mim /usr/share/m17n/vi-tcvn.mim /usr/share/m17n/vi-vni.mim /usr/share/m17n/vi-nom-vni.mim /usr/share/m17n/vi-telex.mim If they are all different, then maybe it would be useful to add vi-bogo.mim and vi-unikey.mim which mimic the behaviour of ibus-bogo and ibus-unikey to be able to use these Vietnamese input methods with ibus-typing-booster (to get word completions). (In reply to Truong Anh Tuan from comment #3) > I am still using both fine on my F30 Workstation. > Let me check this more details later. It works on Xorg, so maybe it works for you because you use Gnome on Xorg, not on Wayland. (In reply to Mike FABIAN from comment #5) > (In reply to Truong Anh Tuan from comment #3) > > I am still using both fine on my F30 Workstation. > > Let me check this more details later. > > It works on Xorg, so maybe it works for you because you use Gnome on Xorg, > not on Wayland. I am currently using Wayland. Just checked: [tuanta@tuanta ~]$ loginctl show-session 2 -p Type Type=wayland (In reply to Mike FABIAN from comment #4) > What is the difference between ibus-bogo, ibus-unikey, and the Vietnamese > input methods available in m17n-db (which are also available in > ibus-typing-booster)? Actually, I am not familiar with this. I am just a packager, not a software developer. > $ ls /usr/share/m17n/vi-*.mim > /usr/share/m17n/vi-base.mim /usr/share/m17n/vi-nom.mim > /usr/share/m17n/vi-viqr.mim > /usr/share/m17n/vi-han.mim /usr/share/m17n/vi-tcvn.mim > /usr/share/m17n/vi-vni.mim > /usr/share/m17n/vi-nom-vni.mim /usr/share/m17n/vi-telex.mim But I think these are Vietnamese keyboards, the way to type Vietnamese (I am using "vi-telex"). ibus-bogo and ibus-unikey are a bit different as they are software for Vietnamese language processing with additional features: + Spelling checks. + Text processing. + Different Vietnamese charsets. ... (In reply to Truong Anh Tuan from comment #7) > (In reply to Mike FABIAN from comment #4) > > What is the difference between ibus-bogo, ibus-unikey, and the Vietnamese > > input methods available in m17n-db (which are also available in > > ibus-typing-booster)? > > Actually, I am not familiar with this. I am just a packager, not a software > developer. > > > $ ls /usr/share/m17n/vi-*.mim > > /usr/share/m17n/vi-base.mim /usr/share/m17n/vi-nom.mim > > /usr/share/m17n/vi-viqr.mim > > /usr/share/m17n/vi-han.mim /usr/share/m17n/vi-tcvn.mim > > /usr/share/m17n/vi-vni.mim > > /usr/share/m17n/vi-nom-vni.mim /usr/share/m17n/vi-telex.mim > > But I think these are Vietnamese keyboards, the way to type Vietnamese (I am > using "vi-telex"). How are you using vi-telex? If I understand correctly, you are not using /usr/share/m17n/vi-telex.mim because you are using neither ibus-m17n nor ibus-typing-booster. So the "vi-telex" you are using must be some Vietnamese keyboard layout from xkb, I guess. But I can find no “telex” in /usr/share/X11/xkb/symbols/vn so I am wondering what exactly you are using. > ibus-bogo and ibus-unikey are a bit different as they are software for > Vietnamese language processing with additional features: > + Spelling checks. > + Text processing. > + Different Vietnamese charsets. > ... Is there a specification what exactly ibus-bogo and ibus-unikey are supposed to do? The Fedora test case for ibus-bogo, https://fedoraproject.org/wiki/QA:Bogo, has: type "Khoong cos gif quis hown ddoocj laapj tuwj do". ... you will get: "Không có gì quí hơn độc lập tự do". That looks like a transliteration which could be done easily with a m17n input method as well. But for creating a m17n input method it would be nice to have some specification, that would be easier than just reverse engineering ibus-bogo. (In reply to Mike FABIAN from comment #8) > > How are you using vi-telex? If I understand correctly, you are not using > /usr/share/m17n/vi-telex.mim > because you are using neither ibus-m17n nor ibus-typing-booster. So the > "vi-telex" you are using > must be some Vietnamese keyboard layout from xkb, I guess. But I can find > no “telex” in > /usr/share/X11/xkb/symbols/vn so I am wondering what exactly you are using. Sorry for getting you confused. I meant I use "Telex" method to type Vietnamese. > > ibus-bogo and ibus-unikey are a bit different as they are software for > > Vietnamese language processing with additional features: > > + Spelling checks. > > + Text processing. > > + Different Vietnamese charsets. > > ... > > Is there a specification what exactly ibus-bogo and ibus-unikey are supposed > to do? > > The Fedora test case for ibus-bogo, https://fedoraproject.org/wiki/QA:Bogo, > has: > > type "Khoong cos gif quis hown ddoocj laapj tuwj do". > ... > you will get: "Không có gì quí hơn độc lập tự do". This is the main/core function so this test is mandatory. > That looks like a transliteration which could be done easily with a m17n > input method as well. > But for creating a m17n input method it would be nice to have some > specification, that would be easier than just reverse engineering ibus-bogo. Not sure. I will give a try. (In reply to Truong Anh Tuan from comment #9) > (In reply to Mike FABIAN from comment #8) > > > > How are you using vi-telex? If I understand correctly, you are not using > > /usr/share/m17n/vi-telex.mim > > because you are using neither ibus-m17n nor ibus-typing-booster. So the > > "vi-telex" you are using > > must be some Vietnamese keyboard layout from xkb, I guess. But I can find > > no “telex” in > > /usr/share/X11/xkb/symbols/vn so I am wondering what exactly you are using. > > Sorry for getting you confused. > I meant I use "Telex" method to type Vietnamese. I am still confused, are you using ibus-bogo, or are you using vi-telex.mim through ibus-m17n or ibus-typing-booster? (In reply to Mike FABIAN from comment #10) > I am still confused, are you using ibus-bogo, or are you using vi-telex.mim > through ibus-m17n or ibus-typing-booster? I am currently using ibus-bogo and ibus-unikey, not ibus-m17n or ibus-typing-booster. (In reply to Truong Anh Tuan from comment #9) > > The Fedora test case for ibus-bogo, https://fedoraproject.org/wiki/QA:Bogo, > > has: > > > > type "Khoong cos gif quis hown ddoocj laapj tuwj do". > > ... > > you will get: "Không có gì quí hơn độc lập tự do". > > This is the main/core function so this test is mandatory. > > > That looks like a transliteration which could be done easily with a m17n > > input method as well. And this test works already when using the vi-telex.mim input method via ibus-typing-booster. And it also works when using vi-telex.mim via ibus-m17n. So I wonder what additional benefit ibus-bogo really offers. Should we bother fixing ibus-bogo at all? (In reply to Mike FABIAN from comment #12) > So I wonder what additional benefit ibus-bogo really offers. Should > we bother fixing ibus-bogo at all? I had a look at the ibus-bogo source code and I think I can fix it with some effort... Unchanged in F32. Reproduced in F33. Thanks Mike for volunteering to fix this issue. I think, good to assign issue to yourself. Truong Anh Tuan already mentioned, he is only doing packaging at the moment. This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Under the discussion in GNOME-Shell upstream. This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed. Mostly seems okay in F37 anyway Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed. |