Index: ash/mus/frame/README.md |
diff --git a/ash/mus/frame/README.md b/ash/mus/frame/README.md |
new file mode 100644 |
index 0000000000000000000000000000000000000000..84fd555e5b1dfc4cea4922439f696f5458627f93 |
--- /dev/null |
+++ b/ash/mus/frame/README.md |
@@ -0,0 +1,26 @@ |
+This directory contains code needed for rendering and interacting with |
+frames decorations in mash. |
James Cook
2016/08/24 19:56:29
nit: frames -> frame
sky
2016/08/24 20:11:14
Done.
|
+ |
+### Immersive mode |
James Cook
2016/08/24 19:56:29
I would change this to "immersive fullscreen" and
sky
2016/08/24 20:11:14
I modified this slightly, but mostly kept it.
|
+ |
+There are two distinct ways for immersive mode to work in mash: |
+ |
+1. Mash handles it all. This is the default. In this mode a separate |
+ui::Window is created for the reveal of the title area. HeaderView is used to |
+render the title area of the reveal in the separate window. The client |
+does nothing special here. |
+ |
+2. The client takes control of it all (as happens in chrome). To |
+enable this the client sets kDisableImmersive_Property on the window. In this |
+mode the client creates a separate window for the reveal (similar to |
+1). The reveal window is a child of the window going into immersive |
+mode. Mash knows to paint window decorations to the reveal window by way of |
+the property kRendererParentTitleArea_Property set on the parent |
+window. The client runs all the immersive logic, including positioning |
+of the reveal window. |
+ |
+In both cases DetachedTitleAreaRenderer and HeaderView is used to |
+render the title area. The difference is in the first case mash |
+creates the window, in the second case the child does (and tells mash |
+about it). And of course in the second case the client runs all the |
+immersive logic. |