Open fujiwarat opened 1 year ago
I think you don't necessarily mean EN layout but direct input mode for whatever keyboard layout is currently active. Because that is what most of the other ibus engines actually have.
Do you ask for this because somebody recently asked for using Western digits for Indian input methods?
See: https://github.com/ibus/ibus/issues/2530
ibus-typing-booster-2.23.0 now has such a feature
☑️ Convert language specific digits to ASCII
see: https://github.com/mike-fabian/ibus-typing-booster/issues/445#issuecomment-1608096803 for a video demonstrating that option.
That option can also be toggled with a user definable key binding, see:
https://github.com/mike-fabian/ibus-typing-booster/issues/445#issuecomment-1609180283
Besides the new
☑️ Convert language specific digits to ASCII
option, ibus-typing-booster has a direct input mode for a long time already. By default the direct input mode is not bound o any key, but one can easily bind a key to the command toggle_input_mode_on_off
like I did in this screenshot of the ibus-typing-booster setup tool:
If one defines a key binding for this, one can easily toggle between direct input mode (off) and typing booster input (on).
ibus-m17n does not yet have configurable keybindings, hard coding a direct input mode toggle to any specific key has a high likelyhood to conflict with something else. So I don't think it makes sense to implement such a toggle before adding configurable keybindings to ibus-m17n.
And, as ibus-typing-booster can do everything what ibus-m17n can do and more, I think it is not high priority to improve that in ibus-m17n..
And, as ibus-typing-booster can do everything what ibus-m17n can do and more,
ibus-typing-booster does not provide a engine per langauge and it does not meet the default engine. Also ibus-m17n is based on C language.
So I don't think it makes sense to implement such a toggle before adding configurable keybindings to ibus-m17n.
I think the implementation order is not important and the one issue would be enough to have multiple patches. In fact I don't think the implementation is so hard and that's why I reported the issue in upstream at first.
Convert language specific digits to ASCII
This is not relative with this issue directly.
We discussed about this issue a little. @mike-fabian pointed out that desktop team suggested not to have the switching layouts in one engine and I replied currently using Super-space takes a high cost to change the focus events and having the switching layouts feature would be useful for some engines.
E.g., I think ASCII layouts likes "fr", "de" should not have the switching layout features but non-ASCII layouts likes "ara" should have the switching layouts features. Currently IBus XKB engines provide the combined layouts likes "ara,us" layouts instead of simple "ara" ones, which uses XKB option shortcut keys. I called they are "Latin layouts" in the codes while I don't know what is the best naming.
I also think the similar way can be applied to ibus-m17n. However I guess most m17n layouts would be non-ASCII layouts and need the switching feature.
I'd like to provide one IBus engine by language in the near future. Currently Fedora provides "jp" layout + an Japanese IME by default for multi language users but an Japanese IME would be enough for the native Japanese.
Is your feature request related to a problem? Please describe. Some language IBus engines provides the ASCII typing to toggle the current layout and US layout with a shortcut key bound by the current engine likes ibus-anthy, ibus-hangul and it would be good for ibus-m17n to have a shortcut key.
Describe the solution you'd like Probably there are several ideas to implement it, g_settings_bind(), the parent IBusEngineSimple::process-key-event, gtk_shortcut_controller_run_controllers() or else.
Describe alternatives you've considered I have no alternative options.
Additional context ibus-hagul just sends the key events to the parent class: https://github.com/libhangul/ibus-hangul/blob/main/src/engine.c#L1435