-
怀念测试组，想念马姐姐
在GTalk上聊天，说起同事集体活动，突然思绪飞回2005年了。我入部门的第一个周六便是项目组活动，去深圳东门的工人文化宫溜旱冰。我并不会溜，所以摔了半死，不过后来倒也勉强能滑一会儿了。 然后我想到了马姐姐，当年那个号称“光网络第一美女”的主管大人。我进测试部一直是一种说不清道不明的奇怪体验，因为我其实只想做开发的，记得到部门报到的那天，项目部的老大跟马姐姐交接了我们两个新人后，轻声跟马姐姐说我的培训计划要调整一下。这是我到现在都没明白是怎么回事的事。 在测试组呆了22个月，其实应...…
-
wxWidgets项目中接管未处理异常
wxWidgets本身支持对未处理异常引起崩溃的拦截和后续处理，从它的官方文档中可以看到，只要在wxApp::OnInit()中调用::wxHandleFatalExceptions(true);然后覆盖wxApp::OnFatalException函数，可以比如遍历当前进程的堆栈什么的。 还有种处理这种未处理异常的方法是在程序启动时（一般就是在wxApp::OnInit()中）动态装入exchndl.dll文件，接下来该dll会自动拦截未处理异常，并在崩溃的时候自动在exe文件所在...…
-
互不兼容的Luabind/SWIG/wxLua
今天开始整理代码，突然又觉得现在嵌入Lua的方法实在太丑陋了。 为了连接C++和Lua，我用了Luabind、SWIG和wxLua。而主要问题在于这三者在映射C++的自定义类型时对同一个C++类型做出了不同的映射，所以不能互相兼容使用。 最早决定是引入wxLua的，因为一开始是确定用wxWidgets框架，并嵌入Lua做扩展，于是必然的Lua会要操作wxWidgets的类型，同时Lua扩展也会需要有一些界面需要画。但实际上，当时没搞清楚使用wxLua到底能不能满足这些需要。而经过真...…
-
Qt Creator插件工作流程代码走读
Qt Creator有个很风骚的插件管理器PluginManager，还有个很骚包的插件说明PluginSpec。基本上，所有的Qt程序的入口都是传统的C程序一样，代码流程从main()函数开始。 在main()中，先初始化用于国际化的translator，然后获取程序配置settings，接着就在栈上创建了PluginManager对象，之后为PluginManager设置搜索用的文件扩展名pluginspec，设置配置，再设置插件搜索路径。 设置好插件搜索路径后，PluginM...…
-
Code::Blocks插件工作流程代码走读
在app::OnInit()中，插件管理器先设置了一个安全模式，安全模式只是影响后续插件是否被激活。 在MainFrame的构造函数中，调用MainFrame::ScanForPlugins()，该函数根据配置又调用插件管理器PluginManager中的方法ScanForPlugins()扫描指定目录下的文件，该方法在指定的目录下查找dll（Windows系统）或so文件（UNIX系统），同时，需要确认当前是否以BatchBuild模式运行。所谓BatchBuild模式，可以这样理...…
-
关于插件机制的补充
首先，之前我说过，现在的CodeLite没有一个很大的包罗万象的dll了，这个说法不是很准确了。因为确实仍然有一个叫libcodeliteu.dll的文件，只不过里面包含的内容确实不介Code::Blocks的那个dll是包含了完整的几乎所有的功能，而是只包含了一些跟IDE业务关系不大，却是比较底层而又基础的通用功能。 其次，CodeLite的插件使用C链接的方式导出几个知名函数，用于创建插件对象，查询插件信息等。而Code::Blocks的插件则不然，它们没有这样的知名函数，而只是...…
-
Qt Creator插件机制简单分析
Qt Creator的插件机制比起CodeLite和Code::Blocks来要强大得多。每个插件至少有一个dll文件（以Windows平台为例），还有一个必须的.pluginspec文件。插件的基本信息在.pluginspec文件中描述，包括插件的名称、版本、版权、作者、基本信息、分类、网站等，最重要的一点是有依赖的插件信息。支持插件依赖可以获取得大的灵活性和可扩展能力，这点CodeLite和Code::Blocks都没做到，因为单靠一个动态链接库很难实现这种依赖关系的描述。 插件...…
-
CodeLite/Code::Blocks插件机制简单分析
昨天查看了一下CodeLite和Code::Blocks的源代码，了解了一下它们的插件机制的实现情况，还是非常简单的。 CodeLite宿主程序是一个单独的exe文件（Windows平台下），插件都是单独的dll文件。宿主程序首先声明了一组接口，这组接口定义了宿主程序可以提供给插件使用的各种服务，比如访问当前编辑器等，然后宿主程序实现这组接口。接着再声明一组接口，这组接口需要每个插件都提供自己的实现，另外，插件还需要提供几个dll标准的导出函数，用于查询插件的基本信息，比如返回版本号...…
-
使用qmake转换工程文件
原本用Qt Creator生成工程文件.pro，然后通过qmake -spec macx-xcode xxx.pro可以生成Xcode可用的工程文件，但是说实话Xcode还是用得不习惯，至少我常常用的在class中声明一个函数后，用Visual Assist X可以在右键菜单中直接将其在cpp文件中生成函数框架，但Xcode中还要自己一个字一个字地敲进去，而且这个过程中输入类名都没有自动完成了。当然整个的编辑功能上，Xcode已经比Qt Creator强出太多了。 今天有人跟说我了下...…
-
给N73换新键盘
我的N73是2007年6月买的，由于一直把它装在一个硬质小挎包里，从去年开始，键盘上的按键就开始一个一个掉落了，最开始是5，最中心的一个，然后沿着这个5把4，7，8，*，0都掉了，今年5月买了个5230后，就让N73光荣退役了。 从上海回来后，就一直把N73丢在书柜上，前天突发奇想，在淘宝搜索了一下，果然有N73的键盘卖，想去年去深圳华强北的电子市场找了半天都没找到。于是马上订了一块，定价20，快递6块，从广东寄过来。今天早上有电话打来，是申通快递，说是我填的那个地址他们不送到，要我...…
-
尝试移植到Mac受挫
这两天想试一下把手头这个用wxWidgets开发的工程移植到Linux和Mac，不过遇到了些困难。 该工程使用wxWidgets作为主GUI Framework，又嵌入了Lua解释器，将一部分界面和逻辑使用Lua脚本实现，而Lua脚本大量使用了wxLua以及诸如LPeg之类的第三方库，除此之外，主程序还使用了Boost、wxFlatNotebook、wxScintilla、wxPropertyGrid等第三方库。 主要的困难在移植到Mac上。目前我使用的wxWidgets是2.8....…
-
升级MinGW到GCC 4.5.0
一直用GCC 4.4.0，之前也尝试过将sf.net上MinGW的各个包下载下来后解压覆盖到4.5.0，但最后编译我的工程时总是std::basic_string什么的一些libstdc++-6中的一些符号链接有问题，于是就搁置下来了。 今天偶然到了mamedev.org上看了看，发现它用的是4.4.3，于是想试试，后来干脆又去sf.net上找官方MinGW的文件来看，居然发现一个叫MinGW-Get的在线安装程序。MinGW很喜欢提供在线安装工具，而很少提供打包好的整体的解决方案，...…
-
实现命令行打开文件
之前我说过，作为一个文本编辑器，一个IDE，不能通过命令行参数打开一个文件，是很说不过去的。前面试图加入这个功能，结果遇到了些问题，经过昨天和今天的奋战，终于搞定了。 其实就是发现用wxWidgets的IPC机制怎么都不能正常运行，于是最后我想到了直接用Boost的InterProcess库，这个库也是跨平台可移植的，基本处于符合我的要求的范围内。 昨天还一直没死心，希望能用wxWidgets的IPC类搞定，结果果然无论是用DDE还是用Socket，都有问题。今天下定决心，先看了一...…
-
一无所获，寸步难行
作为一个文本编辑器，一个IDE，不能通过命令行参数打开一个文件，是很说不过去的，于是我就想加这个功能，不料却意外地困难！ 首先考虑当前没有已经运行的本程序的进程，通过命令行参数指定一个文件后，最wxApp::OnInit的最后返回前，主窗口已经正常创建显示后，可以将文件路径传递给主窗口，让主窗口打开这个文件。照理说，这应该是一个很平常很普通很正规的流程吧，结果不知道为什么，打开文件这个操作会让程序崩溃。 然后考虑当前已经有运行的本程序的进程了，这时如果再通过命令行参数指定一个文件，...…
-
Twitter hosts IP全挂了
昨晚突然发现twitter的hosts ip不能用了，在just-ping.com里找了一遍api.twitter.com的ip，挨个儿ping了一遍，没有一个能ping通的。真是太杯具了，如果用Mac OSX，倒是没什么影响，反正我都是连上SSH后进行全局代理的，Echofon for Mac本身不能设API和Proxy，全靠这样SSH上去用的。但在Windows下就很无奈了，我一般用TweetDeck或Seesmic Desktop2，这两个东西一个用的是Adobe AIR，另一个...…