All Stories

软件界面原型设计工具

  很偶然才知道这个工具——Balsamiq Mockups,因为完全是在另一个主题的论坛里看到的,当时在那个论坛里之所以提到它,不是因为它的功能多强大,也不是因为它的用户体验做得好,更不是因为它能帮助人们解决实际问题,而是因为它卖得好!   以前听说那些做快速软件界面原型设计的人,是用VB、Delphi之类的WYSIWYG的RAD工具,当时我就觉得与其已经用这RAD工具了,还不如直接就添加上各种事件响应函数,然后一个产品就做出来了。直到最近看到了Balsamiq Mockups,最在这两天简单试用之后,才发现这确实是个很不错的工具。   它是用Adobe AIR编写的,所以不但可以在Windows/Linux/Mac三大桌面环境中运行,还可以在网页上运行(貌似作者原来就是在Adobe工作的)。跨平台只是一个优点,另一个很重要的优点的,它的操作确实很傻瓜化,不得不承认的是软件的功能其实也很简单,就是一组图片,拖放堆叠在一个画布上。   这是个共享软件,桌面版要79美金,如果不注册,它会每隔几钟就弹出个消息框来,并且不能保存图像,但它有一些可以免费获得注册码的方法。其实我觉得这个软件的功能很简单,即使自己实现一个,可能也不用多少时间吧!

重复发明了个不咋样的轮子

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

配置功能W.I.P.

  配置功能让我纠结了好些天,现在基本上思路是确定下来了,也已经做了一部分了。   首先想说的是出乎意料的事,当时总以为用XML存储内容会比sqlite3存储内容占用空间大,经过实际测试100KB左右的数据用XML占用空间反而更小,大概是因为用sqlite3的话还会有一些用于索引之类的数据。   接着发现用sqlite3中那种二维表格来存储我想要的那种数据格式不是很方便,还是用XML那种树形结构方便,而且XML可以在同一级层次存入不同含义的节点,这也增强了表达能力。   后来我还是决定有boost::property_tree来操作通用配置文件,结果发现这个官方文档已经过时了,不过好在有人在maillist中提到了,也给出可用的代码了,居然还有人说读库代码就知道用法了,囧。另外想说的是,在存为XML时,没有更多的控制选项吗,没有pretty print吗。这次我倒是没有直接为Lua封装成一个C库,而是直接在宿主程序中用luabind绑定了一个简单的配置文件读写类,省了不少事。   最后想说,这进展实在太慢了,到现在为止,才做完通用配置的读取。

准备实现配置功能

  今天粗略考察了一下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!

回家了

  昨天跟小师妹约好的一起回去,今天早上8点半到了她楼下等她,结果居然电话都关机了,幸亏知道她同屋的室友的电话!原来小师妹还睡着,囧,睡过头了。幸亏我买早点的时候也买了她的份,等她下楼下已经9点半了。   不知道是不是因为放假的第一天,在上海的第一个收费站那里就慢慢吞吞地堵了大半个小时,真是烦躁。我们是要去杭州市三医院的,不过很郁闷的是,在高速杭州北路口拐出去后,就找不到方向了,导航也太蠢了,老是指向不知道什么地方。问了收费站的工作人员市区怎么走,好不容易到了市区,但又不知道怎么往市三医院方向走。在高架上走了一阵子,太堵了,小师妹很生气,后果很严重。我毅然决定下了高架,问了一个的哥,结果的哥居然说走高架本来是可以到的,不过好在他又帮忙指了另一条路。后来又问了个的哥,终于找到了市三医院,没想像的那么大,还找不到停车的地方,更郁闷的是停车的时候又刮到了,唉!   从医院出来大概是一个小时后了,即使有导航,还是有点提心吊胆的,不过这次似乎没怎么乱指,上了高速就好说了,但又有了另外一个问题,油不够了!小师妹说,怎么跟我出来尽是遇到意外情况啊。终于熬到绍兴界的服务区,加了油,之后总算是熟门熟路了。送了小师妹回家,我再自己回家,到家的时候已经快7点了。一天开了8个多小时,还真是累啊!

寻找同类?

  看到小师妹在日志中说寻找同类好难、心头一阵酸楚,使得我也感觉很难受,还有心疼。   回头看一下自己有比较清晰记忆的过去的十几二十年,确实也一直在不知不觉地寻找同类,只不过小些时候追求很少,有一起玩的小伙伴就觉得很满足。稍微大点了,有了一些自己想要的东西时,烦恼就渐渐增加。   那是非常孤独的日子,却又是非常希望能找到依赖的日子,但是一却找寻不到。我也不知道是从什么时候起,开始对寻找同类不抱有信心,甚至于绝望。直到昨天看到小师妹的日志,我才发现,其实我不再试图寻找同类,是因为我已经自以为找到了。找到了,并不是说就能见到,或能接触交流。那是一种认可,成为我的同类的资格的认同。只要知道ta的存在,不管ta在世界的哪个角落,偶尔能知道ta又做了什么事,那已经足够了。其他的事,就只剩下自己努力了,那些一直以来自身需要的精神鼓舞和激励,都可以从ta的事迹中获取。所以,在这个事件中,我可以高声宣布,我不孤独!   希望小师妹不再不安,同类无处不在。

做个源代码浏览工具

  Source Insight有大半年没更新了,我觉得以前一个同事说的没错,Source Insight可算是最不思进取的软件了,最后的几次小版本更新,都不知道到底有什么变动,反正我们最关心的一些问题都在。包括缺少Tab,缺少代码折叠,中文支持极差。不过总的说来,Source Insight的完成度是很高了,除了这三个缺点外,其他确实很难找出明显的问题来了。   我想做一个类似的源代码浏览工具,有几点Source Insight做得不错的地方,很值得学习。比如快速打开文件,快速查找函数和符号,上下文敏感的代码浏览,以及调用关系图示。Source Insight内建支持C/C++、C#和JAVA代码分析,其他的语言是通过扩展定义的规则实现的,这种方式也值得学习。

基本实现ZenHTML

  ZenCoding由2部分组成,ZenCSS和ZenHTML。其中ZenCSS只要简单的查表替换就可以实现,而ZenHTML相对要复杂得多。为了比较完整地给CodingStudio添加ZenCoding支持,花费了我一周时间,当然这一周我也是堕落了,工作时间和效率都很不乐观。   本来我已经发现用LPeg实现ZenCoding将是非常合适的解决方案,但看了一两天LPeg的文档后,还是有点迷糊,再看看ZenHTML的规则很少,硬编码实现也不是太复杂。   首先扫描是否当前表中已经有对应的项,如果没有,则下一步。   匹配E+E,将表达式按+分隔成多个子表达式,然后针对每个子表达式进行处理。   对子表达式匹配E>E,将子表达式按>分隔成多个包含关系的表达式,对各个表达式分别进行处理。   对表达式匹配E#name和E.name,到这步之后,E就可以查表了,而name部分仍然需要继续处理。   对name匹配E*N$和E*N,到这步后,就可以获取到所有信息了,然后向前回溯,组合成最终的字符串。   我这里的实现跟官方ZenCoding还是有点区别,官方ZenHTML是先匹配E>E,再匹配E+E的,我想我还是得照官方的改一下的。