scim-tomoe: can't input recognized characters! (KDE)

newer
XIM and SCIM problems on SuSE 10.1

Philip Amadeo Saeli

29 Aug 2006 29 Aug '06

03:15

Hi, I'm running stock SL-10.1 patched with all relevant security and recommended patches. The default locale is en_US.UTF-8. I started a konsole in the zh_TW.UTF-8 locale so I could input some Chinese characters. When I attempted to use the "Handwriting recognition" feature of scim (scim-tomoe) to input a charater for which I did not know the reading, I was not able to get the character from the Handwriting pad into the target application (KDE konsole). Clicking on the character did nothing, nor was there anything else I could find to input the character (i.e., there was no right-click menu, it was not copied into the clipboard, etc). Another issue: I was able to close the tomoe window by clicking the tomoe icon on the scim toolbar. However, I've been unable to open it back up again since the scim toolbar disappears whenever the mouse cursor leaves the Chinese konsole. I was able to close the tomoe window because the scim toolbar became visible and remained so after clicking on the selected character in the tomoe window. Also, selecting "Handwriting recognition" in the skim menu did not open the tomoe window once it had been hidden via the scim toolbar. I started the Chinese console thusly: (LC_CTYPE=zh_TW.UTF-8 XMODIFIERS=@im=SCIM konsole) & So, my main questions are: 1. How to get recognized characters from the tomoe window into the application? 2. How to click something on the scim toolbar when it disappears whenever I leave the application window from which it had been started? BTW, I found a web page which had a little info on it (http://www.h4.dion.ne.jp/~apricots/scim-anthy/howto.html), but I could find no other relevant documentation on this topic. Any help would be appreciated! Phil -- Philip Amadeo Saeli SUSE Linux 10.1 psaeli@zorodyne.com

Show replies by date

Mike FABIAN

29 Aug 29 Aug

05:40

New subject: [m17n] scim-tomoe: can't input recognized characters! (KDE)

Philip Amadeo Saeli さんは書きました:

...

I'm running stock SL-10.1 patched with all relevant security and recommended patches. The default locale is en_US.UTF-8.

I started a konsole in the zh_TW.UTF-8 locale so I could input some Chinese characters.

You don't need to use zh_TW.UTF-8 locale to enable input of Chinese, scim works in en_US.UTF-8 as well.

...

When I attempted to use the "Handwriting recognition" feature of scim (scim-tomoe) to input a charater for which I did not know the reading, I was not able to get the character from the Handwriting pad into the target application (KDE konsole). Clicking on the character did nothing, nor was there anything else I could find to input the character (i.e., there was no right-click menu, it was not copied into the clipboard, etc).

Below the area where you draw the character, there is a line which shows the matched characters. Click on one of these characters with the left mouse button and it will be inserted into the application. -- Mike FABIAN http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

Mike FABIAN

30 Aug 30 Aug

09:45

New subject: [m17n] scim-tomoe: can't input recognized characters! (KDE)

Philip Amadeo Saeli さんは書きました:

...

Another issue: I was able to close the tomoe window by clicking the tomoe icon on the scim toolbar. However, I've been unable to open it back up again since the scim toolbar disappears whenever the mouse cursor leaves the Chinese konsole.

Looks like you are using "focus follows mouse". I used to like "focus follows mouse" as well but scim was the reason that I switched to using "click to focus". Unfortunately it is difficult to reach the scim panel when using "focus follow mouse", as soon as the mouse hovers over a window where no input is possible, for example the background picture of the KDE desktop, the panel disappears. The only workarounds I know are: - move the mouse over other windows which use scim to the panel without travelling over the desktop background. - if that is not possible, move the current window close to the panel first so that the panel can be reached without having to move the mouse over the desktop background. Then move the window back. That's not convenient, therefore I switched to using "click to focus". -- Mike FABIAN http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

Philip Amadeo Saeli

1 Sep 1 Sep

05:00

New subject: [m17n] scim-tomoe: can't input recognized characters! (KDE)

Thanks, Mike, for the very helpful replies. They gave me exactly what I needed to understand my problem. I've added some additional comments below your responses based on my findings which may be helpful to others like myself from the Jurassic age who are attempting to configure SCIM on a desktop with may legacy settings. * Mike FABIAN [2006-08-29 03:41]:

...

Philip Amadeo Saeli さんは書きました:

...
I'm running stock SL-10.1 patched with all relevant security and recommended patches. The default locale is en_US.UTF-8.

I started a konsole in the zh_TW.UTF-8 locale so I could input some Chinese characters.

You don't need to use zh_TW.UTF-8 locale to enable input of Chinese, scim works in en_US.UTF-8 as well.

Great! This simplifies things quite a bit. I believe the main reason I was doing this was so I could have both SCIM input as well as Compose key input since SCIM seemed to break the Compose key in earlier releases (my most recent being SL-9.2). I also had to set the XMODIFIERS env var accordingly to either "@im=SCIM" or "@im=local", of course. Both SCIM input -and- the Compose key now work in SL-10.1 with the same configuration in the en_US.UTF-8 locale. Yessss!

...

...
When I attempted to use the "Handwriting recognition" feature of scim (scim-tomoe) to input a charater for which I did not know the reading, I was not able to get the character from the Handwriting pad into the target application (KDE konsole). Clicking on the character did nothing, nor was there anything else I could find to input the character (i.e., there was no right-click menu, it was not copied into the clipboard, etc).

Below the area where you draw the character, there is a line which shows the matched characters. Click on one of these characters with the left mouse button and it will be inserted into the application.

I'd tried that but wasn't getting the char I'd clicked on in the application. This is affected by the mouse focus policy (see below). * Mike FABIAN [2006-08-30 07:45]:

...

Philip Amadeo Saeli さんは書きました:

...
Another issue: I was able to close the tomoe window by clicking the tomoe icon on the scim toolbar. However, I've been unable to open it back up again since the scim toolbar disappears whenever the mouse cursor leaves the Chinese konsole.

Looks like you are using "focus follows mouse".

I used to like "focus follows mouse" as well but scim was the reason that I switched to using "click to focus".

Unfortunately it is difficult to reach the scim panel when using "focus follow mouse", as soon as the mouse hovers over a window where no input is possible, for example the background picture of the KDE desktop, the panel disappears.

The only workarounds I know are:

- move the mouse over other windows which use scim to the panel without travelling over the desktop background.

- if that is not possible, move the current window close to the panel first so that the panel can be reached without having to move the mouse over the desktop background. Then move the window back.

That's not convenient, therefore I switched to using "click to focus".

Yup, this is a key issue! Actually, I've been using "focus strictly under mouse" since it is the closest to what I've become used to from very early windowing systems (remember SunTools, SunWindows, or SunView?). I've resisted using "click to focus" because it is slower and more tedious for me to use, though there are still apps or panes within apps that still insist on being clicked to receive the focus. One of my biggest beefs with "focus follows mouse" has been that popups tend to steal the focus and I may end up, e.g., inadvertantly clicking on a popup I really didn't want to click on. It seems that "focus stealing prevention" settings may help prevent that, though (I just learned about this). I did some testing on a default KDE configuration (I created a new account on my system) to see if I could find an acceptable compromise. Here are some observations: - The SCIM main toolbar can be made to work even with "focus strictly under mouse" focus policy iff the SCIM toolbar is docked in the kicker. Use either the "Toggle Docking" menu selection on the SCIM toolbar itself or set it via the "Configure SKIM" -> "Panel" -> "Main Toolbar" -> "Main Toolbar Display Mode" selector from "Stand Alone" (default) to "Embedded" (i.e., in the kicker). - The tomoe "Handwriting recognition" tool and the "Input Pad" both -require- a mouse focus policy -other- than "focus strictly under mouse". If that policy is used, apparently the input of the tool is directed to the tool itself (since it has the mouse focus!) and not the app. All three of the other mouse focus policies worked in my tests. After researching things and making some tests, I've decided to try using the "focus follows mouse" focus policy combined with a "high" or "normal" focus stealing prevention level combined with a docked SCIM main toolbar. Not sure I'm ready for "click to focus" just yet... Phil -- Philip Amadeo Saeli SUSE Linux 10.1 psaeli@zorodyne.com

Mike FABIAN

16:13

New subject: [m17n] scim-tomoe: can't input recognized characters! (KDE)

Philip Amadeo Saeli さんは書きました:

...

Great! This simplifies things quite a bit. I believe the main reason I was doing this was so I could have both SCIM input as well as Compose key input since SCIM seemed to break the Compose key in earlier releases (my most recent being SL-9.2). I also had to set the XMODIFIERS env var accordingly to either "@im=SCIM" or "@im=local", of course.

All input methods using XIM make it impossible to use the Compose mechanism in X11. This includes SCIM. In order to be still able to use Compose, recent versions of SCIM have their own Compose support included. I.e. when using Compose with XMODIFIERS=@im=SCIM your are using the Compose support built into SCIM. But as it behaves the same way as the Compose mechanism in X11 it is hard to tell the difference. (Actually there is a small difference: The Compose mechanism in X11 reads the conversion table from the file /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose (when running in en_US.UTF-8 locale). And you may have your own Compose file in ~/.XCompose. If ~/.XCompose exists, it is used instead of /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose. I.e. with the Compose support in X11 it is rather easy to edit the Compose table if you want to make some personal changes. With the Compose support in SCIM this is not that easy because the table is hardcoded in SCIM. The table hardcoded into SCIM was taken from the default contents of /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose, i.e. unless you edit this file or create your own ~/.XCompose file, you will not be able to tell the difference.

...

Both SCIM input -and- the Compose key now work in SL-10.1 with the same configuration in the en_US.UTF-8 locale. Yessss!

[...]

...

...
Below the area where you draw the character, there is a line which shows the matched characters. Click on one of these characters with the left mouse button and it will be inserted into the application.

I'd tried that but wasn't getting the char I'd clicked on in the application. This is affected by the mouse focus policy (see below).

[...]

...

I did some testing on a default KDE configuration (I created a new account on my system) to see if I could find an acceptable compromise. Here are some observations:

- The SCIM main toolbar can be made to work even with "focus strictly under mouse" focus policy iff the SCIM toolbar is docked in the kicker. Use either the "Toggle Docking" menu selection on the SCIM toolbar itself or set it via the "Configure SKIM" -> "Panel" -> "Main Toolbar" -> "Main Toolbar Display Mode" selector from "Stand Alone" (default) to "Embedded" (i.e., in the kicker).

- The tomoe "Handwriting recognition" tool and the "Input Pad" both -require- a mouse focus policy -other- than "focus strictly under mouse". If that policy is used, apparently the input of the tool is directed to the tool itself (since it has the mouse focus!) and not the app.

The tool itself never gets the mouse focus but usually some other window does when using "focus strictly under mouse". Usually it is the desktop background window.

...

All three of the other mouse focus policies worked in my tests.

The problem is basically the same with all variants of "focus follows mouse": The window which last had the focus before the tomoe window was reached gets the input. With "focus strictly under mouse" this is often the desktop background and the input is lost. With "focus follows mouse", the desktop background will not get focus, i.e. you will not run into that problem. But you might still travel over another window while moving the mouse pointer to the tomoe window and that window may get focus (for example another konsole window). Then this other console window which has the focus now will receive the input from tomoe which might not be what the user intended.

...

After researching things and making some tests, I've decided to try using the "focus follows mouse" focus policy combined with a "high" or "normal" focus stealing prevention level combined with a docked SCIM main toolbar. Not sure I'm ready for "click to focus" just yet...

-- Mike FABIAN http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

6454

Age (days ago)

6457

Last active (days ago)

List overview

Download

4 comments

2 participants

participants (2)

Mike FABIAN
Philip Amadeo Saeli