* feat: add evt listeners for SetAlwaysOnTop
* only emit one event on AlwaysOnTop change
* docs: add new alwaysontop event
* dont emit if theres no change
* address feedback from review
The new `will-resize` event can be used to prevent the resize from
happening before the native window is actually resized. This is in
contrast to the existing the `resize` event, which is sent *after* the
native window has already been resized. For apps with e.g. custom window
snapping logic, the `resize` event is not sufficient because it will
result in flickering between the dragged size and the snapped size.
`will-resize` is only emitted on macOS and Windows.
Adds responders for `newWindowForTab` to `AtomApplicationDelegate` and
`NativeWindowMac`, so that `BrowserWindow`s with a `tabbingIdentifier`
will get the new tab button, and both `app` and `window` will emit a
`new-tab-for-window` event.
* Make the AtomNSWindow also a NSTouchbarDelegate
* Implement basic makeTouchBar and makeItemForIdentifier methods
* Initial sending of touch / update events through IPC to BrowserWindowObjects
TODO:
* JS API
* JS Object Converters
* Generalize methods so that popovers can work
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
LPARAM is defined to differnt types on differnt machines with different
SDKs, so there is no way to represent it on all platforms safely, using
uint64_t seems to be the only safe choice.
