Freezed cangjie 3 and 5's candidate order

[hulloanson]

Turned cangjie 3 and 5's DYNAMIC_ADJUST to FALSE.

Why:
ibus/ibus#2229

[hulloanson]

Looks like the repo has been quiet for a while. Pinging @definite 🙃

[mike-fabian]

That looks OK to me.

[ghost]

Hi, @hulloanson
I'm not sure if you've ever used Cangjie5, but, while dynamic adjustment is indeed an awful choice for Cangjie3, since there are many cases with multiple characters per code, since Cangjie5 eliminates this problem by allowing to disambiguate these pairs with X(難), the dynamic adjustment is actually the preferred option for Cangjie5. In other words, where you'd have to choose the correct character with a number in Cangjie3, you can just type one character with AAA and the other with XAAA in Cangjie5.
Now here is where the problem with DYNAMIC_INPUT set to false comes in. Let me give you an example: okr produces both 知 and 佑 in Cangjie5, but 佑 is the first choice; xokr produces only 佑 (which is less common). Thus, it would make so much more sense for 知 to be the default (first choice) character for okr, right? But for whatever reason the default choice for okr is 佑, the same character as the one you can disambiguate with X. Thus, until the table gets revised as to correct such cases (and there are quite a few of them), the dynamic input is important for Cangjie5, as it allows the user to easily change the default (first choice) character in such cases. Without the dynamic input, the whole idea of Cangjie5 is lost in many cases.

[hulloanson]

Ahh... I didn't see it that way. Your reasoning is like the opposite of mine (ibus/ibus#2229), but equally valid.

To me, the best solution seems to be exposing a GUI option to users then?

[ghost]

Actually we have been discussing this issue with @mike-fabian here: kaio/ibus-table#73 and we both seem to think that the best option is to leave the DYNAMIC_INPUT to false in Cangjie5 and to just parse the cangjie5.txt for such cases as I've described (知／佑) and make sure the character without the alternative x-prefix input is the first choice in each case. What do you think? Would you be opposed to this as a Cangjie user?
Note: this will only affect cangjie5.txt

[mike-fabian]

Ahh... I didn't see it that way. Your reasoning is like the opposite of mine (ibus/ibus#2229), but equally valid.

To me, the best solution seems to be exposing a GUI option to users then?

I can add a GUI option if you like.

[mike-fabian]

Actually we have been discussing this issue with @mike-fabian here: kaio/ibus-table#73 and we both seem to think that the best option is to leave the DYNAMIC_INPUT to false in Cangjie5 and to just parse the cangjie5.txt for such cases as I've described (知／佑) and make sure the character without the alternative x-prefix input is the first choice in each case. What do you think? Would you be opposed to this as a Cangjie user?
Note: this will only affect cangjie5.txt

Yes, I can also change the cangjie5.txt table like that, maybe no GUI option is necessary then?

[mike-fabian]

Or should I do both, change the cangjie5.txt table and add a GUI option for dynamic adjust?

[mike-fabian]

If I add such a GUI option, after toggling it on, the number of times a user has typed a certain character is counted and recorded in the user database.

If that option is switched off again, it would be necessary to either

• throw away all these counts (would loose the count data the user has tediously created by typing)
• keep the counts but do not use them in the calculation of the candidate order until the option is switched on again, then continue using the already existing counts

[ghost]

Since the dynamic adjust option doesn't make any sense for cangjie, I think there's no need for it if the cangjie5.txt is changed.

[ghost]

The only reason I wanted dynamic input in the first place is to simply be able to change the default first choices

[hulloanson]

If I add such a GUI option, after toggling it on, the number of times a user has typed a certain character is counted and recorded in the user database.

If that option is switched off again, it would be necessary to either

• throw away all these counts (would loose the count data the user has tediously created by typing)
• keep the counts but do not use them in the calculation of the candidate order until the option is switched on again, then continue using the already existing counts

I think this makes sense. Users at least get to choose. +1 for this one.

[hulloanson]

If I add such a GUI option, after toggling it on, the number of times a user has typed a certain character is counted and recorded in the user database.

If that option is switched off again, it would be necessary to either

• throw away all these counts (would loose the count data the user has tediously created by typing)
• keep the counts but do not use them in the calculation of the candidate order until the option is switched on again, then continue using the already existing counts

and for what to do when switched off, I think it's better to just keep the counts. Probably they want to try between 2 options.

(and perhaps a "reset count" button if it's not hard to implement?)

[hulloanson]

The only reason I wanted dynamic input in the first place is to simply be able to change the default first choices

only if we could collect everyone's word priorities and adjust the existing tables...

[ghost]

The only reason I wanted dynamic input in the first place is to simply be able to change the default first choices

only if we could collect everyone's word priorities and adjust the existing tables...

It's not about anyone's subjective preferences, but the objective qualities of Cangjie5.
I don't object to making that GUI option, more choice is always better. But Mike raised a valid point that too much choice may be too confusing for end users.
In any case, as long as the table is fixed to reflect the optimal character order for Cangjie5, I don't see a problem with enabling that GUI option as well.

[mike-fabian]

OK, I think I’ll fix the cangjie5 table and add that GUI option.

I am not yet sure about the reset count button. Thinking about it. In ibus-typing-booster I have such an option, it is called “Delete learned data” there..., maybe I’ll add it to ibus-table as well ...

[mike-fabian]

@WhiteCzar @hulloanson I made a new issue for the dynamic adjust option, you might want to follow that one:

mike-fabian/ibus-table#70