Indeed there are two places worth changing. After these two changes i am able to build Atom-Shell using Pyhon installed by default (without adding to paths)
The code came from chrome/browser/media, but was simplified to remove
dependencies on other parts of chrome/ and to always allow the media stream
request.
Chromium crashes when starting a download if a content::DownloadManagerDelegate
is not provided. We now provide a default implementation of
content::DownloadManagerDelegate which disallows all downloads.
The ninja generator of gyp behaves strangely on the 'libraries' field of link
settings, for example, specifying path to an external library works well on
both xcodebuild and msvc generators, but the ninja generator would link to
the wrong path (it can neither translate relative path correctly, nor convert
the command line parameter to the '-lxxx' form).
The only way to make all generators work on all platforms is to use abusolute
paths for external libraries.
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.
