用Intel C++编译Qt失败

  之前说过想用Intel C++编译Qt来着,于是从VeryCD上找到Windows、Mac和Linux的Intel C++安装镜象不辞辛苦地下载下来安装。结果让人很沮丧啊。
  在Windows 7中,无论编译64位版本还是32位版本,都会编译失败,我怀疑是因为Intel C++用了Visual C++的头文件引起的问题,但是我直接用MSVC2010来编译64位的Qt,虽然也是编译失败,却跟Intel C++报的错误不同,好像C++11标准的问题,在Webkit部分中有类名为nullptr,这个名字在C++11中作为保留字了。也不知道那些用MSVC2010编译成功的是用了什么参数。至于使用MSVC2008的配置,我就没兴趣编译了,因为我不喜欢MSVC2008的SxS。
  然后在Mac中编译,32位版本也是编译失败,64位版本编译倒是全部通过了,但貌似make install不完整,那些头文件就没有复制过去,还缺了些什么不知道,反正直接把Qt源代码目录中的include目录复制过去是不能用的。于是也放弃了。
  后来么,在Windows上下载了32位和64位的TDM GCC,编译了两个晚上才编译出来,话说那个-nomake “demos examples docs”参数不起作用啊。试了试编译Ninayan 64位,可以运行。
  这两天看到Nokia的Qt论坛上有个叫Qt4iOS的人,说他做的Qt for iOS插件就要可以正式发布了,好期待啊。又看到有人说,Necessitas虽然还在Alpha版本,但已经可用性很高了,我看了下,现在居然已经提供4.8.0版本的for Windows/Mac/Linux的SDK了。不过在Mac上安装好后想编译Ninayan才发现,源代码还需要做些修改,比如源代码中通过预定义宏只识别了Windows/Mac/X11/Symbian/Maemon,但是这个Android不知道是什么宏,不知道上哪去查点资料看看。
  于是最近还在网上看到的消息,是说Windows Phone的下个版本会支持C++开发,如果这样的话,Qt也会很快就支持WP开发。啊,如果Qt真能用于Android、iOS和Windows Phone的开发,那就太牛逼了。说实话,如果这些port的质量可以的话,只要价格不是太离谱,我应该会买这license去的。

换用Intel C++编译Qt

  春节放假时有一天突然想到Qt是支持用Intel C++编译的,有icc的mkspec,而且Intel C++在Windows、Mac和Linux都有,还能生成32位和64位的可执行文件,于是就想试一下,如果确实可行,以后就不用GCC了,虽然GCC也很好。
  比较囧的是,在Windows上,Intel C++除了最核心的编译器,其他的都是用Visual C++的,比如运行时,甚至包括nmake,于是很不幸的是nmake貌似不能通过命令行参数指定并行编译,只能单线程编译了,纠结。
  自己编译Qt的话,Windows和Linux都要为32位和64位系统分别编译,Mac倒是只要编译一个就行了,但是有个小问题是上次在Mac OS X 10.6.7上编译Qt 4.8.0时64位版本到后面有个什么库没有,于是只能编译32位版本了,囧。

从滑动手势谈到Qt

  N9作为Nokia推出的唯一一部装载MeeGo系统的手机,主打宣传的是其滑动手势。
  滑动手势在其他触摸屏设备上已经有所应用,各种移动操作系统也对其有一定的支持,但在N9上作为主推特性的滑动手势主要是基于Qt这个跨平台的开发框架实现的,因为从实现角度讲,N9装载的MeeGo系统的UI都是建立在Qt的基础之上的。
  Qt自从被Nokia收购后,一直致力于在移动设备上的移植工作,尤其是对Symbian的支持越来越多。而MeeGo这个原本由Nokia和Intel合作开发的项目,同样做了很多跟Qt适配的工作。
  Qt做了很多为方便实现触摸操作响应的工作,特别是后来推出的Qt Quick,彻底地让UI和业务逻辑分享。美工可以只使用非常简单的脱胎于JavaScript的声明式语言QML来构建UI,而程序员则可以专注于使用C++或JavaScript实现底层的业务逻辑。Nokia为QML提供了非常丰富的UI元素,还为Symbian系统特地实现了一组扩展的UI控件,这已经可以实现绝大多数的UI需求,各种UI元素又可以随意组合从而构建出更加复杂的应用。而且Qt还提供了多种QML与C++交互的机制,如果QML内建的UI元素不能满足实际需求,程序员可以用C++实现复杂的UI,而Qt本身又有基于CSS style sheet的UI方案和Graphics View的方案,这都让开发人员可以快速地制作出炫目的UI来。另外值得一提的是,基本上可见的QML UI元素,都为触摸操作甚至滑动手势提供了一定的支持,这从QML自带的Demo就可以看出来,不但需要的代码量非常少,而且做出的UI效果却非常时尚。
  可以这么说,Qt推出Qt Quick这个方案,代表了应用程序开发的一个方向,快速制作精美UI的方向。基本上所有大的开发框架/解决方案都采用了类似的技术,比如微软的WPF,Mozilla的XUL,甚至Qt在开源界的长期竞争对手Gtk+也有类似的方案,即用简单的标记式、声明式的语言构建UI,减少美工们的学习负担和工作量,而使用其他功能强大、便于操控底层的语言实现业务逻辑。相比其他几个竞争对手,整体而言Qt的优势在于跨平台性好,配套的开发工具也一直在进步。但是它必然也有些缺点,比如一直以来Qt的运行效率不高,虽然Nokia收购后这在方面做了大量的努力;前不久Qt又回归了社区,Nokia成为了一个普通的贡献者,这也许会带来发展方向模糊,进度缓慢的问题,比如一直由开源社区在开发的Qt for Android的port,一年多了仍然没能正式发布。
  总的说来,Qt是一个构建Windows、Linux、Mac OS X以及Symbian、MeeGo应用的低成本、高效率的解决方案。如果基于lighthouse机制的Android和iOS移植能尽快正式发布,那在普通消费型电子产品平台上,就真的如它的宣传语所说的Code Less, Create More, Deploy Everywhere了!

钱不够纸醉金迷,呜呜

  作为纸醉金迷的生活的开始,随便在网上看了一下上海的景点列表,排在第一位的居然是上海科技馆,恰好我也知道它在某条地铁线上,于是就跑过去了。之前就听别人说过不好玩,去了之后才体会到到底不好玩到什么程度。60块门票实在太不划算了,6块钱才差不多。里面多数是小孩,以及带小孩子来的大人,像我这样的实在很稀奇。封杀之~
  今天在公司里把AWD的第一部分快速过了一遍,明天继续看第二部分,争取这周把整本书都过一遍,达到可以用windbg完成基本的调试任务的目标。说到底,最终的目标是要能用windbg分析dump file的目的,虽然以前也做过这种事,但都是囫囵吞枣不求甚解的,这次有机会可以系统的学习下很有用。另外,我想在这公司里,估计以后回过头来看,最大的收获可能是英语的听读能力有大进步吧,可能写和说的能力也会有所提高吧,这将是我最高兴的事。
  周末无聊,随便算了一下自己每月的固定开销,吓了一跳,居然这么高,这点工资收入实在不够看,要多久才能攒够买MBP的钱呢,昨天从上海科技馆出来后跑到陆家嘴的苹果专卖店,发现13寸的那款只要11498了,以前印象中是13998的呀,好心动,国庆后一定要入一个。也就是说,光靠这点工资的收入是远远不能支撑我日益膨胀的消费能力和消费欲望了,赚外快呀呀~
  csdn上的Qt应用开发大赛奖品好少,不过E7很让我眼馋喵,还剩下一个半月,快速写几个程序试一把。先就已经提上计划好些日子的Aokiwen吧,豆瓣客户端,支持Win/Mac/Linux,以及Symbian。qDou其实已经做得不错了,不过它一开始就是为手机设计的,有些方面不是很舒服。握拳!

纠结了

  因为想要把CodingStudio移植到Mac,于是就想先编译下wxWidgets 2.9试试。结果在Windows下用VC9倒是正常编译通过了,用MinGW 4.4最后链接的时候报wxScintilla里一些符号找不到,真头痛。
  后来就想试试Qt吧,找来QScintilla最新的稳定版本2.5.1,编译倒是基本上没问题,可是自带的那个example在一启动就崩溃。
  在Mac下编译wxWidgets 2.9倒是正常通过了,而且确实是使用cocoa 64bit port,试了几个sample也能正常运行。
  头痛。

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.(21)

  Ninayan的主要功能基本上都做出来了,剩下的主要是增加各种服务的支持,比如各种微博,各种SNS,以及Google Reader。其次便是界面和操作上的细节方面的调整,现在还是很粗糙的。
  离上次W.I.P.已经有3周多了,这3周主要实现了文章浏览特性。文章浏览有3种模式,一种是仿feedly的可扩展的列表,一种是信reeder的分栏,还有一种是仿paper.li的报纸模式。但是,目前的效果还远远没达到预期。放几张图吧:

feedlyView

feedlyView


feedlyViewFullscreen

feedlyViewFullscreen


reederView

reederView


paperView

paperView


paperViewFullscreen

paperViewFullscreen


  还增加了个视频观看视图,这是计划外的,但觉得有必要,也很粗糙:
videoView

videoView


  直到这里才发现,在Mac OS X 10.6.6上一直以64位Cocoa编译的Qt,果然视频播放不了了,不记得在哪里看到过说明,QtWebKit在Mac上如果是64位的话是载入不了Flash播放插件的,因为Flash播放器稳定发布只有32位版本,于是在Mac上也自己编译了一把Qt,改成32位Cocoa框架的就可以了播放视频了,太纠结了,也难怪乔帮主要封杀Flash了。