Description of problem: When running KDE imsettings seems to ignore ~/.xinputrc and always startup IM. Version-Release number of selected component (if applicable): imsettings-0.105.1-1.fc10 How reproducible: every time Steps to Reproduce: 1. login to rawhide KDE 2. run imsettings-info 3. run im-chooser and toggle IM state. 4. start a new Actual results: 1. SCIM is running (irrespective of session locale) 2. imsettings-info says "No IM running." 4. SCIM runs even if ".xinputrc -> none.conf". Expected results: 1. SCIM should only run for Asian locale 2. imsettings should reflect if SCIM is running. 4. SCIM should not run if IM is disabled.
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.