*** This bug has been marked as a duplicate of 117120 ***

Reopening initial bug report to keep one of the dupes open. :-)

how do you switch between korean and native keyboard? 
 
 

First of all (just to avoid possible misunderstandings), there is no
Korean keyboard layout in X11 yet (see bug #87443). This is no big
problem because the Korean keyboard layout is almost identical with
the US layout anyway, except from a few extra keys.

To input Korean, one needs to use an input method.

Question to the original reporter:

Ulrich, what input method do you use for Korean?

By default we install scim and scim-hangul so I guess that you
are using this. But please confirm.

First of all, sorry for many doubles. The internet session hung and got a time
out. Can someone delete this rubbish?

To the facts. After installation second language there is a keyboard icon in
systray from KDE. Click on it and Korean -> 2bul than you can write Korean. Lock
the session over K Menu and enter your password. That´s it.

#4 That´s right. To write Korean the system changed to US-keyboard. It´s a
little bit fanny to write Korean with US-keyboard set on a German keyboard but
I've tested it also with a Korean keyboard (US-based). Only the Won character is
not working.

Ulrich> First of all, sorry for many doubles. The internet session hung and
Ulrich> got a time out.

I had the same problem once when the network connection failed.

Ulrich>  After installation second language there is a keyboard icon in
Ulrich>  systray from KDE.

That icon is "skim", the KDE frontend for "scim".  "scim" ("simple
common input method") is a powerful input system which supports many
languages.

Ulrich>  Click on it and Korean -> 2bul than you can write
Ulrich>  Korean.

This input method is offered by "scim-hangul".

Now, when you select "Korean -> 2bul" in scim, the skim icon in the
kde kicker changes: Now it shows a Korean hangul character instead of
the keyboard icon which was there before.

This "Hangul" icon indicates that the input method is active, i.e.  if
you type somewhere now, you will type Korean.

To switch back to direct keyboard input you can click on the icon and
select "keyboard", which is probably what you did.  But I guess you
don't know yet that there are also keybindings to switch between your
selected input method and direct keyboard input.

By default, both "Shift+Space" and "Control+Space" are used as
"Trigger"-keys to switch the input method on or off (You can
change that in the skim setup if you like).

Try typing "Shift+Space" and watch the skim icon in the KDE taskbar,
you see that it toggles between the keyboard icon and the icon of the
selected input method (the hangul character in your case).

When you lock the screen while in Korean input mode, you are still in
Korean input mode when you try to unlock the screen.

As you cannot see what you are typing in the widget because of safety
reasons (your password should not be visible for others) and cannot
see the KDE taskbar anymore, you can be easily confused because you
don't know whether you are still in Korean input mode or not.

But as soon as you realize that it doesn't work because you are still
in Korean mode, the solution is easy: just use the trigger key
"Shift+Space" to switch back to direct keyboard input, then you can
log in again.

This problem is a little bit similar to the problem when CapsLock is
on while you try to log in. If CapsLock is on without the user
noticing it, logging in will usually not work. Because of this
problem, the login dialog shows a big red warning when CapsLock is on.

Unfortunately for the input methods, no such warning is shown and as
you cannot see the KDE desktop you can not see the icon in the KDE
taskbar and don't know whether you are in Korean mode or not.

So this is very confusing.

The above explanation should help you to avoid having to power off
your computer, just try to switch between the input modes with the
trigger keys.

But of course this has to be fixed as the current situation is far too
confusing.

I think the easiest solution is probably to disable the input methods
for the KDE screen lock program. One only needs to enter a password
there, nothing else. Therefore I can see no reason why somebody should
want to enter Korean, Japanese, Chinese, or something like that there.

Korean passwords are probably not very practical ☺

ok, understand much better. I agree, we should probably disable the input 
methods or at least make them visibile for the user.  
 
 

Disabling is better.  IM in the password input is useless and/or bad on security.

So now the question is how to disable it.  I'm currently searching
for the easiest way to do it ...

When starting the screen lock from the command line one can easily disable
the input methods by

   XMODIFIERS=@im=local QT_IM_MODULE=xim kdesktop_lock --forcelock

(Compose is still enabled than but that's all).

Checking whether something similar can be done in the source code of
kdesktop_lock ...

#8 I didn´t know that`s working with password as well but I tested it and it´s
working well. But it´s better to switch automaticly into the base language in
which the password was set. If this is possible it would be great, helpful and
plausible.

I think the best way to fix this issue is to patch KDE/QT and GTK/GNOME to force
disable using input method when do password inputing.

Zhe Su> I think the best way to fix this issue is to patch KDE/QT and
Zhe Su> GTK/GNOME to force disable using input method when do password
Zhe Su> inputing.

Yes, that would be the best. Any idea how to do that for *all*
places in KDE where passwords are asked?

For example, when you start YaST2 from the KDE menu, you are also
asked for a password (kdesu is used here).  In that case as well,
input methods are useless. It is not as bad as when locking the screen
because when using kdesu you still see your desktop and therefore you
can still see whether the input method is on or off.

But as the input method is useless here as well, it would be nice to
disable it automatically.

I could hack something like comment #15 into kdesktop_lock.

Is there a better solution? Is it necessary to implement it in every
program which asks passwords separately or is there a general
solution?

Possible to control this by the value KLineEdit::setEchoMode()?
For example, with NoEcho or passwd, it disables IM automatically.

Yes, I'm just thinking about this solution. We could do it in gtk(GtkEntry) as well.

I could try to hack gtk to support it first.

I just wonder, whether it's reasonable that some users want to use input method
when the LineEdit is in non-echo mode?

Created attachment 50156 [details]
A demo patch for gtk 2.8.2 to realize the behaviour.

This patch will bypass input method if gtk_entry is in invisible mode.

User may be confused when he want to activate/deactive input method in such
situation.

Thank you!

I'm adding gnome-maintainers@suse.de to the CC: to evaluate
Zhe Su's patch from comment #21 and add it if possible.

Created attachment 50175 [details]
Patch for qt3 to realize the same behaviour.

This patch is fairly simple :-)

Great Zhe! I tried the qt3 patch and it works well.

Your patch disables the input methods for both "NoEcho" and "Password"
mode. That's OK in my opinion, I don't think using input methods in
non-echo mode makes sense as it will be quite difficult to use.  Most
input methods are difficult to use if one cannot see the preedit
string, e.g. scim-anthy is very difficult to use without being able to
see the preedit string. Therefore I think your patch is perfect as is.

qt3 package with Zhe's patch submitted to STABLE.

Add Andreas Jaeger <aj@suse.de> to CC:.

Andreas, is it OK to fix this for 10.0 as well?

Zhe's patch is a simple, obvious one-liner. And without that it is
really confusing for users if they lock the screen and have an input
method activated.

CC'ing rodrigo to fix with gnome-screensaver.

  	 Maintenance-Tracker-2335.

Mike, could you take care to make *one* update with both qt3 and gnome-screensaver.

trying to submit this patch upstream.. 
 

we probably have a few more bits to fix in qt3 though.. can we collect them 
together with this update? 
 

Dirk> trying to submit this patch upstream..

Thank you! Probably also necessary for Qt4.

Dirk> we probably have a few more bits to fix in qt3 though.. can we
Dirk> collect them together with this update?

I think that is OK. But can you do this and still fulfil Andreas' request
in comment #28?

Let's do two updates if it's needed...

Ok, to add further critical fixes.

Created attachment 50420 [details]
A better patch for gtk2.

Misread the first time, federico, could you review the gtk2 patch?

The patch makes sense - it doesn't make sense to have input methods on entries
with invisible text, since you need to be able to see the intermediate states.

Zhe, can you please submit this upstream?  I'm not very familiar with the
interactions between GtkEntry and input methods, but the patch looks sane.

[Why is this not a problem in GDM?  Is it because it starts up with a different
input method?]

I found that this patch still has some issues. scim doesn't work very well with
this patch. I'll try to fix it as soon as possible and submit it upstream.

Created attachment 50547 [details]
It should be the final patch for gtk2.

Please help test it. If it's ok then I'll try to submit it upstream.

Federico> [Why is this not a problem in GDM?  Is it because it starts
Federico> up with a different input method?]

Actually it *is* a problem in GDM as well.  I'll attach a screen shot.

Created attachment 50636 [details]
gdm.png

gdm during password input on SuSE 10.0 RC4 (Japanese installation).

As you can see, the input method can be activated (using the
trigger-key Shift+Space).

In that mode you will not be able to enter your password.

But it is not as bad as in the screen locker of KDE because in case of
gdm you can see that the input method has been activated, the scim
panel is clearly visible at the bottom right. In case of the KDE
screen locker it could not be seen because it was displayed on the KDE
desktop which was still hidden by the screen locker.

I have tested Zhe Su's patch from comment #38.

It fixes the problem with gdm which I described in comment #40.  The
input method cannot be enabled any more while typing the password.

And I could not find any problems so far.

Yeah, if it works for you (I have no experience with input methods at all),
please submit it to upstream.  If you file it on bugzilla.gnome.org, can you
please CC me on the bug?  My account there is federico@ximian.com.

I encountered a very strange issue with a JAVA SWT gtk2 application. In this
application, filter_keypress handler of immodule will be called directly.
gtk_entry_key_press and gtk_entry_key_release won't be called. Then with my
patch, user won't be able to input anything if the entry is in visible mode,
because gtk_entry_commit_cb will be disabled if entry is invisible.

Created attachment 51106 [details]
A new patch for gtk2.

It's another approach to fix this issue. This patch could avoid the
incompatibility issue of some Java SWT apps. However it doesn't prevent users
from using dead keys and compose keys in password.

Dirk> we probably have a few more bits to fix in qt3 though.. can we collect them 
Dirk> together with this update? 

Dirk, is the update for qt3 including this fix planned soon?

Could you please merge the patch in attachment #51106 [details] into our gtk2 package?

ok, this got a bit out of hand. Zhe Su: please file bug reports for what's missing in Code10 and close this one then. Thanks

New bug filed, #148327
Closing this bug as fixed.

REOPEN. This bug is back in STABLE.
I can again activate the input method in kdesktop_lock.

Reassigned to kde-maintainers@suse.de.

Zhe Su's patch attached to Comment #23 (attachment (id=50175))

is included in qt-x11-immodule-unified-qt3.3.8-20060318.diff which is currently
used in our qt3 package in STABLE.

It's strange why the problem has reappeared nevertheless.

do we know which change caused it ? is there an opensuse alpha which still worked?

please at least change products if a problem reappears

The /usr/lib/qt3/doc/examples/lineedits/lineedits example program has
a combo-box

     Normal
     Password
     No Echo

When testing with lineedits, it works as expected, input methods can
only be activated when the mode is "Normal". I.e. Zhe Su's patch still
works correctly in this simple Qt3 test program.

I just tested on openSUSE 10.2 again. On openSUSE 10.2, this problem
does not occur.

The same problem is also reproducible with kdesu: on openSUSE 10.2,
one cannot activate the input method in the password input field, on
STABLE/Factory, one *can* activate the input method in the password
input field.

What's this?:

KPasswordEdit::KPasswordEdit(QWidget *parent, const char *name)
    : QLineEdit(parent, name)
{
    init();

    KConfig* const cfg = KGlobal::config();
    KConfigGroupSaver saver(cfg, "Passwords");

    const QString val = cfg->readEntry("EchoMode", "OneStar");
    if (val == "ThreeStars")
	m_EchoMode = ThreeStars;
    else if (val == "NoEcho")
	m_EchoMode = NoEcho;
    else
	m_EchoMode = OneStar;

    setInputMethodEnabled( true );         ←←←←←←←←←←
}

kdelibs-3.5.6/kdeui/kpassdlg.cpp line 121.

In the openSUSE 10.2 version of the same code, the
"setInputMethodEnabled( true );" was missing, otherwise the code is
identical.

Mike: thanks for looking into it. from the commit log: 

------------------------------------------------------------------------
r616816 | aacid | 2006-12-27 00:04:33 +0100 (Wed, 27 Dec 2006) | 2 lines
Changed paths:
   M /branches/KDE/3.5/kdelibs/kdeui/kpassdlg.cpp

i need this so that ` + a gets composed to à

------------------------------------------------------------------------
Index: kpassdlg.cpp
===================================================================
--- kpassdlg.cpp        (revision 616815)
+++ kpassdlg.cpp        (revision 616816)
@@ -118,6 +118,7 @@ KPasswordEdit::KPasswordEdit(QWidget *pa
     else
        m_EchoMode = OneStar;

+    setInputMethodEnabled( true );
 }

 KPasswordEdit::KPasswordEdit(QWidget *parent, const char *name, int echoMode)

A related bug for Firefox is bug #161031. In Firefox, it also causes
problems when the input method is enabled on password input fields.

I don't think it is a good idea to use non-ASCII passwords anyway.
Using something like 'à' in a password seems to be possible in several
applications (login on Linux console, su, ssh, ...) when it is done in
the same locale as the password was originally created. But although
this is possible, it will cause problems when trying to login from a
terminal which runs in a different locale, when one is at the computer
of a friend which has a different keyboard, ...

Therefore I think one should not use non-ASCII passwords, at least not
until *everybody* uses UTF-8 *everywhere*.

dropped a mail to Trolltech. I've heared that it could be possible to distinguish between input methods and dead letter composing

Dirk> I've heared that it could be possible to
Dirk> distinguish between input methods and dead letter composing

I think that will be very difficult. Especially the case when the dead
key support is coming from an input method like scim or uim.

If no input method like scim or uim is installed, the dead key support
comes from X11. It is related to the Compose mechanism, the key
combinations for the dead keys are also in
/usr/share/X11/locale/en_US.UTF-8/Compose (search for "dead" in that file).

Some years ago, all XIM servers always made using the Compose support
impossible.  For example, if you were using the Japanese XIM server
"kinput2", you could not use Compose anymore. That is because the
Compose support is an XIM and kinput2 is another one.
To use Compose you set XMODIFIERS=@im=local, to use kinput2 you set
XMODIFIERS=@im=kinput2. But you can choose only one XIM mechanism.

scim and uim solved that problem by featuring their own, builtin
Compose support. I.e. if you use XMODIFIERS=@im=SCIM (or the qt module
QT_IM_MODULE=scim), your dead key and compose support comes from scim,
not from X11. For the user that makes no difference, the dead keys
behave the same whether they are interpreted by X11 or by scim.

But for the software, this will probably be very hard to distinguish.

For example, let's assume that scim is installed. Then the environment
variables

    XMODIFIERS=@im=SCIM
    QT_IM_MODULE=scim

will be set by default. This disables the Compose support in X11.
Therefore, even if it turns out to be possible to distinguish the X11
Compose-/dead key-support of X11 in a Qt password input widget from
something like scim, it won't really help that much. Because, if you
disable scim you will also disable the dead key support build into
scim.

Maybe the following would work:

Instead of disabling the input methods altogether in a password field, one could
force the use of a input method which behaves similar to Compose/Deadkeys and
is always available.

qt3 comes with the libqsimple input module

mfabian@magellan:~$ rpm -ql qt3 | grep input 
/usr/lib/qt3/plugins/inputmethods
/usr/lib/qt3/plugins/inputmethods/libqimsw-multi.lib64.so
/usr/lib/qt3/plugins/inputmethods/libqimsw-none.lib64.so
/usr/lib/qt3/plugins/inputmethods/libqsimple.lib64.so
/usr/lib/qt3/plugins/inputmethods/libqxim.lib64.so
mfabian@magellan:~$ 

which is a compose-like input method, very similar (but not identical)
to the Compose support in X11.

Qt can switch at runtime between input methods, therefore it is
should be possible to remember which input method was set before
starting the password widget, set the input method to the simple
compose input method while using the password widget and then switch
back to the previous input method.

That would disable complicated input (like Chinese, Japanese, ...) in
password widgets but still support compose.

Slight disadvantage is that the compose support is hardcoded in qt
(see the table in the qt-x11-immodule-unified-qt3.3.8-20060318.diff
patch).  It is certainly based on the key combinations used by X11
(SCIM also copied these for its built in compose support) but might
not be exactly the same anymore because some keybindings have been
changed in the X11 compose support and this might not have been synced
again.

task tracker is broken right now, but I heared it is tracked upstream here: 

http://www.trolltech.com/developer/task-tracker/index_html?id=163483&method=entry

Unfortunately this problem has not been fixed before the release of
openSUSE 10.3 and now I have already received a report by a openSUSE
10.3 user who ran into that problem.

Can we please remove

    setInputMethodEnabled( true );

mentioned in comment #57 from KPasswordEdit and release that as
an online update for openSUSE 10.3?

This is a really nasty problem if input methods are used, apparently
most users cannot find the solution and can only reboot when this
happens.

Using accented characters in passwords is silly anyway in my opinion,
doing this today is just asking for trouble.

I've added it to the 10.3 patch queue. 

released:
Bugzilla #117115 - [Fix_is_Ready:10.3] enter password after session lock not in basic language
Bugzilla #308196 - [Fix_is_Ready:10.3] KDE3: get password request for encrypted home-partition
Bugzilla #310769 - [Fix_is_Ready:10.3]blank screen instead of screensaver, no password protection
Bugzilla #331870 - [Fix_is_Ready:10.3,10.2]Screensaver not covering whole screen with Compiz
Bugzilla #332079 - [Fix_is_Ready:10.3]Cannot select Compiz in KControl
Bugzilla #334528 - [Fix_is_Ready:10.3] konquerer text search recounts hits
Bugzilla #334965 - [Fix_is_Ready:10.3]Konqueror not generated preview of black and white photos
Bugzilla #336627 - [Fix_is_Ready:10.3]KDED crash at logout because of nfs
Bugzilla #3377024 - No summary found
Bugzilla #344625 - [Fix_is_Ready:10.3] konqueror doesn't display https connections as such