Bug 468814

Summary: immodule selection behavior is unpredictable without QT_IM_MODULE
Product: [Fedora] Fedora Reporter: Jens Petersen <petersen>
Component: qtAssignee: Than Ngo <than>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: 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 Flags
a proposal patch none

Description Jens Petersen 2008-10-28 07:16:19 UTC
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.

Comment 1 Akira TAGOH 2008-10-28 08:00:05 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?

Comment 2 Jens Petersen 2008-11-04 08:27:27 UTC
(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.

Comment 3 Jens Petersen 2008-11-05 00:50:10 UTC
*** Bug 469515 has been marked as a duplicate of this bug. ***

Comment 4 Akira TAGOH 2008-11-05 08:29:48 UTC
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.

Comment 5 Kevin Kofler 2008-11-05 08:37:32 UTC
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.

Comment 6 Akira TAGOH 2008-11-05 08:53:17 UTC
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.

Comment 7 Akira TAGOH 2008-11-05 08:57:14 UTC
FWIW case 1 in comment #4 isn't actually meaningful to confirm the fix for this bug. sorry for confusion.

Comment 8 Akira TAGOH 2008-11-05 09:27:29 UTC
Oh, wait. you're right. it's false alarm. need to investigate more.

Comment 9 Akira TAGOH 2008-11-05 10:11:40 UTC
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.

Comment 10 Denis Dzyubenko 2008-11-05 10:27:02 UTC
(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.

Comment 11 Akira TAGOH 2008-11-05 11:18:50 UTC
agreed. when no QT_IM_MODULE is set, defaulting xim sounds reasonable to me.

Comment 12 Akira TAGOH 2008-11-06 05:15:33 UTC
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.

Comment 13 Denis Dzyubenko 2008-11-06 12:21:41 UTC
(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.

Comment 14 Kevin Kofler 2008-11-06 12:32:29 UTC
I think we should ship that patch in the Fedora qt package.

Comment 15 Akira TAGOH 2008-11-06 12:34:43 UTC
agreed. it would be really nice if we can get that issue fixed in Fedora.

Comment 16 Than Ngo 2008-11-06 13:37:47 UTC
it's fixed in qt-4_4_3-2_fc10. thanks

Comment 17 Kevin Kofler 2008-11-06 13:47:10 UTC
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.)

Comment 18 Than Ngo 2008-11-06 13:53:49 UTC
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

Comment 19 Akira TAGOH 2008-11-07 09:05:51 UTC
*** Bug 470162 has been marked as a duplicate of this bug. ***

Comment 20 Jens Petersen 2008-11-09 00:22:30 UTC
qt-4.4.3-2.fc10 looks good to me.

Comment 21 Jens Petersen 2008-11-09 00:23:26 UTC
(package has been tagged f10-final now)

Comment 22 Gerald Cox 2008-11-09 16:00:08 UTC
Updated to qt-4.4.3-2.fc10 - my issue with duplicate SCIM icons has been resolved.