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

Hi,
  As far as this paradigm is concerned, if a user want to input French 
and Chinese at the same time, he must switch between French and Chinese 
input method frequently. It'll be very annoying if the switch can not be 
done by a simple key pressing.

So it'll be better if one can switch between two input methods very 
quickly by pressing a simple key, for example ctrl+space or shift+space. 
In most cases, one of the two input methods  is for the native language, 
the other is for commonly used foreign language.

In my point of view, English/European language is likely one of the two 
languages, in most cases. So using a hotkey to switch between another 
language and English/European should be ok for most users.

So we can simply call it input method on/off mode. English/European is 
the off mode, another input method is the on mode.

Regards
James Su

Hideki Hiura wrote:

>Hi Owen,
>
>  
>
>>From: Owen Taylor <[email protected]>
>>I don't have the full background here, but I think the concern was when
>>the selected language engine was something other than UNIT ... a
>>Chinese, or Japanese language engine, say. 
>>
>>Are (latin) dead keys and compose key handling expected to work when
>>conversion for such a language engine is off?
>>    
>>
>
>Thanks for the good question! 
>
>This is a good oppotunity to explore my thought behind composition
>and language engine on/off issue!
>
>Let me start with my short recommendation, which is no, and open the
>discussion on the implication behind this.
>
>There are several aspects we can look at, especially with the history
>of input method and the notion of language engine on/off.
>
>Pre-input method days, the compose key and dead key handling was done
>in keyboard driver or in its sort, in several layer.
>
>Due to the input method introduced quite late in the game, as mostly
>addition additional single language support to what's inputtable by
>keyboard(driver) can generates, the notion of language engine on/off
>is also invented. 
>
>But I doubt that idea is applicable universally now, especially after
>given multilingual input method paradigm. I would say it was just a 
>histrical tactical necessity which we can fix by now.
>
>A right paradigm which we can introduce now is 
>  1. to get rid of partial key operations the keyboard drivers or any
>     pre-input method processings perform, and
>  2. to let Input method handles all input event always, and
>  3. to let a user to choose input language (and language engines for 
>     the language) instead of language engine on/off.
>So that the so-called-"language engine off"-state without composition is 
>handled by English input method, and so-called-"language engine off"-state 
>with composition is handled by, say French input method, German input method
>etc.
>
>Having said that, there is certainly the possibility that it is still too 
>early for the paradigm shift :-), we can certainly retain the previous
>model for now and have a special code in libiiimcf for practicality
>reasons, seeking the best timing to purge later :-).
>
>Thanks!
>Hideki
>
>
>
>  
>