Bug#708847: ibus: provide default input methods if one is not specified

[Drew Parsons]

Package: ibus
Version: 1.5.1.is.1.4.2-1
Severity: normal

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

(fcitx has the same problem, I mentioned it in bug #708149 but I think
I should file a separate bug for it, parallel to this bug in ibus)

Of course ibus 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 ibus 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
dependency is Depends: xserver-xorg-video-all | xorg-driver-video.

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

Each ibus input method (ibus-googlepinyin, ibus-hangul, ibus-skk, ibus-libthai,
etc) then
Provides: ibus-input-method.

And ibus-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
ibus 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

-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.8-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ibus depends on:
ii gconf-service 3.2.5-1+build1
ii gconf2 3.2.5-1+build1
ii gnome-icon-theme 3.4.0-2
ii libc6 2.17-3
ii libgconf-2-4 3.2.5-1+build1
ii libglib2.0-0 2.36.1-2build1
ii libgtk2.0-0 2.24.18-1
ii libibus-1.0-0 1.5.1.is.1.4.2-1
ii librsvg2-common 2.36.1-1
ii libx11-6 2:1.5.0-1
ii python 2.7.3-5
ii python-ibus 1.5.1.is.1.4.2-1
ii python-notify 0.1.1-3
ii python-xdg 0.19-5

Versions of packages ibus recommends:
ii ibus-gtk 1.5.1.is.1.4.2-1
ii ibus-gtk3 1.5.1.is.1.4.2-1
ii ibus-qt4 1.3.1-2.1
ii im-config [im-switch] 0.21
ii python-appindicator 0.4.92-2

Versions of packages ibus suggests:
pn ibus-doc <none>

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Osamu Aoki]

Hi,

On Sun, May 19, 2013 at 01:19:29PM +1000, Drew Parsons wrote:
> Package: ibus
> Version: 1.5.1.is.1.4.2-1
> Severity: normal
>
> One of the design philosophies in Debian is that packages should
> generally "just work" when installed.

Yes.

> At the moment ibus does not do
> this: if you install the ibus package, no input methods are included.
> Hence a default installation does not work.

Really :-) It support xim method.

> (fcitx has the same problem, I mentioned it in bug #708149 but I think
> I should file a separate bug for it, parallel to this bug in ibus)

This is intentional choice with reasons. If we were to make such
utitily package as ibus-all-popular and fcitx-all-popular, this may be
made to pull in many packages. We did not do this.

Please see how CJK language localization tasks pick IM packages.

Japanese ibus-anthy ibus-mozc are your pick (But current Japanese task
maintainer chose to use uim. So he has uim-anthy uim-mozc.) This is
what should happen. (See more in ibus README.Debian)

If we make ibus to pull the other way, you are creating cyclic
dependency. So this is not allowed by recent policy.

> Of course ibus 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 ibus 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.

Although you may disagree, XIM is there for you.

> 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
> dependency is Depends: xserver-xorg-video-all | xorg-driver-video.
>
> By analogy, all that needs to be done is add to ibus
> Depends: ibus-input-method-common | ibus-input-method
>
> Each ibus input method (ibus-googlepinyin, ibus-hangul, ibus-skk, ibus-libthai,
> etc) then
> Provides: ibus-input-method.

I have not thought through but do you claim this does not cause cyclic
dependency for sure. Unlike xorg cases, these ibus-hangul depends on
ibus.

Also unlike xorg, having too many method makes it quite noisy and not
desirable provided we keep im choser as is. That is upstream and ...
eh... we have bigger headach to clear these days since GNOME will
integrate ibus. It is long story which I do not even have whole
picture, yet.

> And ibus-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
> ibus becomes more accessible (more useful) to casual users who are not
> in need of one specific input method.

Excuse me to be so negative ... but I need to be sure.

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

Yes patch and also policy conformance explanation. Otherwise, we will
not be doing concrete discussion.

Osamu

[Drew Parsons]

On Sun, 2013-05-19 at 18:37 +0900, Osamu Aoki wrote:
> > One of the design philosophies in Debian is that packages should
> > generally "just work" when installed.
>
> Yes.

Thanks for allowing the discussion to take place. It sounds like the
cyclic dependency is the point to think through.

> > At the moment ibus does not do
> > this: if you install the ibus package, no input methods are included.
> > Hence a default installation does not work.
>
> Really :-) It support xim method.

Perhaps. But I understand that xim is precisely the problem that ibus
and fcitx are designed to solve... :)

> > (fcitx has the same problem, I mentioned it in bug #708149 but I think
> > I should file a separate bug for it, parallel to this bug in ibus)
>
> This is intentional choice with reasons. If we were to make such
> utitily package as ibus-all-popular and fcitx-all-popular, this may be
> made to pull in many packages. We did not do this.
>
> Please see how CJK language localization tasks pick IM packages.
>

It certainly is reasonable to want to not pull in unneeded packages. In
principle my "xorg-like" mechanism would satisfy that through the
"popular | specific" condition. The localization tasks would include the
specific input method they need, and therefore the other input methods
would not be pulled in.

> Japanese ibus-anthy ibus-mozc are your pick (But current Japanese task
> maintainer chose to use uim. So he has uim-anthy uim-mozc.)

Thanks for the correction for preferred Japanese input. I haven't
tested uim yet. Looks like the same question I'm raising would apply to
it too. If I can convince you to adjust for the input-method-popular |
input-method-specific dependency, then perhaps a general mechanism could
be designed, say by expanding the scope of im-config (but that would
probably introduce unnecessary anbd therefore undesirable complexity).

> I have not thought through but do you claim this does not cause cyclic
> dependency for sure. Unlike xorg cases, these ibus-hangul depends on
> ibus.

Ah, I didn't catch that the ibus input methods Depend on ibus. That
complicates it a little. It's a bit different with fcitx, which uses
Recommends rather than Depends (which I think would not count as a
cyclic dependency).

Best then to lay down the use cases. I think there are only two.

1) Native speaker who wants immediate access to their own language.
This user will see the input method for their language and select it for
installation. It's reasonable for that to be the only action they need
to take. This is the use case you currently have in place. When an
ibus input is selected, it pulls in ibus (via Depends, but would
Recommends be sufficient?) to provide the required framework.

2) Non-native speaker who just wants access to other languages, without
expecting to routinely use them every day (this is the casual user I
invoked). This user doesn't know the difference between anthy, mozc and
skk. For educational purpose they may want each of Chinese, Japanese and
Korean installed. They hear that ibus integrates well with Gnome and
select it for installation. My suggestion is that it's reasonable for
them to gain an ibus installation which is already ready to sue.


The sticking point, then, is that currently the ibus input methods
Depend on ibus. Would you consider changing this to a Recommends? I
believe this will continue to support Use Case 1, so it will continue to
work the way you intended. Then I think with a Recommends
relationship, my mechanism would be able to support Use Case 2 without
introducing a cyclic dependency. Recommends doesn't cause a cyclic
dependency, does it?

A Recommends would mean that a user may explicitly choose to uninstall
ibus while leaving the input method installed. I think this would come
under the category of "expert user", one who knows what they're doing.
We don't need to force the decisions of those users. Maybe they want
access to the ibus data files to help port an input method to uim :)

> > It's easy for me to generate a patch for you, let me know if that would be
> > helpful.
>
> Yes patch and also policy conformance explanation. Otherwise, we will
> not be doing concrete discussion.

Thanks. I'll wait to hear what you think of my policy interpretation,
with the suggestion to use Recommends instead of Depends. I'll generate
some patches if you give the thumbs up :)

Drew

p.s. good luck with the extended Gnome integration :)