Naoyuki Ishimura wrote: > Hi Sebastien, > > Thanks for your review. > > Sebastien Roy wrote: >> On Thu, 2009-12-03 at 13:44 +0900, Fuyuki Hasegawa - Sun Microsystems >> wrote: > ... >>>>> /usr/share/ibus/component Private engine >>>>> specification file >>>>> /xkbc.xml >>>>> /usr/lib/ibus/ibus-engine-xkbc Private engine invocation >>>>> script >>>>> /usr/lib/ibus/ibus-setup-xkbc Private engine specific >>>>> configuration >>>>> invocation script >>>> There has to be some Public interface provided by this project, >>>> otherwise the user would not be able to select this keyboard layout >>>> engine in the GUI, and then would not be able to depend on individual >>>> layouts offered by the engine. >>> The last three are the files for the GUI. >> >> They're imported by the GUI, but I'm asking about interfaces that are >> used by the user. There has to be something that the user depends on as >> an interface. How are other features that are solely enabled and >> controlled through a GUI handled (ask folks on LSARC who have probably >> dealt with interface stabilities for such features)? > > User can select this Input Method Engine (IME) to use through iBus > configuration GUI just like other IMEs (which are listed in iBus > case [PSARC/2009/499] - ibus-anthy, ibus-pinyin, ibus-chewing etc...). > Installing /usr/lib/ibus/component/xkbc.xml makes this IME (ibus-xkbc) > appear in the list of available IMEs of iBus configuration > dialog window. > >> >>> It seems fine to dedine them as Volatile. >>> However, we have defined them as Private in PSARC/2009/499 iBus >>> integration. >> >> Some level of Private is fine for these, as the files themselves are do >> not constitute a Public interface. On a related note, which level of >> "Private" do you actually mean here? > > User or any program other than iBus framework does not access > these files, so I think these files are Project Private. > These files contents and structure depend on iBus framework.
I've updated the material to dedine them as Project Private (from Private). Fuyuki > > I hope this answers your queries. > > Thanks, > Naoyuki >
