Views framework
来源:互联网 发布:唐鹤德对于我知你好 编辑:程序博客网 时间:2024/05/01 00:20
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 views.
views 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.
At the root of a View hierarchy is a Widget, 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.
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 Widget 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.
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.
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.
Code Location and Info
The base set of classes and interfaces provided by views can be found in the src/chrome/views directory. All base views classes are in the "views" namespace.
Common Widgets
- WidgetWin: The base class for all Widgets in views. 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. A subclass of WidgetWin.
- BrowserFrame: A subclass of Window that provides additional message processing for the Browser window in Chrome. See Browser Window.
- ConstrainedWindowImpl: A subclass of Window that provides the frame for constrained dialogs such as the HTTP basic auth prompt.
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 (e.g. Autocomplete), 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.
Limitations/issues
By and large, views 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 Widget 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. The View API will eventually be improved to make this clearer (bug 5191).
- The base Widget interface itself is somewhat frozen in time. Some improvement and consolidation would be worthwhile.
评论
- Views framework
- Zend Framework框架中的modules,controllers,views
- Zend Framework布局和视图 Layouts views
- Zend Framework布局和视图 Layouts views
- python django rest framework Class-based Views
- django rest framework 入门3——Class Based Views
- Django-Rest-Framework 教程: 3. 使用 class based views
- Animating Views Using Scenes and Transitions - The Transitions Framework
- django-rest-framework指南(3):Class Based Views(类视图)
- Django rest framework API Guide的 Views 翻译
- Django REST framework-教程03-class-based views原创翻译
- Django rest framework API Guide的 Generic views 翻译
- Django REST framework-API指南04-Generic views 原创翻译
- Django REST framework-API指南03-Class-based Views 原创翻译
- views::RepeatController
- views::Background
- views::Border
- views::LayoutManager
- SQL SERVER 2008 安装出错 在窗口创建句柄之前,不能调用invoke he beg...
- Android中屏蔽有新短信时通知栏里的通知
- 英语词汇比较 20110130
- Android中的Context
- Safe Browsing
- Views framework
- 阿里巴巴中国站手机客户端项目总结
- K3 BOS 表单插件开发 - 表头值改变事件
- views Windowing system
- 解压刷机文件
- 安全漏洞
- Aura
- 共享内存申请方式
- 《Linux0.11内核完全注释》读后小结 --- 中断与系统调用
Window is not a subclass of WidgetWin. Maybe WindowWin is meant?