All Stories

祝自己生日快乐

  唔,又老一岁了。以前说这话的时候,有点装逼的感觉,现在说这话,则是有点心有戚戚了。   其实昨天晚上到后来我自己都已经差不多忘了,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++版本,这实在太费时费力,还不好维护了。   最后,上个最新界面截图。

Ninayan W.I.P.(19)

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

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下同一个字的不同笔画都有粗细差异,真糟糕。