Bug 468814
Summary: | immodule selection behavior is unpredictable without QT_IM_MODULE | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jens Petersen <petersen> | ||||
Component: | qt | Assignee: | Than Ngo <than> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | denis.dzyubenko, gbcox, i18n-bugs, kevin, pnemade, rdieter, tagoh, than | ||||
Target Milestone: | --- | Keywords: | Reopened | ||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2008-11-10 09:44:27 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 438943, 457626 | ||||||
Attachments: |
|
Description
Jens Petersen
2008-10-28 07:16:19 UTC
to clarify the issue, does scim work on apps? if not, it has been filed as another bug. see Bug#457626. if yes, does modifying QT_IM_MODULE=xim in none.conf help you? (In reply to comment #1) > to clarify the issue, does scim work on apps? Ah no, not in locale where it should not be running by default. It seems qt now ignores QT_IM_MODULE so reassigning to qt. *** Bug 469515 has been marked as a duplicate of this bug. *** Created attachment 322539 [details]
a proposal patch
Tested an attached patch with the follow:
1. run kwrite with QT_IM_MODULE= XMODIFIERS=@im=none
2. run kwrite with QT_IM_MODULE=scim-bridge XMODIFIERS=@im=none
3. run kwrite with QT_IM_MODULE=xim XMODIFIERS=@im=none
4. run kwrite with QT_IM_MODULE=xim XMODIFIERS=@im=SCIM
the behavior of 1 is unpredictable though, it seems Qt uses xim and no IM works as expected. 2, 3 and 4 works as expected. particularly in 2, the candidate window exactly follows current position to appear, which is impossible with XIM.
I don't see how that patch helps, it only changes the fallback if QT_IM_MODULE is not set, it doesn't change anything at all if QT_IM_MODULE is set. So it looks clearly wrong to me. No, in current code, it's set the value to QSettings with the different namespace. so what Qt widgets is supposed to read immodule setting wasn't what people expected with QT_IM_MODULE to use. FWIW case 1 in comment #4 isn't actually meaningful to confirm the fix for this bug. sorry for confusion. Oh, wait. you're right. it's false alarm. need to investigate more. I was a bit confused. well, the patch itself isn't wrong since Qt selected xim without QT_IM_MODULE on even Qt3 with immodule patch, also it looks like it's supposed to work so. in the latest tree, imsettings is set an empty to QT_IM_MODULE when IM is disabled so that it was predictable. but it seems not. so I'd say it's still worth fixing Qt for the default behavior. As I've tested some cases, it looks good when explicitly set QT_IM_MODULE such as: 1. only install scim-bridge-qt and run qt apps with QT_IM_MODULE=scim-bridge. 2. install uim-qt too and run qt apps with QT_IM_MODULE=scim-bridge and QT_IM_MODULE=uim. So updating the summary. (In reply to comment #4) > Created an attachment (id=322539) [details] > a proposal patch Yep. Similar patch has already been applied to qt-4.5. See task http://trolltech.com/developer/task-tracker/index_html?method=entry&id=207426 > Tested an attached patch with the follow: > > 1. run kwrite with QT_IM_MODULE= XMODIFIERS=@im=none > > the behavior of 1 is unpredictable though, it seems Qt uses xim and no IM works > as expected. I am not sure I can see the problem - what do you think should be the expected behavior in this case? As for me falling back to xim make sense for me - in this case complex input methods (like SCIM) won't be used but Compose key will still work. agreed. when no QT_IM_MODULE is set, defaulting xim sounds reasonable to me. Qt/KDE guru, is this the expected behavior? # ps -efww | grep qt tagoh 28361 28219 9 13:45 pts/5 00:00:00 qtconfig-qt4 # lsof -p 28361 | grep inputmethods qtconfig- 28361 tagoh mem REG 253,0 20924 819236 /usr/lib/qt4/plugins/inputmethods/libqimsw-multi.so qtconfig- 28361 tagoh mem REG 253,0 106884 823166 /usr/lib/qt4/plugins/inputmethods/im-scim-bridge.so qtconfig- 28361 tagoh mem REG 253,0 81208 823928 /usr/lib/qt4/plugins/inputmethods/libibus.so qtconfig- 28361 tagoh mem REG 253,0 144476 822392 /usr/lib/qt4/plugins/inputmethods/libuiminputcontextplugin.so QT_IM_MODULE has ibus at this moment. I expected to see libqimsw-multi.so and libibus.so only there though. that might explains why we will see multiple scim instance and scim process even though it's not a default IM. (In reply to comment #12) > QT_IM_MODULE has ibus at this moment. I expected to see libqimsw-multi.so and > libibus.so only there though. that might explains why we will see multiple scim > instance and scim process even though it's not a default IM. ah, you are right. Yesterday I've got a link describing this problem with a patch to solve it: https://bugzilla.novell.com/show_bug.cgi?id=398526#c5 Hopefully, this should be fixed for Qt 4.5. I think we should ship that patch in the Fedora qt package. agreed. it would be really nice if we can get that issue fixed in Fedora. it's fixed in qt-4_4_3-2_fc10. thanks Always the usual: it should only be closed if it gets tagged f10-final. Moreover, I think we should also push at least a F9 update. (Not sure about F8.) as i know the problem does not show up in F8, so it doesn't make sense to push a F8 update. We will do for F9-update too *** Bug 470162 has been marked as a duplicate of this bug. *** qt-4.4.3-2.fc10 looks good to me. (package has been tagged f10-final now) Updated to qt-4.4.3-2.fc10 - my issue with duplicate SCIM icons has been resolved. |