Fedora Account System
Red Hat Associate
Red Hat Customer
Most people in Hong Kong use either Cangjie or Quick input methods. This is why back in 2012 with a few others I set up to implement both in ibus-cangjie. https://gitlab.freedesktop.org/cangjie/ibus-cangjie/ We've had some great success, and quite a few people are using it now. Whether it provides an inferior or superior experience compared to ibus-table-chinese-{cangjie,quick} is a matter of taste I guess, so let's not get into that particular flamewar 😄 However, the fact is that ibus-table-chinese-{cangjie,quick} are installed automatically as dependencies of lanpacks-zh_HK, which is a bit unfair and doesn't provide a healthy competition environment where both are equally as easy to install. 😁 We could fix that by adding ibus-cangjie as a dependency of the langpacks-zh_HK package, then both would be presented alongside. 😊 Reproducible: Always Steps to Reproduce: 1. sudo dnf install langpacks-zh_HK Actual Results: ibus-cangjie is not offered. 😢 Expected Results: ibus-cangjie would be at least suggested
I am a Linux user from Hong Kong and ibus-cangjie served me very well over the years. It will be great if ibus-cangjie can be added as a dependency to the langpacks-zh_HK package.
Have you tried ibus-table Cangjie? How does it compare to ibus-cangjie. Actually we had the impression earlier that ibus-cangjie was less active, so Mike Fabian put in some effort to improve ibus-table Cangjie. It would be great if you could test it and report on the main differences you see.
Hi Jens, how are you? So, yes, ibus-cangjie has been inactive for a while because I got hit by a bus: or rather, I caughe a bad flu in 2020 which attacked my brain an spinal chord, leaving me paraplegic with cognitive troubles. 😭 I then spent almost 2 years in a reeducation center to come back to active life. But since 2022/2023, I'm back at it and started maintaining ibus-cangjie again. 😉 I'll let my comaintainer, Koala to talk about the differences between the two has he's both a Cangjie user (I'm not as I'm still French and can't read or write Chinese 😅) and a Hong Kong person who can advocate others to using either input methods, just like Haggen in comment #1 above. We're about to have a new release very soon (2.5) as soon as we finish with the last few merge requests: https://gitlab.freedesktop.org/cangjie/ibus-cangjie/-/merge_requests If there's anything we can do for you or the rest of the IBus team, do let us know 😊
Hi Jens, There are 1 few difference: 1. The most notable feature of ibus-cangjie is the wildcard matching. It is excellent to use when forgetting some of the radicals of a character. ibus-tables-cangjie，I believe, does not support that at all. 2. I am used to traditional Cangjie setup in Windows. ibus-cangjie works exactly like that out of the box whereas ibus-table-cangjie needs some configurations to work (e.g. single radical character behaviour, shortcut for switching between Chinese and English mode). It also has additional feature (e.g. right-shift toggle to and from pinyin mode) that, while might be useful to some, obstructs the usual typing flow of users from other platforms. 3. One thing missing from both in ibus-tables-cangjie and ibus-cangjie is "related-vocab suggestion". I'm not sure how feasible to work it into ibus-table (considering it has to also support other input methods). ibus-cangjie would be a much cleaner canvas for such feature in a way that is comparable to other platforms (i.e. Windows, macOS). The main target of ibus-cangjie is to prioritize out-of-the-box familiarity to users from other platforms.
(In reply to Koala Yeung from comment #4) > Hi Jens, > > There are 1 few difference: > > 1. The most notable feature of ibus-cangjie is the wildcard matching. It is > excellent to use when forgetting some of the radicals of a character. > ibus-tables-cangjie，I believe, does not support that at all. Can you give an example for that wildcard matching? ibus-table does have wildcard matching and I wonder what exactly the difference is. > 2. I am used to traditional Cangjie setup in Windows. ibus-cangjie works > exactly like that out of the box whereas ibus-table-cangjie needs some > configurations to work (e.g. single radical character behaviour, shortcut > for switching between Chinese and English mode). You mean you don’t like the default of Shift_L to switch between Chinese and English mode? > It also has additional > feature (e.g. right-shift toggle to and from pinyin mode) that, while might > be useful to some, obstructs the usual typing flow of users from other > platforms. Keybindings are configurable of course. > 3. One thing missing from both in ibus-tables-cangjie and ibus-cangjie is > "related-vocab suggestion". I'm not sure how feasible to work it into > ibus-table (considering it has to also support other input methods). Can you give an example for what you would like to have there? Does such a feature exist on the Cangjie on Windows or MacOS?
Hi Mike, > Can you give an example for that wildcard matching? > > ibus-table does have wildcard matching and I wonder what exactly the difference > is. So the wildcard matching is when you type a "*" in the middle of the code, so you do like "d*d" and you get all the candidates that start with a "d" and end with a "d", like 李, 林, 株, ... And in the next release, we now in addition give the actual codes that would need to be typed to get the proper Cangjie code of each character, see this merge request for examples in screenshots: https://gitlab.freedesktop.org/cangjie/ibus-cangjie/-/merge_requests/134 It is now merged in main, but not released yet, so it will be in 2.5. 😉️ > 2. I am used to traditional Cangjie setup in Windows. ibus-cangjie works > exactly like that out of the box whereas ibus-table-cangjie needs some > configurations to work (e.g. single radical character behaviour, shortcut > for switching between Chinese and English mode). > > You mean you don’t like the default of Shift_L to switch between Chinese and > English mode? That feature was in ibus-table as well? It wasn't in ibus-cangjie, until this MR: https://gitlab.freedesktop.org/cangjie/ibus-cangjie/-/merge_requests/115 Same, it's in main, but hasn't been released yet, it will be in 2.5 😉️ > It also has additional > feature (e.g. right-shift toggle to and from pinyin mode) that, while might > be useful to some, obstructs the usual typing flow of users from other > platforms. > > Keybindings are configurable of course. > > 3. One thing missing from both in ibus-tables-cangjie and ibus-cangjie is > "related-vocab suggestion". I'm not sure how feasible to work it into > ibus-table (considering it has to also support other input methods). > > Can you give an example for what you would like to have there? Does such a > feature exist on the Cangjie on Windows or MacOS? Koala would answer that better than I could, but I think the idea is that some characters are very often immediately followed by another one, and so when inputting one character we would suggest the most likely next ones. 🤷️ That hasn't been implemented in ibus-cangjie at all for now, but Koala has some ideas of how it might be done and could work.
(In reply to Mathieu Bridon from comment #6) > Hi Mike, > > > Can you give an example for that wildcard matching? > > > > ibus-table does have wildcard matching and I wonder what exactly the difference > > is. > > So the wildcard matching is when you type a "*" in the middle of the code, > so you do like "d*d" and you get all the candidates that start with a "d" > and end with a "d", like 李, 林, 株, ... > > And in the next release, we now in addition give the actual codes that would > need to be typed to get the proper Cangjie code of each character, see this > merge request for examples in screenshots: > https://gitlab.freedesktop.org/cangjie/ibus-cangjie/-/merge_requests/134 ibus-table already supports all of this. It has configurable wildcards, one can for example use `*` for multiple keys and `?` for single keys or other characters. For the cangjie tables the wildcard settings are empty by default, so one needs to open the setup tool and set wildcard keys. For some other tables like stroke5, wildcards are enabled by default. I wonder whether the cangjie tables should enable them by default. That would be a very simple change. Here one sees that none of the cangie tables (cangjie-big, cangjie5, cangjie3) have wildcards enabled by default but stroke5 for example has it enabled by default: mfabian@hathi:/local/mfabian/src/ibus-table-chinese/tables (release-candidate-1.8.12 %) $ grep -i wildcard {cangjie,stroke5}/*.txt cangjie/cangjie-big.txt:### If true then a multi wildcard will be appended cangjie/cangjie-big.txt:AUTO_WILDCARD = TRUE cangjie/cangjie-big.txt:### Single wildcard char, can have multiple chars. cangjie/cangjie-big.txt:### SINGLE_WILDCARD_CHAR = * cangjie/cangjie-big.txt:### Multi wildcard char. cangjie/cangjie-big.txt:MULTI_WILDCARD_CHAR = * cangjie/cangjie5.txt:### Single wildcard char, can have multiple chars. cangjie/cangjie5.txt:### SINGLE_WILDCARD_CHAR = * stroke5/stroke5.txt:### If true then a multi wildcard will be automatically appended stroke5/stroke5.txt:AUTO_WILDCARD = TRUE stroke5/stroke5.txt:### Single wildcard char stroke5/stroke5.txt:SINGLE_WILDCARD_CHAR = ? stroke5/stroke5.txt:### Multi wildcard char. stroke5/stroke5.txt:MULTI_WILDCARD_CHAR = * mfabian@hathi:/local/mfabian/src/ibus-table-chinese/tables (release-candidate-1.8.12 %) $
Created attachment 2057268 [details] Screenshot-ibus-table-cangie3-wildcards.png The setup tool shows that wildcards `*` and `?` are set. I typed `d*r`. The preedit shows 杏 (the shortest match). The auxiliary text shows in purple what has been typed: `木*口` (木 is on the `d` key and 口 is on the `r` key). The candidate list shows the possible matches, for example: 1 杏 木口 ⬅️ means you can get 杏 just by typing 杏 2 桔 木土口 ⬅️ means you can get 桔 by typing 木土口 (`dgr` keys) ... There is also an ☑️ Auto wildcard feature if that is checked, then a multicharacter wildcard is always **appended** to the input.
(In reply to Mathieu Bridon from comment #6) > Hi Mike, > > You mean you don’t like the default of Shift_L to switch between Chinese and > > English mode? > > That feature was in ibus-table as well? Yes, the left shift key toggles between Chinese and English by default. keybindings are configurable in the setup tool so you could easily change it to use a different key or disable it completely. If Shift keys only are used for a keybinding, they have to be pressed **and** released, just as it iis written in https://gitlab.freedesktop.org/cangjie/ibus-cangjie/-/merge_requests/115 > It wasn't in ibus-cangjie, until this MR: > https://gitlab.freedesktop.org/cangjie/ibus-cangjie/-/merge_requests/115 > > Same, it's in main, but hasn't been released yet, it will be in 2.5 😉️ > > > It also has additional > > feature (e.g. right-shift toggle to and from pinyin mode) that, while might > > be useful to some, obstructs the usual typing flow of users from other > > platforms. By default, this keybinding for switch to pinyin mode is on the right shift key. This can be easily changed or disabled.
Right, so that would be the first difference to ibus-cangjie:by default the right shift key does nothing, and switching to Pinyin is useless for Cangjie typists... IIRC the left key toggle is disabled by default and needs to be explicitly enabled for those who want this feature but to not disturb experienced typists. The fact things can be easily disabled or changed doesn't change the fact that the default behavior can trip up experienced typists, it's one more option which means one more possibility to break things. Instead, we prefer the gnome way in ibus-cangjie:only add options when they are needed, and try to do the right thing by default. 🤷
If pinyin is really useless for Cangjie typists, one could disable it in the cangjie tables: mfabian@hathi:/local/mfabian/src/ibus-table-chinese/tables/cangjie (release-candidate-1.8.12 %) $ grep -i pinyin cangjie*.txt cangjie-big.txt:### Whether support PinYin Mode, default is false. cangjie-big.txt:PINYIN_MODE = TRUE cangjie3.txt:### Whether support PinYin Mode, default is false. cangjie3.txt:PINYIN_MODE = TRUE cangjie5.txt:### Whether support PinYin Mode, default is false. cangjie5.txt:PINYIN_MODE = TRUE mfabian@hathi:/local/mfabian/src/ibus-table-chinese/tables/cangjie (release-candidate-1.8.12 %) $ But then there would be no way to turn it on later, the pinyin information would then not be added when the table is compiled, i.e. `PINYIN_MODE = TRUE` is a compile time option, not a runtime option. I could also make the keybinding for switching to pinyin empty by default when a cangjie table is used, then the information would still be compiled into the table, and one could still enable it by setting a key binding but it would not be there by default. I am not sure whether switching to pinyin is useless. It is probably useless for experienced Cangjie typists, but probably not for beginners. The situation is the same for all the other Chinese tables which enable pinyin: For example wubi or stroke5 input methods are also radical or stroke based and not phonetic like pinyin. So one could argue that a pinyin mode is useless when you have mastered these input methods. But for beginners maybe not. Of course pinyin is probably useless for anybody who does not speak Mandarin, for Cantonese it is probaby useless as the phonetics are different.
(In reply to Mathieu Bridon from comment #6) > > 3. One thing missing from both in ibus-tables-cangjie and ibus-cangjie is > > "related-vocab suggestion". I'm not sure how feasible to work it into > > ibus-table (considering it has to also support other input methods). > > > > Can you give an example for what you would like to have there? Does such a > > feature exist on the Cangjie on Windows or MacOS? > > Koala would answer that better than I could, but I think the idea is that > some characters are very often immediately followed by another one, and so > when inputting one character we would suggest the most likely next ones. 🤷️ So basically what ibus-typing-booster does for non-CJK scripts ... > That hasn't been implemented in ibus-cangjie at all for now, but Koala has > some ideas of how it might be done and could work. Actually ibus-table already has such a feature, it was implemented by Peng Wu. **But** it is only enabled for one Wubi table: mfabian@hathi:/local/mfabian/src/ibus-table-chinese/tables (release-candidate-1.8.12 %) $ grep SUGGESTION_MODE */*.txt cangjie/cangjie-big.txt:SUGGESTION_MODE = FALSE cangjie/cangjie3.txt:SUGGESTION_MODE = FALSE cangjie/cangjie5.txt:SUGGESTION_MODE = FALSE cantonese/cantonese.txt:SUGGESTION_MODE = FALSE cantonese/cantonhk.txt:SUGGESTION_MODE = FALSE cantonese/cantonyale.txt:SUGGESTION_MODE = FALSE cantonese/jyutping.txt:SUGGESTION_MODE = FALSE easy/easy-big.txt:SUGGESTION_MODE = FALSE erbi/erbi-qs.txt:SUGGESTION_MODE = FALSE erbi/erbi.txt:SUGGESTION_MODE = FALSE quick/quick-classic.txt:SUGGESTION_MODE = FALSE quick/quick3.txt:SUGGESTION_MODE = FALSE quick/quick5.txt:SUGGESTION_MODE = FALSE scj/scj6.txt:SUGGESTION_MODE = FALSE stroke5/stroke5.txt:SUGGESTION_MODE = FALSE wu/wu.txt:SUGGESTION_MODE = FALSE wubi-jidian/wubi-jidian86.txt:SUGGESTION_MODE = TRUE yong/yong.txt:SUGGESTION_MODE = FALSE mfabian@hathi:/local/mfabian/src/ibus-table-chinese/tables (release-candidate-1.8.12 %) $ **Only** the wubi-jidian86.txt table has SUGGESTION_MODE = TRUE. I am not sure why, the list of possible completions might depend on the dialect of Chinese, maybe the current list of completions used is only useful for wubi-jidian86 users and would not be helpful for Cangjie users? I don't know. I'll attach a video showing how that completion mode works with the wubi-jidian86 table ... Not sure whether it would be useful to enable this for Cangjie as well and whether a different table of completions would be needed ...
Created attachment 2057284 [details] Video demonstrating suggestion mode with the wubi-jidian86 table - Choosing wubi-jidian86 - Enabling suggestion mode - typing one Chinese character - committing that character Now a list of possible continuations of the character typed appears.
> Of course pinyin is probably useless for anybody who does not speak Mandarin, for Cantonese it is probaby useless as the phonetics are different. That's pretty much it, yes, most people in HK do not speak Mandarin HK doesn't speak Mandarin, it's basically a foreign language for them, despite the abusive efforts of the PRC to make it their first language. They speak Cantonese indeed, and have their own phonetics system: Jyutping: https://en.wikipedia.org/wiki/Jyutping Except most HK people don't know that either, unless they've learned it at university or similar higher education. Koala, do you know Jyutping? I know for a fact my ex wife doesn't, and she only speaks 4 languages (2 of them being Chinese: Cantonese and Mandarin) and is proficient in writing all of them. (well, except Simplified Chinese, she needs to search hard in her memory to remember the characters...) So yes, Pinyin is entirely useless for HK folks, and so would be Jyutping. HK people know either Cangjie or Quick (most of them know Quick, which is why we made that feature to help them learn Cangjie if they choose to). I'm not saying IBus Table Cangjie is useless, I just know for a fact that Koala and I spent a long time since 2012 to make and improve IBus Cangjie to where it is now, and we're actively continuing to do so. Give or take those 2 years I spent in a coma then coming back to life. That's a pretty extreme example of the proverbial "being hit by a bus": just catch a stupid seasonal flu like everybody does each year, and then you're done. 😭😡
(In reply to Mathieu Bridon from comment #14) > I'm not saying IBus Table Cangjie is useless, I just know for a fact that > Koala and I spent a long time since 2012 to make and improve IBus Cangjie to > where it is now, and we're actively continuing to do so. I am doing that for ibus-table as well. And some of the features like - the wildcards and showing which complete series of keys you would need to type to get a certain character you have matched using wildcards - the configurable mode switch with indicator which you have just recently implemented in ibus-cangjie have already been available in ibus-table since a **very** long time. I am not sure whether I should disable pinyin in the ibus-table cangjie tables just because I am not sure whether cangjie isn't also used in Taiwan. I have been told it has some popularity in Taiwan as well and people from Taiwan would know pinyin.
Taiwan people do use Cangjie as well, however I don't think they use Pinyin: they have their own sound based input method: Bopomofo https://en.wikipedia.org/wiki/Bopomofo
> I am doing that for ibus-table as well. And I am saying thank you very much for that work which is probably very useful to a lot of people, but you don't actually need to now, at least not for Cangjie and Quick. At the time I started ibus-cangjie it was because every user I talked to in HK told me the same thing: ibus-table is hard to use and doesn't give the results in the order they expect. I fixed that with ibus-cangjie. Not perfectly, but we're working on it and getting there. > And some of the features like > > - the wildcards and showing which complete series of keys you would need to type to get a certain character you have matched using wildcards > - the configurable mode switch with indicator > > which you have just recently implemented in ibus-cangjie have already been available in ibus-table since a **very** long time. Cool, however we didn't know about that and that's not the reason why we re-implemented those. We did the shift thing because Koala had been wanting a "pass-through" mode for years, and the wildcard to help people learning the Cangjie code because someone had submitted a PR on Github https://github.com/Cangjians/ibus-cangjie/pull/84 Notice the date: 2017. I got sick in early 2019 and that's when I lost 2+ years of my life. I couldn't merge this code until when I did it, because coma, re-education, brain trouble, wheelchair. If you want my working rhythm, you can have my paraplegia and nervous system issues. 🤷
With ibus-cangjie, we meant to create an input experience cater for Hong Kong people. Majority of Hong Kong people has Cantonese as mothertongue. The education system to not teach any Cantonese phonetic system. Mandarin and pinyin is taught but is not popular in daily use. And there are at least 3 phonetics system for Cantonese that uses roman characters. So if a system were to cater for HK people with some additional phonetic system support, it is probably best done in Google's (Android) Cantonese input method. That is to support all 3 types of phonetic systems at the same time. And even as such, we don't usually mix phonetic input system into Cangjie input method. Rather we would usually install and use as a different input method. I would not want to take away previous efforts to add features to the system. It is handy for a small subset of HK people who is proficient in both Cangjie and pinyin, but I'd say this is not the input experience that I, or fellow HK Cangjie users, would prefer. In the spirit of open source system, if we have contributors on an active project for a dedicated solution, I find it difficult to understand why we should sacrifice a more tailor-made out-of-box solution and have a compromises for a generalized system with tradeoffs configs to support other unrelated input methods. I mean it is great that you support input methods without active developer working on it. But I don't think this is the case that we're talking about.
(In reply to Mathieu Bridon from comment #17) > At the time I started ibus-cangjie it was because every user I talked to in > HK told me the same thing: ibus-table is hard to use and doesn't give the > results in the order they expect. > > I fixed that with ibus-cangjie. Not perfectly, but we're working on it and > getting there. Between 2020 and 2022 there have been quite a few improvements in the cangjie tables of ibus table concerning ordering. For example this https://github.com/mike-fabian/ibus-table/issues/87 and several others. If there are any differences in ordering the results between ibus-cangjie and ibus-table cangjie, please tell me, I would of course like to know and improve it further. It is already much better than it was initially when I took over maintenance of ibus table, also because I use Big5 order as a tie breaker when the weights in the table are equal. The function “best_candidates()” which orders the candidates is here: https://github.com/mike-fabian/ibus-table/blob/main/engine/tabsqlitedb.py#L966 Cangjie users will probably use the "only traditional Chinese characters" option, i.e. chinese mode is not in (2, 3) and the chinese_variants.detect_chinese_category() is not used either because it will go to this part: return sorted(candidates, key=lambda x: ( - int( typed_tabkeys == x[0] ), # exact matches first! pinyin_exact_match_function(x[0]), -1*x[3], # user_freq descending -1*x[2], # freq descending len(x[0]), # len(tabkeys) ascending x[0], # tabkeys alphabetical code_point_function(x[1][0]), # Unicode codepoint of first character of phrase: ord(x[1][0]) ))[:maximum_number_of_candidates] exact matches are put on top. pinyin_exact_match_function does nothing for the ordering unless pinyin is really used. "user_freq" in that ordering function does nothing for the ordering for the cangjie and quick tables because all of them have DYNAMIC_ADJUST set to FALSE. "freq" are the weights from the tables. I.e. if there are several entries in the table for the same input sequence (anau in this example): anau 冕 500 anau 晚 495 then the one with higher weight comes first. shorter matches come first if wildcards are used. I.e. here an 門 500 ana 間 500 門 would come first if the user typed only “an” and 間 was only matched because the wildcard match “an*” was used. “tabkeys alphabetical” only does something if wildcards are used **and** the lengths of two wildcard matches is already the same (If the user typed everything without wildcards, ordering that alphabetical does nothing) If the ordering key is still the same up to here, code_point_function is used as a tie breaker. code_point_function is set to self.big5_code for the cangjie and quick tables only, for the other Chinese tables code_point_function is set to something doing nothing. And if the ordering key is is still the same after applying code_point_function (can only happen if the character is not in Big5, should be very rare), the Unicode code point is used as a last ditch tie breaker.
(In reply to Koala Yeung from comment #18) > I would not want to take away previous efforts to add features to the > system. It is handy for a small subset of HK people who is proficient in > both Cangjie and pinyin, but I'd say this is not the input experience that > I, or fellow HK Cangjie users, would prefer. > > In the spirit of open source system, if we have contributors on an active > project for a dedicated solution, I find it difficult to understand why we > should sacrifice a more tailor-made out-of-box solution and have a > compromises for a generalized system with tradeoffs configs to support other > unrelated input methods. Maybe there is a misunderstanding here. I am not against installing ibus-cangjie by default for zh_HK. And I am not against making it the default either. ibus-cangjie was the default input method for zh_HK in Fedora in the past. The **only** reason why we changed that was this: https://github.com/Cangjians/ibus-cangjie/pull/100 The setup tool crashed, I made a quick fix, but upstream was unresponsive. If ibus-cangjie is actively developed again, I have nothing against installing it by default for zh_HK **and** making it the default input method for zh_HK. > I mean it is great that you support input methods without active developer > working on it. But I don't think this is the case that we're talking about. If ibus-cangjie is active again, then it is perfectly fine. Only because it appeared completely inactive we changed the default to ibus-table.
(In reply to Mike FABIAN from comment #20) > (In reply to Koala Yeung from comment #18) > > > I would not want to take away previous efforts to add features to the > > system. It is handy for a small subset of HK people who is proficient in > > both Cangjie and pinyin, but I'd say this is not the input experience that > > I, or fellow HK Cangjie users, would prefer. > > > > In the spirit of open source system, if we have contributors on an active > > project for a dedicated solution, I find it difficult to understand why we > > should sacrifice a more tailor-made out-of-box solution and have a > > compromises for a generalized system with tradeoffs configs to support other > > unrelated input methods. > > Maybe there is a misunderstanding here. I am not against installing > ibus-cangjie by default for zh_HK. And I am not against making it the > default either. Not sure whether we actually want it to be the default, maybe? 🤷 Koala, what do you think? 🤔 > ibus-cangjie was the default input method for zh_HK in Fedora in the past. > The **only** reason why we changed that was this: > > https://github.com/Cangjians/ibus-cangjie/pull/100 > > The setup tool crashed, I made a quick fix, but upstream was unresponsive. Notice the date at which you opened that issue: September 2021. At that time I was undergoing re-education to learn how to deal with my new life as a crip. It took me a long time to accept that new life, but in 2021 I was deep in depression because I couldn't accept that new life, it came as too much of a shock when I woke up from the coma and realized I couldn't move my legs any more. I **think** I'm out of depression now, but you can never know for sure: there are mood swings from time to time, and depression is like cancer, you can never really know for sure when you're cured, you're only in remission. My dad had leukaemia in the past. He's in total remission, but he still needs to do some bone marrow testing and take some pills (some of which cost 10.000€ per pill (hurray for national healthcare in France), and he'll never be fully cured, he'll have to go to that same hospital for the rest of his life to run tests and make really sure he is still in remission and cancer hasn't crept back in. > If ibus-cangjie is actively developed again, I have nothing against > installing it by default for zh_HK **and** making it the default input > method for zh_HK. I'm in remission from depression right now, and working on ibus-cangjie has been a big part of that, much like spending more time with my 6 y.o son. 😁 > > I mean it is great that you support input methods without active developer > > working on it. But I don't think this is the case that we're talking about. > > If ibus-cangjie is active again, then it is perfectly fine. Only because it > appeared completely inactive we changed the default to ibus-table. And that was probably the right thing to do at the time while I wasn't available and Koala was still learning how to deal with the code base. Fortunately, this is over now. 😉
(In reply to Mathieu Bridon from comment #21) > (In reply to Mike FABIAN from comment #20) > > (In reply to Koala Yeung from comment #18) > > > > > I would not want to take away previous efforts to add features to the > > > system. It is handy for a small subset of HK people who is proficient in > > > both Cangjie and pinyin, but I'd say this is not the input experience that > > > I, or fellow HK Cangjie users, would prefer. > > > > > > In the spirit of open source system, if we have contributors on an active > > > project for a dedicated solution, I find it difficult to understand why we > > > should sacrifice a more tailor-made out-of-box solution and have a > > > compromises for a generalized system with tradeoffs configs to support other > > > unrelated input methods. > > > > Maybe there is a misunderstanding here. I am not against installing > > ibus-cangjie by default for zh_HK. And I am not against making it the > > default either. > > Not sure whether we actually want it to be the default, maybe? 🤷 We would also need to change the default upstream in Gnome back then: https://gitlab.gnome.org/GNOME/gnome-desktop/-/blob/master/libgnome-desktop/default-input-sources.h > Koala, what do you think? 🤔
I made this pull request for langpacks: https://src.fedoraproject.org/rpms/langpacks/pull-request/43 Which adds ibus-cangjie-engine-cangjie ibus-cangjie-engine-quick as “recommends”. Then dnf install langpacks-zh_HK should install them if they are available: mfabian@hathi:~/rpmsources/fedora/langpacks (recommend-ibus-cangjie-zh-HK %) $ rpm -qp --recommends ./results_langpacks/4.2/2.fc41/langpacks-zh_HK-4.2-2.fc41.noarch.rpm ibus-cangjie-engine-cangjie ibus-cangjie-engine-quick ibus-table-chinese-quick mfabian@hathi:~/rpmsources/fedora/langpacks (recommend-ibus-cangjie-zh-HK %) $ rpm -qp --requires ./results_langpacks/4.2/2.fc41/langpacks-zh_HK-4.2-2.fc41.noarch.rpm langpacks-core-zh_HK langpacks-fonts-zh_HK rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 mfabian@hathi:~/rpmsources/fedora/langpacks (recommend-ibus-cangjie-zh-HK %) $ rpm -qp --requires ./results_langpacks/4.2/2.fc41/langpacks-core-zh_HK-4.2-2.fc41.noarch.rpm (ibus-table-chinese-cangjie if service(graphical-login)) default-fonts-zh_HK rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 rpmlib(RichDependencies) <= 4.12.0-1 mfabian@hathi:~/rpmsources/fedora/langpacks (recommend-ibus-cangjie-zh-HK %) $ Current state without this pull request is: mfabian@hathi:~ $ rpm -q --recommends langpacks-zh_HK ibus-table-chinese-quick mfabian@hathi:~ $ rpm -q --requires langpacks-zh_HK langpacks-core-zh_HK langpacks-fonts-zh_HK rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 mfabian@hathi:~ $ rpm -q --requires langpacks-core-zh_HK (ibus-table-chinese-cangjie if service(graphical-login)) default-fonts-zh_HK rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 rpmlib(RichDependencies) <= 4.12.0-1 mfabian@hathi:~ $
> > Not sure whether we actually want it to be the default, maybe? 🤷 > > We would also need to change the default upstream in Gnome back then: > > https://gitlab.gnome.org/GNOME/gnome-desktop/-/blob/master/libgnome-desktop/ > default-input-sources.h Indeed! I'll take care of this merge request. 😉 (In reply to Mike FABIAN from comment #23) > I made this pull request for langpacks: > > https://src.fedoraproject.org/rpms/langpacks/pull-request/43 > > Which adds ibus-cangjie-engine-cangjie ibus-cangjie-engine-quick as > “recommends”. > > Then dnf install langpacks-zh_HK should install them if they are available: Thank you very much. ☺️ Hope we can resolve this bug and make people in HK a bit happier, which will definitely take some hard work for IBus Cangjie. ✊
Pull request for comps: https://pagure.io/fedora-comps/pull-request/1047 (Zuul failed, I don’t understand why, doesn’t seem to have anything to do with my pull request).
FEDORA-2024-c5ece8013b (langpacks-4.2-2.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2024-c5ece8013b
FEDORA-2024-c5ece8013b (langpacks-4.2-2.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Mike FABIAN from comment #25) > Pull request for comps: https://pagure.io/fedora-comps/pull-request/1047 > > (Zuul failed, I don’t understand why, doesn’t seem to have anything to do > with my pull request). But Stephen Gallagher has merged it❣️
Hi Mathieu, thanks and I am so sorry to hear what you have gone through. I can't imagine how it must have been, but your courage is great! I still think it would make sense to do a more formal Change process, if you really want to change the default in Fedora now. For Taiwan we had a Discourse discussion and then a F41 Change to switch to ibus-chewing. It would be good still to have more clarity on the pros and cons of ibus-table Cangjie vs ibus-cangjie too. Koala, have you tested it? We also have https://pagure.io/i18n/issue/196 to discuss it.