DevToolsWindow represents a vanilla top-level window that shows the dev tools.
It uses ui::WindowImpl to implement window functionality, which requires a
newer libchromiumcontent which contains the necessary headers for using that
class, and requires some modifications to brightray.gypi to make WTL's headers
available.
* vendor/libchromiumcontent 2f53a96...fc02d93 (4):
> Export third_party/wtl/include headers
> Export test_support_base.pdb and test_support_content.pdb
> Fix linker errors with test_support_base on Windows
> Fix linker errors with base_prefs_test_support on Windows
This class doesn't implement any devtools behavior yet. Right now it's just a
glorified wrapper around a content::WebContents. But it's enough to show web
content on screen on Windows!
This is required to get base::win::PEImage, which is required by sandboxing
code.
* vendor/libchromiumcontent c973a7c...04ccdd8 (1):
> Export base_static.lib for Windows clients
* vendor/libchromiumcontent 15ada44...c973a7c (3):
> Create and export sandbox_static.lib for Windows clients
> Export content/app/startup_helper_win.cc to clients
> Rename dist/include to dist/src
We weren't setting the location of the resource bundle correctly in the
renderer process. It turns out base::mac::OuterBundle() returns the helper
app's bundle in the renderer process. So now we have MainApplicationBundle() to
give us the bundle of the main app.
This class can be used to create a content::WebContents that can be inspected
by the Chrome Dev Tools. This requires embedding applications to copy
content_shell.pak into their resource bundle.
Right now the dev tools are always docked to the bottom of the view; we don't
yet support undocking or changing the docked side.
Fixes#1.
We deduce the name of the application from the CFBundleName of the .app bundle
and use a path based on that. Similar logic should be implementable for other
platforms.
Fixes#3.
