All Stories

Ninayan W.I.P.(22)

Ninayan W.I.P.(22)

  首先一件很郁闷的事,貌似域名被墙了,直接用IP是可以打开本blog的,但是我暂时又不想去折腾这些了,先这么放着吧,问候下方校长18代祖宗及全体女性家属。   Ninayan最近动作倒是不大了,主要是先打了Mac,Win32和Linux的安装包给几个人试用了一下,结果反响很差,有点失落,难道真的定位有问题?   不过说起来,Ninayan现在也只是个雏形,真正的主要的理念需要的特性并没有实现,现在也只是把图片,视频和文章链接单独提取出来可以独立浏览而已,并没有做进一步的工作,比如要能打tag,可以检索,自动语义过滤,优先级排序等等。其次是RSS聚合也没做,Google Reader没实现,UI缺少专业的美工设计等等,总之可以做的工作还有很多很多。   另外,今天勉强让Ninayan在我的Nokia 5230上运行起来了,解决了不少问题,但最终还是由于报内存不足而自动退出。为了让Ninayan可以在5230上运行,遇到了不少问题。首先是开发环境的建立,我用的是Qt SDK 1.1 beta,这个SDK用的是Qt 4.7.2,但有bug,for S60v5的配置文件使用了for Symbian^3的配置,所以编译工程的时候会出错,要自己在工程的.pro里把opengl的配置去掉。其次是部署时,要安装Qt,还要单独安装sqlite,据说以前版本是合在一个安装包里的。最后是这两天一直在纠结的问题,运行后在TextInput获取输入焦点后,虚拟键盘没有显示出来,在Nokia的论坛和Stackoverflow上问,都没人回复,今天偶然想起qDou,试了下它在5230上至少是可以输入文字的,虽然之后会崩溃,于是发邮件问了一下作者,作者给了个网址,原来是我在TextInput控件一起放了个兄弟控件MouseArea,于是TextInput没能收到点击事件,于是虚拟键盘不会自动显示,只要自己强制调用它的openSoftwareInputPanel方法就可以了。   至于最后的自动退出,从现象结合网上的人们的讨论来看,似乎是因为同时请求的网络连接太多,以及内存占用过多引起的。叹气,桌面程序写惯了,散漫惯了,都不怎么注意内存的使用了,反而经常采取以空间换时间的策略,看来如果真要让Ninayan能在手机上正常跑起来的话,还得好好重新设计一下,把各种请求都放进队列里,不要一下并发几十个连接,其他的内存使用策略也得仔细看看,有点想看看侯捷翻译的那本讲内存受限系统的程序开发的书了。

Ninayan W.I.P.(21)

Ninayan W.I.P.(21)

  Ninayan的主要功能基本上都做出来了,剩下的主要是增加各种服务的支持,比如各种微博,各种SNS,以及Google Reader。其次便是界面和操作上的细节方面的调整,现在还是很粗糙的。   离上次W.I.P.已经有3周多了,这3周主要实现了文章浏览特性。文章浏览有3种模式,一种是仿feedly的可扩展的列表,一种是信reeder的分栏,还有一种是仿paper.li的报纸模式。但是,目前的效果还远远没达到预期。放几张图吧:   还增加了个视频观看视图,这是计划外的,但觉得有必要,也很粗糙:   直到这里才发现,在Mac OS X 10.6.6上一直以64位Cocoa编译的Qt,果然视频播放不了了,不记得在哪里看到过说明,QtWebKit在Mac上如果是64位的话是载入不了Flash播放插件的,因为Flash播放器稳定发布只有32位版本,于是在Mac上也自己编译了一把Qt,改成32位Cocoa框架的就可以了播放视频了,太纠结了,也难怪乔帮主要封杀Flash了。

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都正常了!