New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Dictionary lists set with gsettings from an external program (command line, on-screen keyboard, ...) should be fixed up #318
Comments
Encodings in dictionary names like Probably I should cleanup the list of dictionaries when such a list
|
Improved behaviour is now like this:
|
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:
Setting 'dictionary' or 'inputmethod' to an empty string actually sets the default for the current locale:
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: I.e.
instead of:
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, 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 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. |
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
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 ...)
The text was updated successfully, but these errors were encountered: