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.
>> 4.1.2 Switching between iBus, SCIM and IIIMF
>> iBus services are started by gnome-session(1). User could
>> simply enable
>> or disable the service via gnome-session-properties(1). With
>> the help of
>> startup scripts shipped with iiimf and scim, user could set
>> GTK_IM_MODULE
>> environment variable in $HOME/.profile to select iBus, IIIMF or
>> SCIM.
>
> Is the GTK_IM_MODULE variable an interface exported by this case, or was
> it part of a previous case?
GTK_IM_MODULE variable comes from GNOME itself.
It's mentioned in gtk-query-immodules-2.0(1) manpage.
I looked at GNOME 2.14 ARC materials in /shared/sac/LSARC/2006/202/,
but couldn't find out the interface taxonomy.
>
>> 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.
>
>> 4.5. Interfaces:
>>
>> INTERFACE NAME STABILITY NOTE
>>
>> -----------------------------------------------------------------------
>> /usr/bin/ibus-daemon Uncommitted message bus daemon
>> /usr/bin/ibus-setup Uncommitted setup launcher
>> /usr/libexec/ibus-x11 Uncommitted ibus XIM fontend/agend
>>
>> /usr/libexec/ibus-gconf Uncommitted config backend by gconf-python
>> /usr/libexec/ibus-ui-gtk Uncommitted panel GUI by pygtk
>>
>> /usr/lib/libibus.so Uncommitted ibus C binding SDK library
>> /usr/include/ibus-1.0/* Uncommitted ibus C binding header files
>>
>> /usr/share/gtk-doc/html/ Uncommitted ibus developor documents
>> ibus/*
>>
>> /usr/lib/python2.6/ Uncommitted ibus Python binding
>> site-packages/ibus/*
>>
>> /usr/lib/gtk-2.0/2.10.0/ Uncommitted ibus gtk-im-module
>> immodules/im-ibus*.so
>> /usr/lib/{amd64,sparcv9}/ Uncommitted 64bits version of ibus
>> gtk-2.0/2.10.0/immodules/ gtk-im-module
>> im-ibus*.so
>>
>> /usr/share/ibus/setup/* Uncommitted ibus-setup modules
>> /usr/share/ibus/ui/gtk/* Uncommitted panel GUI by pygtk
>>
>> /usr/share/ibus/ Uncommitted ibus components registry
>> components/* like ibus-gconf, ibus-ui-gtk
>> and IMEs
>>
>> /usr/libexec/ Uncommitted IME launcher
>> ibus-engine-<IME_NAME>
>> /usr/libexec/ Uncommitted IME setup launcher
>> ibus-setup-<IME_NAME>
>> /usr/share/ibus-<IME_NAME> Uncommitted IME modules
>> *IME_NAME is among [anthy, chewing, hangul, m17n, pinyin, table]
>>
>> /usr/share/ibus-table/* Uncommitted ibus-table engine and
>> code-tables
>
> I suspect that many of the above are not actually interfaces at all, but
> rather internal components of the implementation. No user or
> application should be using most of these things directly, so
> Uncommitted seems inappropriate. Can you clarify which interfaces you
> expect users and applications to interact with directly and give those
> appropriate stabilities. Everything else should probably be some kind
> of private or not an interface at all.
I see. It seems Project Private is more appropriate for all of them
except the following.
>> /usr/bin/ibus-daemon Uncommitted message bus daemon
>> /usr/bin/ibus-setup Uncommitted setup launcher
Since ibus is fairly new software and being actively developed/enhanced
by the community. I think Volatile would be more appropriate for the
two interfaces.
I've updated the material.
>
>> 4.12. Dependencies:
>> We need python2.6 to be the default in OpenSolaris.
>
> What is the specific case dependency?
I don't know what python2.6 API ibus depends on.
We heard the python default will be changed from 2.4 to 2.6
in near future, but don't know the actual target at this point.
Thanks,
Fuyuki
