1) http://www.chromium.org/developers/design-documents/aura-des...
1) http://www.chromium.org/developers/design-documents/aura-des...
The funny part is though, that they intentionally disable 3D video acceleration, but are happy to use an OpenGL-based toolkit.
The only hope is that they implement a "style engine" ala Firefox so widgets can at least look native-ish rather than Chromium sticking out like a sore thumb.
edit: Oh I read the document you're talking about now. The Shell is specific to ChromeOS. It lets them use the same Aura code in the compositor and the apps, so they get a win there. It's very likely this is to go along with ChromeOS's switch to Wayland or a Wayland-like display protocol at some point in the future.
Anyway; being lazy; so this is kind of a GUI layer on top of HTML/CSS?
If the browsers used something like XAML, with proper support for components, it would be great.
Maybe web components will eventually get us there, but it is surely a very bumpy road to get to something that only now starts to resemble Smalltalk/Lisp environments.
Aye, that would be so nice!
Chrome UI on Windows, ChromeOS and soon Linux are comprised of a few layers:
Views (widget toolkit abstraction) - tabs, buttons, textfields, etc. Aura (window/"native widget" abstraction, event dispatching, what most code at layers above would consider to be the XWindow, except the XWindow is abstracted (and there is only one XWindow per top level browser window)) CC - (Chrome Compositor, also used for web content.)
They're all in native code since being able to drop down to the metal (& grab the app's toplevel XWindow) is often useful when building a desktop UI. HTML/JS/CSS binding to CC is limited to Blink.