commit 2d623278e776340ebf420cdfa6a721e7639f59d1
author stuartmorgan <stuartmorgan@google.com> Mon Apr 06 12:24:05 2020 -0700
committer GitHub <noreply@github.com> Mon Apr 06 12:24:05 2020 -0700
tree 44b8d7565f87536c171e26214ba854bb913eeba2
parent d35ade4a6c1aa2dadb2af388f716ac4e8aa715d6

Restructure the Windows app template (#53600)

This moves the app template more toward being a more generic starting
point for any Flutter application, eliminating some hard-code
assumptions about there being a single window/engine pair that is
directly bound to the life of the application:
- Moves the runloop into its own class, making it capable of servicing
  any number of engine instances.
- Moves the logic for setting up a window containing only a Flutter view
  into a window subclass for ease of re-use.
- Makes quit-on-window-close an optional property. (Long term this
  should be even more generic, like a quit-when-last-window-closes
  option, but this is a short-term improvement that removes the binding
  between the runloop and the window).
- Allows for multiple instances of Win32Window to exist without issues
  relating to the window class registration.

Since there are getting to be a non-trivial number of files associated
with the runner, this moves the source into a runner/ directory, as is
already done on some other platforms.

Note that creating multiple Flutter windows at the same time still
doesn't work correctly even with this change, but this addresses some of
the known issues, and makes it easier to test in the future (e.g., for
debugging engine-level issues with multiple instances).

Fixes #45397