[openi18n-im:01134] Re: iiimcf/iiimgcf/compose keys

Hideki Hiura <[email protected]>
Newsgroups gmane.comp.internationalization.input-methods
Message-ID <[email protected]>
> From: Jens Petersen <[email protected]>
> Yup, I think the simplest UI is if toggling just takes one back to
> the previous LE used where the current "off state" (direct input) would
> also counts as an LE (or at least that is how it should look and feel
> for users).

Sounds like a good model!

> On the other hand since European input already works without an IM
> for people with a European/International keyboard it seems kind of
> a waste to reimplement all the deadkey stuff in im-sdk again? I think
> people would expect it to "just work" when iiimf is off.

You are right. Due to this, the deadkey stuff became a bit tricky.
The platforms like X which already have all of those already enabled in
the below IM layer, the user's expectation must be it should work even
when IM does not exist.

On the other platforms, if you remember how it was like in the earlier
versions of Xlib (Before the integration of Xlib-XI18N...pre-XFree86
4.0?) to switch localIM and remoteIM, it is obviously better that if 
things are handled in the integrated fashon.

Also, regarding wastefulness, yes, duplicate implementation is wasteful,
but since we've reimplemented already a while ago, so wastefulness 
happpened in the past, so hopefully we get return soon after a little
bug fixes.:-). 

> A few comments about the current Latin (European) support in unitLE:
> 
> 1) Currently it only seems possible to input non-ascii chars with
> European keyboard layout (ie using deadkeys) AFAICT.  [Can someone explain
> the latin.utf content to me?]  There really needs to be an LE allowing
> input of European characters without deadkeys (a la Emacs quail).
> As it is now Latin LE is pretty useless if there are no deadkeys bound.

When we dropped old Xlib's Compose IM, we created exactly compatible 
composition rules(but there was a bug on the table which was recently fixed)
exactly the same key bindings defined in the Compose file of current Xlib
work in UNIT as well, which are

     <Compose key> + <composition sequence>
     <alternate compose key sequence> + <composition sequence>

in addition to the deadkey.

BTW, <Ctrl><Shift><T> has been the alternate compose key sequence for
long time used in Xlib's Compose rule, but since this binding was 
overridden by gnome-terminal as reported by Derrick, we've added 
yet another alternate sequence,



> 2) AFAICT only dead_acute and dead_grave currently work with Latin unitLE.
> All the other deadkeys are currently ignored.  Though I would be happy
> to hear that I am wrong.

There was a mis-conversion of the data in the table before, and I thought
we've fixed the mis-mapping of other deadkeys all.
Does this problem happen on the current trunk?

> If the deadkeys worked when iiimf is off, then Latin LE could instead
> give the no-deadkey version of European input: eg with prefix/suffix
> to give accents for example, and then everyone would be happy I think. :-)

:-). We should provide such LE as well for such requirement.
(Is the 'default' LE intended to cover such mode?)

BTW, is the UNIT currently dropping several deadkey?
Or iiimgcf or libiiimcf?

Hideki
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.