Make aura work with mus

Make aura work with mus

The basic idea is to add the option of having aura work with mus. This is
done by way of adding a porting layer for aura::Window. Specifically
WindowPort. Each Window has a WindowPort. WindowPort is typically
created by aura::Window during Init() time (WindowPort may be
explicitly passed in the constructor, but that is not the common
case). If a WindowPort was not explicitly passed in the constructor
then Window calls to Env::CreateWindowPort to create the
WindowPort. Env gets a factory function for creation.

Window calls to WindowPort at key times that need to differ for mus,
or as a hook for mus to call to the server. For example,
Window::AddChild() calls to WindowPort::OnWillAddChild().

WindowPortMus calls to a class similar to ui::WindowTreeClient on on
any changes. WindowTreeClient forwards changes to the server as
appropriate. Changes originating from the server call to WindowMus
(implemented by WindowPortMus). The implementation of the functions in
WindowPortMus called by WindowTreeClient ensure calls made from
the server don't make their way back to the server. For example, we
don't want something like the following happening: WindowTreeClient is
told bounds change -> change bounds on window -> try to set bounds
change back to server.

Wiring up aura to use mus then becomes something like:
. Create WindowTreeClient (encapsulates connection to mus).
. Install factory on Env.

And then use aura like you normally would. You can see this in
AuraTestHelper.

This patch is huge and works, but there are a bunch of TODOs and a
handful of comment out code. I will be addressing this ASAP, but
wanted to land this for others.

BUG=none
TEST=none
R=sadrul@chromium.org

Committed: https://crrev.com/25714fe6afb80a6f6fe562cadad3e598deb3668d
Cr-Commit-Position: refs/heads/master@{#428031}

[sky, 2016-10-25 16:15:02]

There is some commented out code that will be addressed shortly. This patch is
already ginormous though, so I'm hoping to fix that up separately. Same thing
goes for the test code, window_tree_client_unittest is actually a copy of the
existing test and I don't have all of it ported yet. Will port the rest asap.

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_tree...
File ui/aura/mus/window_tree_client_unittest.cc (right):

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_client_unittest.cc:1: // Copyright 2015 The Chromium
Authors. All rights reserved.
This is actually a copy of the existing one, but so much has changed you can't
see the diffs.

[sadrul, 2016-10-26 16:53:29]

Would it make sense to put the mus bits into a separate target, so that there
can still be non-mus aura?

[sky, 2016-10-26 17:04:28]

I could do that, but do you think it's worth it? I believe everywhere
we compile aura now we compile mus as well.

  -Scott

On Wed, Oct 26, 2016 at 9:53 AM,  <sadrul@chromium.org> wrote:
> Would it make sense to put the mus bits into a separate target, so that
> there
> can still be non-mus aura?
>
> https://codereview.chromium.org/2445163002/

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[sadrul, 2016-10-26 18:38:21]

> I could do that, but do you think it's worth it? I believe
> everywhere we compile aura now we compile mus as well.

That's probably the case (not sure about chrome-headless at the moment). Having
mus as a separate target would make DEPS/gn dependencies a bit clearer, but not
sure how value that has.

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_port...
File ui/aura/mus/window_port_mus.cc (right):

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.cc:64: for (auto iter = server_changes_.begin();
iter != server_changes_.end();
Since this is only used by ScopedServerChange, this could reverse the order
(i.e. rbegin()/rend()), since we are adding new entries in the end. And so it's
more likely that this id will be towards the end of the list.

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_port...
File ui/aura/mus/window_port_mus.h (right):

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.h:102: struct ServerChangeData {
Could this be a union?

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_tree...
File ui/aura/mus/window_tree_client.cc (right):

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_client.cc:350:
delegate_->GetCaptureClient()->SetCapture(window ? window->GetWindow()
What are the chances that canceling the capture ends up destroying this client?
(i.e. the AutoReset<>s above would trigger crashes)

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_client.cc:445: user_window->Init(ui::LAYER_NOT_DRAWN);
Yeah, this will almost definitely need to be LAYER_TEXTURED.

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_tree...
File ui/aura/mus/window_tree_host_mus.h (right):

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_host_mus.h:31: // . without a content window.
Who is the owner of WTHMus? especially when there are no content window?

[rjkroege, 2016-10-26 18:45:36]

On 2016/10/26 18:38:21, sadrul wrote:
> > I could do that, but do you think it's worth it? I believe
> > everywhere we compile aura now we compile mus as well.
> 
> That's probably the case (not sure about chrome-headless at the moment).
Having
> mus as a separate target would make DEPS/gn dependencies a bit clearer, but
not
> sure how value that has.

headless is an ozone backend yes? afaik: all ozone backends assume aura.

what about mac and android going forward?

> 
>
https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_port...
> File ui/aura/mus/window_port_mus.cc (right):
> 
>
https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_port...
> ui/aura/mus/window_port_mus.cc:64: for (auto iter = server_changes_.begin();
> iter != server_changes_.end();
> Since this is only used by ScopedServerChange, this could reverse the order
> (i.e. rbegin()/rend()), since we are adding new entries in the end. And so
it's
> more likely that this id will be towards the end of the list.
> 
>
https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_port...
> File ui/aura/mus/window_port_mus.h (right):
> 
>
https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_port...
> ui/aura/mus/window_port_mus.h:102: struct ServerChangeData {
> Could this be a union?
> 
>
https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_tree...
> File ui/aura/mus/window_tree_client.cc (right):
> 
>
https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_tree...
> ui/aura/mus/window_tree_client.cc:350:
> delegate_->GetCaptureClient()->SetCapture(window ? window->GetWindow()
> What are the chances that canceling the capture ends up destroying this
client?
> (i.e. the AutoReset<>s above would trigger crashes)
> 
>
https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_tree...
> ui/aura/mus/window_tree_client.cc:445: user_window->Init(ui::LAYER_NOT_DRAWN);
> Yeah, this will almost definitely need to be LAYER_TEXTURED.
> 
>
https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_tree...
> File ui/aura/mus/window_tree_host_mus.h (right):
> 
>
https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_tree...
> ui/aura/mus/window_tree_host_mus.h:31: // . without a content window.
> Who is the owner of WTHMus? especially when there are no content window?

[sadrul, 2016-10-26 18:48:47]

On 2016/10/26 18:45:36, rjkroege wrote:
> On 2016/10/26 18:38:21, sadrul wrote:
> > > I could do that, but do you think it's worth it? I believe
> > > everywhere we compile aura now we compile mus as well.
> > 
> > That's probably the case (not sure about chrome-headless at the moment).
> Having
> > mus as a separate target would make DEPS/gn dependencies a bit clearer, but
> not
> > sure how value that has.
> 
> headless is an ozone backend yes? afaik: all ozone backends assume aura.

chrome-headless is a content-embedder. It uses aura and ozone (and the headless
ozone backend), yes. But I think it does not currently depend on views, which
probably implies it does not have a dependency on mus right now.

[sky, 2016-10-26 19:12:58]

Description was changed from

==========
Make aura work with mus

The basic idea is to add the option of having aura work with mus. This is
done by way of adding a porting layer for aura::Window. Specifically
WindowPort. Each Window has a WindowPort. WindowPort is typically
created by aura::Window during Init() time (WindowPort may be
explicitly passed in the constructor, but that is not the common
case). If a WindowPort was not explicitly passed in the constructor
then Window calls to Env::CreateWindowPort to create the
WindowPort. Env gets a factory function for creation.

Window calls to WindowPort at key times that need to differ for mus,
or as a hook for mus to call to the server. For example,
Window::AddChild() calls to WindowPort::OnWillAddChild().

WindowPortMus calls to a class similar to ui::WindowTreeClient on on
any changes. WindowTreeClient forwards changes to the server as
appropriate. Changes originating from the server call to WindowMus
(implemented by WindowPortMus). The implementation of the functions in
WindowPortMus called by WindowTreeClient ensure calls made from
the server don't make their way back to the server. For example, we
don't want something like the following happening: WindowTreeClient is
told bounds change -> change bounds on window -> try to set bounds
change back to server.

Wiring up aura to use mus then becomes something like:
. Create WindowTreeClient (encapsulates connection to mus).
. Install factory on Env.

And then use aura like you normally would. You can see this in
AuraTestHelper.

This patch is huge and works, but there are a bunch of TODOs and a
handful of comment out code. I will be addressing this ASAP, but
wanted to land this for others.

BUG=none
TEST=none
R=sadrul@chromium.org
==========

to

==========
Make aura work with mus

The basic idea is to add the option of having aura work with mus. This is
done by way of adding a porting layer for aura::Window. Specifically
WindowPort. Each Window has a WindowPort. WindowPort is typically
created by aura::Window during Init() time (WindowPort may be
explicitly passed in the constructor, but that is not the common
case). If a WindowPort was not explicitly passed in the constructor
then Window calls to Env::CreateWindowPort to create the
WindowPort. Env gets a factory function for creation.

Window calls to WindowPort at key times that need to differ for mus,
or as a hook for mus to call to the server. For example,
Window::AddChild() calls to WindowPort::OnWillAddChild().

WindowPortMus calls to a class similar to ui::WindowTreeClient on on
any changes. WindowTreeClient forwards changes to the server as
appropriate. Changes originating from the server call to WindowMus
(implemented by WindowPortMus). The implementation of the functions in
WindowPortMus called by WindowTreeClient ensure calls made from
the server don't make their way back to the server. For example, we
don't want something like the following happening: WindowTreeClient is
told bounds change -> change bounds on window -> try to set bounds
change back to server.

Wiring up aura to use mus then becomes something like:
. Create WindowTreeClient (encapsulates connection to mus).
. Install factory on Env.

And then use aura like you normally would. You can see this in
AuraTestHelper.

This patch is huge and works, but there are a bunch of TODOs and a
handful of comment out code. I will be addressing this ASAP, but
wanted to land this for others.

BUG=none
TEST=none
R=sadrul@chromium.org
==========

[sky, 2016-10-26 19:12:58]

sky@chromium.org changed reviewers:
+ danakj@chromium.org

[sky, 2016-10-26 19:52:30]

The CQ bit was checked by sky@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-26 19:53:21]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[sky, 2016-10-26 19:56:45]

+dana for deps from ui/aura/ to cc/surfaces

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_port...
File ui/aura/mus/window_port_mus.cc (right):

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.cc:64: for (auto iter = server_changes_.begin();
iter != server_changes_.end();
On 2016/10/26 18:38:20, sadrul wrote:
> Since this is only used by ScopedServerChange, this could reverse the order
> (i.e. rbegin()/rend()), since we are adding new entries in the end. And so
it's
> more likely that this id will be towards the end of the list.

Ugh, you made me lookup how to erase a reverse_iterator.

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_port...
File ui/aura/mus/window_port_mus.h (right):

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.h:102: struct ServerChangeData {
On 2016/10/26 18:38:20, sadrul wrote:
> Could this be a union?

Unions only work with primitive types, which can't be used here because of the
rect and string.

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_tree...
File ui/aura/mus/window_tree_client.cc (right):

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_client.cc:350:
delegate_->GetCaptureClient()->SetCapture(window ? window->GetWindow()
On 2016/10/26 18:38:20, sadrul wrote:
> What are the chances that canceling the capture ends up destroying this
client?
> (i.e. the AutoReset<>s above would trigger crashes)

I think very slim. It would be similar to aura::Env being deleted in a similar
situation, which I can't really imagine. Do you agree?

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_client.cc:445: user_window->Init(ui::LAYER_NOT_DRAWN);
On 2016/10/26 18:38:20, sadrul wrote:
> Yeah, this will almost definitely need to be LAYER_TEXTURED.

Changed.

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_tree...
File ui/aura/mus/window_tree_host_mus.h (right):

https://codereview.chromium.org/2445163002/diff/60001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_host_mus.h:31: // . without a content window.
On 2016/10/26 18:38:20, sadrul wrote:
> Who is the owner of WTHMus? especially when there are no content window?

Good question. I added this:

// If a content window is supplied WindowTreeHostMus deletes itself when the
// content window is destroyed. If no content window is supplied it is assumed
// the WindowTreeHostMus is explicitly deleted.

I'm not convinced this will work out well. Once I get views working with this
I'll get a better feel for what the ownership should be.

[sky, 2016-10-26 19:56:48]

The CQ bit was checked by sky@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-26 19:57:15]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-26 20:06:41]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-26 20:06:42]

Dry run: Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[sky, 2016-10-26 20:31:13]

The CQ bit was checked by sky@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-26 20:32:05]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[danakj, 2016-10-26 20:37:25]

https://codereview.chromium.org/2445163002/diff/120001/ui/aura/DEPS
File ui/aura/DEPS (right):

https://codereview.chromium.org/2445163002/diff/120001/ui/aura/DEPS#newcode2
ui/aura/DEPS:2: "+cc/surfaces",
If it's just for surface_id.h then maybe specify it cuz most of cc/surfaces/ is
for implementing a display compositor which this should not be doing, if it's
for more then this prob fine. LGTM

[sky, 2016-10-26 20:42:47]

On 2016/10/26 20:37:25, danakj wrote:
> https://codereview.chromium.org/2445163002/diff/120001/ui/aura/DEPS
> File ui/aura/DEPS (right):
> 
> https://codereview.chromium.org/2445163002/diff/120001/ui/aura/DEPS#newcode2
> ui/aura/DEPS:2: "+cc/surfaces",
> If it's just for surface_id.h then maybe specify it cuz most of cc/surfaces/
is
> for implementing a display compositor which this should not be doing, if it's
> for more then this prob fine. LGTM

I listed the two headers needed (surface_id and surface_sequence).

[sky, 2016-10-26 20:43:13]

The CQ bit was checked by sky@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-26 20:44:20]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-26 21:00:21]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-26 21:00:22]

Dry run: Try jobs failed on following builders:
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)

[sky, 2016-10-26 22:12:47]

The CQ bit was checked by sky@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-26 22:13:23]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-26 23:32:38]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-26 23:32:39]

Dry run: Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[sky, 2016-10-26 23:57:44]

The CQ bit was checked by sky@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-26 23:58:08]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-27 01:07:14]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-27 01:07:15]

Dry run: This issue passed the CQ dry run.

[sadrul, 2016-10-27 04:59:30]

lgtm

[sky, 2016-10-27 15:15:26]

The CQ bit was checked by sky@chromium.org

[sky, 2016-10-27 15:15:27]

The patchset sent to the CQ was uploaded after l-g-t-m from danakj@chromium.org
Link to the patchset: https://codereview.chromium.org/2445163002/#ps180001
(title: "NON_EXPORTED_BASE_CLASS")

[commit-bot: I haz the power, 2016-10-27 15:15:49]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-27 15:22:00]

Description was changed from

==========
Make aura work with mus

The basic idea is to add the option of having aura work with mus. This is
done by way of adding a porting layer for aura::Window. Specifically
WindowPort. Each Window has a WindowPort. WindowPort is typically
created by aura::Window during Init() time (WindowPort may be
explicitly passed in the constructor, but that is not the common
case). If a WindowPort was not explicitly passed in the constructor
then Window calls to Env::CreateWindowPort to create the
WindowPort. Env gets a factory function for creation.

Window calls to WindowPort at key times that need to differ for mus,
or as a hook for mus to call to the server. For example,
Window::AddChild() calls to WindowPort::OnWillAddChild().

WindowPortMus calls to a class similar to ui::WindowTreeClient on on
any changes. WindowTreeClient forwards changes to the server as
appropriate. Changes originating from the server call to WindowMus
(implemented by WindowPortMus). The implementation of the functions in
WindowPortMus called by WindowTreeClient ensure calls made from
the server don't make their way back to the server. For example, we
don't want something like the following happening: WindowTreeClient is
told bounds change -> change bounds on window -> try to set bounds
change back to server.

Wiring up aura to use mus then becomes something like:
. Create WindowTreeClient (encapsulates connection to mus).
. Install factory on Env.

And then use aura like you normally would. You can see this in
AuraTestHelper.

This patch is huge and works, but there are a bunch of TODOs and a
handful of comment out code. I will be addressing this ASAP, but
wanted to land this for others.

BUG=none
TEST=none
R=sadrul@chromium.org
==========

to

==========
Make aura work with mus

The basic idea is to add the option of having aura work with mus. This is
done by way of adding a porting layer for aura::Window. Specifically
WindowPort. Each Window has a WindowPort. WindowPort is typically
created by aura::Window during Init() time (WindowPort may be
explicitly passed in the constructor, but that is not the common
case). If a WindowPort was not explicitly passed in the constructor
then Window calls to Env::CreateWindowPort to create the
WindowPort. Env gets a factory function for creation.

Window calls to WindowPort at key times that need to differ for mus,
or as a hook for mus to call to the server. For example,
Window::AddChild() calls to WindowPort::OnWillAddChild().

WindowPortMus calls to a class similar to ui::WindowTreeClient on on
any changes. WindowTreeClient forwards changes to the server as
appropriate. Changes originating from the server call to WindowMus
(implemented by WindowPortMus). The implementation of the functions in
WindowPortMus called by WindowTreeClient ensure calls made from
the server don't make their way back to the server. For example, we
don't want something like the following happening: WindowTreeClient is
told bounds change -> change bounds on window -> try to set bounds
change back to server.

Wiring up aura to use mus then becomes something like:
. Create WindowTreeClient (encapsulates connection to mus).
. Install factory on Env.

And then use aura like you normally would. You can see this in
AuraTestHelper.

This patch is huge and works, but there are a bunch of TODOs and a
handful of comment out code. I will be addressing this ASAP, but
wanted to land this for others.

BUG=none
TEST=none
R=sadrul@chromium.org
==========

[commit-bot: I haz the power, 2016-10-27 15:22:02]

Committed patchset #10 (id:180001)

[commit-bot: I haz the power, 2016-10-27 15:28:38]

Description was changed from

==========
Make aura work with mus

The basic idea is to add the option of having aura work with mus. This is
done by way of adding a porting layer for aura::Window. Specifically
WindowPort. Each Window has a WindowPort. WindowPort is typically
created by aura::Window during Init() time (WindowPort may be
explicitly passed in the constructor, but that is not the common
case). If a WindowPort was not explicitly passed in the constructor
then Window calls to Env::CreateWindowPort to create the
WindowPort. Env gets a factory function for creation.

Window calls to WindowPort at key times that need to differ for mus,
or as a hook for mus to call to the server. For example,
Window::AddChild() calls to WindowPort::OnWillAddChild().

WindowPortMus calls to a class similar to ui::WindowTreeClient on on
any changes. WindowTreeClient forwards changes to the server as
appropriate. Changes originating from the server call to WindowMus
(implemented by WindowPortMus). The implementation of the functions in
WindowPortMus called by WindowTreeClient ensure calls made from
the server don't make their way back to the server. For example, we
don't want something like the following happening: WindowTreeClient is
told bounds change -> change bounds on window -> try to set bounds
change back to server.

Wiring up aura to use mus then becomes something like:
. Create WindowTreeClient (encapsulates connection to mus).
. Install factory on Env.

And then use aura like you normally would. You can see this in
AuraTestHelper.

This patch is huge and works, but there are a bunch of TODOs and a
handful of comment out code. I will be addressing this ASAP, but
wanted to land this for others.

BUG=none
TEST=none
R=sadrul@chromium.org
==========

to

==========
Make aura work with mus

The basic idea is to add the option of having aura work with mus. This is
done by way of adding a porting layer for aura::Window. Specifically
WindowPort. Each Window has a WindowPort. WindowPort is typically
created by aura::Window during Init() time (WindowPort may be
explicitly passed in the constructor, but that is not the common
case). If a WindowPort was not explicitly passed in the constructor
then Window calls to Env::CreateWindowPort to create the
WindowPort. Env gets a factory function for creation.

Window calls to WindowPort at key times that need to differ for mus,
or as a hook for mus to call to the server. For example,
Window::AddChild() calls to WindowPort::OnWillAddChild().

WindowPortMus calls to a class similar to ui::WindowTreeClient on on
any changes. WindowTreeClient forwards changes to the server as
appropriate. Changes originating from the server call to WindowMus
(implemented by WindowPortMus). The implementation of the functions in
WindowPortMus called by WindowTreeClient ensure calls made from
the server don't make their way back to the server. For example, we
don't want something like the following happening: WindowTreeClient is
told bounds change -> change bounds on window -> try to set bounds
change back to server.

Wiring up aura to use mus then becomes something like:
. Create WindowTreeClient (encapsulates connection to mus).
. Install factory on Env.

And then use aura like you normally would. You can see this in
AuraTestHelper.

This patch is huge and works, but there are a bunch of TODOs and a
handful of comment out code. I will be addressing this ASAP, but
wanted to land this for others.

BUG=none
TEST=none
R=sadrul@chromium.org

Committed: https://crrev.com/25714fe6afb80a6f6fe562cadad3e598deb3668d
Cr-Commit-Position: refs/heads/master@{#428031}
==========

[commit-bot: I haz the power, 2016-10-27 15:28:42]

Patchset 10 (id:??) landed as
https://crrev.com/25714fe6afb80a6f6fe562cadad3e598deb3668d
Cr-Commit-Position: refs/heads/master@{#428031}