[Pkg-ime-devel] Bug#645729: Bug#645729: Bug#645729: Bug#645729: checking for ibus support in gtk2 and gtk3 separately

[Aron Xu]

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