missdeer之程序的野望

　　昨天完成了自定义快捷键的特性。该特性在配置对话框中实现与用户交互。
　　首先，在程序启动时，装载所有菜单项时，把所有菜单项的ID、标题、快捷键信息记录下来，作为缺省的配置。将缺省配置保存到文件中，然后查看是否存在保存了修改后配置的文件，如果存在该文件，则装载该文件的配置，应用到程序中。应用过程分两步，刷新菜单显示和设置快捷键表。
　　接着，处理在配置对话框中的用户交互响应。在对话框初始化时，加载当前正在使用的快捷键配置。用户可以修改其中任意一项的配置，当用户选择应用修改后的配置时，就将当前配置保存到文件中，以便下次程序启动时可以装载这个修改后的配置。
　　基本处理流程就是这样。用wxWidgets实现时，也是比较容易的。wxWidgets提供了快捷键相关的几个类和方法，相当方便，包括wxAcceleratorEntry、wxAcceleratorTable、SetAcceleratorTable等等。
　　这里不得不抱怨一下，wxWidgets对于一些明明日常需要使用的类和方法，竟然没有文档进行说明。另外还发现个问题，wxAcceleratorEntry有个ToString方法，当其中的Key Code是除了字母、数字外的其他的可打印字符时，会断言失败，太Orz了，只好自己写代码转换了。

　　Relation视图可以算是完成了，至少是处于可用的状态了。基本原理就是调用cscope这个程序，本来这个程序是开源的，而且是用BSD许可的，比较干净的做法是把代码拿来编译进自己的工程里。不过我懒得研究那个代码怎么编译了，直接调用现成的可执行程序，通过管道获取其输出，然后自己解析一遍输出内容，显示在relation视图上。这样看来这该是个很容易实现的功能，但是实际上我却花了不少时间。原因是我一开始考虑得过于简单，把所有工作都放在一个singleton中完成。既要生成新进程，又要获取管道输出，同时还要兼顾老进程没有结果又有新进程的请求到来。于是总是在同时有多个进程时崩溃。后来把新老进程调试和获取管道输出分别放在两个类中实现，就都好了。
　　另外还有个问题是用gcc编译。现在这个版本基本上也到了收尾的阶段，我也买了个Mac Mini，希望能把它移植到Mac OS X上。Mac OS X上可以用gcc，于是我就先尝试在Windows XP上用gcc编译这个工程。这些天一直在折腾这事，总是由于这样那样的原因失败。到今天为止，终于可算是正常通过了，有几点需要记一下。我一直用boost svn trunk中的代码，绝大多数时候，用VC编译链接都是没问题的，可是这次用MinGW中的gcc 4.4.0把boost.thread链接到工程中时，仍然会报有几个符号找不到，如果是用正式发布的1.43.0版本的Boost，是可以正常链接通过的。gcc不支持在函数体内定义结构体（类），VC9是可以的。gcc在用boost.lambda时有些情况会编译不通过，就是几个结构体内的成员被lambda bind后再进行比较的情况，但是VC9是能编译通过的，而且也不是所有这种bind并比较都不能编译过，具体的还得继续研究一下。总的说来，gcc对类型检测比较严格，呃，说难听点，是比较死板，不如VC那么智能。还有种情况是gcc编译wxString::Format时，如果第二个参数开始传入的是wxString，运行时会出错，但它又报不上来，基本上就是直接崩溃，VC在这方面又做得好得多，不过这点我估计是受不同编译器对对象内存布局不同引起的，所以也许gcc真是无能为力，VC那样可以用算是歪打正着吧。
　　好吧，总之最头痛的两件事算是解决了。

　　今天看到推友@liancheng说Mozilla/WPF/QT/GNOME3都同质化了，大体的意思是指这几种方案都把表现层和逻辑层分离得很独立，复杂的，高度重用的，平台相关的部分，用C/C++之类的语言实现成组件，表现层用XML描述界面，用CSS之类的样式描述skin，再用如JS之类的脚本语言描述运算逻辑粘合组件和界面。
　　我最早了解到这种架构是几年前Firefox开始大肆流行，网上这类技术文章也大量涌现。当时也是很惊叹于Firefox的扩展机制如此灵活，却对它的开发环境很是鄙视，而且用于表述逻辑的脚本语言是用JS这个我完全没了解过的东西，所以看过介绍后，就丢到一边了。后来也偶尔听说WPF、XAML之类的东西，但对.NET一直没啥好感，于是也没研究。最近几个月跟个网友讨论，提到QT的界面方案，大体上也是知道QT也采用这种架构了，而且也确实一直计划着做完眼前的这组东西后，以后全面转向QT了，但仍一直没抽出时间来研究。
　　今天看到@liancheng的讨论后，让我有点儿沮丧。我现在用C++/wxWidgets做主框架，好不容易设计并实现了一个并不精巧的插件机制，用Lua来编写逻辑，还总是有这样那样的限制，这不就是典型的重新发明轮子么，而且发明的是个不咋样的轮子。唉！

　　今天粗略考察了一下Code::Blocks/CodeLite/notepad++的配置功能，发现需要做不少工作。
　　和外部工具特性一样，配置功能也需要一个用户界面，但这用户界面却更复杂，因为配置选项有各种不同的应用场景。总体上看来，我比较喜欢Code::Blocks的那种配置对话框，最上边是一个static text控件，中间是一个listbook，最下边是几个标准按钮。查了下wxLua的文档，这种界面效果用wxLua基本上可以实现。从代码中可以看到，Code::Blocks是用XRC这种协议实现的，这样的好处是界面和逻辑代码分离，我也一直觉得通过完全通过代码来构造用户界面实在很土，效率又低，但我又不知道有什么工具可以方便地进行用户界面设计并生成XRC，特别是其中有自定义的控件。不过现在既然是决定用wxLua实现，也没办法了，就继续用代码生成界面吧。
　　我要加入配置功能，主要是为了支持用户可以自定义编辑器的各种设置，特别是各个lexer的风格，于是又看了一下那三个软件的配置文件的存储格式。前些天我一直在想的是，用sqlite3数据库来存储配置内容，今天看了看boost::property_tree，觉得这个库似乎不错，接口使用起来也还算方便，而且屏蔽了底层存储格式细节，目前可以支持INFO/INI/JSON/XML格式，于是我又想把这个库的一些常用接口封装一遍给Lua用，但是又有点担心这些格式在存储时有大量冗余信息，不如sqlite3格式紧凑，而编辑器的风格定义又会有很多信息，所以还得仔细考虑一下，明天就先尝试把编辑器风格定义都用XML描述一遍看看效果，如果实在是冗余信息太多，再用sqlite3吧。

　　这个特性以前就实现过一遍，那是在MFC+Xtreme Toolkit Pro下做的，想起当时的情形，完全没有任何规划和设计，真正的quick & dirty。这回是用wxWidgets实现，总的说来要比上次方便一点，但也方便得有限。
　　此特性分为两部分，一部分是配置用户界面，用户可以实现添加，删除，修改等操作。另一部分便是菜单项以及响应。
　　配置用户界面是一个对话框，我这里用wxLua实现，代码量不大也不小，总之最近总是觉得用wxLua不是个好选择，一方面似乎不稳定，另一方面开发效率不高。用wxLua最大的好处在于字符串处理方面借势Lua，还算比较趁手。
　　菜单项和响应部分就比较低级了，基本上都是在宿主中用C++实现了接口，然后供Lua调用。其中比较重要的是创建进程部分，以前用MFC时，这种功能都是用Win32 API写的，现在用wxWidgets了，好在wx中有这样的封装，不过感觉并不方便，但也勉强能用吧。
　　这个特性原本还以为半天或一天就可以完成了，现在已经大约3天了都没完成，唉，明天争取把剩余部分搞定，然后实现编辑器scheme！