[Pkg-ime-devel] Bug#645729: Bug#645729: Bug#645729: Bug#645729: checking for ibus support in gtk2 and gtk3 separately
On Mon, Oct 24, 2011 at 21:23, Osamu Aoki <osamu at debian.org> wrote:
> [...]
>
>
> My idea of unidirectional dependency chains for the working input method
> are:
> [...]
>
> So people install their IM choice package such as ibus-pinyin, then
> complete system comes up. ?They do not install ibus-gtk first and expect
> ibus-gtk3 and ibus-pinyin to be automatically installed even if it is
> what they need. (If that happen, Japanese, Korean, and chewing users may
> be unhappy) ?Anyway, language task should list ibus-pinyin like package
> for each pertinent language.
>
For ibus, this solution looks good. But for Fcitx, the situation
changed a little bit. Every input method engine of fcitx can work for
any frontend, say XIM, IM Modules, and fbterm, so we can't choose to
add a "Recommends" to any of them to ensure the IM Modules get
installed. Otherwise, I have added all IM Modules to Recommends of the
fcitx metapackage, it will be released with next upload.
> I will not strongly oppose to list all reverse direction dependencies as
> "suggest" if you really think this as an important thing to do. ?This
> may give good guidance if people could not figure out what other
> packages exist to utilize ibus etc. when they want to find out more
> about alternative system setting. ?But people can find these reverse
> direction dependencies from aptitude anyway. ?So making such has no real
> gain, IMHO.
>
>> When the following
>> two things being resolved, we can come back to the *ideal* way.
>
> Do not you think "recommend" by ibus pointing to ibus-gtk3 enough? ?It
> just _INSTALL_ ibus-gtk3 by APT.
>
> Osamu
>
>
The ideal solution In my mind is GTK3_IM_MODULE variable get added to
GTK3, which enables us to write hook script to update the
configuration depend on the exact situation.
--
Regards,
Aron Xu
Reply to: