Bug 174142 - unable to switch input style with shortcut keys in xterm
unable to switch input style with shortcut keys in xterm
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: xterm (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
: i18n
Depends On:
Blocks: SCIM
  Show dependency treegraph
 
Reported: 2005-11-24 20:30 EST by Lawrence Lim
Modified: 2014-03-25 20:52 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-10 16:59:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Lawrence Lim 2005-11-24 20:30:03 EST
Description of problem:
Not a major issue, however, I am curious why shortcut keys, ctrl-SHIFT, does not
work in xterm. In xchat, it is fine.

Version-Release number of selected component (if applicable):
scim-1.4.2-6

How reproducible:
Always

Steps to Reproduce:
1.start xterm
2.activate scim 
3.ctrl-SHIFT to switch input style
  
Actual results:
nothing happens

Expected results:
switch to next input style

Additional info:
Comment 1 James Su 2006-01-10 23:14:33 EST
It seems that xterm doesn't send KeyRelease events to scim.
Ctrl+Shift needs KeyRelease event to work.
Comment 2 Thomas E. Dickey 2006-01-11 06:32:16 EST
The first place I'd check is whether Redhat still has the
unnecessary translations-resource modification in the
"XTerm" app-defaults file.
Comment 3 Jason Vas Dias 2006-01-11 20:22:52 EST
If you have the latest xterm-207-2.FC4, or xterm-207-8 (FC5), then the 
"unnecessary translations-resource" mentioned in Comment #2 has been 
removed. 
The ONLY resources different from the upstream xterm defaults in the 
Red Hat xterm release are :
'
*VT100*eightBitInput: 0
*VT100*backarrowKey:  0
'
Does the problem still happen with the latest Red Hat xterm releases ?
I'll investigate this issue further.
Comment 4 Jason Vas Dias 2006-01-17 15:32:44 EST
I'm not sure how to reproduce this bug .

I've run scim, and can detect no differences when running xchat or konsole
and pressing <CTRL>+<SHIFT>.

There is no man-page for scim, and I'm unsure what it is meant to do / how to
use it.

The <CTRL> and <SHIFT> keys would not normally generate key-press events by
themselves; they are only modifier keys, which would modify the key-press
event sent by pressing any non-modifier key. 

Please append details of how to reproduce this problem and what the effect of
pressing <CTRL>+<SHIFT> is meant to be - thank you.
Comment 5 Lawrence Lim 2006-01-17 20:32:05 EST
RE: Comment #4
My apologies. I think I left out the details the key sequence on activating
SCIM. Please try performing the following steps and observe the behaviour in a
GTK application.

Steps to reproduce:
1. in gdm, select 'Chinese(China Mainland)' under Language option and log in to
GNOME desktop 
2. start gedit application 
3. activate scim with 'Ctrl-SPACE'  (an auxillary window should pop up)
4. try to switch input style with 'Ctrl-SHIFT' (notice the change in wordings in
the auxillary window)

If everything goes well, the steps above will reveal the correct scenario.
Please try to reproduce on xterm and see the difference(bug). 

Hope that helps.
Comment 6 Jason Vas Dias 2006-01-19 19:28:42 EST
Unfortunately, gdm in Rawhide is broken at the moment - if I try to select 
a language, gdm then crashes and resets the xdm session.

Shouldn't scim work under KDE ? I run KDE mostly.

If scim is only meant to work for GNOME / GTK apps, then this bug should be
closed - xterm probably never will be GTK based - it uses the underlying
X libraries only.

When I run 
  # LC_ALL=zh_CN.utf8 LANG=zh_CN.utf8 gedit 
under KDE, gedit appears OK in Chinese, but then neither pressing <CTRL>+<SPACE>
nor <CTRL>+<SHIFT> have any effect - I see no 'auxilliary window' .
 
I've tried running gedit before and after running the 'scim' command from the
command line - and still I see no 'auxilliary window', nor do pressing the 
modifier keys have any effect - also, typed input appears in gedit in English
text.

I'm not sure how one is meant to map pressing two modifier keys onto any
action, since they generate no key press event without a non-modifier key
being pressed. Is some special xmodmap modifier map or keymap table meant
to be installed ?
Comment 7 Lawrence Lim 2006-01-23 01:59:50 EST
RE: Comment #6

OK. I tried to reproduce your env (KDE with en_US). :-)
Please try the following in konsole after the scim process has started. If not,
type 'scim' in konsole then:

LANG=zh_TW.UTF-8 XMODIFIERS=@im=SCIM xterm

Hope its better this time.
Comment 8 Jason Vas Dias 2006-02-10 16:59:15 EST
Thanks for the instructions .

After running SCIM setup, and running scim with 'scim &' (scim hangs in the
foreground), I was now able to get the 'auxiliary window' / IM selection panel
to pop-up when any of the xterm, gnome-terminal, or gedit programs are run 
with the variable settings:

  $ LC_ALL=zh_TW.UTF-8 LANG=zh_TW.UTF-8 XMODIFIERS='@im=SCIM' $program

where $program is xterm, gnome-terminal, or gedit.

Interestingly, no panel would pop-up when the 'zh_CN.UTF-8' LC_ALL and LANG
settings are used - I guess SCIM works only for zh_TW.UTF-8 .

For ALL the programs - xterm, gnome-terminal, or gedit - NOTHING happens 
after <CTRL>+<SHIFT> is pressed, with or without the <CTRL>+<SPACE> scim panel 
popped up; this is to be expected, as <CTRL> and <SHIFT> are MODIFIER keys,
and generate no key press or release events by themselves - some other 
non-modifier key has to be pressed. 

Hence, this is NOTABUG, as all applications when run with the SCIM input 
method do nothing in response to the <CTRL>+<SHIFT> keys only. 

Note You need to log in before you can comment on or make changes to this bug.