All Stories

Ninayan W.I.P.(23)

  blog被墙了就真不太想更新了。   Ninayan这段时间除了不时地发现些bug,然后修正外,主要是增加了对163、Sina、Sohu、QQ微博的支持。从开发者角度讲,163的API是最接近Twitter了,QQ的API设计最山寨,完全自己搞了一套,Sina和Sohu从技术角度讲跟QQ接近,接口设计仍然是模仿Twitter。   然后在google code上放了Linux版的可执行文件上去,今天才知道原来各发行版上普通的应用程序是可以做到二进制兼容的,也怪我以前看CodeLite、Code::Blocks它们都为每个发行版提供一个独立的安装包,就先入为主地以为每个发行版都要各自单独编译才行。今天突然想到Qt Creator就是同一个可执行文件在所有Linux发行版里可以运行,只是区分了32位和64位而已。我还傻乎乎地在12个系统里都编译了一把Qt,再分别编译出Ninayan,再分别打包,再分别上传,天呐!

乱七八糟

  做了个梦,具体的已经忘掉了,只记得我一直在找她,却一直没找到,不知道她去哪里了,明明以为她就在那里,我强颜欢笑,我心如刀割。   可能我真的喜欢上她了吧,可是……我怎么会那么容易就喜欢上人呢……痛苦。

祝自己生日快乐

  唔,又老一岁了。以前说这话的时候,有点装逼的感觉,现在说这话,则是有点心有戚戚了。   其实昨天晚上到后来我自己都已经差不多忘了,11点多时就打算去睡觉了,不过后来玩着玩着就到11点50几分了,然后看到木耳说“换个电池 关键时刻不能没电 8mins”,我还没反应过来,后来不知道是被什么事提醒了一下,才意识到木耳应该是在等00:00这个时刻了,于是心中便不免有点期待,也有点紧张。   果然到00:00后木耳发了祝福推出来,很激动,更是感动。刚回复完木耳,便收到晓晓的短信,后来知道晓晓也是特意没睡等着给我发短信的。然后我的mention timeline瞬间被祝福推刷满了。没多久莎莎也发短信来,说来晚了,嘿嘿。很有趣的是墨墨,1点的时候,我都刚刚迷迷糊糊快睡着的时候,居然发短信来了!   谢谢木耳谢谢晓晓谢谢墨墨谢谢莎莎,还有所有祝我生日快乐的推友们。

Nokia出售Qt业务

  好吧,Nokia真的把Qt卖掉了。不知道Nokia这样彻底放弃软件业务后,真的只做硬件了?它做得过天朝的山寨厂商么?想想其他的有点名气的有点野心的手机厂商,韩国的三星,大陆的魅族,还有台湾的众多厂商,哪个不是一开始做硬件,之后再想办法自己掌握一个操作系统(Android是它们的机会)?Nokia却反其道行之!好吧,算是看明白了,任何与微软合作的厂商都会被它搞垮,想想IBM的个人PC业务,想想Apple在经典Mac的时代,它们倒是瘦死的骆驼比马大,终于要么割肉要么涅槃继续着自己的辉煌,那再想想比较近的Borland,还有Novell,现在还有人记得它们么?Nokia,你以为自己是哪个?   Nokia是在Qt上投入了两三年后,等不及这只鸡下蛋了么?在HP的WebOS明确支持Qt(4.6.1)开发,RIM的PlayBook采用的QNX明确使用Qt构建其UI的年代,Nokia好大方地把Qt就这么丢掉了!问题是它丢却没丢干净,手里还握着LGPL许可!这算怎么回事,难道等着以后实在不行了却得见不得别人过得滋润,就开始咬人?   好吧,我觉得现在的情况可算是对Qt来说,最糟糕的情况了。Qt变得让人不想再用,不想再开发的东西。本来我一直想说,我用过的C++ GUI框架中,包括VCL、MFC、wxWidgets,Qt是外部接口设计上最好的一个。4.7版本加入的Qt Quick对于开发者来说,也真是一大福音。但是现在,一切都变得不确定,让人没有信心。好遗憾!

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的主要功能基本上都做出来了,剩下的主要是增加各种服务的支持,比如各种微博,各种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大部分功能已经实现了,也差不多快可以发布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

  诺基亚与微软合作,以后放弃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)

  已经不记得有几个大年三十的晚上是在电脑前写代码度过了,今年破天荒的因为客厅里电视在放春晚,打偶然走过去看几眼。   今天把超链接处理模块重构了,之前那个实现在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++版本,这实在太费时费力,还不好维护了。   最后,上个最新界面截图。