Ibus doesn't offer french-latin9 keymap

[changwoo]

From Debian bug https://bugs.debian.org/942245

As far as I can see, it is not possible to do the equivalent of a
setxkbmap fr latin9 with ibus. French alternative and French are not
latin9. This forces me to either use ibus and have a bad default keymap
or to disable ibus (currently my choice, using im-config with no
profile).

Would it be possible to include "French (latin9)" in ibus choices of
keymap?

BTW I'm just forwarding. I have no idea which specific keyboard variants are useful or not.

[gunnarhj]

There is a related Ubuntu bug too. Not even the standard English (UK) layout is present.

[fujiwarat]

As you may already notice, the simple.xml can be customizable by sysadmin and you could run ibus restart after you would add the following lines to simple.xml

                <engine>
                        <name>xkb:fr:latin9:fra</name>
                        <language>fr</language>
                        <license>GPL</license>
                        <author>Peng Huang &lt;shawn.p.huang@gmail.com&gt;</author>
                        <layout>fr</layout>
                        <layout_variant>latin9</layout_variant>
                        <longname>French (legacy, alt.)</longname>
                        <description>French (legacy, alt.)</description>
                        <icon>ibus-keyboard</icon>
                        <rank>1</rank>
                </engine>

The white list file simple.xml was generated to support the limited keymaps only in ibus and my understanding is the original ibus owner was a Chinese and Chinese don't wish to have keymaps since they use US layouts normally and also the number of XKB keymaps is huge for UI.
I've followed the policy for several years and updated simple.xml for the required keymaps only.

Since gnome-control-center shows all keymaps and also ibus-setup has enhanced the GUI with GtkListBox since 2015, it may be a stage to review the UI again now.
E.g. white list V.S. black list V.S. everything list
I might think the black list would be still needed for Chinese keymaps.

Also gnome-shell has enabled xkb:us::eng engine for any XKB keymaps because IBus's list is the while list and some keymaps does not exists in IBus XKB engines. I'm thinking it would also prevent IBus engines from being the default instead of GtkIMContextSimple. I.e. currently if the user's configuration does not include any input method sources with gnome-control-center region likes ibus-anthy, ibus-m17n but XKB sources only, gnome-shell enables GtkIMContextSimple for XKB sources.
While there are other problems likes emoji, compose, Wayland UI, I'd fix the problems one by one to unify IBus UI and GNOME one in the future.

Let me think the issue later when I get time.

[gunnarhj]

As you may already notice, the simple.xml can be customizable by sysadmin

Yes, that workaround has been mentioned on both the downstream bug reports.

You mention g-c-c and gnome-shell, but the main problem here isn't with GNOME, is it? My understanding is that the problem is present on non-GNOME desktops where a user wants to be able to switch conveniently between IBus IMs and one or more XKB layouts, and finds that a desired XKB layout is not present.

I've followed the policy for several years and updated simple.xml for the required keymaps only.

Which are the criteria used for determining which keymaps are required?

[fujiwarat]

You mention g-c-c and gnome-shell, but the main problem here isn't with GNOME, is it?

Right. they are not the problems when you use g-c-c but action items in my to-do list to fix the gaps between IBus configurations and GNOME ones and integrate the current emoji handling to GNOME.

Which are the criteria used for determining which keymaps are required?

The basic criteria is to minimize the simple.xml as much as possible. It means the original simple.xml would be enough and let sysadmin to update the file by site.
I'll return to review the design again.

[fujiwarat]

There is a little short term to think the black list.
I change the milestone to 1.5.23.