- 06 May, 2023 1 commit
-
-
Loïc Sharma authored
Enables running the `layers` example on Linux and Windows. Part of https://github.com/flutter/flutter/issues/126033
-
- 08 Dec, 2022 1 commit
-
-
Loïc Sharma authored
Adds a test to verify the console output of `flutter run --release` on Windows. Part of: https://github.com/flutter/flutter/issues/111577
-
- 30 Aug, 2022 1 commit
-
-
Loïc Sharma authored
-
- 15 Aug, 2022 1 commit
-
-
yaakovschectman authored
* Add Windows compilation test (hello_world_windows__compile) * Add devicelab target to .ci.yaml * Bringup on new target * Add license to generated files * Indicate test ownership * Delete asset from repo * Add Windows compilation test (hello_world_windows__compile) * Add devicelab target to .ci.yaml * Bringup on new target * Add license to generated files * Indicate test ownership * Delete icon * Use path.basename Re triggering tests * Update test owner to desktop team
-
- 07 Jan, 2022 1 commit
-
-
Greg Spencer authored
Updates the platform shims in dev/manual_tests so that Windows and Linux can be built. I had to update the Windows shims, because I was unable to build a Windows app there. Also updates the analyze.dart script to report all license issues simultaneously instead of just dying after the first failure. The only substantive code changes are in dev/bots/analyze.dart and dev/bots/test/analyze_test.dart
-
- 05 Mar, 2021 1 commit
-
-
Chris Bracken authored
This adds support for building and running manual tests, such as the raw keyboard test on Windows desktop.
-
- 30 Oct, 2020 1 commit
-
-
George Wright authored
-
- 15 Sep, 2020 1 commit
-
-
stuartmorgan authored
-
- 03 May, 2020 1 commit
-
-
stuartmorgan authored
Redirects stdout/stderr in the Windows template when creating a console. This fixes the console opened when running from Visual Studio to actually show output, instead of being empty. Fixes #53169
-
- 15 Apr, 2020 1 commit
-
-
stuartmorgan authored
Plugins, and the library, should be able to use COM without special setup. This adds COM initialization to the runner template so that it's available for any code on the main thread.
-
- 06 Apr, 2020 1 commit
-
-
stuartmorgan authored
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
-