本科毕业论文---基于云协作平台的客户端设计与实现.doc

题目：基于云协作平台的客户端设计与实现

基于云协作平台的客户端设计与实现
摘要
云协作平台其理论依据来源于云计算，是基于互联网，将共享的软硬件资源和信息,通过云资源调度管理系统（JH scheduler），按需提供给计算机和其他设备，并对这些设备进行管理。云协作平台通常提供通用的通过浏览器访问的应用，软件和数据可存储在数据中心。浏览器和服务器结构虽然简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本，然而浏览器和服务器结构也有一些自身无法克服的缺点。现如今，浏览器种类繁多，良莠不齐，这样，就引发了一个很难做到平衡的问题——浏览器的兼容性问题，还有一个根问重要的是：如果要将本地的一些应用程序集成到云平台，浏览器就显得捉襟见肘了。客户端的出现恰恰解决了以上问题。
本文基于云协作平台，以浏览器实现的功能为设计参考，重点在于节省系统软硬件资源，避免不同浏览器带来的浏览器兼容性问题，增强云协作平台前端的可扩展性，并为客户端增加一些与服务端交互的工具，提高云协作平台的用户体验和产品的认可度。客户端的实现是以观察者模式为设计模式，以QT GUI为开发框架，使用Thrift，Boost等第三方工具库。做到与浏览器端高度一致，与服务器端接口兼容，又具有客户端特色的云协作平台的用户前端软件。
通过几个月的学习和努力，熟悉了服务器端的运行机制，以及服务器和浏览器的交互过程，在此基础上参考浏览器端实现的用户操作界面，实现了与浏览器端功能相同的客户端。经过测试，运行稳定，可以投放使用。

关键词:云协作平台；JH scheduler；客户端；QT GUI

Design and Implementation of the Client On Cloud Collaboration Platform
Abstract
Cloud collaboration platform the theoretical basis from the cloud computing, Internet based, will be shared hardware and software resources and information be provided to computers and other equipment, and management of these devices. Cloud collaboration platforms usually provide generic application through the browser, software and data can be stored in the data center. The browser and the server mechanism while simplifying the client computer load, reduce the cost and the workload of system maintenance and upgrading, reducing the overall cost of the user, but the browser and server structure also has some can not overcome its own shortcomings. Nowadays, the browser types, uneven, some good and some bad, so, it raises a very difficult problem -- the browser balance compatibility issues, there is a root to ask important: if some applications into the cloud platform local, the browser is tightly elbow. The client has solved above problems.
In this paper, cloud based collaboration platform, the browser functions as a design reference, Through resource scheduling management system (JH scheduler)， focused on saving the system software and hardware resources, avoid browser compatibility problems caused by cloud browser, enhanced collaboration platform front-end scalability, and to increase the number of interactive tools for the client and server, improve the recognition of cloud cooperation platform user experience and product the. The client is realized by the observer pattern is a design pattern, using the Thrift to QT GUI as the development framework, Boost, and three party tool library. To do with the browser and the server is highly consistent, compatible interface, user front end software cloud collaboration platform and client characteristics.
Through several months of study and work, familiar with the operation mechanism of the server, and the server and browser interaction process, the user operation interface on the basis of browser implementation, achieved with the same client browser function. After testing, stable operation, can be put in use.

Key Words: Cloud collaboration platform ; JH scheduler ;The client;QT GUI

II

目录
摘要 I
Abstract II
1 绪论 1
1.1课题设计背景 1
1.2课题设计的目的和意义 1
1.3课题的主要研究工作 1
1.4 论文结构安排 2
2 课题设计的关键技术 3
2.1 资源调度管理系统简介 3
2.2 观察者模式简介 4
2.2.1 概述 4
2.2.2 解决的问题 4
2.2.3 模式中的角色 4
2.2.4 模式解读 5
2.2.5 模式总结 5
2.3 Thrift库 6
2.3.1 Thrift简介 6
2.3.2 Thrift架构 6
2.3.3 支持的数据传输格式、数据传输方式和服务模型 7
2.3.4 Thrift使用 7
2.4 Boost库 8
2.4.1 Boost库简介 8
2.4.2 Boost的log库 8
2.5 QT GUI简介 10
2.5.1 QT GUI简介和功能特点 10
2.5.2 信号和槽 10
2.5.3 样式表 11
2.5.4 QtWebKit 12
3 系统需求分析 14
3.1 用户需求分析 14
3.2 性能需求分析 15
3.3 数据需求分析 17
4 系统概要设计 19
4.1 软件体系结构设计 19
4.2 系统的数据库设计 19
4.3 系统的功能模块设计 20
5 系统详细设计与实现 22
5.1 登陆页面的设计与实现 22
5.2 登陆后界面的设计与实现 23
5.3 功能模块的设计与实现 26
5.3.1 文件传输 26
5.3.2 执行远端命令 26
5.3.3 查看节点信息 27
5.3.4 启动远程桌面 27
5.3.5 管理远程桌面 27
5.3.6 提交作业 27
5.3.7 作业数据管理 27
6 系统测试 28
6.1软件测试基础理论 28
6.1.1 软件测试定义 28
6.1.2 软件测试基本概念 28
6.2 软件测试目的 29
6.3 软件测试方法分类 29
6.3.1 静态测试与动态测试 29
6.3.2 黑盒与白盒测试 29
6.3.3 单元测试、集成测试、系统测试、验证测试和确认测试 30
6.4 系统测试 30
6.4.1 测试用例设计要求 30
6.4.2 系统各个模块测试用例 31
6.5测试报告 34
7 总结 35
参考文献 36
致谢 37
附录 40

1 绪论

1 绪论
1.1课题设计背景
2006年8月9日，google首席执行官埃里克·施密特(Eric Schmidt)在搜索引擎大会(SES San Jose 2006)首次提出“云计算”(Cloud Computing)的概念。之后包括Google 、IBM、雅虎、惠普、英特尔，以及戴尔在内的世界顶尖级IT公司为推动和发展云计算不遗余力，争先恐后。云计算理论逐步成熟和结构趋于完整，基于云计算的产品应运而生，云协作平台就是其中的一个典型。
云协作平台其理论依据来源于云计算，自然是基于互联网，将共享的软硬件资源和信息,通过运行于服务器端的资源调度管理系统（JH scheduler）统一协调，按需提供给计算机和其他设备，并对这些设备进行管理。云协作平台通常提供通用的通过浏览器访问的应用，软件和数据可存储在数据中心。浏览器和服务器结构虽然简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本，然而浏览器和服务器结构也有一些自身无法克服的缺点。现如今，浏览器种类繁多，良莠不齐，这样，就引发了一个很难做到平衡的问题——浏览器的兼容性问题，还有一个更为重要的是：如果要将本地的一些应用程序集成到云协作平台，浏览器就显得捉襟见肘了。客户端的出现恰恰解决了以上问题。
1.2课题设计的目的和意义
浏览器能够实现的功能，客户端同样也可以实现，但这并不是说，客户端就可以完全取代浏览器来实现与云平台的交互，完成生产实践。浏览器旨在其灵活性，可移动性，而客户端旨在其高度的集成性，以及其普适性，即可以集成操作系统上的所有应用，更方便的为用户提供服务；普适性在于操作系统的较为明确，程序开发有的放矢，这样也大大降低了开发成本，和开发、维护周期。客户端/服务器结构能充分发挥客户端PC的处理能力，很多工作可以在客户端处理后再提交给服务器，这样可以提高工作效率，缩短工作时间，使云平台能够更高效、快捷的工作。客户端/服务器结构在数据安全性方面也明显高于浏览器/服务器结构，可以较为容易地实现多层认证。
1.3课题的主要研究工作
由于云协作平台的浏览器版已经实现，而客户端版是尽量和浏览器版保持一致，因此，熟悉服务器端运行机制和浏览器版的基本结构使得开发客户端变得有的放矢，也就相对容易的多了。服务器端的为java web实现，客户端实现是用C++实现，两者之间需要一个可以相互调用的接口。除此之外，从服务器端拿到的数据列表需要显示在客户端的对话框页面，而这些数据列表是在浏览器端已经
36

实现的，在对话框上能够直接显示web页面，就使得开发工作量减轻许多，这样也为客户端节省了响应时间。
1.4 论文结构安排
本论文共有四章，具体组织如下：
第一章：通过对已经实现的云协作平台的Web端功能分析，提出客户端开发的目的和意义，此次研究的主要任务，以及本次论文的组织结构。
第二章：主要介绍资源调度管理系统（JH scheduler）和开发本系统所采用的相关技术，包括设计模式中的观察者模式，Thrift库、Boost库以及QT GUI编程等。
第三章：系统需求分析，其中包括用户需求分析、性能需求分析、数据需求分析。
第四章：系统概要设计，从软件体系结构，数据库设计，系统功能模块设计等方面叙述。
第五章：系统详细设计与实现，用户登录页面，操作界面，以及各个功能模块的实现。
第六章：系统测试
第七章：总结

2 课题设计的关键技术

2 课题设计的关键技术
云协作平台是通过资源调度管理系统，统一对用户作业需求进行动态管理、分配资源的协作的系统。一般是基于互联网，也有用专业网的情况。云协作平台的主要功能是：分工合作、资源控制、作业管理等功能。
2.1 资源调度管理系统简介
资源调度管理系统(以下称JH Scheduler)是一个集资源监控和分布式应用调度为一体的云计算的基础架构管理中间件，利用JH Scheduler可以快速的建立起一个完整企业级应用服务平台。它可以监控、调度、管理网络上的10台到上千台不同操作系统的服务器、工作站和虚拟机，把它们作为云计算资源集中管理起来为多种类型的应用软件提供统一服务平台。 JH Scheduler具有完备的和可扩展的资源定义、监控等功能，包括硬件资源、操作系统、软件许可证资源、存储资源等等，并且为应用软件提供多种接口来使用这些云计算资源，从而轻易实现应用软件的并行分布式运行和弹性计算，完成从传统的以服务器为中心的计算模式向以应用服务为中心的计算模式迁移。 JH Scheduler支持多种类型应用软件的通用中间件，包括CAD/CAE软件、制造业设计软件、石油勘探分析软件、模拟仿真软件、科学计算软件等，这些不同类型的应用软件可以同时使用JH Scheduler管理的应用集群，从而实现计算资源的充分共享。 由JH Scheduler管理的应用集群系统具有高可用性，用户可以配置多个管理节点，即使只有一个JH Scheduler管理节点正常运行，应用集群服务也不会宕机，做到应用服务的全天候可用，为用户和应用提供最佳的计算服务。
为了使计算资源得到高效使用，JH Scheduler内置多种高效的管理调度策略，包括先来先服务、用户/用户组资源配额管理、基于队列的优先级设置、资源公平共享调度、独占式作业调度、抢占式作业调度等，基于这些策略，JH Scheduler把应用软件的每一次执行实例作为一个作业来进行调度和管理，并为管理员和作业的用户提供方便的作业状态监控和友好的用户界面。此外，JH Scheduler还有可扩展的接口，可以为特殊的管理调度需求定制策略。 由JH Scheduler管理的应用集群系统具有高可靠性，作业在没有资源的情况下将在系统中排队等待资源。即使在执行过程中计算节点出现故障，JH Scheduler仍然可以把作业重新调度到其它机器上继续执行。
作为云计算基础架构产品，JH Scheduler与其基础之上的Web portal产品提供安全友好的用户管理和使用界面；通过与JH License Manager集成管理应用集
群系统的许可证资源，并提供专门针对许可证资源的先进调度；通过与JH Analytics集成为用户提供丰富的资源使用和作业调度报表功能，以及详尽灵活的计费系统。
JH Scheduler产品的总体结构如图2.1所示。

图2.1 JH scheduler 总体结构图
2.2 观察者模式简介
2.2.1 概述
　　观察者模式有时被称作发布/订阅模式，观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。
2.2.2 解决的问题
　　将一个系统分割成一个一些类相互协作的类有一个不好的副作用，那就是需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合，这样会给维护、扩展和重用都带来不便。观察者就是解决这类的耦合关系的。
2.2.3 模式中的角色
　　抽象主题（Subject）：它把所有观察者对象的引用保存到一个聚集里，每个主题都可以有任何数量的观察者。抽象主题提供一个接口，可以增加和删除观察者对象。
　　具体主题（ConcreteSubject）：将有关状态存入具体观察者对象；在具体主题内部状态改变时，给所有登记过的观察者发出通知。
　　抽象观察者（Observer）：为所有的具体观察者定义一个接口，在得到主题通知时更新自己。
　　具体观察者（ConcreteObserver）：实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题状态协调。
2.2.4 模式解读
实现观察者模式有很多形式，比较直观的一种是使用一种“注册——通知——撤销注册”的形式。如图2.2详细的描述了这样一种过程：

图2.2观察者模式实现过程
观察者
（Observer）将自己注册到被观察对象（Subject）中，被观察对象将观察者存放在一个容器（Container）里。
被观察
被观察对象发生了某种变化（如图中的SomeChange），从容器中得到所有注册过的观察者，将变化通知观察者。
撤销观察
观察者告诉被观察者要撤销观察，被观察者从容器中将观察者去除。
观察者将自己注册到被观察者的容器中时，被观察者不应该过问观察者的具体类型，而是应该使用观察者的接口。这样的优 点是：假定程序中还有别的观察者，那么只要这个观察者也是相同的接口实现即可。一个被观察者可以对应多个观察者，当被观察者发生变化的时候，他可以将消息 一一通知给所有的观察者。基于接口，而不是具体的实现——这一点为程序提供了更大的灵活性。
2.2.5 模式总结
优点
　　观察者模式解除了主题和具体观察者的耦合，让耦合的双方都依赖于抽象，而不是依赖具体。从而使得各自的变化都不会影响另一边的变化。
缺点
依赖关系并未完全解除，抽象通知者依旧依赖抽象的观察者。
适用场景
当一个对象的改变需要给变其它对象时，而且它不知道具体有多少个对象有待改变时。
一个抽象某型有两个方面，当其中一个方面依赖于另一个方面，这时用观察者模式可以将这两者封装在独立的对象中使它们各自独立地改变和复用。
2.3 Thrift库
2.3.1 Thrift简介
Thrift是一个跨语言的服务部署框架，最初由Facebook于2007年开发，2008年进入Apache开源项目。Thrift通过一个中 间语言(IDL, 接口定义语言)来定义RPC的接口和数据类型，然后通过一个编译器生成不同语言的代码（目前支持C++,Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk和OCaml）,并由生成的代码负责RPC协议层和传输层的实现。
2.3.2 Thrift架构

图2.3 Thrift架构
Thrift实际上是实现了C/S模式，通过代码生成工具将接口定义文件生成服务器端和客户端代码（可以为不同语言），从而实现服务端和客户端跨语 言的支持。用户在Thrift描述文件中声明自己的服务，这些服务经过编译后会生成相应语言的代码文件，然后用户实现服务（客户端调用服务，服务器端提服务）便可以了。其中protocol（协议层, 定义数据传输格式，可以为二进制或者XML等）和transport（传输层，定义数据传输方式，可以为TCP/IP传输，内存共享或者文件共享等）被用作运行时库。
2.3.3 支持的数据传输格式、数据传输方式和服务模型
（1）支持的传输格式
TBinaryProtocol – 二进制格式.
TCompactProtocol – 压缩格式
TJSONProtocol – JSON格式
TSimpleJSONProtocol –提供JSON只写协议, 生成的文件很容易通过脚本语言解析。
TDebugProtocol – 使用易懂的可读的文本格式，以便于debug
（2）支持的数据传输方式
TSocket -阻塞式socker
TFramedTransport – 以frame为单位进行传输，非阻塞式服务中使用。
TFileTransport – 以文件形式进行传输。
TMemoryTransport – 将内存用于I/O. java实现时内部实际使用了简单的ByteArrayOutputStream。
TZlibTransport – 使用zlib进行压缩， 与其他传输方式联合使用。当前无java实现。
（3）支持的服务模型
TSimpleServer – 简单的单线程服务模型，常用于测试
TThreadPoolServer – 多线程服务模型，使用标准的阻塞式IO。
TNonblockingServer – 多线程服务模型，使用非阻塞式IO（需使用TFramedTransport数据传输方式）
2.3.4 Thrift使用
（1）编译安装：./configure –》make –》make install
（2）利用Thrift部署服务
主要流程：编写服务说明，保存到.thrift文件–》根据需要，编译.thrift文件，生成相应的语言源代码–》根据实际需要，编写client端和server端代码。
a）.thrift文件编写
一般将服务放到一个.thrift文件中，服务的编写语法与C语言语法基本一致，在.thrift文件中有主要有以下几个内容：变量声明、数据声明（struct）和服务接口声明（service, 可以继承其他接口）。
b）client端和server端代码编写
client端和server端代码要调用编译.thrift生成的中间文件。
在client端，用户自定义CalculatorClient类型的对象（用户在.thrift文件中声明的服务名称是Calculator，则生成的中间代码中的主类为CalculatorClient），该对象中封装了各种服务，可以直接调用（如client.ping()）,然后thrift会通过封装的rpc调用server端同名的函数。在server端，需要实现在.thrift文件中声明的服务中的所有功能，以便处理client发过来的请求。如图2.4所示。

图2.4 client端和server端的书写
2.4 Boost库
2.4.1 Boost库简介
Boost库是一个可移植、提供源代码的C++库，作为标准库的后备，是C++标准化进程的开发引擎之一。Boost库由C++标准委员会库工作组成员发起，其中有些内容有望成为下一代C++标准库内容。在C++社区中影响甚大，是不折不扣的“准”标准库。Boost由于其对跨平台的强调，对标准C++的强调，与编写平台无关。大部分Boost库功能的使用只需包括相应头文件即可，少数（如正则表达式库，文件系统库等）需要链接库。
2.4.2 Boost的log库
（1）相关概念
· 日志记录：一个独立的消息包，这个消息包还不是实际写到日志里的消息，它只是一个候选的消息。
· 属性：日志记录中的一个消息片。
· 属性值：那就是上面所说的属性的值了，可以是各种数据类型。
· 日志槽（LOG SINK)：日志写向的目标，它要定义日志被写向什么地方，以及如何写。
· 日志源：应用程序写日志时的入口，其实质是一个logger对象的实例。
· 日志过滤器：决定日志记录是否要被记录的一组判断。
· 日志格式化：决定日志记录输出的实际格式。
· 日志核心：维护者日志源、日志槽、日志过滤器等之间的关系的一个全局中的实体。主要在初始化logging library时用到。
（2）框架结构
Boost log的框架结构如图2.5所示：

图2.5 Boost log的框架结构
A）应用程序在图的右侧，通过一个或多个logger实例发送日志消息。
B）应用程序也可以出现在左侧，那就是一个日志的显示实例了。
C）一个日志记录的数据中会包括许多属性。属性基本上是一个函数，它的返回值就是属性值。比如时间不仅是一个函数（也是一个属性）。
D）有三种类型的属性集：全局的，特定线程的，特定源的。前两个是由logging core来维护的，所以不用再初始化。
全局属性集中的属性被连接到所以的日志对象上。
线程属性集中的属性会连接到把它注册到属性集时的那个线程。
源属性集由初始化日志的源来维护的，它会连接到一个特定的源上。
当一个源初始化日志对象的时候，它会从上述的三个属性集的所有属性中得到属性值。这些值会在将来处理。
如果在不同的属性集中有相同的属性名字的时候就会造成冲突，解决冲突的方法是全局属性集的优先级最低，源属性集的优先级最高。高优先级的属性会覆盖低优先级的属性。
E）当组合属性值的时候，logging core来决定一个属性是否要被送到sink中，这就是过滤。有两层过滤，首先应用的是全局中过滤，全局过滤用来快速的过滤掉那些不需要的日志记录。然后 就是sink指定的过滤了。每个sink都有单独的过滤器。sink过滤器允许将一个日志记录定向到一个指定的sink。
F）如果一个日志记录至少通过了一个sink的话，它就可以用了。这时候就是日志消息格式化的时候了。格式化完成的日志消息和属性值一起被送到接收它们的sink中。
G）如上图所示，sink被分为前端和后端两个部分。这是为了抽象sink的通用功能，如过滤和线程同步。前端由日志库提供，用户不大可能再去实现它。而后端 很可能是在日志库的外面，它来实现对日志记录的处理。如写文件，发送到网络等。日志库提供了大部分通常用到的后端程序。
2.5 QT GUI简介
2.5.1 QT GUI简介和功能特点
QT提供了设计师工具，可以很方便的使用鼠标拖拽的方式绘制界面。绘制完毕后自动生成一个界面的.h文件（如ui_mainwindow.h），其中含有一个自动生成的Ui_MainWindow类，这个类中核心的函数是setupUi，根据界面向导的不同里面接收一个QWidget *参数或者QMainWindow *参数。这个函数会自动在传入的QWidget或QMainWindow上根据设计师绘制的界面创建可视化控件。使用这个自动生成的类有两种方式，一是在定义QWidget或QMainWindow时创建一个Ui_MainWindow类型的成员ui，在构造函数中调用其setupUi方法ui.setupUi(this)，或使用C++特有的多继承方式，定义子类的时候同时以Ui_MainWindow作为基类，在构造函数中直接调用setupUi(this)。这时已经可以在自定义部件子类中显示绘制的界面了。要访问绘制界面的可视化控件，根据上述两种方式使用ui->控件名称或者控件名称直接进行引用即可。
2.5.2 信号和槽
在图形界面编程中，很多时候我们希望一个可视对象发生某种变化时通知另一个或几个对象，再一个地说，我们希望任何一类的对象能和其他对象进行通讯。例如，某 个数值显示窗口负责显示某个滚动条对象的当前数值，当滚动条对象的值发生变化时，我们希望数值显示窗口能收到来自滚动条对象发送的“数值改变”的信号，从而改变自己的显示数值。
对于类似以上的问题，较早的工具包使用“回调”的方式来实现。回调是指一个函数的指针，如果你希望一个处理函数同志你一些事件，你可以把另一个函数的指针传递给处理函数。处理函数在适当的时候会调用回调函数。
采用回调方式实现对象间的通讯有两个主要缺点，首先回调函数不是类型安全的，我们不能确定处理函数使用了正确的参数来调用回调函数，第二，回调函数和处理函数间的联系非常紧密，因为处理函数必须知道要调用哪个回调函数。
在QT开发环境中，实现对象间的通讯我们有一种称为“信号和槽”的机制可以代替回调函数。信号和槽机制用于实现对象间的通讯，是QT的一个中心特性，恐怕也是QT与其它工具包最不同的地方了。
信号和槽机制就是：当一个特定的事件发生时，一个或几个被指定的信号就被发射，槽就是一个返回值为void的函数，如果存在一个或几个槽和该信号相连接，那在该信号被发射后，这个（些）槽（函数）就会立刻被执行。
信号和槽机制是类型安全的，一个信号的签名必须与它的接收槽的签名相匹配，这样编译器就可以帮助我们检查类型是否匹配。信号和槽是很宽松的联系在一起的，一个发射信号的对象不用考虑哪个槽会接收这个信号，接收信号的槽的所在对象也不知道要连接的信号是哪个对象发射的。QT的信号和槽机制可以保证如果你把一个信号和一个槽连接起来后，槽会在正确的时间使用信号的参数而被调用，信号和槽可以使用任何数量、类型的参数。
QT的窗口部件已经有很多预定义的信号，也有很多预定义的槽，但我们总是通过继承来加入我们自己的信号和自己的槽，这样我们就可以处理感兴趣的信号 了。凡是从QObject类或者它的某个子类继承的所有类都可以包含信号和槽。当某个事件发生后，被指定的信号就会被发射，它不知道也没有必要知道是否有 槽连接了该信号，这就是信息封装。
槽是可以用来接收信号的正常的对象的成员函数，一个槽不知道它是否被其它信号连接。可以把一个信号和一个槽进行单独连接，这时槽会因为该信号被发射 而被执行；也可以把几个信号连接在同一个槽上，这样任何一个信号被发射都会使得该槽被执行；也可以把一个信号和多个槽连接在一起，这样该信号一旦被发射，与之相连接的槽都会被马上执行，但执行的顺序不确定，也不可以指定；也可以把一个信号和另一个信号进行连接，这样，只要第一个信号被发射，第二个信号立刻就被发射。
2.5.3 样式表
QT中可以灵活的使用层叠样式表(CSS)，其语法和css很相似。因为HTML CSS的灵活性，可以很方便的为QT界面设计自己需要的外观。
（1） 各子对象设置样式表
部件的对象名调用样式表，如下:
comboBox->setStyleSheet("QComboBox{border:1pxsolidgray;border-radius:3px;padding:1px18px1px3px;}");
这样单独对该部件设置样式表。需要注意的就是，当后面再次使用setStyleSheet函数对comboBox设置样式表时，之前设置的样式表就不起作用了，也即样式被现在定义效果的取代了。
如果想定义所有某一类控件(比如界面上所有的QComboBox)一个样式，可以使用qApp进行设置。
（2）使用qApp设置样式表
qApp是一个全局对象，使用其设置样式表之后，部件就固定样式了，当然，后面使用某个子对象调用setStyleSheet函数时，会只改变函数中设置的样式，其他的样式不会发生改变。
比如：
qApp->setStyleSheet("QPushButton{border:2pxsolidblue;border-radius:6px;background-color:#E3EAA5;min-width:80px;}QComboBox{border:1pxsolidgray;border-radius:3px;padding:1px18px1px3px;}QLineEdit{border:1pxsolidgray;border-radius:5px;padding:08px;selection-background-color:darkgray;}");
这句话定义了按钮、下拉框、行编辑框的样式，界面中这三种部件都按照里面定义的样式显示。如果后面要对其中一个子部件的样式进行修改，可以直接调用setStyleSheet，将需要的样式覆盖覆盖掉之前的，其他的保留，例如
pushButton->setStyleSheet("QPushButton{background-color:red;}");
这样就只改变按钮的背景色，边框大小那些qApp定义好的还是不变。
注意：当很多部件布局在一起时，有时先使用qApp，然后在子部件中设置会出现意想不到的结果，这时只有不用qApp，直接对子部件进行样式表设置，每次样式表元素都要设置全，因为单独设置会覆盖掉之前的样式表。
2.5.4 QtWebKit
QtWebkit模块提供了一个在QT中使用web browser的engine，这使得我们在QT的应用程序中使用万维网上的内容变得很容易，而且对其网页内容的控制也可以通过native controls 实现。
QtWebkit具有渲染HTML，XHTML和SVG 文档，使用CSS排版，运行JavaScript等功能。
在JavaScript 运行环境和Qt object model直接的桥接技术使得自定义的QObject可以在JavaScript代码中使用。和Qt network module的整合使得网页可以通过从服务器，本地文件系统，甚至QT的资源系统中下载。
另外为了提供渲染特性，可以使用HTML元素的contenteditable属性，使HTML文档可以被用户编辑。
为了使用Qtwebkit模块中的类，我们需要在相关头文件中加入 #include <QtWebKit>，在工程的pro文件中添加 QT += webkit语句。
QWebView主要用来查看网页，一个QWebView的实例中有一个QWebPage。
QWebPage可以访问这个页面的文档结构，它主要描述如Frames，the navigation history, 和编辑内容的the undo/redo stack。
HTML文档可以嵌套到一个frameset中个frame中。HTML一个独立的 frame是通过QWebFrame类展示的。这个类中包含了到JS window object的bridge和用于刷新的QPainter。每一个QWebPage拥有一个QWebFrame作为其main frame，一个main frame可以包含多个child frame。
每一个的Frame都有一个自己的JavaScript Context。QWebFrame::addToJavaScriptWindowObject()可以使Qt C++中的object从JavaScript函数中访问。QWebFrame::evaluateJavaScript()可以使用户在C++代码中直接运行JavaScript代码。
一个HTML文档中独立的元素可以通过在同一个页面中的DOM JavaScript 接口访问。对应的类是QWebElement。可以使用CSS选择器通过QWebFrame's findAllElements()和findFirstElement()函数获取QWebElement对象。
QWebSetting提供了对浏览器常用的各种属性，和各种设置的配置。如：JavaScript enabled，plugin enabled等。通过其默认设置可以显示所有QWebPage实例的默认配置。个别的属性可以通过这个页面的setting来设置。全局的Setting使用QWebSettin