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

This is one of the issues that prevent IIIMF being enabled regardless
any locales. Existing European users find it as problematic because they
are used to their old configuration on deadkeys handled by X. However
currently if IIIMF server is on and they are using a application with
iiimf client, they would not able to use deadkeys from X.

My suggestion is that yes we should migrate all the input to IIIMF, but
having said that we should have a backward compatibility on this so that
users still have their choice without disabling IIIMF services.

Nevertheless LE when conversion on and LE when conversion off sounds
like a good model. It is very suitable for European users - by default
they could have UNIT on when conversion is off.

Regards,
Leon

On Sat, 2004-11-20 at 21:49 -0800, Hideki Hiura wrote:
> > 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