Closed Azl-Eyekay closed 2 years ago
mike-fabian
commented
2 years ago You can completely disable that key binding by setting it to empty. Like in this video:
https://user-images.githubusercontent.com/2330175/190889058-1ed9f8c2-4b9b-4d42-b28f-1c71358d57be.mp4
mike-fabian
commented
2 years ago I know this software is somewhat inclined towards Chinese scripts, but I am currently making input methods for all the different Indian languages, using the same key combinations as the very popular but windows-only Baraha software.
Most likely it would be much better to develop your Baraha input method not for ibus-table but for ibus-m17n and ibus-typing-booster instead.
If you give me more details about that Baraha input method, I could help you with that.
Azl-Eyekay
commented
2 years ago Hi, thanks for the quick response! (I apologise in advance for using layman terms as I am not a linguist, and also for the long rant)
This is the Baraha layout for Devanagari: https://baraha.com/help/Keyboards/dev-phonetic.htm This basically has the English letters type the closest Devanagri letter to the key, for example, k types the consonant with the k sound. All other languages have essentially the same layout with the characters replaced for that language.
I will mention the problems I am facing with the Indic layouts currently available in ibus-m17n. Maybe these can be fixed with features available in the engine but not used by these layouts, I don't know.
In Hindi, there are 4 sounds which would map to 't': a hard T (the one in tank), a soft T (the t in thanks but without the 'h' sound), and then both but with 'h' sounds. This same problem exists for D as well. In layouts like KaGaPa and phonetic in ibus-m17n, this is handled by have the soft Ts with the T key (the base sound with T, the 'h' one with shift+T). The hard Ts are the same, but with the q key instead, and the hard D with the w key, which is confusing. Baraha sorts this out by having t->soft t sound, and T->hard T sound and then typing h after that if required to create those letters.
The other thing is that in Indic scripts, every vowel has two characters: one which is 'independent' and acts like a letter, and one form which is attached to a consonant which is being spoken with that vowel's sound. In Unicode, these are registered separately: for the ee sound in 'keep', the characters in Unicode are ी for the dependent form which gets tacked onto a vowel while writing (की -> 'kee'), and its different, independent form (ई -> just 'ee'). All the available layouts print the useless ी when you press 'i' even if its the beginning of the word and there is no consonant before it for it to attach onto. The layouts require that the user instead press right Alt and that key for the proper form, which does not work on GNOME because you cant reassign that key in the keyboard layout as far as I am aware, and GNOME uses the right alt for bringing up the application menu. Asking users to change these settings after installing the layout will confuse them. In Baraha layout, there is no need for special key apart from the shift key.
I solved this by writing a program which writes the correct key combination ('kee') and then the correct character (the k symbol with the dependent 'ee', की) for all the possible combinations of vowels and consonants, which created a table of ~1500 key combinations which I directly pasted onto the table definition. Then, for the key combinations with just vowels, I added their independent form for those keys.
So, I have been able to solve both problems using ibus-table. I will take a look at the other libraries though.
As for having no keyboard shortcut for the toggle, somehow I did not realise that I could have left it at that, thank you for the info! But is there a way not having a shortcut could be the default? At least if the table says so in its definiation? Thanks!
mike-fabian
commented
2 years ago So, I have been able to solve both problems using ibus-table. I will take a look at the other libraries though.
As for having no keyboard shortcut for the toggle, somehow I did not realise that I could have left it at that, thank you for the info! But is there a way not having a shortcut could be the default? At least if the table says so in its definiation? Thanks!
Theoretically I could add such an option to the table definition.
But I think it is much better to use ibus-m17n/ibus-typing-booster for this and then we don’t need to add another option to ibus-table.
mike-fabian
commented
2 years ago The other thing is that in Indic scripts, every vowel has two characters: one which is 'independent' and acts like a letter, and one form which is attached to a consonant which is being spoken with that vowel's sound. In Unicode, these are registered separately: for the ee sound in 'keep', the characters in Unicode are ी for the dependent form which gets tacked onto a vowel while writing (की -> 'kee'), and its different, independent form (ई -> just 'ee'). All the available layouts print the useless ी when you press 'i' even if its the beginning of the word and there is no consonant before it for it to attach onto.
That sounds very much like the “automatic vowel forming” which I implemented for this Bengali input method recently:
https://github.com/mike-fabian/m17n-db-bn-national-jatiya https://raw.githubusercontent.com/mike-fabian/m17n-db-bn-national-jatiya/main/bn-national-jatiya.mim https://raw.githubusercontent.com/mike-fabian/m17n-db-bn-national-jatiya/main/icons/bn-national-jatiya.png
We could do the same for Hindi.
mike-fabian
commented
2 years ago I solved this by writing a program which writes the correct key combination ('kee') and then the correct character (the k symbol with the dependent 'ee', की) for all the possible combinations of vowels and consonants, which created a table of ~1500 key combinations which I directly pasted onto the table definition. Then, for the key combinations with just vowels, I added their independent form for those keys.
I think with m17n it is possible to do this in a more algorithmic way instead of writing out all possible key combinations.
ibus-table is kind of primitive, it is just a table with 3 columns:
input output priority
And you don’t need the priority for your input method because the results are unique, you don’t get popups with choices with different priorities like when typing Chinese.
If you look at a simple m17n input method like this one:
https://git.savannah.nongnu.org/cgit/m17n/m17n-db.git/tree/MIM/hi-phonetic.mim
This is also a kind of “table” with an input and an output column.
So your 1500 entry table can be easily translated into an m17n input method which does the same as your ibus-table input method.
But by adding a bit of code instead of spelling out all possible combinations it can be done better, I think.
mike-fabian
commented
2 years ago I am looking at https://baraha.com/help/Keyboards/dev-phonetic.htm now …
Can you also show me the table you made as an additional reference?
mike-fabian
commented
2 years ago Here is another somewhat more complicatead m17n input method for Marathi which seems to do similar stuff you want to do:
https://github.com/shantanuo/gamabhana/blob/main/usr/share/m17n/mr-gamabhana.mim
Azl-Eyekay
commented
2 years ago Hi, I have already used https://git.savannah.nongnu.org/cgit/m17n/m17n-db.git/tree/MIM/hi-phonetic.mim, it was the one I was pointing out the problems in.
I looked at your Bangla layout but unfortunately I couldn't figure out how it works, as it seems to have no correlation between the english key and the bangla characters, much like the Indian inscript keyboard . For some reason both India and Bangladesh governments are recommending keyboard layouts which require special keyboards with the local characters printed as well.
The Marathi layout seems the most interesting, so I installed it. Its features seems to check all the boxes. So it seems that I will use ibus-m17n after all.
Thank you so much for the help!
This is not related to this issue, but I was using the GNOME text editor (the gtk4 one) on Debian to test out the layout. It seems to suffer from a strange issue while typing: (Input was 'ghaMTaa ghar)
घंटअ घर घंटा घर घंटा घर घंअ घ्अर घंट घ्अर ग्हंटा घर घंटा घ्अर घंटा घर घंट्आ घर घंटा घ घ्अंटअ घर घंटा घर घंटा घर् घंटा घर घंआ घर
And these are not cherry-picked, this is directly copied after typing it 15 times. Same seems to be happening with ibus-table as well. Where should I report this?
mike-fabian
commented
2 years ago Hi, I have already used https://git.savannah.nongnu.org/cgit/m17n/m17n-db.git/tree/MIM/hi-phonetic.mim, it was the one I was pointing out the problems in.
I looked at your Bangla layout but unfortunately I couldn't figure out how it works, as it seems to have no correlation between the english key and the bangla characters, much like the Indian inscript keyboard . For some reason both India and Bangladesh governments are recommending keyboard layouts which require special keyboards with the local characters printed as well.
The Marathi layout seems the most interesting, so I installed it. Its features seems to check all the boxes. So it seems that I will use ibus-m17n after all.
Great!
If you have problems adapting this Marathi layout for your use, you can ask me again, I will try to help. I guess the author of that Marathi layout would also help.
Thank you so much for the help!
This is not related to this issue, but I was using the GNOME text editor (the gtk4 one) on Debian to test out the layout.
gnome-text-editor still seems to have a lot of problems at the moment, I would recommend to avoid using it for input methods at the moment. If you want a simple text editor for Gnome to use input methods in, I recommend the older “gedit”, this is more mature and more reliable at the moment. I hope gnome-text-editor will improve but at the moment it is not working well.
I just reported yet another issue with gnome-text-editor
mike-fabian
commented
2 years ago This is not related to this issue, but I was using the GNOME text editor (the gtk4 one) on Debian to test out the layout. It seems to suffer from a strange issue while typing: (Input was 'ghaMTaa ghar)
घंटअ घर घंटा घर
घंटा घर is the correct output for typing ghaMTaa ghar, right?
mike-fabian
commented
2 years ago The layouts require that the user instead press right Alt and that key for the proper form, which does not work on GNOME because you cant reassign that key in the keyboard layout as far as I am aware, and GNOME uses the right alt for bringing up the application menu.
Actually you can change that in the Gnome settings here:
mike-fabian
commented
2 years ago By the way, are you using Gnome on Xorg or Wayland?
I recommend Xorg for the moment, there are many more input related bugs on Gnome Wayland than on Gnome Xorg.
mike-fabian
commented
2 years ago This is not related to this issue, but I was using the GNOME text editor (the gtk4 one) on Debian to test out the layout. It seems to suffer from a strange issue while typing: (Input was 'ghaMTaa ghar)
घंटअ घर घंटा घर घंटा घर घंअ घ्अर घंट घ्अर ग्हंटा घर घंटा घ्अर घंटा घर घंट्आ घर घंटा घ घ्अंटअ घर घंटा घर घंटा घर् घंटा घर घंआ घर
And these are not cherry-picked, this is directly copied after typing it 15 times. Same seems to be happening with ibus-table as well. Where should I report this?
There was a very similar issue reported in Fedora 35:
https://bugzilla.redhat.com/show_bug.cgi?id=1850832
The problem occured only on Gnome Wayland, not on Gnome Xorg. At least on Fedora 32/33/34/35 I could reproduce the problem only on Gnome Wayland, not on Gnome Xorg.
Several input methods suffered from this problem, also the Korean input method ibus-hangul had this problem. I don’t remember testing this in ibus-table at that time.
When using ibus-m17n with gu-itrans or hi-itrans, the following is correct:
gu-itrans: kema chhe? ➡️ કેમ છે? hi-itrans: kaise ho? ➡️ कैसे हो?
And in Gnome Xorg this worked for me all of the time.
But in Gnome Wayland sometimes characters typed were disappearing.
Peng Wu made a merge request to fix this problem:
https://bugzilla.redhat.com/show_bug.cgi?id=1850832#c15
I tested it and it seemed to fix the problem for me.
It looks like this merge request has not been merged. Nevertheless I cannot reproduce the problem on Gnome Wayland in Fedora 37 anymore. Maybe other changes in Gnome Wayland fixed it.
mike-fabian
commented
2 years ago Also, when you really want to use Gnome Wayland, I can recommend to use ibus-typing-booster instead of ibus-m17n. I am not sure why but ibus-typing-booster suffers far less from this problem of disappearing characters or spaces inserted at wrong positions than ibus-m17n.
On Gnome Xorg, both ibus-m17n and ibus-typing-booster seemed to work fine in Fedora 35, on Gnome Wayland ibus-m17n had big problems but ibus-typing-booster mostly worked, only in very rare cases I got some spaces inserted at wrong positions when using ibus-typing-booster on Gnome Wayland.
mike-fabian
commented
2 years ago Here is a video using Gnome Wayland on Fedora 37 where I cannot reproduce problems when typing ghaMTaa ghar with ibus-m17n using mr-gamabhana:
https://user-images.githubusercontent.com/2330175/191050849-365bb478-dbcb-492b-981b-39e49acf88a6.mp4
mike-fabian
commented
2 years ago But better still avoid Wayland at the moment, and maybe also consider using ibus-typing-booster instead of ibus-m17n, that will avoid a few more bugs.
If you don’t want to use all the additional nice features ibus-typing-booster has like dictionary lookups and word completions, you can switch them all off and make ibus-typing-booster behave almost identical to ibus-m17n:
See: https://mike-fabian.github.io/ibus-typing-booster/docs/user/#2_2_1_1 “Simulate the behaviour of ibus-m17n”
mike-fabian
commented
2 years ago This is not related to this issue, but I was using the GNOME text editor (the gtk4 one) on Debian to test out the layout. It seems to suffer from a strange issue while typing: (Input was 'ghaMTaa ghar)
घंटअ घर घंटा घर घंटा घर घंअ घ्अर घंट घ्अर ग्हंटा घर घंटा घ्अर घंटा घर घंट्आ घर घंटा घ घ्अंटअ घर घंटा घर घंटा घर् घंटा घर घंआ घर
And these are not cherry-picked, this is directly copied after typing it 15 times. Same seems to be happening with ibus-table as well. Where should I report this?
I opened a new issue here:
https://github.com/ibus/ibus-m17n/issues/54
This is somehow different as it happens only in https://web.whatsapp.com whereas the old issue which was so similar to the problem you report here happened only in Wayland.
(old Wayland issue: https://bugzilla.redhat.com/show_bug.cgi?id=1850832 (The Gujarati & Hindi itrans methods are not able to type sentences correctly.) )
The old Wayland issue can be avoided by using Xorg and it might be already fixed in newer versions of Wayland.
The new issue https://github.com/ibus/ibus-m17n/issues/54 cannot be avoided so easily as it happens both on Wayland and Xorg.
As this happens with practially all ibus-m17n engines, I guess you might run into this as well.
A workaround is to use ibus-typing-booster instead of ibus-m17n.
Is your feature request related to a problem? Please describe. I know this software is somewhat inclined towards Chinese scripts, but I am currently making input methods for all the different Indian languages, using the same key combinations as the very popular but windows-only Baraha software. My grandparents, who offered to test this IME for me and are the ones who would greatly appreciate such software being authors themselves, will more often than not press the shift key and release it by mistake before trying the correct key combination (shift+letter) again. This makes ibus-table switch to direct mode, which is a feature I do not need as most people can have the default QWERTY english layout enabled as well anyway using the keyboard shortcut in ibus. So, I would like to know if it possible for the IME to disable this feature.
Describe the solution you'd like A way for IME which uses ibus-table to disable Ibus mode.
Describe alternatives you've considered Changing the keybinding to something unique and useless like ctrl+apace+alt+bksp, but that will cause confusion if somehow pressed accidently; and also this cannot be done by default.
Additional context
Thanks in advance!