Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
// Copyright (c) 2017 GitHub, Inc.
|
|
|
|
// Use of this source code is governed by the MIT license that can be
|
|
|
|
// found in the LICENSE file.
|
|
|
|
|
|
|
|
#include "atom/browser/native_browser_view_mac.h"
|
|
|
|
|
2018-03-19 07:50:30 +00:00
|
|
|
#include "brightray/browser/inspectable_web_contents.h"
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
#include "brightray/browser/inspectable_web_contents_view.h"
|
|
|
|
#include "skia/ext/skia_utils_mac.h"
|
|
|
|
#include "ui/gfx/geometry/rect.h"
|
|
|
|
|
2017-04-12 11:40:31 +00:00
|
|
|
// Match view::Views behavior where the view sticks to the top-left origin.
|
|
|
|
const NSAutoresizingMaskOptions kDefaultAutoResizingMask =
|
|
|
|
NSViewMaxXMargin | NSViewMinYMargin;
|
|
|
|
|
2017-08-09 00:00:00 +00:00
|
|
|
@interface DragRegionView : NSView
|
2017-08-09 18:57:57 +00:00
|
|
|
|
|
|
|
@property (assign) NSPoint initialLocation;
|
|
|
|
|
2017-08-09 00:00:00 +00:00
|
|
|
@end
|
|
|
|
|
2017-08-23 23:10:31 +00:00
|
|
|
@interface NSWindow ()
|
|
|
|
- (void)performWindowDragWithEvent:(NSEvent *)event;
|
|
|
|
@end
|
|
|
|
|
2017-08-09 00:00:00 +00:00
|
|
|
@implementation DragRegionView
|
|
|
|
|
|
|
|
- (BOOL)mouseDownCanMoveWindow
|
|
|
|
{
|
|
|
|
return NO;
|
|
|
|
}
|
|
|
|
|
2017-08-09 21:49:11 +00:00
|
|
|
- (NSView *)hitTest:(NSPoint)aPoint
|
|
|
|
{
|
|
|
|
// Pass-through events that don't hit one of the exclusion zones
|
|
|
|
for (NSView *exlusion_zones in [self subviews]) {
|
|
|
|
if ([exlusion_zones hitTest:aPoint])
|
|
|
|
return nil;
|
|
|
|
}
|
|
|
|
|
|
|
|
return self;
|
|
|
|
}
|
|
|
|
|
2017-08-09 00:00:00 +00:00
|
|
|
- (void)mouseDown:(NSEvent *)event
|
|
|
|
{
|
2017-08-22 18:14:21 +00:00
|
|
|
if ([self.window respondsToSelector:@selector(performWindowDragWithEvent)]) {
|
2017-09-29 18:20:34 +00:00
|
|
|
// According to Google, using performWindowDragWithEvent:
|
|
|
|
// does not generate a NSWindowWillMoveNotification. Hence post one.
|
|
|
|
[[NSNotificationCenter defaultCenter]
|
|
|
|
postNotificationName:NSWindowWillMoveNotification
|
|
|
|
object:self];
|
|
|
|
|
2017-08-09 18:57:57 +00:00
|
|
|
[self.window performWindowDragWithEvent:event];
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-09-27 13:36:18 +00:00
|
|
|
if (self.window.styleMask & NSFullScreenWindowMask) {
|
2017-09-26 22:03:44 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-08-09 18:57:57 +00:00
|
|
|
self.initialLocation = [event locationInWindow];
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)mouseDragged:(NSEvent *)theEvent
|
|
|
|
{
|
2017-08-22 18:14:21 +00:00
|
|
|
if ([self.window respondsToSelector:@selector(performWindowDragWithEvent)]) {
|
2017-08-09 18:57:57 +00:00
|
|
|
return;
|
|
|
|
}
|
2017-09-26 22:03:44 +00:00
|
|
|
|
2017-09-27 13:36:18 +00:00
|
|
|
if (self.window.styleMask & NSFullScreenWindowMask) {
|
2017-09-26 22:03:44 +00:00
|
|
|
return;
|
|
|
|
}
|
2017-08-09 18:57:57 +00:00
|
|
|
|
2017-08-15 23:13:14 +00:00
|
|
|
NSPoint currentLocation = [NSEvent mouseLocation];
|
2017-08-09 18:57:57 +00:00
|
|
|
NSPoint newOrigin;
|
|
|
|
|
|
|
|
NSRect screenFrame = [[NSScreen mainScreen] frame];
|
2017-09-27 21:43:09 +00:00
|
|
|
NSSize screenSize = screenFrame.size;
|
2017-08-09 18:57:57 +00:00
|
|
|
NSRect windowFrame = [self.window frame];
|
2017-09-27 21:43:09 +00:00
|
|
|
NSSize windowSize = windowFrame.size;
|
2017-08-09 18:57:57 +00:00
|
|
|
|
|
|
|
newOrigin.x = currentLocation.x - self.initialLocation.x;
|
|
|
|
newOrigin.y = currentLocation.y - self.initialLocation.y;
|
|
|
|
|
2017-09-27 21:43:09 +00:00
|
|
|
BOOL inMenuBar = (newOrigin.y + windowSize.height) > (screenFrame.origin.y + screenSize.height);
|
|
|
|
BOOL screenAboveMainScreen = false;
|
|
|
|
|
|
|
|
if (inMenuBar) {
|
|
|
|
for (NSScreen *screen in [NSScreen screens]) {
|
|
|
|
NSRect currentScreenFrame = [screen frame];
|
2017-09-29 18:20:34 +00:00
|
|
|
BOOL isHigher = currentScreenFrame.origin.y > screenFrame.origin.y;
|
2017-09-27 21:43:09 +00:00
|
|
|
|
|
|
|
// If there's another screen that is generally above the current screen,
|
2017-09-29 18:20:34 +00:00
|
|
|
// we'll draw a new rectangle that is just above the current screen. If the
|
|
|
|
// "higher" screen intersects with this rectangle, we'll allow drawing above
|
|
|
|
// the menubar.
|
2017-09-27 21:43:09 +00:00
|
|
|
if (isHigher) {
|
2017-09-29 18:20:34 +00:00
|
|
|
NSRect aboveScreenRect = NSMakeRect(
|
|
|
|
screenFrame.origin.x,
|
|
|
|
screenFrame.origin.y + screenFrame.size.height - 10,
|
|
|
|
screenFrame.size.width,
|
|
|
|
200
|
|
|
|
);
|
|
|
|
|
|
|
|
BOOL screenAboveIntersects = NSIntersectsRect(currentScreenFrame, aboveScreenRect);
|
2017-09-27 21:43:09 +00:00
|
|
|
|
2017-09-29 18:20:34 +00:00
|
|
|
if (screenAboveIntersects) {
|
2017-09-27 21:43:09 +00:00
|
|
|
screenAboveMainScreen = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-08-09 18:57:57 +00:00
|
|
|
// Don't let window get dragged up under the menu bar
|
2017-09-27 21:43:09 +00:00
|
|
|
if (inMenuBar && !screenAboveMainScreen) {
|
2017-08-10 16:38:01 +00:00
|
|
|
newOrigin.y = screenFrame.origin.y + (screenFrame.size.height - windowFrame.size.height);
|
2017-08-09 18:57:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Move the window to the new location
|
|
|
|
[self.window setFrameOrigin:newOrigin];
|
2017-08-09 00:00:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Debugging tips:
|
2017-08-09 21:49:11 +00:00
|
|
|
// Uncomment the following four lines to color DragRegionView bright red
|
2017-08-15 23:13:14 +00:00
|
|
|
// #ifdef DEBUG_DRAG_REGIONS
|
2017-08-09 21:49:11 +00:00
|
|
|
// - (void)drawRect:(NSRect)aRect
|
|
|
|
// {
|
|
|
|
// [[NSColor redColor] set];
|
|
|
|
// NSRectFill([self bounds]);
|
|
|
|
// }
|
2017-08-15 23:13:14 +00:00
|
|
|
// #endif
|
2017-08-09 21:49:11 +00:00
|
|
|
|
|
|
|
@end
|
|
|
|
|
|
|
|
@interface ExcludeDragRegionView : NSView
|
|
|
|
@end
|
|
|
|
|
|
|
|
@implementation ExcludeDragRegionView
|
|
|
|
|
|
|
|
- (BOOL)mouseDownCanMoveWindow {
|
|
|
|
return NO;
|
2017-08-09 00:00:00 +00:00
|
|
|
}
|
|
|
|
|
2017-08-09 21:49:11 +00:00
|
|
|
// Debugging tips:
|
|
|
|
// Uncomment the following four lines to color ExcludeDragRegionView bright red
|
2017-08-15 23:13:14 +00:00
|
|
|
// #ifdef DEBUG_DRAG_REGIONS
|
2017-08-09 21:49:11 +00:00
|
|
|
// - (void)drawRect:(NSRect)aRect
|
|
|
|
// {
|
|
|
|
// [[NSColor greenColor] set];
|
|
|
|
// NSRectFill([self bounds]);
|
|
|
|
// }
|
2017-08-15 23:13:14 +00:00
|
|
|
// #endif
|
2017-08-09 21:49:11 +00:00
|
|
|
|
2017-08-09 00:00:00 +00:00
|
|
|
@end
|
|
|
|
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
namespace atom {
|
|
|
|
|
|
|
|
NativeBrowserViewMac::NativeBrowserViewMac(
|
2018-03-19 07:50:30 +00:00
|
|
|
brightray::InspectableWebContents* inspectable_web_contents)
|
|
|
|
: NativeBrowserView(inspectable_web_contents) {
|
2017-04-12 11:40:31 +00:00
|
|
|
auto* view = GetInspectableWebContentsView()->GetNativeView();
|
|
|
|
view.autoresizingMask = kDefaultAutoResizingMask;
|
|
|
|
}
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
|
|
|
|
NativeBrowserViewMac::~NativeBrowserViewMac() {}
|
|
|
|
|
2017-04-12 11:40:31 +00:00
|
|
|
void NativeBrowserViewMac::SetAutoResizeFlags(uint8_t flags) {
|
|
|
|
NSAutoresizingMaskOptions autoresizing_mask = kDefaultAutoResizingMask;
|
|
|
|
if (flags & kAutoResizeWidth) {
|
|
|
|
autoresizing_mask |= NSViewWidthSizable;
|
|
|
|
}
|
|
|
|
if (flags & kAutoResizeHeight) {
|
|
|
|
autoresizing_mask |= NSViewHeightSizable;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto* view = GetInspectableWebContentsView()->GetNativeView();
|
|
|
|
view.autoresizingMask = autoresizing_mask;
|
|
|
|
}
|
|
|
|
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
void NativeBrowserViewMac::SetBounds(const gfx::Rect& bounds) {
|
|
|
|
auto* view = GetInspectableWebContentsView()->GetNativeView();
|
|
|
|
auto* superview = view.superview;
|
|
|
|
const auto superview_height = superview ? superview.frame.size.height : 0;
|
|
|
|
view.frame =
|
|
|
|
NSMakeRect(bounds.x(), superview_height - bounds.y() - bounds.height(),
|
|
|
|
bounds.width(), bounds.height());
|
|
|
|
}
|
|
|
|
|
|
|
|
void NativeBrowserViewMac::SetBackgroundColor(SkColor color) {
|
|
|
|
auto* view = GetInspectableWebContentsView()->GetNativeView();
|
|
|
|
view.wantsLayer = YES;
|
|
|
|
view.layer.backgroundColor = skia::CGColorCreateFromSkColor(color);
|
|
|
|
}
|
|
|
|
|
2017-08-09 00:00:00 +00:00
|
|
|
void NativeBrowserViewMac::UpdateDraggableRegions(
|
2018-03-19 11:21:03 +00:00
|
|
|
const std::vector<gfx::Rect>& drag_exclude_rects) {
|
2018-03-19 18:45:40 +00:00
|
|
|
NSView* web_view = GetWebContents()->GetNativeView();
|
2018-03-19 11:39:58 +00:00
|
|
|
NSView* inspectable_view = GetInspectableWebContentsView()->GetNativeView();
|
|
|
|
NSView* window_content_view = inspectable_view.superview;
|
|
|
|
const auto window_content_view_height = NSHeight(window_content_view.bounds);
|
|
|
|
|
|
|
|
// Remove all DragRegionViews that were added last time. Note that we need
|
|
|
|
// to copy the `subviews` array to avoid mutation during iteration.
|
2018-03-19 18:45:40 +00:00
|
|
|
base::scoped_nsobject<NSArray> subviews([[web_view subviews] copy]);
|
2018-03-19 11:39:58 +00:00
|
|
|
for (NSView* subview in subviews.get()) {
|
|
|
|
if ([subview isKindOfClass:[DragRegionView class]]) {
|
2017-08-09 00:00:00 +00:00
|
|
|
[subview removeFromSuperview];
|
2018-03-19 11:39:58 +00:00
|
|
|
}
|
|
|
|
}
|
2017-08-09 00:00:00 +00:00
|
|
|
|
2017-08-09 21:49:11 +00:00
|
|
|
// Create one giant NSView that is draggable.
|
2018-03-19 11:39:58 +00:00
|
|
|
base::scoped_nsobject<NSView> drag_region_view(
|
2018-03-19 18:45:40 +00:00
|
|
|
[[DragRegionView alloc] initWithFrame:web_view.bounds]);
|
|
|
|
[web_view addSubview:drag_region_view];
|
2017-08-09 21:49:11 +00:00
|
|
|
|
|
|
|
// Then, on top of that, add "exclusion zones"
|
2018-03-19 11:21:03 +00:00
|
|
|
for (const auto& rect : drag_exclude_rects) {
|
2018-03-19 11:39:58 +00:00
|
|
|
const auto window_content_view_exclude_rect =
|
|
|
|
NSMakeRect(rect.x(), window_content_view_height - rect.bottom(),
|
|
|
|
rect.width(), rect.height());
|
|
|
|
const auto drag_region_view_exclude_rect =
|
|
|
|
[window_content_view convertRect:window_content_view_exclude_rect
|
|
|
|
toView:drag_region_view];
|
|
|
|
|
|
|
|
base::scoped_nsobject<NSView> exclude_drag_region_view(
|
|
|
|
[[ExcludeDragRegionView alloc]
|
|
|
|
initWithFrame:drag_region_view_exclude_rect]);
|
|
|
|
[drag_region_view addSubview:exclude_drag_region_view];
|
2017-08-09 00:00:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
// static
|
|
|
|
NativeBrowserView* NativeBrowserView::Create(
|
2018-03-19 07:50:30 +00:00
|
|
|
brightray::InspectableWebContents* inspectable_web_contents) {
|
|
|
|
return new NativeBrowserViewMac(inspectable_web_contents);
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace atom
|