ui/window: Add platform windowing component

ui/window: Add platform windowing component

This is stripped down version of sadrul's patch with just the bits
needed to make progress on fixing windowing under ozone builds.

The overall ideas is: aura (WindowTreeHost), mojo (NativeViewport), 
and ozone (none yet) need to wrap up platform windows in an interface.
We should use the same one to avoid duplication.

Original patch: https://codereview.chromium.org/255823009/

BUG=392280
TEST=none

[Ben Goodger (Google), 2014-07-11 18:15:15]

https://codereview.chromium.org/378003003/diff/20001/ui/window/platform_windo...
File ui/window/platform_window_delegate.h (right):

https://codereview.chromium.org/378003003/diff/20001/ui/window/platform_windo...
ui/window/platform_window_delegate.h:28: virtual void OnCloseRequest() = 0;
If this really is a close request, this may need to provide the delegate a way
to abort the close.

Or do you want a destruction notification?

On Win32 the order is typically:

WM_CLOSE - user clicked the close button. The app can abort the close (e.g. if
there's unsaved work).
WM_DESTROY - the window is being closed. child windows are still valid.
WM_NCDESTROY - the window is being closed. child windows have been destroyed.

These states map in the various frameworks we have to the following states:
- Close
- Destroying
- Destroyed

FYI. :-)

[spang, 2014-07-11 18:36:31]

On 2014/07/11 18:15:15, Ben Goodger (Google) wrote:
>
https://codereview.chromium.org/378003003/diff/20001/ui/window/platform_windo...
> File ui/window/platform_window_delegate.h (right):
> 
>
https://codereview.chromium.org/378003003/diff/20001/ui/window/platform_windo...
> ui/window/platform_window_delegate.h:28: virtual void OnCloseRequest() = 0;
> If this really is a close request, this may need to provide the delegate a way
> to abort the close.
> 
> Or do you want a destruction notification?
> 
> On Win32 the order is typically:
> 
> WM_CLOSE - user clicked the close button. The app can abort the close (e.g. if
> there's unsaved work).
> WM_DESTROY - the window is being closed. child windows are still valid.
> WM_NCDESTROY - the window is being closed. child windows have been destroyed.
> 
> These states map in the various frameworks we have to the following states:
> - Close
> - Destroying
> - Destroyed
> 
> FYI. :-)

This is just copied from WindowTreeHost::OnHostCloseRequested, and they are
intended to have identical semantics. Looks likes this is only used for the X11
platform, currently.

My understanding

[spang, 2014-07-11 18:39:31]

On 2014/07/11 18:36:31, spang wrote:
> On 2014/07/11 18:15:15, Ben Goodger (Google) wrote:
> >
>
https://codereview.chromium.org/378003003/diff/20001/ui/window/platform_windo...
> > File ui/window/platform_window_delegate.h (right):
> > 
> >
>
https://codereview.chromium.org/378003003/diff/20001/ui/window/platform_windo...
> > ui/window/platform_window_delegate.h:28: virtual void OnCloseRequest() = 0;
> > If this really is a close request, this may need to provide the delegate a
way
> > to abort the close.
> > 
> > Or do you want a destruction notification?
> > 
> > On Win32 the order is typically:
> > 
> > WM_CLOSE - user clicked the close button. The app can abort the close (e.g.
if
> > there's unsaved work).
> > WM_DESTROY - the window is being closed. child windows are still valid.
> > WM_NCDESTROY - the window is being closed. child windows have been
destroyed.
> > 
> > These states map in the various frameworks we have to the following states:
> > - Close
> > - Destroying
> > - Destroyed
> > 
> > FYI. :-)
> 
> This is just copied from WindowTreeHost::OnHostCloseRequested, and they are
> intended to have identical semantics. Looks likes this is only used for the
X11
> platform, currently.
> 
> My understanding

Oops. My understanding is: its just an notifier for the close button. So the
default is the window stays open.

I will have to look into how other platforms work.

[sadrul, 2014-07-14 07:00:00]

https://codereview.chromium.org/378003003/diff/20001/ui/window/platform_windo...
File ui/window/platform_window_delegate.h (right):

https://codereview.chromium.org/378003003/diff/20001/ui/window/platform_windo...
ui/window/platform_window_delegate.h:19: : public ui::PlatformEventDispatcher {
This requires the PlatformWindowDelegate to keep processing platform-events
(i.e. XEvents etc.), which I think would be unfortunate. The way I am thinking
is the PlatformWindowDelegate should process only ui::Events instead (see
https://codereview.chromium.org/391583002/).

[spang, 2014-07-14 16:44:53]

On 2014/07/14 07:00:00, sadrul wrote:
>
https://codereview.chromium.org/378003003/diff/20001/ui/window/platform_windo...
> File ui/window/platform_window_delegate.h (right):
> 
>
https://codereview.chromium.org/378003003/diff/20001/ui/window/platform_windo...
> ui/window/platform_window_delegate.h:19: : public ui::PlatformEventDispatcher
{
> This requires the PlatformWindowDelegate to keep processing platform-events
> (i.e. XEvents etc.), which I think would be unfortunate. The way I am thinking
> is the PlatformWindowDelegate should process only ui::Events instead (see
> https://codereview.chromium.org/391583002/).

sadrul is landing his version with

[spang, 2014-07-14 16:46:16]

On 2014/07/14 16:44:53, spang wrote:
> On 2014/07/14 07:00:00, sadrul wrote:
> >
>
https://codereview.chromium.org/378003003/diff/20001/ui/window/platform_windo...
> > File ui/window/platform_window_delegate.h (right):
> > 
> >
>
https://codereview.chromium.org/378003003/diff/20001/ui/window/platform_windo...
> > ui/window/platform_window_delegate.h:19: : public
ui::PlatformEventDispatcher
> {
> > This requires the PlatformWindowDelegate to keep processing platform-events
> > (i.e. XEvents etc.), which I think would be unfortunate. The way I am
thinking
> > is the PlatformWindowDelegate should process only ui::Events instead (see
> > https://codereview.chromium.org/391583002/).
> 
> sadrul is landing his version with

sadrul is landing his version with x11 support @
https://codereview.chromium.org/391583002/

let's continue there - closing

[spang, 2014-07-14 16:53:38]

https://codereview.chromium.org/378003003/diff/20001/ui/window/platform_windo...
File ui/window/platform_window_delegate.h (right):

https://codereview.chromium.org/378003003/diff/20001/ui/window/platform_windo...
ui/window/platform_window_delegate.h:19: : public ui::PlatformEventDispatcher {
On 2014/07/14 07:00:00, sadrul wrote:
> This requires the PlatformWindowDelegate to keep processing platform-events
> (i.e. XEvents etc.), which I think would be unfortunate. The way I am thinking
> is the PlatformWindowDelegate should process only ui::Events instead (see
> https://codereview.chromium.org/391583002/).


That sounds good. In fact, this CL actually did that for ozone since  platform
event is currently defined as ui::Event.