Updates from 一月, 2013 Toggle Comment Threads | 键盘快捷键

  • Roger 6:47 pm on January 3, 2013 固定链接 | 回复  

    Ubuntu for Phone 

    phone-photo-hero

     

    新年伊始最大的IT新闻莫过于Ubuntu for Phone的发布,系统的亮点除了全手势操作外,最让人感兴趣的就是插上底座后可以转换成桌面模式,作为一台thin PC来用,官方宣传语是Introducing the superphone that’s also a full PC。(其实自己一直期望Android和Chrome OS能够在底层进行融合,两者可以共存并且共享数据,分别运用于移动模式和桌面模式)

     

    目前已知的信息不多,只是知道除了像Tizen一样,WebApp会得到一等公民的待遇,获得系统级的支持外,跟Sailfish一样,可以使用QML/Qt开发原生应用,对于游戏来说也可以直接使用OpenGL。

     

    虽然很高兴看到Qt得到支持,但是官方暗示系统底层模式是C++编写,QML应用是native应用,效率会比Android的Java来的好就有点误导群众了,应用和系统是否流畅跟开发语言的关系不大,基本取决于系统的绘图堆栈,而无论是Android还是QML,背后的绘图堆栈都是C++编写的,跟上层应用的开发语言没有半毛钱关系,Android发展到现在,绘图堆栈已经改进了很多,可以更充分的利用硬件性能,而不像早期过多依赖于CPU进行计算,当然QML背后的渲染引擎从目前已知的资料来看也相当优秀。另外QML本身也是一种脚本语言,运行在v8 JavaScript虚拟机上,相对而言Java还更原生一些。

     

    Ubuntu为了争取硬件厂商的支持,号称完全兼容Android的硬件驱动(官方的宣传语是If you already make handsets that run Android, the work needed to adopt Ubuntu will be trivial),只是不知道会使用Android的系统模块,还是会使用标准的Linux系统模块来取代Android,比如窗口混合器是使用Android的SurfaceFlinger还是使用Wayland就不得而知了。
    Advertisements
     
    • fxwan 11:44 上午 on 一月 13, 2013 固定链接 | 回复

      http://andreasgal.com/2013/01/08/why-the-web-is-going-to-win-mobile/
      博主可以参考这篇文章的comments部分,V8某些方面比Dalvik优秀可能并不为过。

      • Roger 6:32 下午 on 一月 13, 2013 固定链接 | 回复

        这个虽然有可能,不过文章中我强调的是系统和应用是否流畅,跟应用开发的语言本身关系并不大,主要取决于系统本身,特别是图形子系统。

    • fxwan 7:34 下午 on 一月 13, 2013 固定链接 | 回复

      嗯,这点没问题。Skia看上去更现代(?)

      • Roger 7:54 下午 on 一月 13, 2013 固定链接 | 回复

        现在的Android,使用Skia的地方已经不多了,无论是服务端的窗口混合器,这个从一开始就是使用OpenGL ES1,应用端UI控件的绘制,现在也改成使用OpenGL ES2。

  • Roger 10:40 am on October 24, 2011 固定链接 | 回复
    Tags: Hybiard, ,   

    为什么学习JavaScript 

    最近花了不少时间去学习JavaScript,以一般的理解,JS主要用于浏览器前端编程,也就是所谓的Web App。我自己目前是以本地客户端应用开发为主,也就是所谓的Native App,所以JS跟目前的工作交集不大,不过个人认为JS的学习和研究仍然是一件非常有意义的事情,下面是列举的一些理由。

     

    JavaScript的编程范式跟主流语言有很大的不同,跟Python这样的脚本语言也有比较大的差异,它从其它语言里面吸收了很多不同的概念并糅合在一起。学习JavaScript,可以帮助编程经验比较局限在C++/Java这样的主流语言的我拓宽思维的边界,吸收更多新的理念,及打破以往对编程和编程语言理解的一些局限性。

     

    JavaScript虽然是从浏览器前端编程中发展起来,目前也还是它最大的应用领域。但JS本身仍然是一门完整的面向对象的编程语言,只要能够为它提供一个合适的运行时环境,它就可以很好的应用于在其它的领域。而它作为编程语言的一些优点如下:

    1. JavaScript虚拟机的速度越来越快,以V8虚拟机为代表的即时编译技术的成熟使得构建更复杂的应用成为可能;
    2. JavaScript跟其它语言如C++/Java/.Net的binding越来越容易,使它很适合作为一门粘合剂语言,构建Hybird App;
    3. JavaScript对函数式编程和闭包的支持使得它很适合应用于异步编程,像跟网络相关的应用和以事件驱动为基础的GUI应用;
    4. JavaScript操作复杂的数据结构如树结构很容易,这使得它很适合用于GUI编程和网页编程(后者本来就是它最初的发展目的);

    JavaScript在浏览器前端编程的领域内继续迅猛发展,HTML5标准为浏览器的JS运行时环境增加了大量新的API,提供了更完整的功能,为使用JS编写更复杂和本地化的Web App提供了强有力的支持,而其它以浏览器运行时为核心的中间件如PhoneCap更是增强了通过JS直接访问和控制移动设备的能力,这些都进一步模糊了Web App和Native App的界限。

     

    其它的JS运行时环境的发展也使得JS在除了浏览器前端领域外的应用变得越来越重要,NodeJS构建了JS服务器编程的运行时,QML/JavaScipt构建了JS用于Qt的QML GUI编程的运行时,Windows 8的Windows Runtime构建了JS跟.Net混合编程的运行时等等。所以未来,JS在3个主要的编程领域,本地客户端,浏览器前端,服务器后端都会得到更广泛的应用,特别是本地客户端编程,目前主流的GUI框架和OS的发展都有把JS搭配HTML或者其它的UI脚本语言作为本地GUI应用构建的主要语言的趋势,通过JS跟C++/Java/.Net的Binding,Hybird Native App会变得越来越普遍。

     
  • Roger 5:00 pm on August 22, 2011 固定链接 | 回复
    Tags: Layout, Layout Engine, Layout Management   

    Layout Management – Andorid and Qt 

    这是在公司内部做的一个关于GUI框架布局管理的一次培训的PPT,主要内容包括:

    1. 布局管理的基本概念
    2. Android的布局管理
    3. Qt的布局管理
    4. Android和Qt布局管理的比较

     

     
  • Roger 11:28 am on June 23, 2011 固定链接 | 回复
    Tags: , WebKit Port   

    WebKit 代码阅读笔记 (一) 理解WebKit Port 

    所谓一个WebKit Port,并没有确切的形式,可以看作是OS,平台(应用程序框架),JS引擎,以及各种第三方库的一个组合。

    • 比如WinCairo Port,就是OS=Windows,GraphicsLib=Cairo的一个Porting
    • Qt Port是一个跨平台的Port,Qt本身是跨平台的,所以WebKit对OS的依赖性就依靠Qt本身来解决

    WebKit Port通常处于以下几种目的

    • 使用WebKit作为浏览器(或者类似的User Agent)的页面解析,排版和渲染的核心,如Safari,Chrome
    • 对WebKit进行封装,对外提供构建一个浏览器(或者类似的UA)的API接口,如Qt
    • 以上两者皆有,如Android,iOS,BlackBerry

    对于一个WebKit Port,必须提供的部分包括:

    1. Threading:线程支持
    2. Timer:计时器支持
    3. File System:文件系统
    4. Network:网络(网络甚至都不一定是需要的,如果Port不支持网络请求,而是只支持从文件系统读取的话…)
    5. Graphics Engine/Drawing Surface:绘图引擎/绘图表层
    6. Theme:页面内的各种输入组件的绘制(滚动条,按钮,输入框等),交由外部绘制的原因是它们通常需要符合相应的平台的感观(Look&Feel)

    这里很重要的一点在于,WebCore本身并不一定需要一个窗口环境才能运作:

    • 它需要一个绘图表层来绘制页面,但是并不关心这个绘图表层是来自于一个Widget还是一个离屏位图,是否需要和如何将最后的页面显示输出到一个Widget上面是Port自己的事情。
    • WebCore中的页面可以接收各种各样的输入事件,它处理这些事件和其它因为JS产生的事件,根据处理的结果更新自己的显示,如果产生一些进阶的事件需要外部进行处理,这时就会调用Port提供的相应的回调接口交由Port来处理。但是这些输入事件可以来源于用户真正的输入,然后通过外部的窗口环境转发给页面,但也可能是模拟的事件,WebCore本身并不关心这一点

    简单的说,WebCore本身对外定义了一个干净,清晰的接收输入事件,输出页面显示的接口,并且定义了各种事件的回调接口,Port可以对输入/输出接口进行适配,并且根据自己的需要实现相应的回调接口,来达成WebCore跟窗口环境的整合,所以对于一个WebKit Port,以下是可选的部分:

    1. 将平台产生的输入事件转发给页面处理
    2. 将页面的显示输出一个Widget的Surface上面
    3. 处理输入/输出过程中产生的一些事件的回调,和其它各种各样的回调,比如网络请求和响应的处理,弹出对话框,创建新窗口等等
    4. 插件的创建和绘制
    5. 提供自己的API封装

    WebCore的这种架构引入了很多抽象层,带来额外的系统复杂性,但是获得了对各种不同平台,不同的窗口环境,不同的系统架构支持的灵活性,这也是它成功的主要原因。


    更多:

    QtWebKit Visual Studio 2008 编译和调试环境建立指南

    https://rogeryi.wordpress.com/2011/06/08/qtwebkit-visual-studio-2008-compile-debug-env-setup-guide/

    Chrome的编译:https://rogeryi.wordpress.com/2011/03/29/chrome-webkit-build-on-windows/

    WebKit资源收集 https://rogeryi.wordpress.com/2011/03/28/webkit-resources/

     
  • Roger 11:13 pm on June 8, 2011 固定链接 | 回复
    Tags: , QtWebKit, VS2008,   

    QtWebKit Visual Studio 2008 编译和调试环境建立指南 

    主要参考官方的构建指南:http://trac.webkit.org/wiki/BuildingQtOnWindows,建立QtWebKit在VS2008下面的编译和调试环境,本文提供了对官方构建指南的一些补充和错误纠正。

    工具的准备和编译环境配置

    包括Qt(使用4.7-VS2008的版本),Perl,Python和一些GnuWin32工具集的安装,具体请参考官方构建指南。

    可以修改Qt的qtvars.bat(在Qt安装目录的bin里面),把上述工具加入PATH路径,修改如下(具体目录根据自己的安装目录进行修改)

    set PATH=C:\Perl\bin;C:\GnuWin32\bin;C:\Python27;D:\Qt\4.7.3\bin;%PATH%

    然后运行Qt 4.7.3 Command Prompt进入编译环境。

    代码修正

    当前的Night Build(r88232 07 June 2011)有一个文件在VC下面编译会出错,出错的地方在WebCore/platform/DefaultLocalizationStrategy.cpp第342行, <selection>周围使用了非标准的双引号,去掉或者改成单引号后就可以编译通过。

    编译脚本修改

    按照官方构建指南里面运行build-webkit的方式不能满足我们的需要,并且指南里面生成VC工程的方法有问题,需要自己对编译脚本做一些修改,并且自己手动运行某些步骤。

    运行build-webkit,其实会顺序执行下列步骤:

    1. 创建一个build目录(默认为WebKitBuild,可以通过设定WEBKITOUTPUTDIR环境变量进行修改,按设置,Qt的port会为debug和release版本分别生成debug和release子目录,这种情况会导致后面的VC工程生成出错,需要的修改见下文)
    2. 进入build目录,先生成一些脚本自动产生的代码
    3. 调用qmake,根据.pro文件生成相应的make脚本
    4. 调用nmake,根据make脚本生成库文件

    在webkitdirs.pm脚本里面的函数usesPerConfigurationBuildDirectory定义那些port会分别生成debug和release子目录,我们需要修改让Qt的port不会生成子目录,修改如下:

    sub usesPerConfigurationBuildDirectory
    {
        # [Gtk][Efl] We don't have Release/Debug configurations in straight
        # autotool builds (non build-webkit). In this case and if
        # WEBKITOUTPUTDIR exist, use that as our configuration dir. This will
        # allows us to run run-webkit-tests without using build-webkit.
        #
        # Symbian builds do not have Release/Debug configurations either.
        return ($ENV{"WEBKITOUTPUTDIR"} && (isGtk() || isEfl()))
               || isSymbian() || isAppleWinWebKit() || isQt();
    }

    主要在后面加上isQt()。

    编译和VC工程生成

    在进入WebKit所在的目录下运行:

    perl Tools\Scripts\build-webkit --qt --debug --no-svg

    –debug是生成debug调试版本,如果需要生成release版本可以换成–release,–no-svg是禁用svg支持模块,可以加快编译的速度,更多编译的开关可以查看build-webkit脚本,或者使用参数–help查看帮助,然后根据自己的需要进行选择。

    image

    编译完成1,2,3步,正式开始库编译的时候,就可以终止掉编译过程(crtl+break),生成VC工程后再通过VC工程进行后续的编译。如果按照官方的构建指南加入–qmakearg=”-tp vc”直接运行:

    perl Tools\Scripts\build-webkit --qt --debug --no-svg --qmakearg="-tp vc"

    会出错,原因是因为build-webkit每次都会先清空之前生成的makefiles,可以先临时注释掉这一语句,注释掉build-webkit脚本的431行,然后再运行上面的命令:

    image

    生成VC工程后,即可终止编译。

    打开构建目录下面的WebKit.sln,打开后会得到一个提示说webcore工程加载错误,原因是路径生成有误,直接修改WebKit.sln的第9行的WebCore工程路径即可,然后再加入工具项目DumpRenderTree,ImageDiff,QtTestBrowser,其中QtTestBrowser是一个很简单的浏览器,通过它去跟踪WebKit内部的处理流程和了解内部结构会非常有帮助。设置好项目的依赖关系(QtTestBrowser->QtWebKit->webcore->jscore),就可以开始编译QtTestBrowser了,漫长的编译过程后得到的最后的结果(如果内存足够,可以考虑使用RamDisk和启用更多并行编译设置来加快编译速度):

    image 

    更多

    Chrome的编译:https://rogeryi.wordpress.com/2011/03/29/chrome-webkit-build-on-windows/

    WebKit资源收集 https://rogeryi.wordpress.com/2011/03/28/webkit-resources/

     
    • 匿名 7:52 下午 on 六月 17, 2011 固定链接 | 回复

      谢谢楼主的分享。不过我确很不幸,用命令行编译没问题,但是用vs2008 却出一堆莫名其妙的问题。

      而且如果用命令
      D:\WorkInSVN\Webkit>perl Tools\Scripts\build-webkit –qt –v8 –debug –no-svg –
      -qmakearg=”-tp vc”会出

      Project ERROR: To build QtWebKit+V8 you need qtscript-staging’s v8 branch. (See:
      http://qt.gitorious.org/+qt-developers/qt/qtscript-staging)
      Failed to setup build environment using qmake!

      的错误。

      • Roger 12:21 下午 on 六月 23, 2011 固定链接 | 回复

        因为我没用V8引擎的选项,所有没有碰见这样的状况…

  • Roger 10:50 am on May 12, 2011 固定链接 | 回复
    Tags: , , Qt5   

    Lars Knoll 对Qt5的展望 

    Lars Knoll, KHTML(WebKit引擎的前身)的创建者,目前在Nokia从事Qt的开发。他对Qt,一个极其成功的C++跨平台应用程序/GUI框架,的下一个版本Qt5描绘了自己期望的愿景。从这篇文章中我们可以看到GUI框架未来的演化方向,和以后可能的交互式应用的主流开发方式。

    Objectives with next major version of Qt (Qt 5)

    • Make better use of the GPU, allowing you to create smooth (and accelerated) graphics performance even with limited resources;
    • Making your creation of advanced applications and UIs easier and faster (with QML and Javascript);
    • Make apps connected to the web be as powerful as possible, i.e. to embed and power up web content and services into any Qt app; and
    • Reduce the complexity and amount of code required to maintain and implement a port.

    Qt下一个主要版本(Qt5)的主要目标

    • 更好地利用GPU(2D/3D加速),使得我们即使在有限资源的情况下(移动设备)也可以获得流畅(被加速的)绘图性能。
    • 创建更高级的应用和UIs变得更快更容易(基于QML和Javascript)
    • 应用与Web的互联互通将会变得非常的强悍,也就是可以在Qt应用中嵌入web内容和应用与web之间可以互动
    • 降低移植到不同平台的复杂度和需要的代码量

    从上面可以看出,得益于更普遍和更快的2D/3D硬件加速的能力,和更快的Javascript引擎,我们可以用更快速的方式开发更高级的交互式应用,并且天然具备web整合和跨平台的能力。我们可以使用QML描述界面,用Javascript处理事件交互,少量需要高性能的后端组件(backend component)可以使用C++编写(像已经整合的QtWebKit组件),C++编写的组件和QML/Javascript的解释环境可以无缝地衔接在一起。

    原文:http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/

    对原文的进一步解释,澄清误解:http://labs.qt.nokia.com/2011/05/11/responses-to-qt-5/

     
c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
回复
e
编辑
o
Show/Hide comments
t
返回顶部
l
Go to login
h
Show/Hide help
shift + esc
取消