伪·通向Fcitx 4之路（一）——配置

本来题目是用来吐槽我拍拍脑袋想的配置架构……后来觉得还是这个题目比较好……

Fcitx的配置文件可以说还是比较复杂的，数一数的话config profile tables.conf 码表配置，今后还有个皮肤的配置文件，杯具的是每个文件格式都不大统一，不能说不统一，说貌合神离更加合适，除了config和profile是用的同一个接口，这为gui开发也带来了麻烦。所以就考虑用统一的格式进行开发。

当时想玩玩compiz的插件的时候看到，没有gui部分，compiz config setting manager是怎么把界面搞定的呢？后来看了看发现是用xml描述配置实现的，这给我了一个启发…想把类似的机制用在Fcitx上面。不过原来Fcitx用的就是类Ini的格式，所以也没有用Xml而是用Ini的格式。

配置文件最后就变成了这样的结构：

配置文件描述->配置文件，然而他们的格式又本质是相同的Ini格式。另外的一个启发就是KDE的Desktop file的极大应用，我以前一直以为Desktop file只能支持xdg的那些，KDE把这个拿过来扩展了一下，结果看起来很美好。

老的配置文件是中文，当时是为了简化用户的应用，但是编码问题却仍然困扰着很多人……做utf8的Fcitx也是为了解决这个问题。后来想到还是用英文的好……省得不同Locale的人打架。那么英文->中文的转化就是必要的了，于是想到了gettext，配置文件的描述当中可以抽取出必要的信息进行翻译，在GUI显示时就可以翻译了，Locale也没问题。

同时为了给GUI提供更多的Hint，定义了比较多的配置选项类型：

String，Integer，Boolean，Enum，File，Font，Color，Hotkey，可以针对不同的类型生成不同的GUI。其中Enum是我特别想说的……以前配置文件里面有些0，1，2……不看文档确实没人知道是干什么用的，所以就在Integer之外再分离出Enum类型用做选项。

另外的一个问题就是如何读取这些选项，Fcitx以前用了太多的全局变量，这是一个将全局变量整合起来的机会。如果每次都需要用Group，Name这样的键值读取选项，未免有些浪费，于是又想实现一个Binding的机制。同步变量的值和配置文件中读取的值，以前Fcitx是通过指针实现的，其实是个不错的想法，变量名和选项名是不用面向用户的，代码中描述就行。

另外一个新的问题就是某些选项的限制，一方面可以通过配置文件描述，这样描述的信息可能不足，另一方面可能需要代码配合支持，所以打算给一个filter函数的属性位置，这和原来的读写函数可能很像。

嗯就这样，这部分代码改动很大，还没敢往svn上提交（其实是还没改出个能用的……）