stringByStandardizingPath has an interesting quirk that causes it to
remove `/private` from the path if the result still indicates an
existing file or directory
All our native code now gets built into Atom.framework. Atom.app and
Atom Helper.app both link against this framework. All resources other
than a couple of main-bundle-only ones (e.g., atom.icns) go into
Atom.framework.
Note that this means that there's no compile- or link-time separation
between main process code and helper process code. We could introduce a
compile-time separation by building main process and helper process code
into separate static libraries with mutually exclusive include paths, if
we want.
Atom.framework exports a single symbol: AtomMain(). Atom.app and Atom
Helper.app contain a single source file: main.cpp. main() just calls
AtomMain().
All frameworks are placed in Atom.app/Contents/Frameworks. We now link
against all frameworks using @rpath-based install names, which allows
Atom.app and Atom Helper.app to find them automatically based on their
own LD_RUNPATH_SEARCH_PATH settings. We use install_name_tool at build
time on each of our three binaries (Atom.app, Atom Helper.app,
Atom.framework) to set the install names.
By reducing duplication of code and resources between Atom.app and Atom
Helper.app (and the EH/NP copies of Atom Helper.app), this reduces the
size of the total installed Atom.app bundle from 145MB to 82MB. By
compiling .coffee and .cson files only once, clean build time drops from
114 seconds to 79 seconds on my MacBook Pro.
Previously this was done during `rake install`.
Also default to `~/github/atom` as the default resource path
when no `--resource-path` argument is specified. This argument
will now be required when running in dev mode if the repository
is not at the default location.
Closes#300
This adds support for accessing native extensions in web workers, though it may
not work quite how we need it to just yet. Figured we'd bank an upgrade anyway.
This appears to be handled by stringByAddingPercentEscapesUsingEncoding
and so explicitly doing it causes a space to be encoded to %2520 instead
of %20
This commit adds a boolean constructor parameter to the AtomCefClient indicating whether it should handle the standard pasteboard commands for its associated browser. We pass `true` when constructing the client for the dev tools, so these commands work there.
This allows us to use Atom to edit Atom, even when changes will break Atom on reload. It does this by ensuring the editor only uses code included with the bundle, but it allows benchmarks and specs to use code located in the path specified by --resource-path.
There's something wrong with CEF 3 right now where meta-` events aren't being forwarded to cocoa correctly. I just added some code to intercept meta-` and manually cycle the windows. I ignore any windows for which `excludeFromWindowsMenu` is true. That means we don't ever cycle to the hidden menu.
