MacViews: Initial skeleton for implementing NativeWidgetMac

ui/views/cocoa/bridged_content_view.mm

Index: ui/views/cocoa/bridged_content_view.mm
diff --git a/ui/views/cocoa/bridged_content_view.mm b/ui/views/cocoa/bridged_content_view.mm
new file mode 100644
index 0000000000000000000000000000000000000000..0c62df53acbce9d4bcdb49311e515f2e3eb505bb
--- /dev/null
+++ b/ui/views/cocoa/bridged_content_view.mm
@@ -0,0 +1,49 @@
+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#import "ui/views/cocoa/bridged_content_view.h"
+
+#include "ui/gfx/canvas_paint_mac.h"
+#include "ui/views/view.h"
+
+@implementation BridgedContentView
+
+- (id)initWithView:(views::View*)viewToHost {
+  DCHECK(viewToHost);
+  gfx::Rect bounds = viewToHost->bounds();
+  // To keep things simple, assume the origin is (0, 0) until there exists a use
+  // case for something other than that.
+  DCHECK(bounds.origin().IsOrigin());
+  NSRect initialFrame = NSMakeRect(0, 0, bounds.width(), bounds.height());
+  if ((self = [super initWithFrame:initialFrame])) {

[sky, 2014/06/11 16:15:53]

Why the self = check here? Can initWithFrame return NULL? Shouldn't we crash if
that happens?

[sky, 2014/06/11 16:15:53]

nit: no {}

[tapted, 2014/06/12 09:13:12]

Done.

[tapted, 2014/06/12 09:13:12]

Yeah - this is Objective C weirdness ;). Constructors follow this pattern partly
by convention (see eg `grep 'if ((self =' -- '*.mm'`). Superclass constructors
are allowed to return nil and, if they do, child classes should skip their own
initialization and also return nil.

And, since method calls on `nil` objects in Objective C are allowed and
well-defined (and checks for nil discouraged - http://go/objcguide#nil_Checks),
often things just chug along nicely even if the constructor returns nil (while
often making things a real pain to debug :/).

[sky, 2014/06/12 16:51:47]

I realize this is all allowed, but shouldn't we treat it similar to a malloc
failing and crash? Say for example you're creating a tabbed browser and the
creation of the underlying window fails, shouldn't we crash?

[Robert Sesek, 2014/06/12 17:31:37]

If allocation fails, that will be caught by
base::EnableTerminationOnOutOfMemory. This is idiomatic for Cocoa (though I'd
not have removed the {}).

+    hostedView_ = viewToHost;
+  }
+  return self;
+}
+
+@synthesize hostedView = hostedView_;
+
+- (void)clearView {
+  hostedView_ = NULL;
+}
+
+// NSView implementation.
+
+- (void)setFrameSize:(NSSize)newSize {
+  [super setFrameSize:newSize];
+  if (!hostedView_)
+    return;
+
+  hostedView_->SetSize(gfx::Size(newSize.width, newSize.height));
+}
+
+- (void)drawRect:(NSRect)dirtyRect {
+  if (!hostedView_)
+    return;
+
+  gfx::CanvasSkiaPaint canvas(dirtyRect, false /* opaque */);
+  hostedView_->Paint(&canvas, views::CullSet());
+}
+
+@end