这个问题我认为是ibus的的一个bug,在scim下没有这个问题。opp 写了:是这样的,一点不错,这对于用五笔的人来说是比较麻烦的一件事。绝对会影响你的效率,你在选择的时候,至少会损失打一个字或者词组的时间,如果你是打字员那种速度的话,看候选词再选的话,你至少会损失2个单字或者2个词的时间。liuke.forever 写了:目前我发现ibus的字频调整有问题(不知是不是我不会设置)
情况是这样的比如我习惯打L: “国” G:“一”
但是当我打L: “国”的次数比较多的时候,就会出现我再打G的时候默认的是“国”,"一"到第二位了
我分析可能的问题如下:
ibus中记录字频的文件是/home/youname/.ibus/tables/wnwb-user.db
所对应的table是phrases
查看按一个键可这输入 '国'的资料:
sqlite> select * from phrases where m1 is null and phrase='国';
id|mlen|clen|m0|m1|m2|m3|m4|m5|m6|m7|m8|m9|m10|m11|category|phrase|freq|user_freq
1|1|1|7||||||||||||3|国|0|16
3|1|1|12||||||||||||3|国|0|16
(字母表abcdefghijklmnopqrstuvwxyz)
m0=7表示字母的顺序,也就是表是字母G 字频user_freq=16, 字频高的打字的时候会排在前面,
现在的问题是同一个字在不同按键下记录的字频(user_freq)的一样的,
正确的应该是同一个字在不同的按键下的字频要分开来记录,
应该要如下才对
1|1|1|7||||||||||||3|国|0|16
3|1|1|12||||||||||||3|国|0|10
会python sqlite 的朋友可这看一下/usr/share/ibus-table/engine/tabsqlitedb.py这个文件
我怀疑这个文件在更新user_freq时 where 里少了一个条件