专注于互联网--专注于架构

最新标签
网站地图
文章索引
Rss订阅

首页 »嵌入式开发 » 浏览器源代码:基于Linux的源代码开放浏览器 »正文

浏览器源代码:基于Linux的源代码开放浏览器

来源: 发布时间:星期五, 2008年12月12日 浏览:149次 评论:0

Linux在嵌入式系统中应用正在迅速扩大这意味着软件开发工程师必须弄懂如何将为资源丰富台式PC和服务器开发源代码开放软件应用于资源有限嵌入式系统
7CgfbaiducukKnY

7CgfbaiducukKnY
现在PC机上具备上百兆字节RAM和几十GB硬盘资源已很普遍但对嵌入式系统开发者来说通常是不可能而且运行在可随意重启动系统中桌面和企业级软件很容易经常升级但是安装在工业现场嵌入式应用系统就不太容易而且理想状态下这种系统会直运行下去根本不存在重新启动问题因此开发工程师们应当研究如何在个只有数兆存储器资源嵌入式设计中充分利用过去十年来开发桌面软件资源?
7CgfbaiducukKnY

7CgfbaiducukKnY
现有基于Linux操作系统桌面浏览器家族已经发展到了相当规模目前市面上可供用户选择桌面浏览器超过20种那么为什么还要引入另外种呢?在做了哪种现有桌面浏览器适合用于开发嵌入式浏览器调查之后我们发现没有个网络客户端桌面浏览器满足嵌入式系统要求这些浏览器不是象NetscapeMozilla那样太大而导致没法在大多数嵌入式系统上运行就是太小其HTML功能很不完整因此我们决定自己设计种新型浏览器种专门适用于嵌入式Linux设备浏览器
7CgfbaiducukKnY

7CgfbaiducukKnY

7CgfbaiducukKnY
我们有五个最初设计目标首先希望创建尽可能小浏览器不过这种浏览器要保持与HTML 100%标准兼容性这种浏览器可以应用于很多应用设备从嵌入式设备文档显示到因特网电器设备和机顶盒而且我们必须确信这种浏览器总能正确地显示网页其次同样重要希望采用现有用于HTML语法分析和显示引擎开放式源代码我们不想再从零开始编写HTML引擎代码这是实现大多数小型浏览器时最常见个毛病正确地显示所有HTML文件需要大量知识和经验尤其是现在很多HTML文件仍然是手写
7CgfbaiducukKnY

7CgfbaiducukKnY
第三希望采用已选定HTML窗口部件代码我们不想改变任何核心HTML显示引擎代码尽管它源代码是开放这样做将带来两大主要好处:是不用操心HTML显示引擎功能升级HTML专家已经优化了HTML分析引擎代码设计;二是不会有设计缺陷被直接引入到核心显示子从而可保证很高代码质量
7CgfbaiducukKnY

7CgfbaiducukKnY
小型窗口部件
7CgfbaiducukKnY

7CgfbaiducukKnY
第四我们想要使用套适用于小环境用户界面窗口部件为此决定利用Fast Light工具套件(FLTK)应用框架FLTK可从www.fltk.org获得它能提供套理想适用于小型应用环境用户界面窗口部件
7CgfbaiducukKnY

7CgfbaiducukKnY
最后我们认为为了使这种浏览器被市场广泛接受应使它具有足够灵活性即既可以运行在新型嵌入式Microwindows图形窗口环境中(www.microwindows.org)也可以运行在标准X Windows系统中此外我们希望确保这两种视窗操作系统都可以与该软件设计进行无缝集成而且不会对该浏览器体系结构产生任何影响
7CgfbaiducukKnY

7CgfbaiducukKnY
个主要决定是选择源代码开放HTML语法分析和显示引擎我们从KDE桌面kmf文件管理器中选择了KDE 1.0 HTML窗口部件(KDE可在www.kde.org获得)选择引出了至少三个问题:为什么不使用KDE更新v2.0 Konqueror窗口部件?Mozilla 和 Gecko 搜索引擎怎样?为什么不使用QT(它是挪威Trolltech AS公司C跨平台GUI开发系统)?
7CgfbaiducukKnY

7CgfbaiducukKnY
对于第个问题我们是这样考虑:KDE 1.0 HTML窗口部件在大多数网站上都能正确显示点我们已经通过运行桌面kfm文件管理器得到验证KDE窗口部件工作稳定支持全部HTML 3.2功能相对较小而且其代码可读性好易于再利用那么为什么不使用可支持HTML 4.0和javascript 1.4KDE 2.0窗口部件呢?这里至少有两个问题:首先KDE 2.0在我们设计工作开始时候还不成熟缺少很多功能而且在实际运作工程中表现还不够稳定现在它已经改进了很多但仍缺乏实际验证与此相反KDE 1.0窗口部件已经推出了年多实践证明是比较成熟;第二KDE 2.0窗口部件几乎比它1.0版本大四倍我们认为对第版来说其功能与大小折衷是可以接受尤其是由于该设计可扩展性好即便在其设计定型以后仍允许添加新功能
7CgfbaiducukKnY

7CgfbaiducukKnY
有段时间我们还曾考虑过Mozilla, 它是继网景浏览器之后推出种源代码开放浏览器但最终因反对声过多而放弃了它Mozilla过于庞大了Mozilla 版本GTK+窗口部件(不包括邮件、新闻等)在不装入任何网页情况下需要多达12M字节这比目前ViewML浏览器要大6倍GTK+窗口部件集合也很大与FLTK100k相比它至少有2M字节
7CgfbaiducukKnY

7CgfbaiducukKnY
易置换类集
7CgfbaiducukKnY

7CgfbaiducukKnY
到目前为止在考虑使用那种窗口部件时争论最多是KDE 1.0窗口部件使用QT窗口部件集合(QT可从www.trolltech.com 获得)如果我们可以对最初设计目标做些妥协那么QT窗口部件将由于好几种理由而成为这方案个合乎逻辑选择其中之尚没有Microwindows版本QT采用了种独特编码风格它允许用运行在另工具套件上改进版类方便地置换原有工具套件具有Microwindows和X版本
7CgfbaiducukKnY

7CgfbaiducukKnY
事实降低了QT API总体大小我们不再需要所有你可得到个免费QT版本作为编码参考
7CgfbaiducukKnY

7CgfbaiducukKnY
我们最终选择是可同时在Microwindows和X上运行窗口部件集合FLTK工具套件也采用C编写选择它另外个好处是这工具套件在对QT API和后端FLTK进行集成时相对较简单
7CgfbaiducukKnY

7CgfbaiducukKnY
在选择了核心显示引擎之后我们创建了个分层软件体系结构结构严格地定义了每个浏览器模块以及每模块应该完成功能为了满足不改变显示引擎编码设计目标该体系结构是必需我们也必须定义些新模块旦开发出更小模块或因采用图形化视窗系统而需要对某些模块进行更改就可以置换旧模块我们集成模块包括:浏览器应用层、万维网WWWLib库、KHTML View和窗口部件模块、QT兼容层、IMLIB 图形库和FLTK应用框架
7CgfbaiducukKnY

7CgfbaiducukKnY
ViewML浏览器应用层很小并完全用C FLTK应用框架编写它提供了基本图形用户界面布局我们尽量将这层做得很小以便应用工程师能够很容易地为某个特定嵌入式应用环境修改ViewML浏览器而无需深入了解整个浏览器些嵌入式应用环境中可能根本没有用户界面只显示个全屏幕浏览器页面层也可以处理网络和本地文件存取需求
7CgfbaiducukKnY

7CgfbaiducukKnY
我们选用了万维网协会WWWLib库来执行所有异步网络输入/输出和HTTP获得(HTTP get)功能它比较容易使用我们发现WWWLib库基本上要比实际所需要因此它可能将被改写不过就目前而言它使我们不必在这专门领域花费太多精力就可迅速获取版浏览器功能
7CgfbaiducukKnY

7CgfbaiducukKnY
KHTML View和窗口部件模块由原始未经修改KDE 1.0 HTML窗口部件代码构成未经修改源代码被上层用户界面应用层仍认为是在和下层QT应用框架通信KHTML窗口部件处理所有HTML语法分析、作图和基本布局操作它并不直接处理屏幕滚动或显示框架操作而是把这些任务授权给KHTML View去做KHTML View是ViewML中功能最全面种窗口部件它管理个或多个KHTML窗口部件并执行屏幕滚动和HTML框架显示操作
7CgfbaiducukKnY

7CgfbaiducukKnY
QT兼容性层提供未经修改HTML窗口部件和FLTK应用框架(而不是QT框架)之间接口C QT类在这层被改写以保持相同公共接口这些类包括图形窗口部件(编辑控制、按钮等)、类集及串类、以及实现些特定QT功能通用功能类所有图形类采用FLTK提供功能实现这使得所有标准控制和大多数作图功能相对比较容易实现不过用于窗口部件内部通信非标准QT信号机制不得不从零开始进行编码所有类集和串类在标准C库中实现这些库包括:堆栈、列表、字典(哈希表)和常见串类除了QT在其类集合中使用新型自动删除机制以外这些类完全是标准
7CgfbaiducukKnY

7CgfbaiducukKnY
对图象而言Gnome项目中IMLIB曾用于X视窗系统IMLIB库允许实现QT类型图象显示功能包括自动检测图象类型、自动缩放图象、以及将图象显示在屏幕上尽管IMLIB库也有些不足之处例如大小但最主要缺点是它不适用于Microwindows因此对于该环境我们直接将图形图象支持功能增加到Microwindows中这样就较好地解决了这问题同时使该模块仍保持较小尺寸并且允许增加新图像解码器
7CgfbaiducukKnY

7CgfbaiducukKnY
根据视窗系统不同可以采用两个不同版本FLTK应用框架标准版本FLTK包括对Win32和X支持我们和Microwindows项目开发人员起将FLTK移植到Microwindows已有Nano-X API中技术支持允许与Microwindows服务器进行客户-服务器交互就如同采用Xlib模型由于FLTK和Microwindows都能支持X Window系统因此它是个很不错选择
7CgfbaiducukKnY

7CgfbaiducukKnY
通过直接采用带FLTKX Windows系统或在X Windows系统上运行Microwindows服务器ViewML浏览器就可在Linux平台上进行调试和改进用这种方法不管运行Microwindows还是X Windows系统目标环境确切特性都可以被仿真出来Microwindows系统允许在台式机上仿真目标设备准确显示特性我们也希望能够在台式机上运行与目标设备基本相同代码路径这可极大地改善质量控制
7CgfbaiducukKnY

7CgfbaiducukKnY
ViewML项目已经在短时间内开发出了种高品质网络浏览器它直接针对嵌入式Linux环境通过包含源代码开放核心部件我们已经能够在不占用多少RAM和ROM资源情况下使用个高品质显示引擎
7CgfbaiducukKnY

7CgfbaiducukKnY
ViewML浏览器运行大概需要2M字节RAM代码文件大小大约是800k在Microwindows系统环境下运行时对RAM需求不超过2.5M字节这使它可用在大多数带图象显示功能32位嵌入式Linux系统上由于整个ViewML项目源代码是开放因此其他开发者可以迅速理解ViewML并进步将它加以完善
7CgfbaiducukKnY

相关文章

读者评论

  • 共0条 分0页

发表评论

  • 昵称:
  • 内容: