First step into enabling pure views build for Chromium/ChromiumOS

views/widget/widget.cc

Index: views/widget/widget.cc
diff --git a/views/widget/widget.cc b/views/widget/widget.cc
index 8ed6c8d724acab94f1a18a45af72dbd9cdc51554..1128c2bd0cd5d80ffb69d567ce19966775a3fd8f 100644
--- a/views/widget/widget.cc
+++ b/views/widget/widget.cc
@@ -215,7 +215,7 @@ void Widget::SetPureViews(bool pure) {
 
 // static
 bool Widget::IsPureViews() {
-#if defined(TOUCH_UI)
+#if defined(TOOLKIT_USES_PURE_VIEWS)

[oshima, 2011/09/10 02:04:19]

TOOLKIT_USES_PURE_VIEWS and TOOLKIT_USES_GTK will co-exists for a while, so
let's keep the original way.

[Emmanuel Saint-loubert-Bié, 2011/09/10 03:06:31]

The goal of this CL is to have a unique gyp flag (toolkit_use_pure_views) get us
a default build that let us test Pure Views (and soon work in concert with Aura)
for Chrome and for ChromeOS.

PureViews means that we are trying to *not* co-exist (with GTK). And I agree we
are not there. I want to start stubbing out more of GTK (like we do for Wayland
and Aura) under this define so that we can better estimate the size of the GTK
iceberg. Or maybe directly use the Aura stubs (based on the progress of Aura).

We can already coexist today with GTK if we:
 - set toolkit_views=1 (but not toolkit_uses_pure_views)
 - run with --use-pure-views on the command line

Ideally we want to see less of TOUCH_UI and more of specific defines like
USE_VIRTUAL_KEYBOARD, TOOLKIT_USES_PURE_VIEWS...

I certainly can introduce yet another flag, however we have enough of them I
think :-)

   return true;
 #else
   return use_pure_views;