翻译chromium开发文档之 -ChromeViews，chrome的UI体系

Overview and background

总览与背景

Windows provides very primitive tools for building user interfaces. The system provides a few basic controls and native window containers, but building a custom user interface is difficult. Since we desired a differentiated aesthetic for Chromium, we have had to build a framework on Windows to accelerate our development of custom UI. This system is called ChromeViews.

Windows 操作系统(以下简称Windows)仅为UI(用户界面)绘制提供了相当原始的工具.系统提供了一些基本的控件和一些本地化的容器,但是要建立一个自定义 (自绘)的用户界面还是相当地困难.因为我们想给Chromium一个不同与Windows的艺术风格,所以我们必须在Windows提供的接口上建立一 个框架,用来加速我们的自定义UI开发,这个框架系统被命名为 ChromeViews.

ChromeViews is a rendering system not unlike that used in WebKit or Gecko to render web pages. The user interface is constructed of a tree of components called Views. These Views are responsible for rendering, layout, and event handling. Each View in the tree represents a different component of the UI. An analog is the hierarchical structure of an HTML document.

ChromeViews 是一个渲染系统,它不像WebKit或者是Gecko中渲染网页的引擎.用户界面由许多个称为View的组件所组成,它们形成一个树的结构.这些View 负责渲染,排版,和事件处理.树中的每一个View都表示不同的用户界面组件.与之类似的是HTML文件的层次结构.

注: 这里的 not unlike 我把握不准,不知道怎么翻译才算准确,请大人们指点指点.

At the root of a View hierarchy is a Container, which is a native window. The native window receives messages from Windows, converts them into something the View hierarchy can understand, and then passes them to the RootView. The RootView then begins propagation of the event into the View hierarchy.

View 树中的根结点是一个容器,它是一个Windows本地窗口.这个窗口从Windows接收消息,把它们转换成View能够理解的格式然后把它们传给 View树. (说得这么玄乎,其实就是调用对应的函数罢了.)

Painting and layout are done in a similar way. A View in the View tree has its own bounds (often imbued upon it by its containing View's Layout method), and so when it is asked to Paint, it paints into a canvas clipped to its bounds, with the origin of rendering translated to the View's top left. Rendering for the entire View tree is done into a single canvas set up and owned by the Container when it receives a Paint message. Rendering itself is done using a combination of Skia and GDI calls — GDI for text and Skia for everything else. For WebKit or Gecko developers, the analog of a View can be thought of as a RenderObject or nsFrame respectively, and a Container Widget or nsWidget respectively.

绘制与排版也是按相似的方法来完成的,View树 的一个View拥有自己的区域(通常是由它包含的View来填满),那么当它被请求绘制的时候,它向定位在它的区域上的画布进行绘制输出,绘制从View 的左上角开始.当View树接收到一个绘制消息时,整个View树所有内容被绘制到容器拥有的唯一一个画布上.绘制是由Skia和GDI共同完成的 -----GDI负责文件,而Skia负责其它所有的事情.对WebKit或者是Gecko的开发人员来说,唯一的共同点就是View可以被看作是一个个 单独的渲染对象或者是nsFrame,或者是一个个单独的容器Widget或nsWidget.

Chromium has several Container implementations for various purposes, but over time it would be ideal to standardize on just one, with specializations for different kinds of windows. (The most generic case is child control; the most specific case is when custom high-level pieces of UI need to respond to particular Windows messages to implement their desired functionality.) Since these objects are the View system's interface to the operating system, they are not especially portable.

chromium拥有多个为了不同目的而实现的容 器,但随着时间的流逝,对各种不同的窗口把不同的容器特殊化,把它们标准化或者是干脆合并成一个,后者看上去更理想.(最常见的情况就是子窗口控件,最特 殊的情况就是自定义一个高级别的需要处理特定Windows消息的用户界面.)因为这些对象是View系统面向操作系统的接口,它们没有好的可移植性.

Several UI controls in Chromium's UI are not rendered using Views, however. Rather, they are native Windows controls hosted within a special kind of View that knows how to display and size a native widget. These are used for buttons, tables, radio buttons, checkboxes, text fields, and other such controls. Since they use native controls, these Views are also not especially portable, except perhaps in API.

Chromium的用户界面中有许多控件是用 View来绘制的,但是也有相当一部分本地化窗口,它们有一种独特的可以处理显示和调整窗口大小的View.这些窗口用于按钮,表 格,Radio,Checkbox,文本框,或者其它类似的控件.排除API的因素,因为它们使用本地控件,这些View也没有好的可移植性.

Barring platform-specific rendering code, code that sizes things based on system metrics, and so on, the rest of the View system is not especially unportable, since most rendering is done using the cross-platform Skia library. For historical reasons, many of View's functions take Windows or ATL types, but we have since augmented base/gfx with many platform independent types that we can eventually replace these with.

除非是系统 相关的绘制代码,用于尺寸的代码都基于系统度量,View系统的其它部分并非完全不可移植,因为许多绘制工作是使用跨平台的Skia库来完成的.由于历史 原因,View函数使用了Windows编码形式或者是ATL类型,但自从我们在base/gfx库里增加了大量系统无关的类型以后,我们最终将替换掉它 们.

Code Location and Info
The base set of classes and interfaces provided by ChromeViews can be found in the src/chrome/views directory. All base ChromeViews classes are in the "views" namespace.

代 码路径与信息
ChromeViews提供的类和接口可以在src/chrome/views目录中找到,所有的ChromeView基础类可以在 views命名空间里找到.

Containers you might encounter

ContainerWin: The base class for most Containers in ChromeViews. Provides a basic child window control implementation. Subclass this directly if you are not making a top-level window or dialog.

Window: A top-level window with a native (Windows-provided) non-client frame. A subclass of ContainerWin.

CustomFrameWindow: A subclass of Window that does custom non-client rendering, used on Windows XP. Note: Do not use this or Window directly, instead create a Window using Window::CreateChromeWindow. This will ensure you get the most appropriate frame for Windows XP or Vista.

OpaqueFrame and AeroGlassFrame: The contains used to represent the Browser Window.

Deprecated: XPFrame: Contains the contents of the main browser window on Windows XP and Windows Vista when DWM compositing is not enabled. Not a subclass of ContainerWin, though eventually this will be desirable (via CustomFrameWindow). The entire window is client area; non-client area is faked using a View.

Deprecated: VistaFrame: Contains the contents of the main browser window on Windows Vista when DWM compositing is enabled. Uses a native non-client frame to make use of Aero's glass capabilities. Also not a subclass of ContainerWin; again it will be desirable to make it one eventually, probably via Window.

你可能会遇到的容 器类

ContainerWin: ChromeViews中大部分容器的基类.提供基础的子窗口控件实现.如果你需要创建一个顶级窗口,直接子类化它就可以了. 注: 在最新的代码中,它已经被替换为WidgetWin.

Window: 一个顶级的本地化不包含客户区的frame窗口,ContainerWin的子类.

CustomFrameWindow: Window的子类,定义了非客户区的自绘,在XP上使用.提示:不要直接使用这个类或者是Windows类,应该使用 Window::CreateChromeWindow来创建一个窗口.这可以例证你得到一个最合适的同时用于XP或者是VISTA的frame.

OpaqueFrame and AeroGlassFrame:用于网页浏览器窗口的容器.

Deprecated: XPFrame:包含主浏览窗口的容器,用于XP,在DWM没有启用的情况下用于VISTA,不是ContainerWin的子类.即使以后会成为事实. 整个窗口是一个客户区,非客户区使用一个View来替换.

Deprecated: VistaFrame: 包含主浏览器窗口,在DWM启用的情况下用于VISTA,使用一个本地化的非客户区frame来显示毛玻璃效果.同样也不是ContainerWin的子 类,即使以后会成为事实.

Other approaches
At the start of the project, we began building the Chromium browser using native windows and the owner-draw approach used in many Windows applications. This proved to be unsatisfactory, since native windows don't support transparency natively, and handling events requires tedious window subclassing. Some early UI elements gravitated towards custom painting and event handling, but this was very ad-hoc based on the circumstance.

Existing UI toolkits for Windows are similarly unsatisfying, with limited widget sets, unnatural aesthetics, or awkward programming models.

其它方法
在 项目的开始,我们在许多Windows程序中使用本地窗口和自绘的方法来创建Chromium浏览器.已经证明这并不让人满意,因为本地窗口并不支持天然 的透明,并且处理事件需要单调乏味的子类窗口子类化.有一些早期的用户界面元素使用了自绘与事件处理,但是这是严重受到当时条件影响的.

已 有的Windows平台上的UI工具都不令人满意,它们要么widget有限,要么视觉效果不自然,或者是有着不便使用的编程模式.

Limitations/issues
By and large, ChromeViews makes it relatively easy to build complex custom UIs. However it has a few rough edges that can be improved over time:

The Event types currently are occasionally problematic - they crack the native windows message parameters and then discard them. Sometimes this information is useful.
Some ad-hoc message processing.
Mix of native controls that don't work properly until inserted into a View hierarchy attached to a Container with a valid HWND. Many of our native controls have API methods that require them to exist within a window hierarchy. This means that they cannot be fully initialized until they are inserted.
No common pattern for initialization following view insertion. It'd be good if the WindowDelegate, View or some other aspect of the framework would advocate for a clear path here.
The Container interface is a bit weak and frozen in time somewhat. It should be reviewed and improved

局限性与缺陷:
从大体上讲,ChromeViews 使得创建一个复杂的自宝义用户界面比较容易.但是它还有一些粗糙的地方有待改进.
事件类型目前有时候会出问题,事件类型分析Windows消息参 数然后丢掉它们,有时候这些信息可能是有用的.一些特别的事件处理.
本地控件的混合会导致它们不能正常工作,除非把它们放入一个拥有有效的 HWND的容器当中,这个容器包含一个View树,这个View树插入前面提到的控件.我们的许多本地化控件有一些API函数要求它们生存于一个窗口体系 当中,这就意味着直到它们被插入到容器中它们才能被完全初始化.
在view插入后的初始化没有一个固定的模式可以去遵守.如果窗口代理,view 或者框架中的其它方面扫清道路话会更好.
容器的接口尽早会显得比较弱或者是过于固定.它应当被重新检查并且加以修改.

后记：这篇文 章大意我相信我已经译出来了，我已经尽了我最大的努力。如果有朋友发现了文章里的问题，请留言或者是给我发邮件。非常感谢。