Tested that with two windows, events are fired on the correct BrowserWindow instance and not both, and that scrolling a window which is in the background works properly.
In N1, we want to implement the famous "swipe to archive" action on threads in the user's inbox. Chrome exposes `scroll` and `wheel` events, but these aren't sufficient to implement the interaction because the element needs to "snap" when the user lifts their fingers from the trackpad, not when they / we stop receiving `wheel` / `scroll` events. These events may stop before the user lifts their fingers, or continue after the user has lifted their fingers if they had enough momentum for the gesture to continue.
This exposes BrowserWindow `scroll-touch-down` and `scroll-touch-up`, which fire immeditaely when the user touches two fingers to the trackpad, and again when the user lifts their fingers. Combined with the existing wheel event should allow for "swipe-to-archive" and other similar interactions.
Note: This is only implemented on Mac OS X and the events don't fire unless you're using a trackpad!
Related: #1486, #2683, https://github.com/nylas/N1/issues/541
`hidden` and `hidden-inset` windows differ only by the hidden-inset window having a toolbar. Yet, the toolbar yields an incorrect look in fullscreen mode. So, we hide and recreate the toolbar for such windows when going to/from fullscreen.
There are some visible artifacts during the fullscreen animations, as the toolbar gets created and destroyed. When entering fullscreen, you see a toolbar that then disappears. When going back to normal window, you see the traffic light buttons jump around a little bit. Yet, this is definitely better than the current broken fullscreen look.
Adds the desktop window type referenced in https://github.com/atom/electron/issues/2899 for compatiblity with the linux version. Note that on Mac OS X, the desktop window cannot receive input events (seems to be a limitation of being behind the desktop).
In this diff I also removed the `standardWindow` option from the docs, in favor of an additional `textured` value for window `type` on Mac OS X. The old `standardWindow` option continues to work, but seemed more confusing. If this seems like a bad idea, I can revert that change.
