UI Framework-1: Aura Event Handling

Event Handling

A diagram of the architecture of this system:

 

 

HWNDMessageHandler owns the WNDPROC, and is code that is shared with the non-Aura windows build. This code is in production and "should work."

On this diagram, the new classes are DesktopRootWindowHostWin(**) and DesktopNativeWidgetAura. DesktopNativeWidgetAura is a new views::NativeWidgetPrivate implementation that wraps an aura::Window* hosted in a special RootWindow/Host, which is implemented by DesktopRootWindowHost[Win|Linux].

 

DesktopNativeWidgetAura is cross platform code, DesktopRootWindowHostWin|Linux is platform-specific.

 

Basically there are a bunch of functions on these two new classes that need to be connected together.

 

I've made a list of these functions here:

 

https://docs.google.com/a/google.com/spreadsheet/ccc?key=0AsMZXOiSimBbdGhhTU1xQWo2QUZGRTExdWhBN2toenc

 

.. along with some notes I quickly made about what I thought would be a resolution for that method.

 

A couple of notes about event handling:

 

• Events from the system progress through the diagram above left to right, i.e. received at the HWND/XWindow and are processed, maybe eventually making it to the Widget (and hence the View hierarchy) on the right.
• Input events in aura must be dispatched by the RootWindow's dispatcher for correct behavior, so rather than sending them directly from the DesktopRootWindowHostWin to the DesktopNativeWidgetAura, we send them into the DRWHW's RootWindow. They'll wind up being received by the DNWA's aura::Window via its WindowDelegate.
• Other types of events can perhaps be sent directly from the DRWHW to the DNWA.

 

• On the other side, the NativeWidgetPrivate interface provides the API that views::Widget expects the native widget to perform, and this direction goes right-to-left on the diagram above. The typical flow here is through DNWA (which implements NWP) and through a DesktopRootWindowHost interface (we can add new methods to this as needed) which DRWHWin|Linux implements.

• Sometimes there is a conflict on a method name between one on aura::RootWindowHost, which DRWHW|L also implements. In this case you can manual RTTI the DRWH to RWH.

• Some methods in DRWHW are never sent back to the DNWA, e.g. those that are windows-specific and are for example completely implemented by NativeWidgetWin. I tend to look at NativeWidgetWin for inspiration when figuring out this kind of thing.