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

Philip Amadeo Saeli <[email protected]> :

> 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   <[email protected]>   http://www.suse.de/~mfabian


-- 
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]