Allow to use kbd engines

[wladmis]

Despite of similar functionality, m17n kbd engines behave in the different way to xkb engines. For my specific use-case, the m17n kbd engines map Latin key to Cyrillic key only in the text fields while the command hotkeys are handled as Latin. It is very handy when you use smth like Firefox with Tridactyl (the Vimperator remake).

[mike-fabian]

See also:

#25

[mike-fabian]

Apparently you are not using Gnome, Gnome seems to have a hack which makes hotkeys like “Control+a” work even if the key where the “a” is on the US English keyboard layout produces something else (It produces ф on the Russian keyboard layout).

In this video I use a Gnome desktop and type type into gedit. First I use the US English layout and type:

a Control+a Right

The Control+a selects all the text in gedit (blue background), the Right (arrow-right) cancels the selection.

Then I switch to the Russian keyboard layout and type the same sequence of keys. Now the “a”-key produces ф, so actually I type:

ф Control+ф Right

and the Control+ф selects all text in gedit.

I think Gnome has a hack that if something like Control+ф does nothing, it checks what letter would have been produced when typing the same key on an US layout, which would be an “a” and then tries Control+a.

Peek.2021-08-10.10-49.mp4

[mike-fabian]

(All?) other desktops don’t have this hack, so if I try this on my usual i3 desktop, Control+ф does not select all text in gedit.

[mike-fabian]

You are right that using /usr/share/m17n/ru-kbd.mim via ibus-m17n can be used as a workaround for this, it gives you a Russian keyboard layout (emulated on an US English layout) and the hotkeys still work.

[mike-fabian]

Personally I have nothing against dropping the blacklisting of all the m17n:*:kbd engines.

I just counted 30 keyboard layouts/input-methods for Russian offered in the gnome-control-center settings, I don’t really see the harm in making that 31 ...

(I guess these were blacklisted in an attempt to reduce the amount of “useless” clutter in the selection of input methods in the gnome-control-center, but actually these m17n:*:kbd engines are not completely useless ...)

I don’t see really good reasons here:

289c8b7
https://codereview.appspot.com/6485073

why to blacklist the m17n:*:kbd engines.

[mike-fabian]

By the way, you can also use the /usr/share/m17n/ru-kbd.mim in ibus-typing-booster.

ibus-typing-booster supports all the input methods from m17n-db and doesn’t blacklist any.

ibus-typing-booster does much more than ibus-m17n, it offers to complete words does lots of others stuff.
But all that extra stuff can be disabled in the options, when the extras are disabled, ibus-typing-booster behaves just like ibus-m17n (but doesn’t blacklist any m17n-db input methods!):

http://mike-fabian.github.io/ibus-typing-booster/documentation.html#simulate-ibus-m17n

[wladmis]

On Tue, Aug 10, 2021 at 02:44:38AM -0700, Mike FABIAN wrote: By the way, you can also use the /usr/share/m17n/ru-kbd.mim in ibus-typing-booster. ibus-typing-booster supports all the input methods from m17n-db and doesn’t blacklist any. ibus-typing-booster does much more than ibus-m17n, it offers to complete words does lots of others stuff. But all that extra stuff can be disabled in the options, when the extras are disabled, ibus-typing-booster behaves just like ibus-m17n (but doesn’t blacklist any m17n-db input methods!): http://mike-fabian.github.io/ibus-typing-booster/documentation.html#simulate-ibus-m17n

ibus-typing-booster looks interesting, but even if all the features of it are disabled, this is too much for me: I just want to select one of the layout I use, to do some typing and quickly switch back to English layout. Anyway I don't see why any engine that is seems redundant should be blacklisted. While default.xml looks like a policy, an user has no way to change it, even then he or she still can create $HOME/.m17n.d/, copy ru-kbd.mim and uk-kbd.mim to that dir, and rename the engine names, and those engines will work. May be it would be better if every redundant engines will be set on the lowest priority instead? Just a proposition.

Closed #32 via 256b8e1.

Thank you!

[mike-fabian]

Anyway I don't see why any engine that is seems redundant should be blacklisted.

I agree.

May be it would be better if every redundant engines will be set on the lowest priority instead? Just a proposition.

ibus-setup sorts according to the priority, but the gnome-control-center apparently does not.

[wladmis]

Apparently you are not using Gnome, Gnome seems to have a hack which makes hotkeys like “Control+a” work even if the key where the “a” is on the US English keyboard layout produces something else (It produces ф on the Russian keyboard layout).

In this video I use a Gnome desktop and type type into gedit. First I use the US English layout and type:

a Control+a Right

The Control+a selects all the text in gedit (blue background), the Right (arrow-right) cancels the selection.

Then I switch to the Russian keyboard layout and type the same sequence of keys. Now the “a”-key produces ф, so actually I type:

ф Control+ф Right

and the Control+ф selects all text in gedit.

I think Gnome has a hack that if something like Control+ф does nothing, it checks what letter would have been produced when typing the same key on an US layout, which would be an “a” and then tries Control+a.
Peek.2021-08-10.10-49.mp4

No, AFAIK Control-ф works just as it is expected everywhere: like Control-a, there is no problem. The problem appears when you typing just plane 'ф' symbol somewhere outside the text input area and you expect it to work with effect like when you press 'a', but nothing happens.

[mike-fabian]

No, AFAIK Control-ф works just as it is expected everywhere: like Control-a, there is no problem.

Only in desktops which translates this back to Control-a, i.e. this works in Gnome but not in most other desktops.

The problem was when you typed just plane 'ф' symbol somewhere outside text input area and expected it works with effect like you pressed 'a', but nothing happened.

If you type outside a text input area, ibus-m17n doesn’t get focus and does nothing. That means if you are using ibus-m17n to simulate a Russian keyboard by transliteratig “a” to “ф” then you still get an “a” when you type outside a text input area because ibus-m17n can do nothing there.

But when you use a “real” Russian keyboard layout, you always get a “ф” when typing that key, no matter whether you do that in a text input area or elsewhere. So you cannot type an “a” (easily) anymore with the “real” Russian keyboard layout.

[wladmis]

If you type outside a text input area, ibus-m17n doesn’t get focus and does nothing. That means if you are using ibus-m17n to simulate a Russian keyboard by transliteratig “a” to “ф” then you still get an “a” when you type outside a text input area because ibus-m17n can do nothing there.

But when you use a “real” Russian keyboard layout, you always get a “ф” when typing that key, no matter whether you do that in a text input area or elsewhere. So you cannot type an “a” (easily) anymore with the “real” Russian keyboard layout.

Thank you for the explanation, it was just as I thought! The interesting thing is that I don't see why would somebody need a "real" Russian keyboard layout: it seems that it requires some external workarounds in to make things work.