[BUG] Dictionary lists set with gsettings from an external program (command line, on-screen keyboard, ...) should be fixed up

[mike-fabian]

The Gnome on-screen keyboard with the latest patches by Carlos Garnacho Parro sometimes sets quite weird dictionary lists.

https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/wip/carlosg/osk-updates/js/misc/ibusManager.js#L343-L346

 settings.set_string(KEY_DICTIONARY, GLib.get_language_names().join(','));

Using GLib.get_language_names() directly without any cleanup can produce results like this for example:

(By the way, this list is seen in the ibus-typing-booster setup tool even though the on-screen keyboard is not active because the on-screen keyboard failed to reset the original dictionaries when closing. Maybe it crashed and couldn’t do that anynmore ...)

[mike-fabian]

Encodings in dictionary names like .UTF-8 are not supported by ibus-typing-booster, the fallback mechanism still finds the en emoji dictionary for en_US.UTF-8 but not the hunspell dictionary en_US.

Probably I should cleanup the list of dictionaries when such a list en_US.UTF-8,en_US,en.UTF-8,en,C comes in:

• cut off all encoding parts ➡️ en_US,en_US,en,en,C
• translate things like C, POSIX to en_US ➡️ en_US,en_US,en,en,en_US
• then we have duplicates, they cause a useless slowdown, remove them ➡️ en_US,en

[mike-fabian]

Improved behaviour is now like this:

$ dconf write /org/freedesktop/ibus/engine/typing-booster/dictionary '"en_US.UTF-8,en_US,en.UTF-8,en,C"'
$ dconf read /org/freedesktop/ibus/engine/typing-booster/dictionary
'en_US,en,en_US_POSIX'

[mike-fabian]

With the new behaviour, one can also set empty strings to get the locale specific defaults.

For example:

Let’s start the setup tool in Hindi locale:

$ LC_ALL=hi_IN.UTF-8 python3 setup/main.py &

Setting 'dictionary' or 'inputmethod' to an empty string actually sets the default for the current locale:

$ dconf write /org/freedesktop/ibus/engine/typing-booster/dictionary '""'
$ dconf read /org/freedesktop/ibus/engine/typing-booster/dictionary
'hi_IN,en_GB'

$ dconf write /org/freedesktop/ibus/engine/typing-booster/inputmethod '""'
$ dconf read /org/freedesktop/ibus/engine/typing-booster/inputmethod
'hi-inscript2,NoIME'

The typing booster engine does the same as the setup tool, it converts empty strings to the locale defaults, but saves that conversion back to gsettings only at startup.

When typing booster is already running, and one sets the above values in gsettings to empty strings, typing booster converts its internal variables for input methods and dictionaries to the locale defaults, it just doesn’t write them back to gsettings (not immediately, it may do that if the order of the input methods and dictionaries is changed using a key binding).

Therefore, it might be a good idea now for the on-screen keyboard to set empty strings here:

https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/wip/carlosg/osk-updates/js/misc/ibusManager.js#L343-L346

I.e.

settings.set_string(KEY_DICTIONARY, '');

instead of:

settings.set_string(KEY_DICTIONARY, GLib.get_language_names().join(','));

and also an empty string for the input methods.

I am not 100% sure if this is a good idea to set the locale defaults, but it seems reasonable and I think it is worth a try.

I am not 100% sure for the input methods because it might be problematic if more than one input method is set as the locale default and the first one does not produce ASCII.

For example the default inputmethod value for hi_IN locale is 'hi-inscript2,NoIME'. The first input method, hi-inscript2 does produce Devanagari characters, not ASCII.

I.e. when this is set and one types some ASCII keys on the on-screen keyboard, the result in the preedit will be Devanagari. The candidates on top of the on-screen keyboard maybe Devanagari and/or ASCII because the typed characters may find matches inthe hi_IN dictionary or the en_GB dictionary or in both. So one maybe able to select a desired English word as a candidate, even if the preedit shows only Devanagari. But if the desired English word cannot be found in the en_GB dictionary, one may be out lof luck. When using ibus-typing-booster “normally”, i.e. without the on-screen keyboard, one can switch the order of the input methods with key bindings (Control+Up and Control+Down). The result of the first input method is shown in the preedit so one can switch the preedit between Devanagari and English if the desired word is not found in any dictionary. But one cannot type these key bindings on the on-screen keyboard, so it seems impossible to change the input method of the preedit.

If that is too problematic, then it is maybe better when the on-screen keyboard sets the empty string (locale default) only for the dictionaries but sets 'NoIME' for the input method whichmeans to use what comes from the keyboard without any modification/transliteration.