Philip Amadeo Saeli <psaeli@zorodyne.com> さんは書きました:
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 <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。