开始全面接触 GTK+
说来也惭愧,2 年前我就打算好好学习 GTK+,期间断断续续的进行了几次,每次都是浅尝辄止。这主要是因为在我们的项目里,我不负责界面设计,因此也没有足够的动力。另外,我将大把的时间都用来折腾 TeX 上了,从 PDFTeX、XeTeX 到 LuaTeX,从 LaTeX 到 ConTeXt,又从 ConTeXt MkII 到 ConTeXt MkIV。现在之所以决定认真的搞定 GTK+,是因为有些鲠骨在咽般的因素在刺激我。
Evince 老放我鸽子
每次在 Evince 的新版本开发路线中都要提到会支持 PDF 批注,可是每当我查看 Evince 开发版本的 changelog 文件时,就会失望,因为我连一点 PDF 标注支持的影子都看不到。我跟 galeki 经常说起这个事情,直到后来他说在 Windows 环境下使用嗯 WPF 里做 PDF 标注是非常简单的(我没有去查验,不过我估计是依赖 Adobe 提供的 PDF 控件)。不过,Windows 平台有许多第三方开发的 PDF 阅读器都支持 PDF 标注,这很刺激我。按说说,GNU/Linux 环境要比 Windows 环境更需要 PDF,除非 OpenOffice.org 的 ODF 文档格式能在排版方面超越 MS Word 格式。
我是知道 evince 之所以一再放我鸽子,主要是因为它所使用的 PDF 渲染库——poppler 不支持 PDF 标注。当然 PDF 标准中许多内容,poppler 也不支持。KDE 桌面的 okular 也是基于 poppler 开发的,它提供了 PDF 标注支持,不过那只是一个表面现象,批注的内容是不会被写入 PDF 文件内部的。另外,还有一个叫做 xournal 的工具,它也是假批注,是通过将 PDF 页面转化为图片,然后在图片上涂涂画画来实现批注,但是它的算法有问题,它是一次性的将 PDF 文件所有页面都转换为图片,巨耗内存(区区 200 来页的 PDF 文档大概可以吃掉 1G 多的内存)。如果将 xournal 算法修改一下,建立一个页面的缓存区,每次只转换数十页的图片,或许会好一些。
随着对这个问题的认识日渐清晰,我也开始不满足 PDF 标注功能了。我们之所以要对 PDF 文档做标注,是因为在阅读 PDF 格式的论文或书籍时,需要记录自己的见解,而有些内容是无法通过 PDF 标注来解决的。比如,我发现某篇论文中,有个公式写错了,我是无法使用 PDF 批注写出正确的公式作为注释,即使是最 Adobe 的 acrobat 也无法做到这一点。也就是说,在阅读 PDF 文档的过程中,我们还需要一个便于记录自己的见解甚至是长篇大论的读书笔记的工具。
除了这些,我还有一些更高的要求,但是目前没有这样的工具满足我。当我认为自己有能力去做,并且也可以做好的时候,我就打算做 CoNote 这个东西。这需要一个漫长的过程,掌握 GTK+ 是一个必须的起点。
我想让 ConTeXt 更易用
我第一次知道 ConTeXt,就像我第一次知道 LaTeX 一样,是从王垠的主页上看到的。
说点题外话。当初我选择 GNU/Linux(无论 GNU 再怎么想突出它的地位,我还是觉得直接输入 Linux 比较快捷),也主要是受了王垠的“蛊惑”。虽然,我早在 2004 年就已经在机器上安装过 RedHat 9.0(很清楚记得当时看到的是以后才知道的 KDE 桌面),但是因为当时看到是英文界面,感觉用不惯,很快就放弃了。当我看到王垠的那篇讨伐 Windows 的文章时,我正在 Windows XP 里面折腾 Unigraphics(现在叫 NX)的二次开发,我已经开始无比地反感 Unigraphics 那些丑陋并且难以猜解的 API 、迷宫一般的 MFC、自虐的 C++ 语法……所以当我看到王垠所描述的 Unix 技术环境之后,我感觉在那边我会生活的更为轻松,而且技能也会有所增进。我当时,甚至已经在 Unigraphics 二次开发中初步尝试了一下 Qt(记得当时的版本是 3.3),感觉很不错,比如有我很熟悉的 main 入口函数、很直观的信号/槽机制、很丰富又易用的控件……程序员们不需要很了解 Qt 内部实现便可以高效率的写程序。当我迈入 Linux 环境时,我才发现 Windows 世界之外原来有这么多的好东西。其实,那些东西在 Windows 环境中也都可以使用,只是我以前一直在 CSDN 里晃悠,并不知道太多外面的东西。后来,我专门写了一份报告给了我的导师(俗称老板),他同意后,实验室的软件开发环境就全面转向 Linux。我觉得这种选择并没什么错误,因为我们的最终目的,就是要拥有一个方便的开发平台来快速验证我们的一些想法。当这些想法成熟后,完全可以在 Linux 环境里继续让它成熟,同时也可以在 Windows 环境去实现它,或者将这些工作外包给其它一些专门搞 Windows 软件开发的单位来做。
再回到正题。当我转向 Linux 环境之后,曾经用过多种标记语言来撰写文档,HTML、XML/XSLT、DocBook、LaTeX+PGF/TikZ + Beamer,最后感觉,这些标记语言,要么是不能很好地实现文档排版,要么就是使用起来太繁琐,感觉没有一种是适合我的。另外,刚使用 Linux 时,看到很多人都吹嘘 OpenOffice.org 多么的好。真正的用过一段时间之后才发现,OOo 作为办公软件还可以,但是要用它来排版文档,说实在的,它做的还不如 MS Word 一半好。我是经过很长时间的比较之后,才感觉 ConTeXt 适合我,就像经过很长一段时间的比较之后才发现 Linux 适合我一样。这期间,WangYue 在 TeX 社区的频繁出入宣传 LuaTeX 也对我影响颇巨。
当我订阅了 ConTeXt 的邮件列表之后,近距离地看到 Hans、Taco 等开发者们很有想法并且也很积极的开发活动,我才真正感触到自由/开源软件的魅力。他们给我带来了许多积极的影响,首先是让我有了提高自己的英文书写能力的紧迫感(从小到大,我每次的英语考试都是只靠蒙选择题来得分),主要是为了提交那些让我难以忍受的 bug 们。另外就是让我愿意在力所能及的情况下也为 ConTeXt 做点事情,虽然主要是为了方便自己。也许自由/开源软件的起源就是在方便自己的前提下去方便别人吧,虽然不是纯粹地为了方便别人,但这也是一种比较美好的事情。
我在 CTeX BBS 上发了一个投票帖子“你喜欢那种 TeX 中文排版环境”,在看了许多人的反馈意见之后,感觉要让 TeX 更易用,我们只需要做好两件事情。第一件事情是做好中文的入门文档。第二件事情就是实现更好用的 TeX 编辑器,包括中文字体配置、排版细节调整以及好用的文档输入界面。我对 LaTeX 不感冒,因为它乱糟糟的,无论是为它做文档还是开发编辑器,都要触及一大堆很繁琐的问题。因为 ConTeXt 这些年一直在致力于提高 TeX 的易用性,并且制作了便于安装与升级的 ConTeXt Minimals,为它写文档和开发编辑器,都比较省心。为此,我已经开启了 "A Way to ConTeXt" 文档项目,一边自我学习,一边很缓慢的进行。另外,就是要学习 GTK+,再开启 ConTeXt 编辑器项目。由于 ConTeXt 的最新版本 MkIV 还处于 Beta 状态中,这给我留出了足够长的时间来完成我想做的。
我需要更好用的思维导图软件
现在,思维导图软件有很多了。著名的有 FreeMind,是用 Java 开发的,说它不好用,是因为它到现在也不支持我使用的中文输入法的光标跟随功能。现在,又出现 XMind,也是 Java 开发的,比 FreeMind 好用得多,但是文档导出的功能远不及 FreeMind 丰富。还有一款 VYM,是用 Qt 写的,表现很一般。何况,我对所有基于 C++ 的东西都存有偏见。
我说“我需要更好用的思维导图软件”,只是根据我的使用习惯而言的,并无蔑视其它软件的意思。另外,思维导图也不应该就是目前的这个样子,动不动就要搞成树形结构的。人类的思维是混乱的,是由一个一个神经元相互联系形成的,思维导图最起码应当是一个有向联通图的形式,它的特殊形式才是树形结构。所以,我认为 Graphviz 的那种绘图方式是符合我的要求,只不过它太随意了,虽然那恰好是它的特色。
由于我是 GNOME 用户,我希望有一个可以在 GNOME 桌面里便于使用的概念图软件。但是,这种希望在目前依然是奢望。不过,我认为使用 GTK+ 来做出这样的软件也不是很困难。
那么,为什么非要用 GTK+ 呢?
因为我对 C++ 语言和开发技术存有偏见,所以不会选择 Qt 和 wxWidgets。计算机编程语言、开发工具的优劣之争,古已有之。我觉得选择什么并不重要,只要自己能接受就可以。己所不欲,勿失于人;反之,亦然。总之,许多人反对 GTK+ 的许多观点,都不是很正确,因为他们对 C 语言和开发技术也存有偏见。有偏见,就很难客观,这就是诸多争论的起源。
就是选择 GTK+,也要面临着 C API 还是 Python、Ruby 之类脚本绑定的选择。我选择 C API,因为我认为动态语言,目前只是一个 RAD 工具。它们可以很快地解决问题,但是不能很好的解决问题。C 是稳定的,虽然写程序有些低效,但是借助一些辅助库的力量,提高开发效率也不是很困难。大家都说 C++ 开发效率高,事实上假如只有一个赤裸裸的 C++,无论做什么也是低效率的。面向对象,已经被证明并非是解决软件工程一切问题的银弹。
我一直赞成用 C 做底层,上层用动态语言来整合,但是一直也没有怎么实践过。类似的成功项目有许多。现在,我为自己选择了三个题目,可以认真实践、体验一下了。
我的话,太多了!
在没有做出来成果之前,说再多,也都是虚的。我需要闭关一段时间。只是当我有点心得的时候,会及时的将它们发表在 Blog 上。
2009年4月30日 07:59
C 做这样的非数值计算的东西编程效率太低了吧。直接上 Python 或者 Ruby 吧,别只局限于 Binding 了,我们系的一个几十万行的大项目都换 Python 写前端了 (后端是数值计算,只能用C++),呵呵。而且, Python 会让人编程和调试起来心情非常舒畅,呵呵。C/C++出个问题都不知道哪里去找,很郁闷的。尤其是Linux下的gdb调试程序只能用力不从心来形容。
GTK+和Qt与C++/C其实没多大关系。 Qt只是用C++最简单最傻瓜的那一部分东西,压根没有涉及到任何高级的C++技术,所以开发起来还是比较直接的。GTK+也有GTKMM,写起来感觉到是比Qt难多了。不过终究来说我觉得好多人选C还是C++取决于人们对于C++这门语言的厌恶程度,恩。近来Python和Ruby的binding越做越好,尤其喜欢MacRuby的HotCocoa,好用得很啊。
2009年4月30日 08:58
@Yue Wang:
只是用 C 去调用那些库的 API 就可以了,并不需要自己去写太多的 C 代码。数据结构什么的,尽量地去用 glib 里提供的那些(尽管它的 list 一直存在着效率问题,我忍了),也基本够用。
估计今后很长一段时间,我的 blog 就要充满 C 程序的抱怨了。
2009年4月30日 09:02
被Wang Yue兄搶了sf.
相比起coding efficiency,我覺得用C寫的代碼後期維護看起來更辛苦點吧.一般來說也會寫得比較長一點.針對這些non computation intensive的東西,直接用high level一點的語言寫起來也會比較舒服自然的...
anyway,knuth大爺也用它的OOXX語言寫得不亦樂乎,還是自己選擇自己喜歡的語言吧~
2009年4月30日 20:14
其实要说写 Gtk+ 程序,我第一反应也是用 C,即使明白会很麻烦,除了很有成就感之外,还有种征服感。但是如果用 binding 来写,就有种“被 Gtk+ 征服了”的感觉。
不过,之所以有这种感觉,应该是因为 Gtk+ 对我来说还是神秘的。因为自己的水平注定了自己没有能力开发一个类似 Gtk+ 的库,所以使用 Gtk+ 的 C API 也算是最接近这个目标的行动了。 :D
但是得有时间才行,目前这个状态,还是期待 Ruby 的 Binding 加油吧~ :D
2009年5月02日 04:21
李师兄,
师弟们不能啃骨头么,呵呵,给他们点机会,
锻炼锻炼。。。
2009年5月05日 19:53
其实GTK+的编码风格我也是很喜欢的,可是它的Windows的移植版实在是太失败了,又卡又丑。
2009年5月17日 06:09
evince还有个问题,对繁体支持不好。