Hide Forgot
Description of problem: While inputting Hangul (Korean alphabet) with ibus, curor does't move. Version-Release number of selected component (if applicable): 3.3.0-8.2.fc14.x86_64 How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: ibus-1.3.7-5.fc14.x86_64 ibus-hangul-1.3.0.20100329-3.fc14.x86_64
I think I see it, but maybe what I wrote just weren't allowed IM sequences... Can you give us a sample sequence and the Hangul characters it should turn into?
Steps to Reproduce: 1. start openoffice and start hangul input 2. type akakak with hangul input method (ibus-hangul) Actual results: 마 Expected results: 마마마
So, in GtkSalFrame::IMHandler::signalIMCommit we have pThis->m_aInputEvent.mpTextAttr = 0; and some 20 lines below a condition that tests for pThis->m_aInputEvent.mpTextAttr != 0 .-)
will be fixed in >=3.3.0-11.2.fc14
openoffice.org-3.3.0-12.1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/openoffice.org-3.3.0-12.1.fc14
openoffice.org-3.3.0-12.1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update openoffice.org'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/openoffice.org-3.3.0-12.1.fc14
openoffice.org-3.3.0-13.3.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/openoffice.org-3.3.0-13.3.fc14
Fixed! thanks.
openoffice.org-3.3.0-13.3.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.