Terms are given below, ordered alphabetically. Corrections or requests for addition? Contact the Views team.
The Chrome OS windowing environment, responsible for non-browser UI such as the login screen, system tray, and various built-in control surfaces. Like Chrome, Ash UI is built using the Views toolkit.
Sometimes, the phrase “Ash Chrome” is used to distinguish the historic Chrome-on-CrOS design (that is, tightly integrated with the operating system) from “LaCrOS Chrome” (where the browser is basically separate from the OS, as on other desktop platforms).
A cross-platform window manager abstraction used on desktop platforms other than macOS. Aura handles tasks like showing windows onscreen and responding to native input events. Because Aura is not the only “platform” Views targets, there is some complexity in Views that would not be necessary if Mac used Aura as well; however, Mac platform conventions differ enough from the platforms Aura currently supports that using Aura on Mac might require significant redesign or impose undesirable API constraints. As of this writing, the question of whether Mac should use Aura remains open.
An abbreviation for “accessibility”. Many different classes with the “AX” prefix are involved in exposing accessibility information for Views, but perhaps the best starting point is one that lacks it: ViewAccessibility.
The application environment on macOS. Originally, Chrome for Mac had UI written exclusively in Cocoa; now the majority of the native UI uses Views, but there are still pieces in Cocoa. Code interacting with Cocoa is generally written in Objective-C++, whose source files typically end in .mm. More general background on Cocoa
A control that displays a selected choice from a list of options. Sometimes called a “select” or “dropdown” control. The specific control in Views has a focus ring and a dropmarker by default, and can be customized in a variety of ways. The “Combo Box” example in views_examples creates a couple of simple comboboxes.
A system responsible for producing the final displayable graphics for a Widget, given a View hierarchy. The compositor manages a Layer tree that allows it to cache, transform, and blend various graphical layers so that it can minimize repaints, accelerate scrolling, and sync animation to the underlying display refresh rate.
A colored outline around an object that is visible when an object has focus and hidden when focus is gone. It is often drawn by a FocusRing object, a View subclass that handles drawing a colored border along a path. When creating focus rings, it's important to color them such that they contrast with both the color inside and the color outside the ring; see the uses of the PickGoogleColorTwoBackgrounds function.
Windows-specific. An opaque handle to a system-native window. Ultimately type-aliased to a void*, but you should never dereference this or examine the actual value; it is only used to pass to various Windows native APIs. Used as the type for AcceleratedWidget on Windows.
The collection of classes that implement hover and click effects on Views. These came from the original Material Design and use dynamically-created layers to draw translucent overlays that may be contained to the bounds of a View or extend outside it. The name came from the appearance of a drop of ink spreading in water, and the most prominent effect, known as a “ripple”, spreads rapidly outward from a single point (generally the cursor position). The base InkDrop class can also manage instant on/off “hover highlight” effects and contains a variety of hooks for different uses.
An abbreviation for “Linux And Chrome OS”. An architecture project to decouple the Chrome browser on Chrome OS from the operating system stack; historically these were tightly coupled and updated simultaneously. More general background on LaCrOS
A node in a tree of objects used by the compositor to manage textures. Calling View::SetPaintToLayer() causes a View to paint to a Layer, which is necessary to do things like paint outside the View's own bounds or perform certain kinds of operations (e.g. blending) in hardware instead of software; however, layers have memory and performance costs and affect sibling paint order, and should be used sparingly.
An operation where a View sets the bounds of all of its children. Generally, calling InvalidateLayout() on a View will recursively mark that View and all ancestors as dirty; then at some point, Widget::LayoutRootViewIfNecessary() will call LayoutImmediately() on the RootView, which will call Layout() on its contents, and so forth down the tree. Views can currently implement custom layout by overriding the virtual Layout() method, but should instead use one of the available LayoutManagers to describe how children should be arranged; then the LayoutManager will be responsible for both computing the View's preferred size and for updating child bounds as necessary.
The platform-specific object that backs the cross-platform Widget object; Widget implements its API by calling methods on the NativeWidget. This is implemented separately for Aura and Mac, and at least on Aura is still an abstraction over the true underlying OS windowing objects. Historically, lifetime and ownership between Widget and NativeWidget instances could vary and was error-prone; as of this writing, this is being addressed.
An abbreviation for “NeXTSTEP”. Seeing this prefix on a type generally means that the type is a longstanding fundamental type in macOS, whose origins date to the 1990s and Apple's acquisition of NeXT.
The combined search and address bar in the browser window toolbar. Coined by early PM Brian Rakowski (as “psychic omnibox”) because it knows and does everything. In code, the term “omnibox” generally refers specifically to the text editing control and its associated popup; the larger visual “bar” it appears in, which also contains affordances to indicate security state, allow bookmarking, and display page action icons, is called the “location bar”.
A website that may provide various native-app-like capabilities, such as installability, integration with system hardware, and/or persistence. PWAs in Chrome are given special UI treatment. More general background on PWAs
A 32bpp (8 bits per channel) non-premultiplied ARGB color value, stored as a uint32_t. This is the most common color type used in Views when interacting with drawing and painting APIs. Because this is a fixed (physical) color value instead of a themed (logical) color identifier, computed SkColors may need recalculation on theme changes; in general, prefer to pass colors around as ColorIds instead, where possible.
The 2D graphics library Chrome uses. Skia is maintained by Google employees and provides hardware-accelerated drawing primitives. More general background on Skia
A web application used to compare pixel test result images against verified baselines. A test in browser_tests or interactive_ui_tests may opt in to pixel testing, and will then produce result images that are managed by a Skia Gold instance. As of this writing, these pixel tests are Windows-only. To run them, add the --browser-ui-tests-verify-pixels, --enable-pixel-output-in-tests, and --test-launcher-retry-limit=0 flags when invoking the test binary.
An animated object used to indicate definite or indefinite progress to the user. The specific control in Views is a 16 DIP spinning circle that can optionally display a checkmark when an operation completes. The “Throbber” example in views_examples creates a throbber.
A cross-platform UI toolkit used to create “native” UI (as opposed to UI built from web technologies). Views is important to both the Chrome browser and the Chrome OS native UI in Ash. Views was created in the early days of Chrome to abstract away calls to platform-specific functions and make it possible to build Chrome UI for multiple operating systems; unlike other cross-platform toolkits of the time like wxWidgets or GTK, it aimed for a platform-native feel (especially on Windows) and a minimal API that was designed to do just what Chrome needed. Over time the Views look-and-feel moved away from platform-native fidelity, toward a style called “Harmony” influenced by all desktop platforms as well as Google's Material Design. However, the minimal API surface persists; Views lacks many controls and features found in other UI toolkits and is not supported on mobile.
View (class)A node in a tree of objects used to represent UI. A View has rectangular bounds, a (possibly-empty) set of child Views, and a large set of APIs to allow interaction and extension. Its primary goal is to abstract user interactions and present data to the browser for display. Historically, implementers have built subclasses as heavyweight objects containing all the code to handle display, business logic, and the underlying data model; this reduces boilerplate but makes classes difficult to test, reuse, or port to other platforms. By taking the name literally and making a View subclass handle only the “view” role in the MVC paradigm, implementers can produce more robust code.
The cross-platform abstraction that represents a “window” in the Views toolkit. It is the gateway between the Views library and the OS platform. Each Widget contains exactly one RootView object that in turn holds a hierarchy of Views representing the UI in that window. Widget is implemented in turns of a platform-specific NativeWidget, which itself may be backed by other abstractions (at least on Aura). It's possible to have parent/child relationships between widgets, for example when displaying a small floating bubble anchored to (and clipped by) a larger window.