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.
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?
- 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?
- 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?!
- 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
