ozone: Port WindowTreeHostOzone on top of PlatformWindow

ui/ozone/common/platform_window_base.h

+// Copyright (c) 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.
+
+#ifndef UI_OZONE_COMMON_PLATFORM_WINDOW_BASE_H_
+#define UI_OZONE_COMMON_PLATFORM_WINDOW_BASE_H_
+
+#include "ui/base/cursor/cursor.h"
+#include "ui/gfx/geometry/rect.h"
+#include "ui/gfx/native_widget_types.h"
+#include "ui/ozone/ozone_export.h"
+#include "ui/platform_window/platform_window.h"
+
+namespace gfx {
+class Point;
+class Rect;
+}
+
+namespace ui {
+
+class PlatformWindowDelegate;
+
+// Platform window subclass with stubs for most window functions.
+class OZONE_EXPORT PlatformWindowBase : public PlatformWindow {

[sadrul, 2014/07/14 22:58:07]

I don't think we should have this. If we must, we should add default
implementations in PlatformWindow instead, but I don't think we should do that
either.

For the short-term, have a single PlatformWindowStub that does what Compat does,
but the platforms should provide complete implementations (with NOTIMPLEMENTED()
where appropriate).

[spang, 2014/07/14 23:17:41]

Please elaborate - what's the harm? Maximizing doesn't make any sense when the
output is an image file, or a TV. All 5 of our current platforms need stubs
here. X11 will be the only one that is reasonably complete, and can just not
inherit this class.

Putting it on PlatformWindow itself is probaby a mistake, since out of tree
platforms may break silently if we change the interface. I'd like them to have
the option of getting a compile error instead.
I disagree. PlatformWindowCompat is not a stub, and its name captures what it
actually does. In any case, it's not going to exist very long.

[sadrul, 2014/07/15 16:53:10]

The platforms that don't need maximize will have an empty implementation.
Yes, and this applies for the in-tree platforms too. Each [new] ozone platform
that gets added should explicitly make the decision of which methods to
implement and which not. I think this is generally the style chromium follows
(see aura::WindowDelegate, for an example, and the numerous overrides that
provide empty implementation for a number of the interface there), observers
being the exception. I personally don't have strong preference either way, but
consistency would be good.

+ public:
+  PlatformWindowBase();
+  virtual ~PlatformWindowBase();
+
+  // PlatformWindow:
+  virtual void Show() OVERRIDE;
+  virtual void Hide() OVERRIDE;
+  virtual void Close() OVERRIDE;
+  virtual void SetCapture() OVERRIDE;
+  virtual void ReleaseCapture() OVERRIDE;
+  virtual void ToggleFullscreen() OVERRIDE;
+  virtual void Maximize() OVERRIDE;
+  virtual void Minimize() OVERRIDE;
+  virtual void Restore() OVERRIDE;
+
+ private:
+  DISALLOW_COPY_AND_ASSIGN(PlatformWindowBase);
+};
+
+// This is just transitional code. Will be removed shortly.
+class OZONE_EXPORT PlatformWindowCompat : public PlatformWindowBase {
+ public:
+  PlatformWindowCompat(PlatformWindowDelegate* delegate,
+                       const gfx::Rect& bounds);
+  virtual ~PlatformWindowCompat();
+
+  // PlatformWindow:
+  virtual gfx::Rect GetBounds() OVERRIDE;
+  virtual void SetBounds(const gfx::Rect& bounds) OVERRIDE;
+
+ private:
+  PlatformWindowDelegate* delegate_;
+  gfx::Rect bounds_;
+
+  DISALLOW_COPY_AND_ASSIGN(PlatformWindowCompat);
+};
+
+}  // namespace ui
+
+#endif  // UI_OZONE_COMMON_PLATFORM_WINDOW_BASE_H_