[Pkg-ime-devel] Bug#690605: Bug#690605: Bug#690605: Bug#690605: ibus-xkbc: not installed on with desktop metapackage

Aron Xu happyaron.xu at gmail.com
Sat Oct 20 07:10:40 UTC 2012


On Thu, Oct 18, 2012 at 10:27 PM, Osamu Aoki <osamu at debian.org> wrote:
> Hi,
>
> On Tue, Oct 16, 2012 at 01:33:18PM -0500, Ma Xiaojun wrote:
>> On Tue, Oct 16, 2012 at 12:51 PM, Aron Xu <happyaron.xu at gmail.com> wrote:
>> > I see your point, and I agree it's not intuitive. But unfortunately we
>> > can't add ibus to Recommends for all desktop tasks, and even if any
>> > GNOME package do that then it is a bug.
>> > It's a long story to tell the whole thing, but in short it is not an
>> > ideal solution because some (significant amount of) users have other
>> > preference on input method framework other than ibus. It could be
>> > added to ibus package so that users of ibus get this feature by
>> > default.
>> It's up to you.
>> Why we integrate Vi when user base of Emacs, Nano is also huge?
>> Provide a default and let the tweakers do whatever they want.
>>
>> > There were some discussions about how the input method integration
>> > should be implemented in GNOME, but the outcome was that GNOME
>> > designers and developers disagreed to accept the advices from input
>> > method developers and took an approach that has led us to an
>> > embarrassing situation.
>> Better to summarize as the developer and fans of one IMF try to
>> prevent GNOME from integrating another IMF.
>
>[...]
>
> GNOME people are integrating IM into GNOME shell.  I do not know how to
> handle this new situation yet.  What I know now is Gnome-shell is
> reconfuarable by external javascript code.  Even if GNOME people tightly
> integrate ibus into gnome-shell, it does not theoretically prevent fcitx
> to replace ibus as long as someone can write codes to replace
> functionalities as a hot patch. Considering next Debian release comes
> after several GNOME3 releases, situation will be easier to handle than
> how it looks now.
>

The situation here isn't that optimistic, because if one has enabled
IBus integration at build time, then whenever a ibus-daemon exist no
other input method can work because gnome-settings-daemon will force
to use ibus by monitoring and resetting various variables. They are
integrating configuration interface of IBus into gnome-control-center,
but that's another thing for us to think about.

>> > If you'd like to choose which input method framework to use, try
>> > im-config. After you have installed the package, run the command
>> > "im-config" from a terminal and then follow the guide.
>> > Ubuntu has language-selector, a tool said to be deprecated by GNOME's
>> > new control center component, but the replace won't happen in the
>> > upcoming 12.10 at least. The input method framework selection part of
>> > language-selector is a frontend of im-switch, which has been
>> > deprecated by im-config in Debian. If the tool won't get out of 13.04,
>> > I'll try to push patch to migrate it from im-switch to im-config. We
>
> The fixed im-config has moved to testing on Debian.  Since some of the
> missing features complained by Ubuntu people is fixed in im-config,
> Ubuntu can move to im-config as backend to language selector.
>
> Considering Ubuntu updating every 6 month, they have to deal upcoming
> IMF integrated GNOME3 first as "released packages".  That is the biggest
> challenge. (not minor tweaking between im-config and im-switch.)
>

As yesterday the discussion about making systemd a hard dependency of
some important GNOME components, how to deal with the problem for
Debian and Ubuntu remains a question. But we can port
language-selector to im-config by a easy patch, and the reason for not
porting it for such a long time is because of the lack of hands.

Ubuntu developers have thought about using GNOME's input method
configuration UI, but it's far more harder for them to stick with
current language-selector. The original author of language-selector
left the company for more than a year ago, and that piece of software
is just being maintained to "work", no new plans so far.

>> > won't have that tool because it manages language packs and fonts as
>> > well, which are pointless for Debian.
>> That's the solution favored by some people.
>> They know im-config on Debian, im-switch on Ubuntu, im-chooser on
>> Fedora, System/Environment/Language/INPUT_METHOD on openSUSE...
>> They also know input method related environmental variables (apply to
>> all distribution).
>
> The challenge is GNOME3 may not be as compatible as other desktop
> environment ....  and it requires a lot of GObject and introspection
> internal things.  GNOME3 documentation for developer is not well
> organized yet.  It is not so easy to learn ...  No API documentation for
> Vala or Python bindings in packaged form.  Just C one is available as
> package.
>   http://people.debian.org/~osamu/fun2prog.html#_vala_3
>   http://people.debian.org/~osamu/fun2prog.html#_pygobject
>
> With the speed I am learning, I am not sure if I can propose good path
> forward ...
>
>> Happy tweaking!
>>
>> _______________________________________________
>> Pkg-ime-devel mailing list
>> Pkg-ime-devel at lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-ime-devel



-- 
Regards,
Aron Xu



More information about the Pkg-ime-devel mailing list