Use a specialized new tab page in TOUCH_UI builds
This has no change on regular builds (except to rename the NTP resource to
be something more generic).
On TOUCH_UI builds, an alternate NTP front-end that is optimized for touch
is embedded into chrome instead of the standard one. In particular,
I use conditional resource processing to choose the source of the
IDR_NEW_TAB_HTML resource (new_new_tab_page.html for regular builds,
touch_ntp/newtab.html for TOUCH_UI builds).
The same WebUI back-end supports the union of functionality needed by all
front-ends. Eg. the addition of page-index tracking is used only by this
touch-ntp, and there are many features that the touch-ntp doesn't use (yet
The idea with this touch NTP is to focus (for now) on apps, and make it easy
to arrange them into pages. You can swipe/drag to switch pages, and press
and hold to lift an app and rearrange it.
There is lots of further work to improve the touch NTP (including the addition
of automated tests and various UI improvements). But it's far enough along
now that we'd like to use it as the only NTP in TOUCH_UI builds.
Note that only the files in the main 'touch_ntp' directory are embedded as
a resource in chrome. The 'tools' sub-directory provides a script for
type and syntax checking. The 'standalone' sub-directory is a hack that
is used only if newtab.html is loaded directly as a regular web-page. It
enables the app to be used (with fake data) directly for rapid prototyping
TEST=Existing NTP tests still pass in regular builds. Tests for Touch_UI builds are forthcoming.
Total comments: 82
Total comments: 60
Total comments: 4
Total comments: 2
Patch Set 5 : Fix some indentation issues and enable gjslist --strict mode to catch them automatically #
Total messages: 14