Joerg Barfurth wrote:
> Fuyuki Hasegawa - Sun Microsystems schrieb:
>> Sebastien Roy wrote:
>>> On Thu, 2009-09-17 at 03:54 -0700, Fuyuki Hasegawa wrote:
>>>> Integrating ibus does not mean to obsolete iiimf or scim, but
>>>> we would put them in maintenance state.
>>>
>>> What is "maintenance state"? If you mean that they will remain
>>> supported but that ibus is the preferred method, then making them
>>> "Obsolete" in the ARC sense would seem like the right thing to do. Is
>>> that what you intend? See
>>> http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/.
>>>
>>
>> The "maintenance state" means that we will stop feature work
>> and unlikely to fix low priority bugs.
>> iiimf is still default IM for OpenSolaris 2010.02.
>> It seems we should change iiimf or scim interfaces to Obsolete
>> when we switch default IM to ibus for Solaris Next.
>>
>
> [...]
>
>>>> We plan to change default IM framework from iiimf to ibus in
>>>> Solaris Next.
>>>
>>> So this case does not change the default IM framework. A future case
>>> will do that. Is that accurate?
>>
>> Yes.
>>
>
> Such a future case would need to call out the feature differences
> between ibus and iiimf.
It should be addressed in the future case.
>
> I just learned that ibus does not (currently) support the keyboard
> layout switching functionality for European languages that iiimf has.
>
> Is there any long-term architectural direction for that area?
One of the reasons iiimf is still default IM, is that ibus has not
the keyboard layout emulation feature (iiimf has) yet while ibus
already supports several keyboard input for European languages
by utilizing m17n (MultilingualizatioN) library.
We have been planning to add the keyboard layout emulation feature
into ibus for Solaris Next.
>
> - First we had keyboard switcher based on libxklavier. Then that was
> dropped, because of some fundamental brokenness
>
> - Now we had to relearn that keyboard switching may be found in input
> method configuration. (And some people who need it never found it, as
> input methods are perceived to be for asian languages.) I'm not sure
> what, if any, are the limitations here. Does this require applications
> to be input-method-aware?
Yes if need to use keyboard switching function provided by Input Method.
Since GTK or java apps are already input-method-aware, such apps are
also input-method-aware by default.
>
> - Then keyboard-switcher/libxklavier comes back for 'familiarity' -
> including the known brokenness. Apparently we now find it acceptable to
> pretend that Xserver == Xorg.
>
> - But we still have iiimf. I don't really want to know what happens when
> both methods are used at the same time. And as neither method is
> Obsolete, I don't know what customers should prefer. I'd assume that
> when there is a risk of running into the libxklavier limitations, iiimf
> can still work?!
(While this is not make sense, if both methods are uses at the same time,
IM will get the output of libxklavier and should work as expected as far as
the current libxklavier's KB layout is informed to IM via IM config tool.)
User should use either keyboard-switcher+libxklavier or the iiim/ibus's
KB emulation in his/her preference. Probably most EMEA users would prefer
the former. For the users running into the libxklavier limitations,
yes, iiimf/ibus are also available.
I hope the aboves would also answer the followings.
Fuyuki
>
> - Now along comes ibus, which takes this function back out of input
> methods, so if someone has learned that, they'll have to relearn again.
> ("Ah, but there never was a real product release of this intermediate
> state, only the SXCE and OpenSolaris non-releases.")
>
> Do we have a clear picture of where we want to go with this, or are we
> going to keep providing an everchanging method of the day?
>
> And is that the only thing where ibus has less functionality than iiimf
> and depends on a different project to make up for that.
>
> While all that only needs to be addressed in a 'make ibus default,
> obsolete iiimf' case, it would have been good to expose the underlying
> architectural direction now (assuming there is one other than following
> the crowd).
> - J?rg
