One of the design philosophies in Debian is that packages should
generally "just work" when installed.  At the moment fcitx does not do
this: if you install the fcitx package, no input methods are included.
Hence a default installation does not work.

(I mentioned this in bug #708149, but I think the question is worth
raising as a separate bug. ibus has the same problem, I filed a
parallel bug #708847).

Of course fcitx does not know if you want Korean, Japanese or Chinese
input (or which version of them). Nevertheless by pulling in no
method, it appears to a dumb casual user as though fcitx is just
broken. I think it would be better for casual users if some input
methods (the most common input method of each language) were installed
by default, unless the user specifies a specific one.


It is useful to make a comparison with xserver-xorg.  xserver-xorg
installs all video drivers via xserver-xorg-video-all, unless a user
specifies a specific one (which provides xorg-driver-video). The
xserver-xorg dependency is Depends: xserver-xorg-video-all | xorg-driver-video.

By analogy, all that needs to be done is to add to fcitx
     Depends: fcitx-input-method-common | fcitx-input-method

Each fcitx input method (fcitx-googlepinyin, fcitx-hangul,
fcitx-anthy, etc) then
     Provides: fcitx-input-method.

And fcitx-input-method-common is a simple dummy package that depends on
selected common methods (it's a separate debate which ones should be
recommended for each language!)

The patch is essentially non-invasive I think.  The outcome is that
fcitx becomes more accessible (more useful) to casual users who are not
in need of one specific input method.


It's easy for me to generate a patch for you, let me know if that would be
helpful.

Cheers,
Drew Parsons

I agree that pulling in none of the input methods is something
annoying for people don't know how to proceed next, and a slightly
amend solution is good enough to solve the problem. That says, we only
pull in one/two input method as recommended to the users, but not all
of them like xserver-xorg because some of the engines are just big,
fat, in size (which to recommend can be decided/changed later in the
dummy package's dependency at any time).

And it's appreciated if you can provide a patch for it!

Thanks,
Aron

I agree that pulling in none of the input methods is something
annoying for people don't know how to proceed next, and a slightly
amend solution is good enough to solve the problem. That says, we only
pull in one/two input method as recommended to the users, but not all
of them like xserver-xorg because some of the engines are just big,
fat, in size (which to recommend can be decided/changed later in the
dummy package's dependency at any time).

And it's appreciated if you can provide a patch for it!

Thanks,
Aron