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/. > 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? > 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? > 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. > 4.12. Dependencies: > We need python2.6 to be the default in OpenSolaris. What is the specific case dependency? -Seb
