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

Ma Xiaojun damage3025 at gmail.com
Thu Oct 18 16:07:07 UTC 2012


On Thu, Oct 18, 2012 at 9:27 AM, Osamu Aoki <osamu at debian.org> wrote:
> I am a bit neutral to this.  I do not think we need to be
> confrontational to upstream (GNOME3 mainly by Fedora=RH).  Fedora is
> their test ground with little regards to the stability.  They have
> reason to do so.  If we want such thing as stability, we need to be
> careful what part to follow and how fast we follow.  RH provides
> stability with their commercial distribution still with GNOME2.  I think
> RH is still providing customer with security updates with source on
> them.  RH and Debian have different positions on how software get
> integrated.  RH needs one good working solution for upcoming their
> commercial distribution by testing them on FEDORA.  Debian is community
> thus needs to make as much reasonable software to live together.  This
> is our task and we should not complain too much to upstream RH on their
> single combination strategy.
True.

> 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.
Fcitx people already have their GNOME extension.
https://extensions.gnome.org/extension/261/kimpanel/

This extension is necessary even before 3.6 since otherwise you cannot
use IM in Shell integrated chat, say.

In contract, what GNOME 3.6 really breaks is IBus. Because they
changed the way of IBus usage and the new way is not good enough yet.
For example, they enforce global input source state. They offer no
switching shortcut by default. They offer no OSD like ibus-gjs. Fedora
users are going to enjoy all these once they have their long awaited
Fedora 18. To be fair, the issues I mentioned is known to GNOME people
already, having good chance to be fixed in 3.8. (Global input source
state is still being discussed. )

> 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 ...
I'm not a fan of GNOME's development stack.
But GObject Introspection gives us free language bindings, say Python
3 bindings.
How many manually maintained Python libraries don't support Python 3 yet?
Vala or Python API should be direct mapping of C API, yes, a bit awkward.
IBus follows GNOME technology closely which may not be appealing for
KDE users, say.
But making a choice between GTK+ and Qt is just natural.
Fcitx seems to be more compatible is more of a historical heritage
rather than a design advantage I guess.



More information about the Pkg-ime-devel mailing list