Aura vs views for desktop implementation

629 views
Skip to first unread message

Marshall Greenblatt

unread,
Dec 5, 2013, 3:22:02 PM12/5/13
to chromium-dev
Hi All,

I'm migrating Chromium Embedded Framework (CEF) from the old Win32/GTK architecture to the new aura-based architecture. I notice that there are two versions of content shell -- aura and views. It seems like the views-based implementation more closely matches how the Chromium browser is implemented (using files from ui/views/widget/desktop_aura).

If I'd like to minimize the re-implementation of platform-specific code in CEF and generally have it behave correctly on desktop platforms (Windows and Linux) am I better off using the views layer instead of using aura directly?

Is it possible to parent a views-created widget (views::Widget) to an external native window (HWND or ::Window) and have everything behave correctly?

Thanks,
Marshall

Steven Bennetts

unread,
Dec 5, 2013, 3:26:15 PM12/5/13
to magree...@gmail.com, chromium-dev
This may not entirely answer your question, but the following page has a good description and a nice diagram describing the relationship between Aura and Views:




--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

Sadrul Chowdhury

unread,
Dec 5, 2013, 3:41:52 PM12/5/13
to magree...@gmail.com, chromium-dev
On Thu, Dec 5, 2013 at 3:22 PM, Marshall Greenblatt
<magree...@gmail.com> wrote:
> Hi All,
>
> I'm migrating Chromium Embedded Framework (CEF) from the old Win32/GTK
> architecture to the new aura-based architecture. I notice that there are two
> versions of content shell -- aura and views. It seems like the views-based
> implementation more closely matches how the Chromium browser is implemented
> (using files from ui/views/widget/desktop_aura).

The non-views aura implementation of content-shell is for ozone
(http://www.chromium.org/developers/design-documents/ozone), which
always uses aura, but views dependency is optional.

chrome-aura on the desktop (linux, ChromeOS or Windows) is expected to
always use aura+views.

>
> If I'd like to minimize the re-implementation of platform-specific code in
> CEF and generally have it behave correctly on desktop platforms (Windows and
> Linux) am I better off using the views layer instead of using aura directly?
>
> Is it possible to parent a views-created widget (views::Widget) to an
> external native window (HWND or ::Window) and have everything behave
> correctly?

On linux-x11, it should be possible, yes
(Widget::GetNativeWindow()->GetDispatcher()->host()->GetAcceleratedWidget()
should give you the X window hosting the views::Widget). For toplevel
windows, you may need to unset some of WM-properties set on the
window.

I am not familiar with Windows/HWND, so I do not know about that. Note
that views has always been used on Windows (even without aura).

Sadrul

John Abd-El-Malek

unread,
Dec 5, 2013, 3:43:30 PM12/5/13
to Marshall Greenblatt, chromium-dev
In Aura, there is only HWND for the top level window, so this isn't going to be possible.

Note that we're on track to shipping Aura in M32. When that happens, the plan is to remove all the old non-aura platform code on Windows.

Marshall Greenblatt

unread,
Dec 5, 2013, 3:48:22 PM12/5/13
to John Abd-El-Malek, chromium-dev
On Thu, Dec 5, 2013 at 3:43 PM, John Abd-El-Malek <j...@chromium.org> wrote:



On Thu, Dec 5, 2013 at 12:22 PM, Marshall Greenblatt <magree...@gmail.com> wrote:
Hi All,

I'm migrating Chromium Embedded Framework (CEF) from the old Win32/GTK architecture to the new aura-based architecture. I notice that there are two versions of content shell -- aura and views. It seems like the views-based implementation more closely matches how the Chromium browser is implemented (using files from ui/views/widget/desktop_aura).

If I'd like to minimize the re-implementation of platform-specific code in CEF and generally have it behave correctly on desktop platforms (Windows and Linux) am I better off using the views layer instead of using aura directly?

Is it possible to parent a views-created widget (views::Widget) to an external native window (HWND or ::Window) and have everything behave correctly?

In Aura, there is only HWND for the top level window, so this isn't going to be possible.

I assume you mean RootWindow in this case. I think I can parent the underlying RootWindow native handle to an external native window (by adding the WS_CHILD flag on Windows, for example), but I'm not sure if activation, focus, event handling, etc will all work correctly.
 

Note that we're on track to shipping Aura in M32. When that happens, the plan is to remove all the old non-aura platform code on Windows.

Does this affect the views + aura implementation in any way?

Scott Graham

unread,
Dec 5, 2013, 3:51:39 PM12/5/13
to Marshall Greenblatt, John Abd-El-Malek, chromium-dev
On Thu, Dec 5, 2013 at 12:48 PM, Marshall Greenblatt <magree...@gmail.com> wrote:

On Thu, Dec 5, 2013 at 3:43 PM, John Abd-El-Malek <j...@chromium.org> wrote:



On Thu, Dec 5, 2013 at 12:22 PM, Marshall Greenblatt <magree...@gmail.com> wrote:
Hi All,

I'm migrating Chromium Embedded Framework (CEF) from the old Win32/GTK architecture to the new aura-based architecture. I notice that there are two versions of content shell -- aura and views. It seems like the views-based implementation more closely matches how the Chromium browser is implemented (using files from ui/views/widget/desktop_aura).

If I'd like to minimize the re-implementation of platform-specific code in CEF and generally have it behave correctly on desktop platforms (Windows and Linux) am I better off using the views layer instead of using aura directly?

Is it possible to parent a views-created widget (views::Widget) to an external native window (HWND or ::Window) and have everything behave correctly?

In Aura, there is only HWND for the top level window, so this isn't going to be possible.

I assume you mean RootWindow in this case. I think I can parent the underlying RootWindow native handle to an external native window (by adding the WS_CHILD flag on Windows, for example), but I'm not sure if activation, focus, event handling, etc will all work correctly.

I believe Chrome Frame more or less works, so I suspect that's probably not completely broken at least.

John Abd-El-Malek

unread,
Dec 5, 2013, 3:59:55 PM12/5/13
to Marshall Greenblatt, chromium-dev
On Thu, Dec 5, 2013 at 12:48 PM, Marshall Greenblatt <magree...@gmail.com> wrote:

On Thu, Dec 5, 2013 at 3:43 PM, John Abd-El-Malek <j...@chromium.org> wrote:



On Thu, Dec 5, 2013 at 12:22 PM, Marshall Greenblatt <magree...@gmail.com> wrote:
Hi All,

I'm migrating Chromium Embedded Framework (CEF) from the old Win32/GTK architecture to the new aura-based architecture. I notice that there are two versions of content shell -- aura and views. It seems like the views-based implementation more closely matches how the Chromium browser is implemented (using files from ui/views/widget/desktop_aura).

If I'd like to minimize the re-implementation of platform-specific code in CEF and generally have it behave correctly on desktop platforms (Windows and Linux) am I better off using the views layer instead of using aura directly?

Is it possible to parent a views-created widget (views::Widget) to an external native window (HWND or ::Window) and have everything behave correctly?

In Aura, there is only HWND for the top level window, so this isn't going to be possible.

I assume you mean RootWindow in this case. I think I can parent the underlying RootWindow native handle to an external native window (by adding the WS_CHILD flag on Windows, for example), but I'm not sure if activation, focus, event handling, etc will all work correctly.

Sure parenting the root window should work. I thought you meant parenting any generic view::Widget. That won't work since they won't have an HWND.

 

Note that we're on track to shipping Aura in M32. When that happens, the plan is to remove all the old non-aura platform code on Windows.

Does this affect the views + aura implementation in any way?

Nope, this will just be removing the views + non-aura code.
Reply all
Reply to author
Forward
0 new messages