TextBuffers now maintain a reference to their containing project to
make it easier to test replication of buffers between environments
without worrying about the value of the `project` global.
We're also starting the process of moving the `git` global into Project
as the `Project.repository` property.
We're using Peer.js to stream changes to shared telepath documents
between participants.
We're replacing the rootView of joiners in a somewhat hacky way,
but replication of pane splits and items is fully tested.
This allows the pathToOpen to be changed when the project
path changes.
Previously if the untitled window file was saved, the project
path would be forever associated with the undefined window.
Now when the project path changes, the pathToOpen changes so
that the state is persisted to the project area and the untitled
window never has a project.
For some events generated on the browser side, like reloading, closing
window, we should not handle those events directly, instead we should
send the corresponding commands to the renderer and let the renderer
deal with it.
The window.reload() is also moved to atom.reload(), because I saw things
like toggleFullScreen(), focus(), toggleDevTools() are also there.
Ideally both window closing and reloading should use 'beforeunload' to
control whether the unloading should continue, however since the save as
dialog is asynchronous, we have to prevent unloading first and then
continue after user's confirmation. And since we can not distinguish
whether the window is reloading or closing in the 'beforeunload'
handler, we do not know what to continue after user's confirmation. So I
have to rely on BrowserWindow's 'close' event to let user decide whether
window should be closed.
When user wants to close the window, the 'beforeunload' event would be
called, then the closing would be cancelled and the 'window:close'
command would be triggered. In the 'window:close' handler, a confirm
dialog could be showed if there are unsaved contents, and if the window
is really meant to be closed, the window would be tried to be closed
again and this time 'beforeunload' handler wont't prevent it.
In Atom, the 'beforeunload' event never prevents window from closing so
it in fact has the same effect with 'unload' event, I guess using
'beforeunload' instead of 'unload' is because the 'beforeunload' is
guarrenteed to happen when window is closing or application is quiting.
However in Atom Shell the 'unload' event is guarrenteed to happen on
both conditions, just like the 'beforeunload' in Atom, so it's safe to
replace the 'beforeunload' with 'unload' here.
And in Atom Shell, the 'beforeunload' event is mainly used for
preventing window from closing, just like the 'window:close' command in
Atom.
Currently the toggleDevTools of atom-shell is simulated by keeping state
of devtools, because there is no way to know the state of devtools in
brightray, so it could not behave correctly sometimes.
This problem will be solved when brightray is patched and atom-shel gets
updated.
