ibus/im-config in Ubuntu GNOME

I have now also filed a report on this issue upstream: https://bugzilla.gnome.org/show_bug.cgi?id=762877

Changing bug status in accordance with feedback from upstream.

Hey Gunnar,
   any thoughts on this one? I don't think we have any patches for ibus/input methods in the GNOME components, but maybe the lower level components do? See the upstream bug for more deatils.

Hi Tim,

On 2016-03-02 10:17, Tim wrote:
> any thoughts on this one?

Possibly. gnome-language-selector (the language-selector-gnome package) includes that UI for controlling the im-config behavior.

If I understand it correctly, Ubuntu GNOME does not ship any of these packages by default:

- language-selector-gnome
- language-selector-common
- im-config

Is that correct?

But if a user installs language-selector-gnome, as Nikita did, all those three packages get installed, and thus im-config may affect the input method configuration. Also, if you use gnome-language-selector to install Japanese (or any other CJKV language), fcitx gets installed as well.

And yes, in this situation im-config defaults to "none" (which is actually xim...).

This makes me think of bug #1550325. Possibly we should make a similar change to im-config (and language-selector-gnome), so they behave in the same way in Ubuntu GNOME as they do in Unity and MATE.

Let me know.

we seed language-selector-common, since that provides the list of packages that make up language packs (when installing from gnome-control-center). im-config is on our images, seems like ibus pulls that one in.

I wonder should be just switch to ibus by default? I am not really up to date with the whole ibus vs fcitx for CJK statuses, but I do wonder how broken is fcitx under gnome-shell, i.e. does layout switching even work etc? or is it just the xim mode being set incorrectly causing the issues?

I see, so you do have both language-selector-common and im-config. In that case it's important that we do *something*.

Just switching to ibus by default all over would be a slightly more complex change.

It should be noted that as regards the Chinese languages, pkg_depends does currently (16.04) not pull any ibus IM engine. The switch to fcitx as the default for CJKV languages has been done at request of the CJKV users.

Does fcitx at all work on Ubuntu GNOME? I can't tell for sure, but I know that it was possible to use fcitx in Unity before unity-control-center had been changed to support fcitx. However, then you had to use the fcitx tools for enabling and switching between input methods. It would need to be tested for Ubuntu GNOME.

So we have two options, I suppose:

1) Same as Unity (if it works), which is in accordance with what most
   CJKV users prefer, but would result in a more complex UI for input
   method switching for them (i.e. g-c-c can't be used).

2) ibus default all over, which would not break the use of g-c-c for IM
   handling.

@Tim: Your decision. ;)

@Aron: Any thoughts on the topic?

Another thing: If I understand it correctly, gnome-session sets always the IM related environment variables to ibus. Considering that you have im-config anyway in Ubuntu GNOME, it may be desirable to comment that code via a patch. Doing so may be a condition for making it possible to use fcitx at all.

I have uploaded modified versions of im-config and language-selector to this PPA:

https://launchpad.net/~gunnarhj/+archive/ubuntu/im-config-gnome

Please feel free to upload and test.

With those changes, im-config (and gnome-language-selector) will default to IBus in Ubuntu GNOME. I added an exception for Ubuntu GNOME, so it will not default to fcitx even if a CJKV language is used as the display language. This seemed to be the most reasonable solution, considering the limitations of gnome-control-center in this respect.

I also changed pkg_depends so it pulls IBus IM engines for Chinese in Ubuntu GNOME. (Currently it does not.)

It should be noted that you don't need to install language-selector-gnome to switch between IM frameworks (IBus, fcitx, etc.). It can be done from the im-config GUI "Input Method Configuration" or from command line.

Let me know if you have any objections on the proposed changes.

Personally I think it would make sense to at least try to *allow* the users to use fcitx, even if g-c-c doesn't support it. Possibly it would require that the settings of the IM related environment variables in gnome-session are commented. (im-config sets them anyway as long as IBus is the selected IM framework.) I added a gnome-session task as a reminder. ;)

@Nikita: The input source you should use for typing Japanese is "Japanese (Anthy)" or possibly "Japanese (Mozc)".

> With those changes, im-config (and gnome-language-selector) will default to IBus in Ubuntu GNOME.

Hi, I've tested the packages from the PPA under Xenial's gnome-flashback, and now I got ibus running by default.
And it again breaks keyboard layout switching with the default Win+Space, so I can't type in Greek (LP: #1481025).

Why can't im-config default to ibus in locales that need it, and to None in locales that don't need it, as it did in previous Ubuntu releases?
Apart from the serious problems that it's causing, it's also wasting a lot of MB RAM per user, which is completely unacceptable for multi-user systems like LTSP.

@Gunnar, Yes, I have been told this before, but the only Input Source that shows in any of the settings is "Japanese"...

On 2016-03-06 11:08, Alkis Georgopoulos wrote:
> Hi, I've tested the packages from the PPA under Xenial's
> gnome-flashback, and now I got ibus running by default. And it again
> breaks keyboard layout switching with the default Win+Space, so I
> can't type in Greek (LP: #1481025).

Thanks for testing! Bad news, apparently. :(

May I ask: Which display language are you using? If it's something else but Greek, can you please switch to Greek, log out, log in again, and then try to type in Greek (with IBus running). Does that make a difference?

Also, just to make sure: Is your Xenial updated with the latest package versions?

> Why can't im-config default to ibus in locales that need it, and to
> None in locales that don't need it, as it did in previous Ubuntu
> releases?

Well, it started with bug #1550325, where it was reported that some applications need IBus to work. Maybe that's true for other flavors but MATE. Then there is the inconsistency in Ubuntu GNOME, which led to the confusion resulting in this bug report.

> Apart from the serious problems that it's causing, it's also wasting
> a lot of MB RAM per user,

Nah, I don't think IBus requires a lot of memory. Please note that IBus is running in Unity and Ubuntu GNOME, whatever the settings are. (Only some environment variables differ.) I don't know about Gnome Flashback in this respect.

On 2016-03-06 11:50, Nikita Yerenkov-Scott wrote:
> @Gunnar, Yes, I have been told this before, but the only Input
> Source that shows in any of the settings is "Japanese"...

Did you log out or reboot after you had installed the Japanese language support? If not, please do so.

If that doesn't make Anthy show up among the input sources, can you please let us know the output from these terminal commands:

dpkg-query -W ibus-anthy

env | grep -E 'XMOD|IM_MODULE'

@Gunnar, It was about a week ago that I installed the Japanese language, so yes, I've done many reboots since... And it's still not working...

The output of the first command is:

    ibus-anthy 1.5.6-1

And of the second:

    CLUTTER_IM_MODULE=xim
    QT_IM_MODULE=ibus
    XMODIFIERS=@im=ibus
    QT4_IM_MODULE=xim
    GTK_IM_MODULE=ibus

Also, should the title of this bug be changed as I'm not sure it still fully reflects on the subject we are talking about...?

On 2016-03-06 20:01, Nikita Yerenkov-Scott wrote:
> The output of the first command is:
>
> ibus-anthy 1.5.6-1
>
> And of the second:
>
> CLUTTER_IM_MODULE=xim
> QT_IM_MODULE=ibus
> XMODIFIERS=@im=ibus
> QT4_IM_MODULE=xim
> GTK_IM_MODULE=ibus

That looks fine AFAICT. To make sure that the ibus program actually runs, can you also show us the output of:

ps -A | grep ibus

If it does, it beats me why "Japanese (Anthy)" does not show up as an input source option (unless "Japanese" actually means "Japanese (Anthy)" in Ubuntu GNOME, but then it ought to work OTOH... (I'm not using Ubuntu GNOME myself, so I'm actually referring to what it looks like in Unity.)

> Also, should the title of this bug be changed as I'm not sure it still
> fully reflects on the subject we are talking about...?

We seem to be talking about multiple aspects of IBus in Ubuntu GNOME, so I changed the title to a more general wording.

@Gunnar, The output of that command is:

     1714 tty7 00:00:00 ibus-daemon
     1720 tty7 00:00:00 ibus-dconf
     1722 tty7 00:00:00 ibus-x11
     1811 tty7 00:00:00 ibus-engine-sim
     1925 ? 00:00:28 ibus-daemon
     1958 ? 00:00:00 ibus-dconf
     1961 ? 00:00:00 ibus-ui-gtk3
     1967 ? 00:00:00 ibus-x11
     1975 ? 00:00:07 ibus-engine-sim
     2291 ? 00:00:00 ibus-engine-han

Also, perhaps you should at least install Ubuntu GNOME in a VM or something for this because we know that it works in Unity, so if this is just a bug in Ubuntu GNOME, it's not exactly going to be very helpful if you are testing things in Unity...

Also, do you think that the bug description should be changed too now or can that be left to reflect the original topic of discussion (with perhaps a note at the bottom to say that the discussion has become more general now)?

On 2016-03-06 21:43, Nikita Yerenkov-Scott wrote:
> @Gunnar, The output of that command is:
>
> 1714 tty7 00:00:00 ibus-daemon
> 1720 tty7 00:00:00 ibus-dconf
> 1722 tty7 00:00:00 ibus-x11
> 1811 tty7 00:00:00 ibus-engine-sim
> 1925 ? 00:00:28 ibus-daemon
> 1958 ? 00:00:00 ibus-dconf
> 1961 ? 00:00:00 ibus-ui-gtk3
> 1967 ? 00:00:00 ibus-x11
> 1975 ? 00:00:07 ibus-engine-sim
> 2291 ? 00:00:00 ibus-engine-han

So there are two instances of ibus-daemon and a couple of other processes, probably because ibus was started both by some gnome package and im-config. Wonder if that might explain why it doesn't work for you.

It would be great if you could help debugging this by uninstalling im-config:

sudo apt-get purge im-config language-selector-gnome

and then reboot and see if Japanese (Anthy) is available after that.

> Also, perhaps you should at least install Ubuntu GNOME in a VM or
> something for this because we know that it works in Unity, so if this is
> just a bug in Ubuntu GNOME, it's not exactly going to be very helpful if
> you are testing things in Unity...

Well, I'm not an Ubuntu GNOME guy - I try to help because Tim asked me. ;) But I may install Ubuntu GNOME later on.

> Also, do you think that the bug description should be changed too now

I'd suggest we leave it as is for now.

thanks Gunnar, I will try and test this soon.

however I did notice your use of XDG_CURRENT_DESKTOP is not consistent with the spec. It changed when it became an official spec, which allows specifying multiple values colon seperated

gnome-shell XDG_CURRENT_DESKTOP set as GNOME
gnome-shell classic mode is set as "GNOME-Classic:GNOME"
gnome flashback,was setting as Unity, but at some point will likely become "GNOME-Flashback:GNOME"

On 2016-03-07 02:04, Tim wrote:
> however I did notice your use of XDG_CURRENT_DESKTOP is not
> consistent with the spec.

Thanks for mentioning that. Then I suppose that replacing

"$XDG_CURRENT_DESKTOP" != 'GNOME'

with

"${XDG_CURRENT_DESKTOP%%-*}" != 'GNOME'

takes care of it.

I have now installed Ubuntu GNOME and made some observations:

On a fresh Ubuntu GNOME 16.04 install I added the Japanese language including the suggested language support. For me it pulled exactly the same packages as gnome-language-selector would have done, so there is no reason to install gnome-language-selector for that reason.

After having logged out and logged in again, I found "Japanese (Mozc)" among the input sources and added it. Then I could open gedit, select "Japanese (Mozc)" and type beautiful characters: 絵画井笥 :) (Mozc is pulled in 16.04; previously it was Anthy. But I installed ibus-anthy manually, and could type Japanese with Anthy too.)

Then I changed the display language to Japanese, and now it was broken. Some of the IM related environment variables had been set to fcitx (even if XMODIFIERS and QT_IM_MODULE had been set to ibus by gnome-session) and fcitx had been started by im-config. After having commented the setting of the IM_CONFIG_PREFERRED_RULE variable in /etc/default/im-config, I could type using IBus also with Japanese as the display language.

(I failed to change the display language with Region & Language, and had to do it manually. However, using Region & Language for the purpose worked after I had used gnome-language-selector to switch language once, and thus created ~/.pam_environment and set the "Language" and "FormatsLocale" values in /var/lib/AccountsService/users/gunnar!? But that's a separate issue.)

So one conclusion is that im-config should indeed not set IM_CONFIG_PREFERRED_RULE on Ubuntu GNOME.

It's also clear that if users shall have a chance to use fcitx, gnome-session must not set those variables. (But this is probably not the most urgent thing right now.)

I played with user specific im-config settings using the "Input Method" GUI. IBus typing seems to work with any of the values "none", "xim" and "ibus", since two of the IM related environment variables are set by gnome-session anyway. Can't help feeling that "ibus" (i.e. in accordance with the current proposal in the PPA) is the safest and most sensible choice, though.

Hey Gunnar,
  Thanks for looking further into this.
>> however I did notice your use of XDG_CURRENT_DESKTOP is not
>> consistent with the spec.
> Thanks for mentioning that. Then I suppose that replacing
>
> "$XDG_CURRENT_DESKTOP" != 'GNOME'
>
> with
>
> "${XDG_CURRENT_DESKTOP%%-*}" != 'GNOME'
>
> takes care of it.
well that assumes that there is a hyphon in the name, while that is the case for the ones I know of, its not necessarily guaranteed. Thus:

"${XDG_CURRENT_DESKTOP##*:}" should be safer, GNOME (or Unity) should always be last since its essentially a fallback value
>
> I have now installed Ubuntu GNOME and made some observations:
>
> On a fresh Ubuntu GNOME 16.04 install I added the Japanese language
> including the suggested language support. For me it pulled exactly the
> same packages as gnome-language-selector would have done, so there is no
> reason to install gnome-language-selector for that reason.
As expected, since we get the list of packages from language-selector-common using PackageKit
>
> After having logged out and logged in again, I found "Japanese (Mozc)"
> among the input sources and added it. Then I could open gedit, select
> "Japanese (Mozc)" and type beautiful characters: 絵画井笥 :) (Mozc is pulled
> in 16.04; previously it was Anthy. But I installed ibus-anthy manually,
> and could type Japanese with Anthy too.)
>
> Then I changed the display language to Japanese, and now it was broken.
> Some of the IM related environment variables had been set to fcitx (even
> if XMODIFIERS and QT_IM_MODULE had been set to ibus by gnome-session)
> and fcitx had been started by im-config. After having commented the
> setting of the IM_CONFIG_PREFERRED_RULE variable in /etc/default/im-
> config, I could type using IBus also with Japanese as the display
> language.
>
> (I failed to change the display language with Region & Language, and had
> to do it manually. However, using Region & Language for the purpose
> worked after I had used gnome-language-selector to switch language once,
> and thus created ~/.pam_environment and set the "Language" and
> "FormatsLocale" values in /var/lib/AccountsService/users/gunnar!? But
> that's a separate issue.)
Does gnome-control-center need to create ~/.pam_environment? I didn't think that is used upstream, but specific to Ubuntu patched
accountsservice so maybe we will have to patch it for that?
>
> So one conclusion is that im-config should indeed not set
> IM_CONFIG_PREFERRED_RULE on Ubuntu GNOME.
This makes sense
> It's also clear that if users shall have a chance to use fcitx, gnome-
> session must not set those variables. (But this is probably not the most
> urgent thing right now.)
It would be good to allow users the option of using fcitx (even if poorly integrated), however lets just get the default session working for now!
>
> I played with user specific im-config settings using the "Input Method"
> GUI. IBus typing seems to work with any of the values "none", "xim" and
> "ibus", since two of the IM related environment variables are set by
> gnome-session anyway. Can't help feeling that "ibus" (i.e. in accordance
> with the current proposal in the PPA) is the safest and most sensible
> choi...

@Gunnar, After purging 'im-config language-selector-gnome' and doing a reboot 'Japanese (Anthy)' now shows up and it works as it should!

Should I install im-config again as it is a default package?

Oh, I have now also tested it in a VM, and just removing the 'language-selector-gnome' will do, no need to remove 'im-config' to get it to work so I'll reinstall that now...

Hi Gunnar,

> May I ask: Which display language are you using? If it's something else but Greek, can you please switch to Greek, log out, log in again, and then try to type in Greek (with IBus running). Does that make a difference?

I tested with display language = Greek. I haven't tested with display language = English.

> Also, just to make sure: Is your Xenial updated with the latest package versions?

Yes.

> Well, it started with bug #1550325, where it was reported that some applications need IBus to work. Maybe that's true for other flavors but MATE. Then there is the inconsistency in Ubuntu GNOME, which led to the confusion resulting in this bug report.

From what I read there, some people reported that xim doesn't work for them.
Noone reported that ibus or xim are useful for people that don't need any input method at all.

> Nah, I don't think IBus requires a lot of memory. Please note that IBus is running in Unity and Ubuntu GNOME, whatever the settings are. (Only some environment variables differ.) I don't know about Gnome Flashback in this respect.

I did report that ibus breaks the first Greek accented character in Unity as well.
Many people don't have the knowledge to pinpoint that ibus is what breaks their keyboard input, and just live with their problems.

Gunnar,
1) Would you be willing to accept a patch that makes im-config default to None in all desktop environments, in locales that don't need ibus or xim?
2) If not, is it possible to make language-selector-gnome NOT depend on im-config?
Or ubuntu-desktop not depend on language-selector-gnome?
Now we can't even uninstall im-config without uninstalling ubuntu-desktop, so we will have to resort to dpkg-divert to bypass this current issue... i.e. that 16.04 will be the first LTS release that we won't be able to properly type in Greek, in all desktop environments.

On 2016-03-07 10:48, Tim wrote:
>
>> Then I suppose that replacing
>>
>> "$XDG_CURRENT_DESKTOP" != 'GNOME'
>>
>> with
>>
>> "${XDG_CURRENT_DESKTOP%%-*}" != 'GNOME'
>>
>> takes care of it.
>
> well that assumes that there is a hyphon in the name, while that is
> the case for the ones I know of, its not necessarily guaranteed.
> Thus:
>
> "${XDG_CURRENT_DESKTOP##*:}" should be safer, GNOME (or Unity) should
> always be last since its essentially a fallback value

I proposed 'the hyphen way' to include GNOME Flashback. An alternative, until it has been changed for Flashback, would be:

"${XDG_CURRENT_DESKTOP##*:}" != 'GNOME' and "${XDG_CURRENT_DESKTOP%%:*}" != 'GNOME-Flashback'

>> (I failed to change the display language with Region & Language,
>> and had to do it manually. However, using Region & Language for the
>> purpose worked after I had used gnome-language-selector to switch
>> language once, and thus created ~/.pam_environment and set the
>> "Language" and "FormatsLocale" values in
>> /var/lib/AccountsService/users/gunnar!? But that's a separate
>> issue.)
>
> Does gnome-control-center need to create ~/.pam_environment?

No, that is done by accountsservice (the Ubuntu version of it). l-s doesn't write to ~/.pam_environment directly - no reason why g-c-c would either.

I haven't digged deep into the reason why it fails when there are no user specific settings previously. But when I started g-c-c from command line, I noticed an incorrect error message which said something like "ja_JP.UTF-8 is not installed" ... Probably there is a subtle bug in the current patch.

> It would be good to allow users the option of using fcitx (even if
> poorly integrated), however lets just get the default session working
> for now!

Right.

On 2016-03-07 20:36, Gunnar Hjalmarsson wrote:
> "${XDG_CURRENT_DESKTOP##*:}" != 'GNOME' and
"${XDG_CURRENT_DESKTOP%%:*}" != 'GNOME-Flashback'

Correction:

"${XDG_CURRENT_DESKTOP##*:}" != 'GNOME' -a "${XDG_CURRENT_DESKTOP%%:*}" != 'GNOME-Flashback'

On 2016-03-07 11:54, Nikita Yerenkov-Scott wrote:
> @Gunnar, After purging 'im-config language-selector-gnome' and doing
> a reboot 'Japanese (Anthy)' now shows up and it works as it should!

Hmm.. After having tested it myself, I'm a little surprised that purging those packages made a difference. Anyway, good that you finally made it work.

> Oh, I have now also tested it in a VM, and just removing the 'language-
> selector-gnome' will do, no need to remove 'im-config' to get it to work
> so I'll reinstall that now...

At least when the changes to im-config and language-selector, which we are now discussing in this bug report, have been uploaded, neither im-config nor language-selector-gnome will be a problem (but the latter should normally not be necessary in Ubuntu GNOME).

Considering Alkis' objections, and since it's late in the cycle, I uploaded less aggressive changes to the PPA.

https://launchpad.net/~gunnarhj/+archive/ubuntu/im-config-gnome

The changes make im-config start ibus in Ubuntu GNOME including GNOME Classic, and leave the im-config behavior unchanged for the other desktops.

@Alkis: If I understand it correctly, the issue, which you reported in bug #1481025, means that it's not possible in GNOME Flashback (and possibly other desktops) to switch easily between Greek typing and e.g. Chinese typing, while it works in e.g. Unity. That's obviously a bug in GNOME Flashback. IMNSHO that bug should be fixed the right way ASAP, so we can drop this workaround. GNOME Flashback screws currently up IBus in other ways too, but it's being worked on: https://bugzilla.gnome.org/759083

It should be possible to switch between any input sources without any hassle.

Anyway, hopefully this latest proposal will make everyone reasonably happy. :)

Thank you very much Gunnar, the latest PPA changes work as expected for me in gnome-flashback, i.e. ibus isn't running and I can type Greek just fine.
What you have in the PPA is a good compromise for 16.04, please keep it that way.

For the future, post 16.04, I'll try to raise the issue in Debian's im-config, so that there's no need to have an Ubuntu debdiff (or to minimize it).
I.e. I will ask that ibus isn't running in locales where it's not needed, because:
1) It's causing issues (some of them will be solved in time)
2) It's wasting 20 MB of non-shared RAM (echo 3 > /proc/sys/vm/drop_caches; free; killall ibus-daemon; echo 3 > /proc/sys/vm/drop_caches; free), which is an issue in multi-user systems like LTSP thin clients.

I've still not tested, but those patches look mostly fine from GNOME side.

However not really sure if the Flashback stuff is correct (edubuntu guys maintain that), but note on flashback is now using

XDG_CURRENT_DESKTOP=GNOME-Flashback:Unity

It is still using unity-settings-daemon/unity-control-center and presumably language-selector-gnome, so I guess it just uses the same config as Unity does? Now I wouldnt be surprised if there are snippets of code all over the place that don't support the above format, since they never broke on core ubuntu desktop.

Otherwise
+ if os.environ.get('XDG_CURRENT_DESKTOP')[-5:] in ['Unity', 'MATE', 'GNOME'] \
+ or locale.getlocale(locale.LC_CTYPE)[0][:3] in ['zh_', 'ja_', 'ko_', 'vi_']:

os.environ.get('XDG_CURRENT_DESKTOP').split(':')[-1]

Would seem a little safer with the know use-cases

++if [ "$XDG_CURRENT_DESKTOP" = 'Unity' -o "$XDG_CURRENT_DESKTOP" = 'MATE' -o "${XDG_CURRENT_DESKTOP##*:}" = 'GNOME' ]; then

that won't match for Flashback (I don't know if its meant to though?)

Dmitry, any thoughts on what Flashback requires in terms of above?

On 2016-03-08 08:25, Alkis Georgopoulos wrote:
> For the future, post 16.04, I'll try to raise the issue in Debian's
> im-config, so that there's no need to have an Ubuntu debdiff (or to
> minimize it).
> I.e. I will ask that ibus isn't running in locales where it's not
> needed, because:
> 1) It's causing issues (some of them will be solved in time)

They should better be solved.

It should also be mentioned that the input source switching GUIs in Unity and GNOME, especially the latter, are designed so the user shouldn't typically need to know about IBus or im-config. They should be able to just pick a source and start typing.

> 2) It's wasting 20 MB of non-shared RAM (echo 3 >
> /proc/sys/vm/drop_caches; free; killall ibus-daemon; echo 3 >
> /proc/sys/vm/drop_caches; free), which is an issue in multi-user
> systems

Please note that the IBus processes are started in Unity and GNOME (not sure about GNOME Flashback) anyway. What's affected by the im-config configuration is the IM related environment variables.

On 2016-03-08 08:34, Tim wrote:
> However not really sure if the Flashback stuff is correct (edubuntu
> guys maintain that), but note on flashback is now using
>
> XDG_CURRENT_DESKTOP=GNOME-Flashback:Unity

Understood.

> It is still using unity-settings-daemon/unity-control-center and
> presumably language-selector-gnome, so I guess it just uses the same
> config as Unity does? Now I wouldnt be surprised if there are
> snippets of code all over the place that don't support the above
> format, since they never broke on core ubuntu desktop.
>
> Otherwise
> + if os.environ.get('XDG_CURRENT_DESKTOP')[-5:] in ['Unity',
> 'MATE', 'GNOME'] \
> + or locale.getlocale(locale.LC_CTYPE)[0][:3] in ['zh_',
> 'ja_', 'ko_', 'vi_']:
>
> os.environ.get('XDG_CURRENT_DESKTOP').split(':')[-1]
>
> Would seem a little safer with the know use-cases

Yeah, your code is better. At the same time I now realize that this includes GNOME Flashback, which was not intended, so I just uploaded a new language-selector version to the PPA.

> ++if [ "$XDG_CURRENT_DESKTOP" = 'Unity' -o "$XDG_CURRENT_DESKTOP" =
> 'MATE' -o "${XDG_CURRENT_DESKTOP##*:}" = 'GNOME' ]; then
>
> that won't match for Flashback (I don't know if its meant to
> though?)

Right, it's deliberately.

I did some testing with the latest packages in the PPA.

On Ubuntu GNOME it worked as expected. Whether the display language is English or Japanese, im-config starts IBus and sets ibus in the variables, and I can type Japanese. gnome-language-selector behaves in consistency with im-config.

On GNOME Flashback im-config seems to work as expected. When the display language is English, im-config does not start IBus or change any variables. When I start gnome-language-selector from the terminal, it behaves in consistency with im-config.

However...

When I start gnome-language-selector from System Settings in GNOME Flashback, gnome-language-selector thinks that the applicable system default is "auto". Hence it shows that IBus is the selected IM framework, and creates a ~/.xinputrc file stating ibus. The reason proved to be that while XDG_CURRENT_DESKTOP has the value "GNOME-Flashback:Unity" in the terminal, XDG_CURRENT_DESKTOP has the value "Unity" when gnome-language-selector is started from the graphical environment. This undesired behavior is not due to the proposed changes in language-selector, but it's apparently there also with the current version.

My view right now is that at least these two issues should be further dealt with in separate bug reports:

* The incorrect XDG_CURRENT_DESKTOP value in the graphical environment of GNOME Flashback. (Dmitry?)

* The failure (first time) to change the display language from Region & Language in Ubuntu GNOME. (Tim, if you can reproduce that problem, please feel free to subscribe me to a bug report. Considering that it worked after the language had been changed once using gnome-language-selector, the required change should reasonably not be very extensive.)

Since those pending issues won't likely result in any further changes to im-config or language-selector, personally I think the proposed packages in the PPA should go to the xenial archive now. Let me know.

> ... I'll try to raise the issue in Debian's im-config, ... I will ask that ibus isn't running in locales where it's not needed...

I installed Debian Stretch with the Gnome desktop environment and neither im-config nor ibus were installed by default there.
So I cannot report it in Debian, as it does make sense that if someone manually installs ibus, he'd want to have it running by default.

The problem is Ubuntu-specific, that people that don't need ibus have it installed by default and running anyway.

Nevertheless, since ibus isn't running under gnome-flashback in non-cjkv locales, I'm not affected by that, so I can't complain.
Thanks again Gunnar, much appreciated! :)

About the "XDG_CURRENT_DESKTOP=Unity" part in gnome-flashback, it's caused by
unity-control-center/shell/control-center.c:
  g_setenv ("XDG_CURRENT_DESKTOP", "Unity", TRUE);

GNOME Flashback currently uses unity-control-center and unity-settings-daemon, so the input handling is exactly like in Unity (gnome-flashback's own input methods code is disabled).

When we switch XDG_CURRENT_DESKTOP from Unity to GNOME, at the same time we'll start using our own code and gnome-control-center. I was basically waiting for upstream to implement a StatusNotifier based tray because I don't want to reintroduce the XEmbed tray. Hope it will happen next cycle.

So if there is Unity in XDG_CURRENT_DESKTOP, one may expect that the code behaves just like Unity (at least from input methods point of view).

Just to be more precise: XDG_CURRENT_DESKTOP will switch from "GNOME-Flashback:Unity" to "GNOME-Flashback:GNOME". It is standardized that the desktop name can have multiple components separated by semicolons, so one must not use plain comparisons.

yes I am sure there are plenty of broken checks throughout the stack, I filed bug 1554878 to get those back into shape

There have been some discussions on IRC (#ubuntu-desktop) which have clarified the confusion wrt unity-control-center and GNOME Flashback. One part of the solution is that u-c-c should not overwrite an already existing XDG_CURRENT_DESKTOP value, and I've filed a MP (linked above) to fix that. Thanks Alkis for pointing at the right spot in the u-c-c source!

The other part is that the u-c-c task at bug #1554878 needs to be fixed.

@Dmitry: The result of this is that we keep the current difference between Unity and GNOME Flashback in this cycle, meaning that im-config does not start IBus or set the input method related environment variables by default on GNOME Flashback. This is to work around the problem with Greek typing which Alkis has reported.

I have uploaded language-selector and attached an im-config patch.

Gunnar: if the im-config_ibus-on-gnome.patch you attached is uploaded and your unity-control-center branch is merged, all the issues will get resolved, right? Do you want me to upload the patched im-config then?

On 2016-03-11 17:42, Dmitry Shachnev wrote:
> Gunnar: if the im-config_ibus-on-gnome.patch you attached is
> uploaded and your unity-control-center branch is merged, all the
> issues will get resolved, right?

Yes, that's my understanding.

Robert is about to remove all the XDG_CURRENT_DESKTOP queries in u-c-c, and if that's done, bug #1554878 will no longer apply to u-c-c.

> Do you want me to upload the patched im-config then?

Yes, that would be great.

Ok, uploaded.

This bug was fixed in the package im-config - 0.29-1ubuntu10

---------------
im-config (0.29-1ubuntu10) xenial; urgency=medium

  * debian/patches/01-ubuntu-locale-override.patch:
    Exempt GNOME desktops from modifying auto mode for CJKV locales
    (LP: #1551283).
  * debian/patches/02-ubuntu-system-default.patch:
    Make "auto" the system default for Ubuntu GNOME (LP: #1551283).

 -- Gunnar Hjalmarsson <email address hidden> Tue, 08 Mar 2016 01:25:00 +0100

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

---------------
language-selector (0.159) xenial; urgency=medium

  * LanguageSelector/ImConfig.py:
    Make "auto" the system default for Ubuntu GNOME (LP: #1551283).
  * debian/control:
    Bump version of the im-config dependency.
  * data/pkg_depends:
    Pull IBus IM engines in Ubuntu GNOME (LP: #1551283).

 -- Gunnar Hjalmarsson <email address hidden> Thu, 10 Mar 2016 23:33:00 +0100

As I haven't completely been following the discussion here please ignore my ignorance on this matter if I have any, but will this be backported into the previous version at least?

I don't think it's worth it. 16.04 will be an LTS release and 15.10 support ends in summer so all 15.10 users are very much recommended to upgrade to 16.04 anyway.

This needs fixes in some different places so it's not that easy to backport it.

I agree with Dmitry.

Actually, Nikita, it's still not clear to me *why* you didn't find "Japanese (Anthy)" initially. Based on my own tests, the changes we have now uploaded (or are about to upload) shouldn't make a difference in that respect. I had no problem on a fresh Ubuntu GNOME 16.04 (before the changes) to prepare for Japanese typing.

Anyway, since you filed this bug report, we identified and fixed a few things which may prevent confusion going forward. The most important thing, I think, is that im-config (and language-selector-gnome) no longer will set fcitx by default for Ubuntu GNOME users who have a CJKV language as display language.

Thanks for your help to identify the issues, Nikita. :) Please let us know if you feel there is some loose end which we haven't addressed.

I think that the language-selector-gnome must have caused some confusion somewhere because I have run some more test in VMs where simply removing that (no need to remove im-config though) will make "Japanese (Anthy)" and a few others show.

You're welcome, I don't think that there are any loose ends which you haven't addressed. :)

On 2016-03-12 12:50, Nikita Yerenkov-Scott wrote:
> I think that the language-selector-gnome must have caused some
> confusion somewhere because I have run some more test in VMs where
> simply removing that (no need to remove im-config though) will make
> "Japanese (Anthy)" and a few others show.

Well, while *installing and opening* language-selector-gnome might mess it up in 15.10, *removing* it can't possibly make a difference in this respect.

This bug was fixed in the package unity-control-center - 15.04.0+16.04.20160315-0ubuntu1

---------------
unity-control-center (15.04.0+16.04.20160315-0ubuntu1) xenial; urgency=medium

  [ Gunnar Hjalmarsson ]
  * Don't set XDG_CURRENT_DESKTOP if it already exists. (LP: #1551283)

  [ Luke Yelavich ]
  * Add switch to allow the toggling of the accessibility profiles
    indicator

  [ Robert Ancell ]
  * Always show the legal notice.
  * Always use Ubuntu help (remove hangover from g-c-c days).
  * Always use a menubar.
  * Drop legacy g-c-c code for panel width.
  * Remove show notifications code, we don't do that in Unity.

 -- Dmitry Shachnev <email address hidden> Tue, 15 Mar 2016 20:34:43 +0000

On 09/03/16 08:15, Gunnar Hjalmarsson wrote:
> * The failure (first time) to change the display language from Region &
> Language in Ubuntu GNOME. (Tim, if you can reproduce that problem,
> please feel free to subscribe me to a bug report. Considering that it
> worked after the language had been changed once using gnome-language-
> selector, the required change should reasonably not be very extensive.)
I am seeing this, but seems its only on some languages that it is failing

It looks like it might be related to Bug 1556684. I am getting similar logs, however I was able to get Japanese langpacks installed, just can't
set it.

Bug 1556684 does not exist.

It was marked private, should be visible now

Yep, my observation is identical with the description in that bug.

Just to add, I have now tested it and if I install "Japanese" through the language-selector-gnome and then remove that program (because it doesn't work otherwise for some reason) I get the "Japanese (Anthy)" input source, however if I add "Japanese" just through the normal means (not the language-selector-gnome) then I do not get that input source which is actually the only real one that properly provides Japanese so that is bad. Should I file a new report on this issue?

Because clearly there is something which is necessary for Anthy that the langauge-selector-gnome installs that the in-built system doesn't for some reason but should.

@Nikita: If you still have that issue, yes, it would be a new bug. Then it would be great if you could start with a fresh installation of Ubuntu GNOME 16.04, and explain step by step what you did.

Well, I just did a fresh install of Ubuntu GNOME 15.10, I planning to upgrade to 16.04 soon through fresh install (probably) but I haven't done so yet, though I can run a fresh install of 16.04 in a VM.

Right, I have now filed a report here on this issue: Bug #1586164.