All Stories

Ninayan W.I.P.(打包)

Ninayan W.I.P.(打包)

  今天觉得Ninayan大部分功能已经实现了,也差不多快可以发布beta版了,于是要打包,先解决Windows和Mac上的打包问题。   Windows上一直以来我都习惯用Inno Setup了,所以在如何制作安装包的问题上并不纠结,InnoIDE和ISTool都是很方便的工具,主要的问题在于解决Qt的插件的部署。Ninayan在Windows上也是用GCC(MinGW)编译的,相比VS2008,少了个SxS的问题,只要带两个dll一起发布就行了。Qt本身有一种简单但比较有用的插件机制,它的字符编码支持CJK,图形文件格式支持,数据库驱动等等都是由插件实现的。也就是说$(QTDIR)/plugins下的东西都要跟着发布,而且程序代码中需要自己在main()中,app对象创建后及时调用QCoreApplication::addLibraryPath()添加plugins的路径。另外由于用到了QtWebKit和QML,QDeclarativeEngine对象也需要指定一下qmlwebkitplugin插件的目录,把$(QTDIR)/imports/QtWebKit目录打包进去,然后在代码中调用QDeclarativeEngine::addImportPath()添加路径,这样整个目录就是发布的所有内容了。   在Mac OSX上比较流行用dmg,但这之前还要解决Qt的framework链接的问题。Qt在Mac OSX下官方发布的二进制包是framework形式的,这跟Windows下有点不同,呃,其实跟SxS有点类似。要用install_name_tool -change命令行修改自己的程序可执行文件链接的framework的位置,这个工作可以由Qt自带的一个叫macdeployqt的小工具完成,只要在命令行执行macdeployqt Ninayan.app就可以了。不过除此之外,还是由于qmlwebkitplugin的缘故,需要自己复制这个插件到程序的bundle中,我就放在跟最终的可执行文件相同的目录中,这个插件macdeployqt并不处理,除了要自己复制,还要自己用install_name_tool来修改链接的framework。这样操作后,是一个可以正常运行的,完整的应用程序bundle,整个bundle就有113MB,谁让Qt那么大呢!然后是把这个bundle打包成dmg。Mac OSX自带免费的工具,GUI和CUI的都有,GUI的叫Disk Utility,不过看了下感觉界面挺复杂的,还是用命令行的hdiutil爽,而且我前面是用命令行修改的符号链接,这里当然最好也是用命令行打包,这样一个shell脚本就能搞定编译后生成dmg的所有事情了。用hdiutil的话,这个命令行就可以打出一个dmg来: hdiutil create -srcfolder Ninayan.app -volname Ninayan -format UDZO -ov Ninayan.dmg 不过这个有点土,就是把Ninayan.app放成了dmg而已,其他什么都没有。我的要求其实也很简单,有自定义的背景图片,有Applications目录的链接,这样用户打开这个dmg就可以完成把Ninayan拖拽到Applications目录中的操作。在网上找了不少文章和视频,多是用其他的GUI工具,在stackoverflow上有个家伙用AppleScript写了段脚本,确实通用性和灵活性都比较好了。最后我选了条简易简陋没通用性的路子,但够用。首先需要明白的是,dmg被Finder打开后,就是当成一个普通的文件夹处理的,所以它的背景什么的设置,都是放在.DS_Store文件中的(Mac中以dot开头的文件都会自动隐藏),所以很dirty的做法是,先用这个命令行创建一个可读可写的dmg并挂载: hdiutil create -srcfolder Ninayan.app -volname Ninayan -format UDRW -size...

可怜的Qt

可怜的Qt

  诺基亚与微软合作,以后放弃Symbian,在高端机型中使用Windows Phone7系统,而一直在大吹特吹的MeeGo将只作为一个实验性的作品,这消息发布后,网上就像炸了锅。   我个人表示很无语,感觉我期望的那个诺基亚已经远去了,那个Elop简直就是微软派去的卧底。关键一点是,以后也是使用微软的开发工具,最近两年那些开发出Qt、QtCreator、Qt SDK的人的工作,几乎等于打了水漂。不可否认微软的IDE很强大很好用,但它的框架(类库)我却是相当不喜欢,而且我现在觉得Qt实在是个有希望好好跨平台的方案,但这些大厂商硬要自己搞一套,实在烦人。Windows Phone开发用C#,Android开发用JAVA,iOS开发用ObjC,而Symbian/MeeGo开发用C++,这是让人非常纠结的事。而因为Qt的存在,让我曾经幻想,可以在WP、Android和iOS也使用C++/Qt进行开发,如今看来,毕竟是我贪心了,叹气。   现在网上都在说,以后就进入三足鼎立的时代了,要我选择的话,如果苹果的品质没有大的变化的话,我会首选iOS的,然后是Android,最后才会是WP。

Ninayan W.I.P.(20)

Ninayan W.I.P.(20)

  已经不记得有几个大年三十的晚上是在电脑前写代码度过了,今年破天荒的因为客厅里电视在放春晚,打偶然走过去看几眼。   今天把超链接处理模块重构了,之前那个实现在Mac下崩溃得比较频繁,但在Windows和Linux下却不是很多。对于这个现象我有点疑惑,虽然说代码确实是写得有问题,但为什么只有在Mac才比较明显呢。好在Mac下崩溃了打印出来的栈回调信息比较详细,几乎能跟踪到最终引起崩溃的代码行。   原来的实现把所有中间数据结构以指针的形式保存在一个list里,然后在自认为结束的时候销毁对象。这样的做法本没有什么问题,关键是我在操作这个list时并没有考虑重入的情况。于是重构主要做了两个重大修改,一是在list中直接保存对象,而不是指针,这样更不容易写错;二是对list操作大部分情况下都加mutex锁住。顺便也修正了些其他的小问题,比如原来即使是基于embed.ly的服务识别url是图片还是视频也有问题,其实embed.ly是返回了这个类型的。   另外,今天还把主界面针对360*640分辨率修改了一下,因为Nokia的S60v5和Symbian^3现在几个机型都是用这个分辨率的。至此,图片浏览特性的实现暂时告一段落,接下来该实现文章阅读了。昨天大致研究了一下Readability,发现它在Firefox表现那么风骚,结果在QtWebkit下总是返回不能分析的错误。不知道是DOM树的实现还是JavaScript引擎的问题。难道真要我移植一个C++版本,这实在太费时费力,还不好维护了。   最后,上个最新界面截图。

Ninayan W.I.P.(19)

Ninayan W.I.P.(19)

  终于勉强加上了一个功能比较凑合的图片浏览功能,还有很多地方需要改善。本来我的想法是UI上直接拿QML Demo PhotoViewer的代码来用的,可是昨天发现PhotoViewer中的代码会导致在Windows下程序不能切换输入法,于是只好自己写了。自己写就极大地简化了功能,才简化了代码,于是最后所有东西都放在一个QML文件中写完了,最终的效果,也就是几个视图场景切换时那个动画效果没有了。残念!   另外有个问题是图片下载的问题,现在的Twitter上比较流行的图床大多是被墙的,如果让QML的引擎自己通过代理下载图片,感觉不是一般的慢!所以我就觉得把这些图片事先下载到本地缓存起来似乎挺有必要的。   还有个比较重要的问题是全屏模式下浏览图片,默认是自动拉伸到整个显示区了,这样似乎比较影响显示性能,当然也是机器配置不是那么好的才会有这种卡的情况,在我的T43上会卡,拿到Mac mini上就流畅了。应该稍微改一下,看一下是不是在加载前就获取图片本身的尺寸,如果比显示区域大,才缩放,不大的话,就以图片本身的大小显示了,这样显示也更清晰点。   还有个浏览某张图片的大图就不截了,没啥好看的。

Ninayan W.I.P.(18)

Ninayan W.I.P.(18)

  有些问题,总是那么奇怪。因为XP里的虚拟机在跑Debian编译Qt,于是在Mac下把QML的Demo PhotoView抠过来用,本来就很吃力,还顺带发现了一个因为先后顺序问题引起的崩溃bug,终于可以在Ninayan里看到PhotoView的样子了。可是到了晚上突然发现,在Windows下不能切换输入法了,一切换Ninayan就挂死!经过一部分一部分地屏蔽代码发现,引起这个问题的似乎是VirtualDataModel中Package的一些代码。好吧,决定索性不用抠别人的代码,用自己的方法写一遍相同的UI吧。   上一段提到,我又蛋疼地在Debian里编译Qt了,嗯,又花了一下午。之后就是编译Ninayan,呃,我现在最大的乐趣就在于在不同的系统里编译Ninayan并用它来上Twitter了,囧rz。想来也不会有多大问题,毕竟之前在Arch和Mint里都比较顺利的,唯一大的区别是在Arch和Mint里桌面都是用Gnome,而这次Debian里用的是KDE,很花哨的感觉。言归正传,Ninayan运行得很顺利,除了字体不太好看。在Twitter上报怨了一下后,@truthurt建议自带一个开源的字体,真是个不错的主意,在Mint里的那种就很好,我后来去网上找了文泉驿的微米黑,在Debian和Arch里效果都很好。其实昨天就想过字体的问题,不过当时想到的是直接将字体装入到系统中,然后在程序中直接通过字体family名使用。今天偶然想到,其实可以程序直接载入指定路径的字体文件来使用的!不过Windows下还是用微软雅黑吧,微米黑在XP下同一个字的不同笔画都有粗细差异,真糟糕。

Ninayan W.I.P.(17)

Ninayan W.I.P.(17)

  今天照计划,实现了查看对话的功能,不过不完善,因为网络传输的原因,是一条消息一条消息从服务器获取后显示,如果显示到一半切断,又要显示另一组对话,就会把前一组对话后面没显示的那些消息作为后一组对话的消息。所以要考虑一下怎么加一个中断的机制,不过这个留到以后版本中完善吧,毕竟Ninayan一开始定位就不是一个完善的客户端。   然后又蛋疼地去装ArchLinux了。这个发行版安装比Ubuntu麻烦多了,它的iso镜像只装一个最基本的字符界面,然后带一个pacman包管理工具,GNOME之类的桌面需要自己再另外安装,所以最好有比较畅通的网络。   装完后,中文字体的显示惨不忍睹,google随便搜了一下,也挺折腾的,我懒得弄了。我就是想在上面试试编译Ninayan。没想到可以用pacman安装已经编译好的Qt 4.7.1,再装个Qt Creator,就可以编译Ninayan了。除了显示的字体不好外,其他的还算凑合吧。   明天开始做图片浏览和文章阅读功能吧。

Ninayan W.I.P.(16)

Ninayan W.I.P.(16)

  昨天和前天晚上蛋疼地在Linux上编译Ninayan了。我用的是Mint9,也就是一个Ubuntu的修改版。在Linux上编译Qt程序有点麻烦的是需要自己编译一遍Qt,前天晚上就编译了一遍最新的qt-everywhere-opensource-src-4.7.1.tar.gz,过程比较顺利,再装上Qt Creator就可以编译出Ninayan了,简单试用了一下,很正常。而且令我比较惊讶的是,我学Hotot用了Droid Sans字体,最终的显示效果在我个人看来比Windows XP SP3和Mac OS 10.6.6上都要好,但XP SP3上加上Gdipp或MacType后,效果会有很大的提升。   昨天突然发现,Ninayan在Mint下不能访问https://api.twitter.com(不是被墙的缘故),测试了几次才确认是不能访问https的地址,于是想到前不久看过一篇博文说Qt 4.7是有这么个bug不能访问https的,因为原来Qt 4.6带了SSL证书,而Qt 4.7没带,于是照那篇文章的作者的说法,从Qt 4.6.2里找到qt-ca-bundle.crt文件,然后每次QNetworkRequest在被post或get前都设置一下Ssl证书。结果我的情况是连编译都不通过,于是可以确认是Qt在编译时没有编译进OpenSSL了。然后找到了这篇《Compile Qt 4.7 on Ubuntu 10.10》,先要安装一堆的库的开发包,再来编译Qt,最后再编译Ninayan,果然就正常了!于是我就不明白那篇博文讲述的到底是个神马问题了!   今天就比较烦躁地在做网址缩短功能了。本来打算内置goo.gl,bit.ly和is.gd三个短网址服务,结果很郁闷的是bit.ly总是返回INVALID_URI,但同样的URL我拿到Firefox下测试就能返回正确的数据,这不是歧视嘛,难道是在http header里还要设置神马东西?倒是goo.gl和is.gd都正常了!

Ninayan W.I.P.(15)

Ninayan W.I.P.(15)

  话说前天偶然发现了MacType和Gdipp,觉得这种功能对Ninayan之类偏阅读的应用非常有帮助,于是我在极限论坛上给MacType的作者私下发了个email询问是否可以提供专门的API以便集成此功能。不过到现在也没收到回应,估计是不愿意了。   今天看了一下MacType的安装目录,发现有个MacLoader.exe,而Gdipp的安装目录下也有个loader文件,这时才明白过来,可以通过把可执行文件的完整路径作为命令行参数传递给这loader,那么该可执行文件会被启动运行,并被注入实现字体渲染增强效果。   经过简单的测试,Ninayan在我的XP SP3上使用微软雅黑字体,加上增强字体渲染效果,感觉确实更舒服了!而Gdipp是以GPLv3,最新的版本好像是用LGPL了,一起打包发布应该是木有问题的。我只要另外再写一个小小的启动程序,在安装包中把启动程序作为快捷方式添加到开始菜单和桌面等位置,可以自己调整是否使用增强字体渲染效果,使用什么样的渲染配置等等。   这样一来,似乎Windows上的效果都超过Mac上的了,一直没找到感觉特别好的Mac上的用于大段文字阅读的字体,微软雅黑只适合在Windows上用,而且至少要开了ClearType Tuner才行,有MacType或Gdipp最好。也许是因为我在Mac下用的是CRT的显示器的缘故,不止一个人对我说过那个视频信号转换后损失挺大的,也许用LCD的就要好些了!   今天心情不错,呼呼!

Ninayan W.I.P.(14)

Ninayan W.I.P.(14)

  前面说到内存泄漏的问题。后来通过逐段屏蔽代码,终于找到了最大一处泄漏源。这个办法比较笨,但这次真的有用,主要还是因为程序结构简单,流程也不复杂才能用吧。   程序大体上分为三部分,UI层,数据层,网络通信层。用户在UI层上操作,1、UI层向数据层请求数据,2、数据层根据不同情况直接查询本地数据库或通过网络通信层获取数据,3、网络通信层自己有一个定时轮循的任务,每分钟从远程服务器获取数据,4、有了数据就发送给数据层,5、数据层将数据经过简单处理发送给UI层,6、然后显示,就是这么简单。   我开始主要怀疑UI显示调用的Qt/QML也许MM有问题,于是把最终UI显示的代码屏蔽掉。发现仍然泄漏的情况基本没有变化,说明跟UI显示的关系不大。后来发现Mem Usage的增长是有周期,大概是1分钟1次,那么可以确定是在4和5两步有问题。这时把第5步中代码全部屏蔽掉,果然Mem Usage就不增长了。然后逐步缩小范围,一点点放出代码,最后发现竟然是QSqlQuery查询本地数据库时,select出来的东西需要程序员自己clear掉!内牛满面啊,果然是Qt用得有问题!   今天偶然发现一个叫MacType的东东,可以在Windows下以进程注入的方式给指定进程增强字体渲染效果。跟微软官方的ClearType Tuner是一类东西,不过MacType的选项更丰富。于是我想到,我这个以阅读为主的工具,要是集成这么个美仑美奂的功能,该是多酷啊。在极限论坛翻了一遍帖子,貌似MacType是闭源的,另外有个新生的Gdipp项目,倒是在googlecode上开源了,不过听说它的配置复杂,而且目前不够稳定,尤其是32位系统上。好吧,反正这种功能对我有致命吸引力,一定要集成!