Distribution
LMDE 7 - Cinnamon 64-bit
Package version
Cinnamon 6.6.7
Graphics hardware in use
NVIDIA Corporation GP108 [GeForce GT 1030]
Frequency
Always
Bug description
This is a follow-up to my final posting to 13280, which I inadvertantly added AFTER it was closed by the original poster. Just for info, my current version of iBus is 1.5.32. I keep the LMDE/Cinnamon system updated continuously, and believe I have all the necessary dependencies installed for the various IMEs I use, including the core m17n libraries, as well as specialty ones I need (e.g. libpinyin, a few tables, etc.) This will summarize the things I’ve run across while attempting to restore IME functionality. I’ve preceded each with how serious I believe it is given my own use cases.
-
(Significant Issue while troubleshooting, but normally not something I need to use very often):
Restarting Cinnamon (for testing while exploring the current issues) by using Alt+F2, then typing "r" does not work if any IME engine is active. I can't swear that this worked under the same condition in previous versions, but I believe I would have noticed if it hadn’t. This "system" key combination needs to be captured in the GUI of course, but PRIOR to any key codes reaching the IME, so this sounds like a “bug” to me. I have not tried similar combos e.g. Ctrl+Alt+Backspace since I'm too old to handle the stress.
-
(Serious)
Even with the recent (and welcome) changes, I have still been unable to get any specific hot-key combination to have any effect on what layout is active at any given time; only using the mouse with the panel icon permits that. That’s a serious usability issue.
Even more interesting is that every so often while typing away on auto-pilot, I find characters from some other language/writing system begin to appear; some unlisted key combination has activated a different IME. I suspect this is related to the previous entry (i.e. the point at which input is fed to the IME), since they just “smell” like similar issues. (also see PiskarevSA’s Feb 23rd comment above, vladmycode’s prior comment, and several others before those — I’d bet these stem from the same ultimate cause, since I’ve never experienced any of these things in any past distro, or even in past versions of LMDE)
-
(Trivial Issue)
In the “Choose a layout” dialog that pops up when "adding" a new layout, the default setting for the dialog's width is a bit narrow for many of the options; it might be nicer if it could be expanded so that at least the most common choices don't require the internal ellipses.
-
(Confusing Interface)
When highlighting an engine in the Enabled layouts (System > Settings > Keyboard > Layouts), the options shown when pressing the [Configure] button seem to be completely independent of those that appear when running ibus-setup from the command line. When testing the engines I've so far gotten to work under LMDE 7, it seems (!!) that the engines are using the option values shown for that engine in ibus-setup, not those shown in the Cinnamon GUI. This is particularly important for options like "🗹 Use US keyboard layout." All such options/configurations/etc should rely on the same/single source, and preferably that provided by the IME engine, since those engines may be periodically improved independently of any operating system using them.
-
(Very Serious, at least in my view)
In System Settıngs > Keyboard > Layouts, once you've added more than one writing system/keyboard layout, positioned the cursor over one of the engine choices, and pressed the ^ button to move that selection higher, the selection is indeed moved up, but the selection bar's focus is then immediately set to whatever engine is in the TOP position, and doesn't stay with the one you just moved. So, if you haven’t yet moved it as far up as you intended, you need to reselect it after each move.
“push” – a side comment here:
This may seem trivial if, as is currently the case, only four entries are possible. But such a limitation is arbitrary, severely limiting, and unnecessary; the layout switching bug reported in earlier forum discussions was fixed in iBus version 1.4.23, and operated correctly in LMDE 6 prior to the in-place LMDE 7 upgrade. So this seems (admittedly, to me, but I suspect to many, to be quite limiting. I use more than four fonts as well, which is not intended as a flippant comparison, but is actually very relevant in multi-lingual typing); there is no need to limit the number of fonts (and no one does of course) assuming the memory is there.
“pop” back to the quirks/bugs/whatever I’ve experienced with LMDE 7.
And if the engine you just reordered needs to be "configured," you MUST therefore pay much closer attention to the selection box than is usually required with such boxes to avoid inadvertently "configuring" a different engine.
-
(Confusing and possibly misleading to many users)
While this observation too may seem trivial, I was able to move any IME engine I selected to the very top position in the list, seeming to suggest that this layout MIGHT now be acting as the system keyboard layout in the now integrated dialog. A BIT of testing (and I'm fearful of going much further) seems to suggest that it (thankfully) isn't actually doing that, but I don't think this should even be permissible, since the aforementioned "🗹 Use US keyboard layout" setting for all/any other IME engines installed MIGHT then be undefined and cause havoc. Looking at System Settings > Languages > Language suggests that English is still actually the system layout in spite of its position in the list. At the risk of being repetitive, I don’t believe the system keyboard should be in the list at all, since it plays a much more important role in the system.
-
(Confusing and probably a holdover from the distant past)
Going to System Settings > Input Method, the user is offered seven options. The blurb for six of them suggests installing and using fcitx as the system IME. Only the seventh (Telugu) suggests installing ibus. I have no experience with Telugu, so I can't comment on that. It isn’t apparent to me why only seven are mentioned, or how those seven were chosen; I only mention it in case it is somehow relevant. But I do have some experience with the other six and don't believe these recommendations are very advisable for a number of reasons.
For example: Simplified (a relative term) Chinese (more correctly and specifically 汉字, the simplified "characters" or Hànzì used to write Mandarin) is used in "mainland" China. And I believe fcitx is indeed the most commonly used layout FOR PRIMARY KEYBOARDS in China, so the suggestion for fcitx is understandable, but keep that distinction in mind while reading the next few paragraphs.
Traditional Chinese refers to 漢字, the classic Hànzì used to write several other "Chinese" (or "Han") languages/dialects, such as Cantonese and several other Han siblings and cousins.
These terms both refer to what ultimately RESULTS from these inputs, though. Input Method Engines such as Pinyin (certainly the most common, and for which there are even multiple engines available) permit entering simplified Hànzì using characters from Latin Script (the same Script used by English, French, etc. for their alphabets). In Taiwan, an artificial “made-up” (in that it is only used, so far as I'm aware, to produce Hànzì) alphabet called 注音 (Zhuyin) is used. This rhymes with, and is colloquially called, "chewing" by westerners; in response, Mandarin-speaking users began referring to Zhuyin as "BoPoMoFo" after the alphabet's first four "letters" – poking fun at westerners' use of the equally meaningless term "qwerty" as an actual word.) All that trivia aside, however, having these recommendations on the language selection pages could well lead to some users of multiple engines possibly having both fcitx and ibus installed. In theory, that should work just fine. In reality, it often causes mystifying problems. Both ibus and fcitx should remain available, of course, but since ibus is typically installed by default in western distros, and has greater coverage, I believe the notes on those dialogs could do with an updated rewrite. Or something.
- (Annoying)
LMDE 7 now completely ignores the collection of m17n icons in /usr/share/m17n/icons as well as other .svg and .png icons for various engines scattered elsewhere around /usr/share/*/. Having a grey on black character as the only indicator of the keyboard state is still a problem when actually typing; something that pops out in the corner of one’s eye is even more important (in actual practice) than having indicators for caps lock, numlock, and their ilk.
Luckily, I got a private e-mail from a forum reader (who actually only uses one IME engine) suggesting that I look into the option "Use a country flag, if available, to represent keyboard layouts" (in System Settings > Hardware > Keyboard > Layouts), since the flag colors stood out more than the monochrome symbols.
I had seen this option before, but always ignored it, not quite "getting" the idea of associating a language or writing system with a flag, but decided to try it. The collection of flags (in /usr/share/iso-flag-png/) seemed colorful enough that the IME state would be more obvious when typing - and not be effectively camouflaged in the panel. Perhaps I could switch that option ON, copy the necessary IME icons over the relevant flags it it worked, and things would get slightly better.
I tried it, and my mood improved immediately, if only by making me laugh out loud and relieving the acute stress of the LMDE 7 upgrade. That’s why I’ve saved this eighth point for last. I suspect this is neither a Cinnamon nor even Mint-specific issue, and possibly older than Mint itself, but if you decide to make the IME symbolic icons accessible again (please...), it might be worth looking into this final discovery as well ...
So, before copying any icons over the flags, I activated the "Use a country flag..." option for “Arabic” (m17n:ar:kbd), my first engine (in alphabetic order), to see what would happen. Magically, the light blue and white flag of Argentina (ar.png) was displayed. I would have preferred the dark green flag of Saudi Arabia, but this was certainly a visible improvement over the grey on black "ي" character that I had to rely on after the LMDE 7 upgrade. I'm not sure this makes any sense even to Arabic-speaking Linux users in Argentina (there must be some, right?), but I feel vindicated in having kept my distance until now.
Inexplicably (to me anyway), the flags in /usr/share/m17n/icons turn out to be named with an ISO-639-* LANGUAGE code (hence the "iso" in the path name), and not named as you (well at least I) might have expected, for the country they represent (i.e. with an ISO-3166-* COUNTRY code).
To make things clear (well, possibly only a bit more translucent), the ISO-639 LANGUAGE code for “Arabic” is “ar.” The ISO-3166 COUNTRY code for “Saudi Arabia” is “sa.” The ISO-639 LANGUAGE code for “Spanish” is “es” (dialects, such as the Rioplatense Spanish spoken in Argentina, don’t have separate Language Codes.) The ISO-3166 COUNTRY code for “Argentina” is “ar.” In the Arabic engine I use, m17:ar:kbd, the “ar” refers to the Arabic LANGUAGE, and the “ar” in the flag image “ar.png” refers to the COUNTRY of Argentina.
The caveat "if available" in the Layouts dialog mentioned above isn't to be taken lightly, since many languages and/or writing systems for which an IME can be usefully employed actually aren't SPOKEN in any currently existing COUNTRY (e.g. the IPA/International Phonetic Alphabet, Cuneiform, Linear-B ...). Take "Church Slavic/Slavonic," for instance. Like Latin, Church Slavic is a third or fourth great-grandparent of a variety of languages currently spoken across multiple countries, each with its own flag (e.g. I count at least ten alphabetically, from Belarus to Ukraine). The ISO-639 code for the Old Slavic LANGUAGE is "cu," so of course we can now guess that the Cuban flag (whose ISO-3166 country code is "cu") will appear. Cuba’s ISO-639 LANGUAGE code, like Argentina’s is “es.”
Of course, a few lucky countries have identical ISO-639 and ISO-3166 codes so, for example, my substitute icons for English (us.png) and Turkish (tr.png) work fine as substitute "flags." Both French codes happen to be "fr," so if Clem uses an AZERTY IME with flag icons, "Le Tricolore" dutifully appears and he may never have noticed this issue either.
There are still a few flags (e.g. "gb.png" and "au.png") whose purpose is unclear though; luckily I haven't ever needed whatever bizarre languages are spoken in those obscure wilderness areas [apologies to my ex-colleagues in both delightful countries].
A few final notes on item #8, that may or may not be relevant:
a) The two character ISO-639 LANGUAGE codes are, by convention only, given as small/minuscule/lower case letters, e.g. “en” for English. The two character ISO-3166 COUNTRY codes are, also by convention, given as capital/majuscule/upper case characters, e.g. “US” for the United States. This distinction does not, however, appear to be required.
b) The Internet Engineering Task Force (IETF) has established a convention for Locale Codes, which are combinations that ATTEMPT to combine both of the above in a form such “en-US” for the “English as spoken in the U.S.” Since, for example, Linear-B isn’t spoken by anyone in any country, these parts of the Locale information in the computer often appear differently.
But this is enough poking about for one weekend. Thanks for listening.
Frank
Steps to reproduce
Add and attempt to use an additional keyboard layout. Steps beyond that depend on which ime is added, but details are given in the Bug Description above.
Expected behavior
Details are given in both my final posting to Bug #13280 (I missed the fact that it had closed) and supplemented by the closely-related Bug Description(s) above.
Additional information
The report posted above also attempts to explain WHY I believe some recent changes are "bugs" - or at least deficiencies - but I would be more than happy to answer any specific questions either here or off-line. As with the worlds' writing systems, IMEs range from fairly basic to very complex. I'm also willing to prepare some "tests" that don't require any detailed knowledge of some of the more arcane languages IMEs need to cover if that would help in any way.
Distribution
LMDE 7 - Cinnamon 64-bit
Package version
Cinnamon 6.6.7
Graphics hardware in use
NVIDIA Corporation GP108 [GeForce GT 1030]
Frequency
Always
Bug description
This is a follow-up to my final posting to 13280, which I inadvertantly added AFTER it was closed by the original poster. Just for info, my current version of iBus is 1.5.32. I keep the LMDE/Cinnamon system updated continuously, and believe I have all the necessary dependencies installed for the various IMEs I use, including the core m17n libraries, as well as specialty ones I need (e.g. libpinyin, a few tables, etc.) This will summarize the things I’ve run across while attempting to restore IME functionality. I’ve preceded each with how serious I believe it is given my own use cases.
(Significant Issue while troubleshooting, but normally not something I need to use very often):
Restarting Cinnamon (for testing while exploring the current issues) by using Alt+F2, then typing "r" does not work if any IME engine is active. I can't swear that this worked under the same condition in previous versions, but I believe I would have noticed if it hadn’t. This "system" key combination needs to be captured in the GUI of course, but PRIOR to any key codes reaching the IME, so this sounds like a “bug” to me. I have not tried similar combos e.g. Ctrl+Alt+Backspace since I'm too old to handle the stress.
(Serious)
Even with the recent (and welcome) changes, I have still been unable to get any specific hot-key combination to have any effect on what layout is active at any given time; only using the mouse with the panel icon permits that. That’s a serious usability issue.
Even more interesting is that every so often while typing away on auto-pilot, I find characters from some other language/writing system begin to appear; some unlisted key combination has activated a different IME. I suspect this is related to the previous entry (i.e. the point at which input is fed to the IME), since they just “smell” like similar issues. (also see PiskarevSA’s Feb 23rd comment above, vladmycode’s prior comment, and several others before those — I’d bet these stem from the same ultimate cause, since I’ve never experienced any of these things in any past distro, or even in past versions of LMDE)
(Trivial Issue)
In the “Choose a layout” dialog that pops up when "adding" a new layout, the default setting for the dialog's width is a bit narrow for many of the options; it might be nicer if it could be expanded so that at least the most common choices don't require the internal ellipses.
(Confusing Interface)
When highlighting an engine in the Enabled layouts (System > Settings > Keyboard > Layouts), the options shown when pressing the [Configure] button seem to be completely independent of those that appear when running ibus-setup from the command line. When testing the engines I've so far gotten to work under LMDE 7, it seems (!!) that the engines are using the option values shown for that engine in ibus-setup, not those shown in the Cinnamon GUI. This is particularly important for options like "🗹 Use US keyboard layout." All such options/configurations/etc should rely on the same/single source, and preferably that provided by the IME engine, since those engines may be periodically improved independently of any operating system using them.
(Very Serious, at least in my view)
In System Settıngs > Keyboard > Layouts, once you've added more than one writing system/keyboard layout, positioned the cursor over one of the engine choices, and pressed the ^ button to move that selection higher, the selection is indeed moved up, but the selection bar's focus is then immediately set to whatever engine is in the TOP position, and doesn't stay with the one you just moved. So, if you haven’t yet moved it as far up as you intended, you need to reselect it after each move.
“push” – a side comment here:
This may seem trivial if, as is currently the case, only four entries are possible. But such a limitation is arbitrary, severely limiting, and unnecessary; the layout switching bug reported in earlier forum discussions was fixed in iBus version 1.4.23, and operated correctly in LMDE 6 prior to the in-place LMDE 7 upgrade. So this seems (admittedly, to me, but I suspect to many, to be quite limiting. I use more than four fonts as well, which is not intended as a flippant comparison, but is actually very relevant in multi-lingual typing); there is no need to limit the number of fonts (and no one does of course) assuming the memory is there.
“pop” back to the quirks/bugs/whatever I’ve experienced with LMDE 7.
And if the engine you just reordered needs to be "configured," you MUST therefore pay much closer attention to the selection box than is usually required with such boxes to avoid inadvertently "configuring" a different engine.
(Confusing and possibly misleading to many users)
While this observation too may seem trivial, I was able to move any IME engine I selected to the very top position in the list, seeming to suggest that this layout MIGHT now be acting as the system keyboard layout in the now integrated dialog. A BIT of testing (and I'm fearful of going much further) seems to suggest that it (thankfully) isn't actually doing that, but I don't think this should even be permissible, since the aforementioned "🗹 Use US keyboard layout" setting for all/any other IME engines installed MIGHT then be undefined and cause havoc. Looking at System Settings > Languages > Language suggests that English is still actually the system layout in spite of its position in the list. At the risk of being repetitive, I don’t believe the system keyboard should be in the list at all, since it plays a much more important role in the system.
(Confusing and probably a holdover from the distant past)
Going to System Settings > Input Method, the user is offered seven options. The blurb for six of them suggests installing and using fcitx as the system IME. Only the seventh (Telugu) suggests installing ibus. I have no experience with Telugu, so I can't comment on that. It isn’t apparent to me why only seven are mentioned, or how those seven were chosen; I only mention it in case it is somehow relevant. But I do have some experience with the other six and don't believe these recommendations are very advisable for a number of reasons.
For example: Simplified (a relative term) Chinese (more correctly and specifically 汉字, the simplified "characters" or Hànzì used to write Mandarin) is used in "mainland" China. And I believe fcitx is indeed the most commonly used layout FOR PRIMARY KEYBOARDS in China, so the suggestion for fcitx is understandable, but keep that distinction in mind while reading the next few paragraphs.
Traditional Chinese refers to 漢字, the classic Hànzì used to write several other "Chinese" (or "Han") languages/dialects, such as Cantonese and several other Han siblings and cousins.
These terms both refer to what ultimately RESULTS from these inputs, though. Input Method Engines such as Pinyin (certainly the most common, and for which there are even multiple engines available) permit entering simplified Hànzì using characters from Latin Script (the same Script used by English, French, etc. for their alphabets). In Taiwan, an artificial “made-up” (in that it is only used, so far as I'm aware, to produce Hànzì) alphabet called 注音 (Zhuyin) is used. This rhymes with, and is colloquially called, "chewing" by westerners; in response, Mandarin-speaking users began referring to Zhuyin as "BoPoMoFo" after the alphabet's first four "letters" – poking fun at westerners' use of the equally meaningless term "qwerty" as an actual word.) All that trivia aside, however, having these recommendations on the language selection pages could well lead to some users of multiple engines possibly having both fcitx and ibus installed. In theory, that should work just fine. In reality, it often causes mystifying problems. Both ibus and fcitx should remain available, of course, but since ibus is typically installed by default in western distros, and has greater coverage, I believe the notes on those dialogs could do with an updated rewrite. Or something.
LMDE 7 now completely ignores the collection of m17n icons in /usr/share/m17n/icons as well as other .svg and .png icons for various engines scattered elsewhere around /usr/share/*/. Having a grey on black character as the only indicator of the keyboard state is still a problem when actually typing; something that pops out in the corner of one’s eye is even more important (in actual practice) than having indicators for caps lock, numlock, and their ilk.
Luckily, I got a private e-mail from a forum reader (who actually only uses one IME engine) suggesting that I look into the option "Use a country flag, if available, to represent keyboard layouts" (in System Settings > Hardware > Keyboard > Layouts), since the flag colors stood out more than the monochrome symbols.
I had seen this option before, but always ignored it, not quite "getting" the idea of associating a language or writing system with a flag, but decided to try it. The collection of flags (in /usr/share/iso-flag-png/) seemed colorful enough that the IME state would be more obvious when typing - and not be effectively camouflaged in the panel. Perhaps I could switch that option ON, copy the necessary IME icons over the relevant flags it it worked, and things would get slightly better.
I tried it, and my mood improved immediately, if only by making me laugh out loud and relieving the acute stress of the LMDE 7 upgrade. That’s why I’ve saved this eighth point for last. I suspect this is neither a Cinnamon nor even Mint-specific issue, and possibly older than Mint itself, but if you decide to make the IME symbolic icons accessible again (please...), it might be worth looking into this final discovery as well ...
So, before copying any icons over the flags, I activated the "Use a country flag..." option for “Arabic” (m17n:ar:kbd), my first engine (in alphabetic order), to see what would happen. Magically, the light blue and white flag of Argentina (ar.png) was displayed. I would have preferred the dark green flag of Saudi Arabia, but this was certainly a visible improvement over the grey on black "ي" character that I had to rely on after the LMDE 7 upgrade. I'm not sure this makes any sense even to Arabic-speaking Linux users in Argentina (there must be some, right?), but I feel vindicated in having kept my distance until now.
Inexplicably (to me anyway), the flags in /usr/share/m17n/icons turn out to be named with an ISO-639-* LANGUAGE code (hence the "iso" in the path name), and not named as you (well at least I) might have expected, for the country they represent (i.e. with an ISO-3166-* COUNTRY code).
To make things clear (well, possibly only a bit more translucent), the ISO-639 LANGUAGE code for “Arabic” is “ar.” The ISO-3166 COUNTRY code for “Saudi Arabia” is “sa.” The ISO-639 LANGUAGE code for “Spanish” is “es” (dialects, such as the Rioplatense Spanish spoken in Argentina, don’t have separate Language Codes.) The ISO-3166 COUNTRY code for “Argentina” is “ar.” In the Arabic engine I use, m17:ar:kbd, the “ar” refers to the Arabic LANGUAGE, and the “ar” in the flag image “ar.png” refers to the COUNTRY of Argentina.
The caveat "if available" in the Layouts dialog mentioned above isn't to be taken lightly, since many languages and/or writing systems for which an IME can be usefully employed actually aren't SPOKEN in any currently existing COUNTRY (e.g. the IPA/International Phonetic Alphabet, Cuneiform, Linear-B ...). Take "Church Slavic/Slavonic," for instance. Like Latin, Church Slavic is a third or fourth great-grandparent of a variety of languages currently spoken across multiple countries, each with its own flag (e.g. I count at least ten alphabetically, from Belarus to Ukraine). The ISO-639 code for the Old Slavic LANGUAGE is "cu," so of course we can now guess that the Cuban flag (whose ISO-3166 country code is "cu") will appear. Cuba’s ISO-639 LANGUAGE code, like Argentina’s is “es.”
Of course, a few lucky countries have identical ISO-639 and ISO-3166 codes so, for example, my substitute icons for English (us.png) and Turkish (tr.png) work fine as substitute "flags." Both French codes happen to be "fr," so if Clem uses an AZERTY IME with flag icons, "Le Tricolore" dutifully appears and he may never have noticed this issue either.
There are still a few flags (e.g. "gb.png" and "au.png") whose purpose is unclear though; luckily I haven't ever needed whatever bizarre languages are spoken in those obscure wilderness areas [apologies to my ex-colleagues in both delightful countries].
A few final notes on item #8, that may or may not be relevant:
a) The two character ISO-639 LANGUAGE codes are, by convention only, given as small/minuscule/lower case letters, e.g. “en” for English. The two character ISO-3166 COUNTRY codes are, also by convention, given as capital/majuscule/upper case characters, e.g. “US” for the United States. This distinction does not, however, appear to be required.
b) The Internet Engineering Task Force (IETF) has established a convention for Locale Codes, which are combinations that ATTEMPT to combine both of the above in a form such “en-US” for the “English as spoken in the U.S.” Since, for example, Linear-B isn’t spoken by anyone in any country, these parts of the Locale information in the computer often appear differently.
But this is enough poking about for one weekend. Thanks for listening.
Frank
Steps to reproduce
Add and attempt to use an additional keyboard layout. Steps beyond that depend on which ime is added, but details are given in the Bug Description above.
Expected behavior
Details are given in both my final posting to Bug #13280 (I missed the fact that it had closed) and supplemented by the closely-related Bug Description(s) above.
Additional information
The report posted above also attempts to explain WHY I believe some recent changes are "bugs" - or at least deficiencies - but I would be more than happy to answer any specific questions either here or off-line. As with the worlds' writing systems, IMEs range from fairly basic to very complex. I'm also willing to prepare some "tests" that don't require any detailed knowledge of some of the more arcane languages IMEs need to cover if that would help in any way.