views: Support Desktop Aura creation on Ozone

views: Support Desktop Aura creation on Ozone

This CL creates classes BrowserDesktopRootWindowHostOzone and
DesktopRootWindowHostOzone to support for Aura Ozone implementations based on
views.

Different than other Aura platforms, DesktopRootWindowHostOzone is an abstract
class where it delegates the construction and also all its methods for the
native Ozone implementation. A pointer called drwh_ozone_ is used for storing
the implementation vtable.

The Ozone implementation is actually the responsible for implementing
DRWHOzone, but the implementation class cannot derivate from DRWHOzone since
such class was already inherited by a different scope,
BrowserDesktopRootWindowHostOzone. Therefore the implementation class has to
simply create another class with the same classes derivation as in DRWHOzone.

In particular, this CL gives support for Chromium browser in Ozone-Wayland.

BUG=295089

[James Cook, 2013-10-23 16:51:46]

I'm not the right reviewer for this change - I don't know much about desktop
aura.

sky, are you the right person?

[rjkroege, 2013-10-23 18:47:48]

On 2013/10/23 16:51:46, James Cook wrote:
> I'm not the right reviewer for this change - I don't know much about desktop
> aura.
> 
> sky, are you the right person?

Might be good for erg to have a look?

[James Cook, 2013-10-23 19:26:01]

-sky

erg, are you the right person to look at this?

[Elliot Glaysher, 2013-10-23 22:20:58]

+sky

Readding sky.

I am wary of the implementation of BDRWHLinux ::AsDesktopRootWindowHost().
You're returning a different object through what looks like a casting method.
Adding sky@ to see if that's acceptable.

[sky, 2013-10-23 22:56:48]

This is such a hack (and I suspect it leaks too). Why not create a
BrowserDesktopRootWindowHostOzone?

[vignatti (out of this project), 2013-10-24 09:14:05]

On 2013/10/23 22:56:48, sky wrote:
> This is such a hack (and I suspect it leaks too). Why not create a
> BrowserDesktopRootWindowHostOzone?

Hi. Thanks all for reviewing.

I've spent half-hour trying to track down whether my solution really leaks but I
gave up. When I was coding, I copied the idea pretty much from
views::DesktopNativeWidgetAura::InitNativeWidget (used by content_shell), so I
assumed that that code is de/allocating the objects correctly. Therefore the
desktop_root_window_host_pointer I've introduced would be just be just fine and
not really leak. Meh.

then erg@ mentions about the casting of BDRWHLinux::AsDesktopRootWindowHost(),
but my lack of knowledge in C++ didn't tell me what's really wrong there (I'm
not being sarcastic - I'm bad in C++). Maybe you can be a bit more specific
please?

Finally, I don't mind in just create BrowserDesktopRootWindowHostOzone class. My
initial attempt was to avoid it, but I'm perfectly fine in doing that way. Just
let me know.

[vignatti (out of this project), 2013-10-28 12:51:01]

On 2013/10/24 09:14:05, vignatti wrote:
> On 2013/10/23 22:56:48, sky wrote:
> > This is such a hack (and I suspect it leaks too). Why not create a
> > BrowserDesktopRootWindowHostOzone?
> 
> Hi. Thanks all for reviewing.
> 
> I've spent half-hour trying to track down whether my solution really leaks but
I
> gave up. When I was coding, I copied the idea pretty much from
> views::DesktopNativeWidgetAura::InitNativeWidget (used by content_shell), so I
> assumed that that code is de/allocating the objects correctly. Therefore the
> desktop_root_window_host_pointer I've introduced would be just be just fine
and
> not really leak. Meh.
> 
> then erg@ mentions about the casting of BDRWHLinux::AsDesktopRootWindowHost(),
> but my lack of knowledge in C++ didn't tell me what's really wrong there (I'm
> not being sarcastic - I'm bad in C++). Maybe you can be a bit more specific
> please?
> 
> Finally, I don't mind in just create BrowserDesktopRootWindowHostOzone class.
My
> initial attempt was to avoid it, but I'm perfectly fine in doing that way.
Just
> let me know.


alright, no comments anymore so I assumed that using
BrowserDesktopRootWindowHostOzone is what you guys preferred. PTAL.

[Elliot Glaysher, 2013-10-28 19:50:00]

https://codereview.chromium.org/36953002/diff/120001/chrome/browser/ui/views/...
File chrome/browser/ui/views/frame/browser_desktop_root_window_host_ozone.cc
(right):

https://codereview.chromium.org/36953002/diff/120001/chrome/browser/ui/views/...
chrome/browser/ui/views/frame/browser_desktop_root_window_host_ozone.cc:31:
return desktop_root_window_host_;
You haven't fixed the major problem here. You're returning an object that isn't
this. The whole point of this method is to downcast this object. Returning a
different object here is probably *really* wrong.

[vignatti (out of this project), 2013-10-29 16:08:38]

https://codereview.chromium.org/36953002/diff/120001/chrome/browser/ui/views/...
File chrome/browser/ui/views/frame/browser_desktop_root_window_host_ozone.cc
(right):

https://codereview.chromium.org/36953002/diff/120001/chrome/browser/ui/views/...
chrome/browser/ui/views/frame/browser_desktop_root_window_host_ozone.cc:31:
return desktop_root_window_host_;
On 2013/10/28 19:50:00, Elliot Glaysher wrote:
> You haven't fixed the major problem here. You're returning an object that
isn't
> this. The whole point of this method is to downcast this object. Returning a
> different object here is probably *really* wrong.

I see now.

rjkroege@, it all boils down to the fact that we don't have a
DesktopRootWindowHostOzone class and therefore we cannot make
BrowserDesktopRootWindowHostOzone inherit it just like in the other platforms.
Now I'm not very sure the consequences of simply adding that class in views, and
specially the impact for the downstream Ozone implementations. I need you input
here. Thank you.

[rjkroege, 2013-10-29 19:32:54]

On 2013/10/29 16:08:38, vignatti wrote:
>
https://codereview.chromium.org/36953002/diff/120001/chrome/browser/ui/views/...
> File chrome/browser/ui/views/frame/browser_desktop_root_window_host_ozone.cc
> (right):
> 
>
https://codereview.chromium.org/36953002/diff/120001/chrome/browser/ui/views/...
> chrome/browser/ui/views/frame/browser_desktop_root_window_host_ozone.cc:31:
> return desktop_root_window_host_;
> On 2013/10/28 19:50:00, Elliot Glaysher wrote:
> > You haven't fixed the major problem here. You're returning an object that
> isn't
> > this. The whole point of this method is to downcast this object. Returning a
> > different object here is probably *really* wrong.
> 
> I see now.
> 
> rjkroege@, it all boils down to the fact that we don't have a
> DesktopRootWindowHostOzone class and therefore we cannot make
> BrowserDesktopRootWindowHostOzone inherit it just like in the other platforms.
> Now I'm not very sure the consequences of simply adding that class in views,
and
> specially the impact for the downstream Ozone implementations. I need you
input
> here. Thank you.

I see no reason not to add a DesktopRootWindowHostOzone. It won't affect any
other current downstream ozone users that are known to me because all the
remaining ozone implementations are widget-per-display.

Eventually, we will want to inject this class's implementation right? Therefore
it must participate in the ozone platform scheme. And if so, to avoid a layering
violation, we need the base in ui/gfx I'm thinking. This will require side
discussion.

[vignatti (out of this project), 2013-11-22 18:15:30]

alright, another try now after the long pause here. PTAL in Patch Set 3 now
guys. Thank you.

On 2013/10/29 19:32:54, rjkroege wrote:
> On 2013/10/29 16:08:38, vignatti wrote:
> >
>
https://codereview.chromium.org/36953002/diff/120001/chrome/browser/ui/views/...
> > File chrome/browser/ui/views/frame/browser_desktop_root_window_host_ozone.cc
> > (right):
> > 
> >
>
https://codereview.chromium.org/36953002/diff/120001/chrome/browser/ui/views/...
> > chrome/browser/ui/views/frame/browser_desktop_root_window_host_ozone.cc:31:
> > return desktop_root_window_host_;
> > On 2013/10/28 19:50:00, Elliot Glaysher wrote:
> > > You haven't fixed the major problem here. You're returning an object that
> > isn't
> > > this. The whole point of this method is to downcast this object. Returning
a
> > > different object here is probably *really* wrong.
> > 
> > I see now.
> > 
> > rjkroege@, it all boils down to the fact that we don't have a
> > DesktopRootWindowHostOzone class and therefore we cannot make
> > BrowserDesktopRootWindowHostOzone inherit it just like in the other
platforms.
> > Now I'm not very sure the consequences of simply adding that class in views,
> and
> > specially the impact for the downstream Ozone implementations. I need you
> input
> > here. Thank you.
> 
> I see no reason not to add a DesktopRootWindowHostOzone. It won't affect any
> other current downstream ozone users that are known to me because all the
> remaining ozone implementations are widget-per-display.
> 
> Eventually, we will want to inject this class's implementation right?
Therefore
> it must participate in the ozone platform scheme. And if so, to avoid a
layering
> violation, we need the base in ui/gfx I'm thinking. This will require side
> discussion.

[vignatti (out of this project), 2013-11-22 18:17:05]

On 2013/11/22 18:15:30, vignatti wrote:
> alright, another try now after the long pause here. PTAL in Patch Set 3 now
> guys. Thank you.
> 
> On 2013/10/29 19:32:54, rjkroege wrote:
> > On 2013/10/29 16:08:38, vignatti wrote:
> > >
> >
>
https://codereview.chromium.org/36953002/diff/120001/chrome/browser/ui/views/...
> > > File
chrome/browser/ui/views/frame/browser_desktop_root_window_host_ozone.cc
> > > (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/36953002/diff/120001/chrome/browser/ui/views/...
> > >
chrome/browser/ui/views/frame/browser_desktop_root_window_host_ozone.cc:31:
> > > return desktop_root_window_host_;
> > > On 2013/10/28 19:50:00, Elliot Glaysher wrote:
> > > > You haven't fixed the major problem here. You're returning an object
that
> > > isn't
> > > > this. The whole point of this method is to downcast this object.
Returning
> a
> > > > different object here is probably *really* wrong.
> > > 
> > > I see now.
> > > 
> > > rjkroege@, it all boils down to the fact that we don't have a
> > > DesktopRootWindowHostOzone class and therefore we cannot make
> > > BrowserDesktopRootWindowHostOzone inherit it just like in the other
> platforms.
> > > Now I'm not very sure the consequences of simply adding that class in
views,
> > and
> > > specially the impact for the downstream Ozone implementations. I need you
> > input
> > > here. Thank you.
> > 
> > I see no reason not to add a DesktopRootWindowHostOzone. It won't affect any
> > other current downstream ozone users that are known to me because all the
> > remaining ozone implementations are widget-per-display.
> > 
> > Eventually, we will want to inject this class's implementation right?
> Therefore
> > it must participate in the ozone platform scheme. And if so, to avoid a
> layering
> > violation, we need the base in ui/gfx I'm thinking. This will require side
> > discussion.

description got updated as well.

[Elliot Glaysher, 2013-11-22 18:50:04]

https://codereview.chromium.org/36953002/diff/190001/chrome/browser/ui/views/...
File chrome/browser/ui/views/frame/browser_desktop_root_window_host_ozone.cc
(right):

https://codereview.chromium.org/36953002/diff/190001/chrome/browser/ui/views/...
chrome/browser/ui/views/frame/browser_desktop_root_window_host_ozone.cc:42: void
BrowserDesktopRootWindowHostOzone::Init(
You don't need to override these methods if you're just calling your base class
implementation. The reason the X11 impl overrode these was because it needed to
do additional work here.

https://codereview.chromium.org/36953002/diff/190001/ui/views/widget/desktop_...
File ui/views/widget/desktop_aura/desktop_root_window_host_ozone.cc (right):

https://codereview.chromium.org/36953002/diff/190001/ui/views/widget/desktop_...
ui/views/widget/desktop_aura/desktop_root_window_host_ozone.cc:337:
DesktopRootWindowHost* DesktopRootWindowHost::Create(
This is confusing, and probably incorrect.

This method is what gets called to build a new DesktopRootWindowHost, and by
convention, return a DesktopRootWindowHostOzone specifically.

What this implementation does is ask your factory for a new instance of a
DesktopRootWindowHost, performs a probably unsafe cast, ***assigns it to a
global that was named like a member variable***, and then returns this object.
This whole implementation is probably incorrect in the presence of multiple
DRWHs, and why a global?

I suspect what you really want to do is turn DRWH::Create into a method that
just returns a new DRWHOzone, modify the DRWHOzone constructor to ask your
factory the DRWH that you are proxying for, and assign that to a member variable
for this instance.

https://codereview.chromium.org/36953002/diff/190001/ui/views/widget/desktop_...
ui/views/widget/desktop_aura/desktop_root_window_host_ozone.cc:343: //
implementation
This comment makes no sense. I have no idea what you're trying to tell me here.

[vignatti (out of this project), 2013-11-22 19:54:19]

Thanks for the review! PTAL.

https://codereview.chromium.org/36953002/diff/190001/chrome/browser/ui/views/...
File chrome/browser/ui/views/frame/browser_desktop_root_window_host_ozone.cc
(right):

https://codereview.chromium.org/36953002/diff/190001/chrome/browser/ui/views/...
chrome/browser/ui/views/frame/browser_desktop_root_window_host_ozone.cc:42: void
BrowserDesktopRootWindowHostOzone::Init(
On 2013/11/22 18:50:05, Elliot Glaysher wrote:
> You don't need to override these methods if you're just calling your base
class
> implementation. The reason the X11 impl overrode these was because it needed
to
> do additional work here.

Done.

https://codereview.chromium.org/36953002/diff/190001/ui/views/widget/desktop_...
File ui/views/widget/desktop_aura/desktop_root_window_host_ozone.cc (right):

https://codereview.chromium.org/36953002/diff/190001/ui/views/widget/desktop_...
ui/views/widget/desktop_aura/desktop_root_window_host_ozone.cc:337:
DesktopRootWindowHost* DesktopRootWindowHost::Create(
On 2013/11/22 18:50:05, Elliot Glaysher wrote:
> This is confusing, and probably incorrect.
> 
> This method is what gets called to build a new DesktopRootWindowHost, and by
> convention, return a DesktopRootWindowHostOzone specifically.
> 
> What this implementation does is ask your factory for a new instance of a
> DesktopRootWindowHost, performs a probably unsafe cast, ***assigns it to a
> global that was named like a member variable***, and then returns this object.
> This whole implementation is probably incorrect in the presence of multiple
> DRWHs, and why a global?
> 
> I suspect what you really want to do is turn DRWH::Create into a method that
> just returns a new DRWHOzone, modify the DRWHOzone constructor to ask your
> factory the DRWH that you are proxying for, and assign that to a member
variable
> for this instance.

Done.

https://codereview.chromium.org/36953002/diff/190001/ui/views/widget/desktop_...
ui/views/widget/desktop_aura/desktop_root_window_host_ozone.cc:343: //
implementation
On 2013/11/22 18:50:05, Elliot Glaysher wrote:
> This comment makes no sense. I have no idea what you're trying to tell me
here.

Done.

[Elliot Glaysher, 2013-11-22 20:21:57]

Please reupload. I can't see several of the files.

[vignatti (out of this project), 2013-11-22 21:10:29]

On 2013/11/22 20:21:57, Elliot Glaysher wrote:
> Please reupload. I can't see several of the files.

yeah, there were errors before. let's see how they look now.

[Elliot Glaysher, 2013-11-22 21:19:37]

https://codereview.chromium.org/36953002/diff/430001/ui/views/widget/desktop_...
File ui/views/widget/desktop_aura/desktop_root_window_host_ozone.cc (right):

https://codereview.chromium.org/36953002/diff/430001/ui/views/widget/desktop_...
ui/views/widget/desktop_aura/desktop_root_window_host_ozone.cc:24: drwh_ozone_ =
(DesktopRootWindowHostOzone *)
Why are you doing this cast? The interface returns something different and you
shouldn't be relying on it to return a DRWHOzone.

Why are you casting to a DesktopRootWindowHostOzone? That's the type of this
class. Is DesktopRootWindowHostOzone supposed to be an interface that something
from your factory implements? Then it shouldn't be a concrete implementation.

[kalyank, 2013-11-23 12:11:52]

https://codereview.chromium.org/36953002/diff/430001/chrome/browser/ui/views/...
File chrome/browser/ui/views/frame/browser_desktop_root_window_host_ozone.cc
(right):

https://codereview.chromium.org/36953002/diff/430001/chrome/browser/ui/views/...
chrome/browser/ui/views/frame/browser_desktop_root_window_host_ozone.cc:48:
return new BrowserDesktopRootWindowHostOzone(native_widget_delegate,
Why not use the existing DesktopFactory interface to able to create the Ozone
version of BrowserDesktopRootWindowHost?
I mean DesktopFactoryOzone, would have have an api like:
BrowserDesktopRootWindowHost* CreateBrowserDesktopRootWindowHost(
	views::internal::NativeWidgetDelegate* native_widget_delegate,
        views::DesktopNativeWidgetAura* desktop_native_widget_aura,
        BrowserView* browser_view,
        BrowserFrame* browser_frame);
and  BrowserDesktopRootWindowHost::CreateBrowserDesktopRootWindowHost would call
this. This would avoid desktop_root_window_host_ozone.cc.

If your concern was that ozone implementations might not implement
BrowserDesktopRootWindowHost properly(implementing all proper interfaces),
BrowserDesktopRootWindowHost clearly documents the expectations.I guess this
should give all needed hints for ozone implementations to make sure that it
implements both views::DesktopRootWindowHost and BrowserDesktopRootWindowHost.
Clearly document, the purpose of CreateRootWindowHost and
CreateBrowserDesktopRootWindowHost in DesktopFactoryOzone.

[vignatti (out of this project), 2013-11-25 20:41:30]

https://codereview.chromium.org/36953002/diff/430001/ui/views/widget/desktop_...
File ui/views/widget/desktop_aura/desktop_root_window_host_ozone.cc (right):

https://codereview.chromium.org/36953002/diff/430001/ui/views/widget/desktop_...
ui/views/widget/desktop_aura/desktop_root_window_host_ozone.cc:24: drwh_ozone_ =
(DesktopRootWindowHostOzone *)
On 2013/11/22 21:19:38, Elliot Glaysher wrote:
> Why are you doing this cast? The interface returns something different and you
> shouldn't be relying on it to return a DRWHOzone.

yup, I'm fixing it next.

> Why are you casting to a DesktopRootWindowHostOzone? That's the type of this
> class. Is DesktopRootWindowHostOzone supposed to be an interface that
something
> from your factory implements? Then it shouldn't be a concrete implementation.

you're right that we want an abstract implementation here ideally but in
practice it's easier to have it like concrete, so Ozone would be similar as the
X11 and WIN platforms code; that's what I tried to explain in the CL
description: "The Ozone implementation is actually the responsible for
implementing DRWHOzone, but the implementation class cannot derivate from
DRWHOzone since  such class was already inherited by a different scope,
BrowserDesktopRootWindowHostOzone. Therefore the implementation class has to
simply create another class with the same classes derivation as in DRWHOzone".

and there's a drawing I made here, maybe it helps to understand:
https://docs.google.com/file/d/0Bz5Ndb_dzfQpZkhaUWh3VU4ybWMtb0h1R3BhcTdFV2cwU...

[vignatti (out of this project), 2013-11-25 22:44:23]

On 2013/11/23 12:11:52, kalyank wrote:
>
https://codereview.chromium.org/36953002/diff/430001/chrome/browser/ui/views/...
> File chrome/browser/ui/views/frame/browser_desktop_root_window_host_ozone.cc
> (right):
> 
>
https://codereview.chromium.org/36953002/diff/430001/chrome/browser/ui/views/...
> chrome/browser/ui/views/frame/browser_desktop_root_window_host_ozone.cc:48:
> return new BrowserDesktopRootWindowHostOzone(native_widget_delegate,
> Why not use the existing DesktopFactory interface to able to create the Ozone
> version of BrowserDesktopRootWindowHost?
> I mean DesktopFactoryOzone, would have have an api like:
> BrowserDesktopRootWindowHost* CreateBrowserDesktopRootWindowHost(
> 	views::internal::NativeWidgetDelegate* native_widget_delegate,
>         views::DesktopNativeWidgetAura* desktop_native_widget_aura,
>         BrowserView* browser_view,
>         BrowserFrame* browser_frame);
> and  BrowserDesktopRootWindowHost::CreateBrowserDesktopRootWindowHost would
call
> this. This would avoid desktop_root_window_host_ozone.cc.
> 
> If your concern was that ozone implementations might not implement
> BrowserDesktopRootWindowHost properly(implementing all proper interfaces),
> BrowserDesktopRootWindowHost clearly documents the expectations.I guess this
> should give all needed hints for ozone implementations to make sure that it
> implements both views::DesktopRootWindowHost and BrowserDesktopRootWindowHost.
> Clearly document, the purpose of CreateRootWindowHost and
> CreateBrowserDesktopRootWindowHost in DesktopFactoryOzone.

it's good point Kalyan.

But I think ideally we want only one API to create Desktop implementations using
DesktopFactoryOzone and it seems that the current one is enough for both Content
based targets and also the Chromium browser. So my take is to stick with it
solely.

[kalyank, 2013-11-26 05:06:10]

On 2013/11/25 22:44:23, vignatti wrote:
> On 2013/11/23 12:11:52, kalyank wrote:
> >
> But I think ideally we want only one API to create Desktop implementations
using
> DesktopFactoryOzone and it seems that the current one is enough for both
Content
> based targets and also the Chromium browser. So my take is to stick with it
> solely.
BrowserDRWH is a platform specific implementation and wouldn't it be ideal to
customize the implementation ? . BrowserDRWH should implement/extend
DRWH<Ozone-implementation>. So, in this case you are not directly using DRWH but
BrowserDRWH which implements/extends DRWH.

A) current approach:
You have DRWHOzone, which would create/own another DRWH(ozone-implementation
specific) acting as a platform layer and forward all calls to
it.BrowserDRWHOzone would implement DRWHOzone.

B)Mechanism for ozone implementations to provide BrowserDRWH:
In Ozone implementation, one would have class A implementing BrowserDRWH and
DRWH<Ozone-implementation>. We would need to add the necessary interface to
desktop factory[1], which would return this implementation. I guess this is how
X11, win implementations are done.

For me A seems to involve un-necessary complications to avoid an API in
DesktopFactory class, which for me exists for this very purpose.

To give context for people not familiar with Ozone Desktop Factory class:
1)
http://src.chromium.org/viewvc/chrome/trunk/src/ui/views/widget/desktop_aura/...

[vignatti (out of this project), 2013-11-26 11:43:08]

On 2013/11/26 05:06:10, kalyank wrote:
> On 2013/11/25 22:44:23, vignatti wrote:
> > On 2013/11/23 12:11:52, kalyank wrote:
> > >
> > But I think ideally we want only one API to create Desktop implementations
> using
> > DesktopFactoryOzone and it seems that the current one is enough for both
> Content
> > based targets and also the Chromium browser. So my take is to stick with it
> > solely.
> BrowserDRWH is a platform specific implementation and wouldn't it be ideal to
> customize the implementation ? . BrowserDRWH should implement/extend
> DRWH<Ozone-implementation>. So, in this case you are not directly using DRWH
but
> BrowserDRWH which implements/extends DRWH.
> 
> A) current approach:
> You have DRWHOzone, which would create/own another DRWH(ozone-implementation
> specific) acting as a platform layer and forward all calls to
> it.BrowserDRWHOzone would implement DRWHOzone.
> 
> B)Mechanism for ozone implementations to provide BrowserDRWH:
> In Ozone implementation, one would have class A implementing BrowserDRWH and
> DRWH<Ozone-implementation>. We would need to add the necessary interface to
> desktop factory[1], which would return this implementation. I guess this is
how
> X11, win implementations are done.
> 
> For me A seems to involve un-necessary complications to avoid an API in
> DesktopFactory class, which for me exists for this very purpose.
> 
> To give context for people not familiar with Ozone Desktop Factory class:
> 1)
>
http://src.chromium.org/viewvc/chrome/trunk/src/ui/views/widget/desktop_aura/...

yes, I understood the way you're suggesting Kalyan. Thank you. But I'd still
prefer to keep it simple and use only one API interface for all Desktop Aura
targets as I shown in the latest patch set. Let's see if the other developers
have something else in mind.

erg@ PTAL.

[rjkroege, 2013-11-26 22:14:45]

sadrul@: can you evaluate this from the viewpoint of the refactoring that we
discussed?

[Elliot Glaysher, 2013-11-26 22:29:46]

At this point, I think you should work with Robert to work through the issues
with this patch.

[vignatti (out of this project), 2013-11-27 11:38:29]

Thanks erg@. I'm adding sadrul@ now -- please check rjkroege@ message above.

[rjkroege, 2014-07-14 22:09:08]

On 2013/11/27 11:38:29, vignatti wrote:
> Thanks erg@. I'm adding sadrul@ now -- please check rjkroege@ message above.

Now that we've landed PlatformWindow, you should be able to restructure this?

[vignatti (out of this project), 2014-07-16 18:52:17]

On 2014/07/14 22:09:08, rjkroege wrote:
> On 2013/11/27 11:38:29, vignatti wrote:
> > Thanks erg@. I'm adding sadrul@ now -- please check rjkroege@ message above.
> 
> Now that we've landed PlatformWindow, you should be able to restructure this?

I've been following the PlatformWindow changes but unfortunately to track back
them in desktop aura side would be a low-priority task for me. I hope someone
could pick this work from me in the mean time.

Thanks for the reminding.

[kalyank, 2014-07-17 06:43:34]

On 2014/07/16 18:52:17, vignatti wrote:
> On 2014/07/14 22:09:08, rjkroege wrote:
> > On 2013/11/27 11:38:29, vignatti wrote:
> > > Thanks erg@. I'm adding sadrul@ now -- please check rjkroege@ message
above.
> > 
> > Now that we've landed PlatformWindow, you should be able to restructure
this?
> 
> I've been following the PlatformWindow changes but unfortunately to track back
> them in desktop aura side would be a low-priority task for me. I hope someone
> could pick this work from me in the mean time.
> 
> Thanks for the reminding.

I can take it up, if no one handles this before August 10th (I am on vacation
till August 10th)