All Stories

继续改进插件扩展框架后续

  今天修改了插件扩展的描述方式,把菜单项、工具栏按钮的标题、路径和帮助文本,工具栏按钮的图片等信息,全都写到xml描述文件中,这样一弄,lua脚本确实精简了很多。到现在为止,已经可以正常地通过插件扩展实现主菜单和工具栏的点击响应了,如果要说更新界面状态,也不是很麻烦,也就是多添加一个消息连接而已。  再说右键弹出菜单,我粗略地想了想,应该不是很麻烦,也就是添加到各自的扩展点下即可。其实直到现在,我才想起来,我这种实现方式,其实应该跟Windows传统的GUI资源编程基本思路是一样的。主菜单用一个编号标识,然后是菜单项信息,需要足够多的信息可以标识出菜单项的位置(路径),然后是给菜单项添加消息响应。工具栏的实现也是类似,所以如果要支持右键弹出菜单,也沿用那套思路就行了。  昨天说到,如果在插件扩展中使用wxLua,那么wxLua不能使用宿主程序使用的wxWidgets二进制文件,于是我今天想用IUP来试试。我从CVS里取出IUP的代码,然后用MinGW编译出所有的dll文件,可是用的时候发现总是报IupClipboard符号在指定的dll中找不到,而我用depends看是有的,郁闷!但是用LuaForWindows里的dll是可以的,可是它是用VS2005编译的,要带一个VC2005的redist,不爽啊!  另外一个问题是,本来以为脚本扩展时用了wxLua,而宿主程序也用了wxWidgets,两个之间可以无阻碍地互相使用各种控件,今天才发现,当时太想当然了。我用SWIG封装了宿主程序中的一些代码,比如wxFrame,在wxLua中是不认识这种封装的,两种不是相同的类型。所以现在只能精心挑选一组必需的,常用的代码来用SWIG封装,现在让它生成的包括scintilla和scilexer以及wxcintilla的声明后,生成的文件有近30000行,编译要花不少时间。说起来,我应该再仔细研究一下SWIG的用法先。  这两天用wxWidgets,有时候感觉它比MFC、VCL要灵活,比WTL要易懂。这也许很偏面。不过我最不满的是它的资料太少,以及运行效率不高。  

继续改进插件扩展框架

  这两天又用wxWidgets,不得不感叹一下,资料实在太少了,只有一个现成的manual,其他时候就只有看看CodeLite、Code::Blocks的源代码了!  到今天为止,修改了脚本扩展的功能,可以在一个描述文件中定义多个扩展的信息。对于主菜单来说,倒是勉强够用了,不过当时因为想让描述文件中对扩展的描述尽量通用,将其他的信息都写到脚本里去了,现在看来如果要对工具栏也使用脚本扩展,那么这种方式实在太不方便了点,还是应该把这种静态配置信息的都放在xml格式的描述文件中,脚本中应该只有动态的逻辑。所以还需要修改。  今天又忘了,wxWidgets的程序如果使用Lua扩展,而扩展又装载wxLua的话,wxLua的二进制文件不能用和wxWidgets程序相同的wxWidgets二进制动态链接库,不然会出现各种奇怪的问题。这是让我目前比较头痛的问题。我现在是用MinGW来编译wxWidgets和相关工程,那么一来wxLua就只能用VC或其他编译器编译了,但我今天试了OpenWatcom和Borland C++ 5.5,连wxWidgets都编译不过,郁闷!

又一年重阳

  今天是重阳节,据说要登高,这个习俗我是去年才知道的。突然想起去年的情景。  去年十一的时候嫌无聊,开始参加网上组织的户外活动组织,一个月要出去2-4次,而像重阳登高这种是纯娱乐休闲级别的,那次是下了班转了几次车最后还是打车去的集合地点的。  时间过得真快啊,就这么一年过去了!

提交了100多个网站

  这是这三天来忙碌的成果,其实实打实只有近一天的时间是花在这个上面了。前天差不多提交了50个,昨天休息了,今天则是差不多提交了90个左右。本来说是一个150的列表,其中有重复的,有需要back link的,有类型不合适的,还有其他一些原因的,最终没有提交成功的,所以估计最后的总数在140左右。  今天开始就新的内容了,嗯!

提交也不很麻烦

  原本我提交的时候,都是老老实实一项一项地填写软件信息的,虽然也知道有PAD,还装过个自动生成软件,但一直没用上。今天突然觉得应该多提交些网站,于是从cnsw论坛里找了批下载站的地址,开始提交,猛然发现大多数站点是只接受PAD方式提交的,于是没办法咯,只好老老实实生成各个PAD,再提交。  不过这样下来,发现用PAD提交,既然没有软件自动提交,纯粹人肉也不是很费时间啊!

投身AV事业

  昨天跟一个以前的同事在QQ上聊天,说到他有朋友是卖电脑的,问有没有什么软件可以OEM的。想到要OEM,必然要大众,要傻瓜,要新潮。于是我随便想了想,倒也不是真想去OEM,只是最后想到AV类的软件,实在是极其巨大的市场!  于是我又发散思维地想了想,最后觉得这类型的产品是有利可图,而且网上代码和成品软件很多,开始涉足的技术难度应该不是非常大。  唉,为了快速圈地,只好先投身AV事业了!

ISTool区别大了

  今天在安装程序中添加了2个网页快捷方式,因为用的是ISTool编辑的,所以就直接用它来编译了,结果试了几次,都发现没正确添加上快捷方式,连原来应该有的其他的快捷方式都没有了,甚至发现我本来让它在所有文件复制完后,应该有个选项可以让用户选择是否运行程序的,连选项都没有了。  真是奇怪的问题,于是在CruiseControl的历史记录中翻出最近的历史,发现还是正确的。想到这个安装脚本的区别基本没有,主要在于使用的是不同的编译工具。于是用命令行ISCC.exe编译了一下,居然是正确的!  这ISTool原来还是自己做了一套编译功能的说?

MinGW编译IUP、CD和IM

  知道IUP应该是去年的事,有个叫LuaForWindows的集合,里面就带了一个,上网了解了一下,知道还有一起的IM和CD。LuaForWindows已经提供了使用MSVC2005编译好的二进制文件,不过我不喜欢。我打算用MinGW编译一把。  开始的时候我以为可以直接用自带的makefile编译。结果是我花了半天时间,在msys里编译,还试图根据编译时报的出错信息,来修改makefile。在msys编译失败后,我尝试看那个自带的makefile,以为用TecMake可以编译通过,事实又是让我那么的失望!  最后,经过我对makefile的简单解读和分析,我决定自己写下个bjam的编译脚本。总的说来,我深信bjam是很适合用来编译库的,毕竟boost就是一堆的库。经过近一天的努力,除了那些需要依赖OpenGL、Windows Media SDK、DirectX等额外库支持的库,其他的基本都被我编译出来了。  本来bjam是可以支持一次编译多个工程(库),或只编译一个工程(库)的,不过那种bjam脚本我还不会写,我只能分别为IUP、CD和IM各写了一个bjam编译脚本。看来还是得再深入学习一下啊!

封得越来越死了

  前些天才知道,tor也是会被封的,要用tor bridge才行,至于bridge的ip从哪来,网上到处有说,也就是给某邮箱发个邮件索取来的。  这两天发现,这些bridges也是时好时坏的,于是笨办法是不停地索取新的bridges来用,今天发现得到的ip有的是之前得到过的,也就是说可能是不好用的,只能试试之前没用过了。  唉,封得越来越死了,无语!