Please port input method function to use im-config

Hi Aron,

im-switch will be replaced by im-config in Ubuntu during the Raring cycle. This is a natural consequense of the fact that the language-selector UI will be replaced by gnome-control-center's "Region and Language", which already provides some interface to im-config. I'm sorry if my response to Ma Xiaojun's initiative in comment #91 of bug #875435 made you believe otherwise.

Ma is aware of the transition to im-config, and if I understand it correctly, her concern is about the stable releases only. But as you probably know, for an SRU request to be considered, you need to first have the changes uploaded to the current development version.

For the case you want to test, a build of the proposed language-selector branch is available in my PPA at https://launchpad.net/~gunnarhj/+archive/misc

Ubuntu Seeds fixed at revision 2106.

This bug was fixed in the package language-selector - 0.95

---------------
language-selector (0.95) raring; urgency=low

  * LanguageSelector/gtk/GtkLanguageSelector.py:
    - Deprecated keyword "type" in Gtk.MessageDialog constructors
      replaced by "message_type".
  * debian/control, LanguageSelector/gtk/GtkLanguageSelector.py,
    LanguageSelector/ImConfig.py, data/LanguageSelector.ui:
    - Transition from the im-switch framework for handling input
      method systems to im-config (LP: #1076975).
 -- Gunnar Hjalmarsson <email address hidden> Fri, 30 Nov 2012 05:36:00 +0100

Sebastien,

I think we need to talk more about how to deal with the transition. In any case 80im-switch needs to be removed or disabled, and after having thought about it, I can't see how it could be safely done in im-switch.

It would be possible to add e.g.

  test -f /usr/bin/im-switch || exit 0

to the top of 80im-switch, update at least Quantal and Precise with im-switch SRUs, wait a couple of weeks, and then accomplish the transition to im-config by re-merging the applicable language-selector changes. However, users who don't upgrade (often enough) would end up with a broken setup.

If "dpkg-maintscript-helper rm_conffile" was used, it would be possible to have specified config files removed when people upgraded to the new im-switch version, but then the automatic launch of an input method would be disabled until the transition to im-config happened. (Maintainer scripts seem not to be run when a package is simply removed.)

The postinst file I proposed may be unconventional, but it would work safely, and would do no harm. Actually, Debian does it in a similar way, i.e. there is a postinst file in im-config that removes 80im-switch. The code is not effective in Ubuntu, though, since md5sum doesn't match.

@Sebastien
The natural conclusion of what I wrote in my previous comment is to add the missing md5sum to postinst in im-config.

This bug was fixed in the package im-config - 0.19ubuntu1

---------------
im-config (0.19ubuntu1) raring; urgency=low

  * debian/patches/01_make_cjkv_mode_default.patch:
    Make cjkv mode the system default (LP: #1076975).
  * debian/postinst:
    Make sure that 80im-switch is removed by adding md5sum for
    version 1.22ubuntu3.
 -- Gunnar Hjalmarsson <email address hidden> Mon, 10 Dec 2012 14:24:00 +0100

Comments at the im-config merge proposal, posted for the record
---------------------------------------------------------------

osamu (osamu) wrote on 2012-12-01:

Hi,

This cjkv is almost as an example code for me and it is not meant to be
default. Thai, India, ... many other locale may wish to enable IM.

Whoever install im-config with some IM packages has some needs to enable
IM. That is the official thought behind the current choice in Debian.

You can call this selfish choice because the other reason was that I use
en_US.UTF-8 but I need ibus-mozc :-)

If Ubuntu thinks that cjkv mode is better for its audience, please go
ahead with cjkv mode as default.

Since under normal install of Debian system, im-config and IM packages
are installed only under CJK... my current default is good one for
Debian situation. But Ubuntu being one install image for many locales,
you may wish to differ from Debian here.

(Somehow my post to Ubuntu sometimes rejected. If it does not show up
there, plese forward this to Ubuntu site.)

Gunnar Hjalmarsson (gunnarhj) wrote on 2012-12-01:

Thanks for your comment, osamu!

Please note that even if standard Ubuntu is a global distribution, and most of its users don't use input methods, Ubuntu is/will be shipped with IBus + im-switch/im-config. It would not be good IMO to use "auto" as default, since then Ubuntu would suddenly start launching IBus for users who don't even know what an input method is.

im-switch defaults to launch IBus for CJK languages only, and I concluded that "cjkv" is a reasonable im-config default for Ubuntu. Yes, I think it's motivated that we differ from Debian in this respect.

Of course, if you could add further appropiate locales to the list of locales that trigger launch of an input method in the "cjkv" mode, it would be even better. ;-)

osamu (osamu) wrote on 2012-12-02:

On Sat, Dec 01, 2012 at 04:50:33PM -0000, Gunnar Hjalmarsson wrote:
> Thanks for your comment, osamu!
>
> Please note that even if standard Ubuntu is a global distribution, and
> most of its users don't use input methods, Ubuntu is/will be shipped
> with IBus + im-switch/im-config. It would not be good IMO to use
> "auto" as default, since then Ubuntu would suddenly start launching
> IBus for users who don't even know what an input method is.

I agree your assessment. No objection here.

> im-switch defaults to launch IBus for CJK languages only, and I
> concluded that "cjkv" is a reasonable im-config default for Ubuntu.
> Yes, I think it's motivated that we differ from Debian in this
> respect.

I see.

> Of course, if you could add further appropiate locales to the list of
> locales that trigger launch of an input method in the "cjkv" mode, it
> would be even better. ;-)

I do not know which locale to activate. Please file wishlist bug to
Debian on which locales to activate under cjkv mode. Since this will be
Ubuntu default, I will listen to your decision on this matter.

Osamu
PS: Please repost this to your bug list so this message is in public
eyes if this does not show up in LP.

Gunnar Hjalmarsson (gunnarhj) wrote on 2012-12-02:

Your messages show up in Launchpad just fine.

On 2012-12-02 01:07, osamu wrote:...

Hi Osamu,

On 2012-12-11 14:20, osamu wrote:
> Hi, (please repost if launch pad reject my mail)

I suppose it was rejected, since the merge proposal doesn't exist any longer (it was merged yesterday), so I quote your full message in this bug comment. My replies inline.

> I agree with almost all changes but one.
>
> On Sat, Dec 01, 2012 at 01:23:22PM -0000, Gunnar Hjalmarsson wrote:
>> Gunnar Hjalmarsson has proposed merging lp:~gunnarhj/ubuntu/raring/im-config/cjkv-default into lp:ubuntu/im-config.
>> === modified file 'debian/rules'
>> --- debian/rules 2011-12-20 00:37:14 +0000
>> +++ debian/rules 2012-12-01 13:22:23 +0000
>> @@ -1,6 +1,6 @@
>> #!/usr/bin/make -f
>> %:
>> - dh $@
>> + dh $@ --with quilt
>>
>> override_dh_auto_build:
>> sed -e "s/@@VERSION@@/$$(dpkg-parsechangelog --format dpkg|sed -ne '/^Version/s/Version: *//p')/"\
>>
>
> Why you need this "--with quilt" if you are using dpkg 3.0 (quilt) format?
> Isn't it the case for this package?

No, unfortunately the format is 3.0 (native), so "--with quilt" was needed for the patch to be applied.

> It looks like some Ubuntu specific backport compatibility trick.

Don't think so. :)

> I am sure this is fine for your aim but I really wish to know the
> official Ubuntu reference recommending this. Then I know when this
> stops. I may change tone of maint-guide depending on the Ubuntu
> guideline. I thought all Ubuntu releases use tool chain which
> understand dpkg 3.0 (quilt) format.

Actually, I think it would have been easier if the format had been 3.0 (quilt). I'm certainly not a packaging expert, but I think that if we would change the package format, we would need a im-config_0.19.orig.tar.gz file without the debian folder.

> The dh_quilt_patch manpage stating:
>
> | This tool is useless if you use the source package format 3.0 (quilt).
> | Consider switching to this source format if you haven't done it yet.
>
> I wrote in maint-guide as:
>
> | Add support for the dh_quilt_patch and dh_quilt_unpatch commands.
> | * Include the quilt package in Build-Depends.
> | * Use dh $@ --with quilt instead.
> | * This applies and un-applies patches to the upstream source from files in
> | the debian/patches directory for a source package in the 1.0 format.
> | * This is not needed if you use the new 3.0 (quilt) source package format.

So let's change it from 3.0 (native) to 3.0 (quilt). Do you know which steps are involved to accomplish such a switch?

Gunnar