- 30 Jun, 2022 1 commit
-
-
stuartmorgan authored
-
- 28 Sep, 2021 1 commit
-
-
Greg Spencer authored
This adds a smoke test for every single API example. It also fixes 17 tests that had bugs in them, or were otherwise broken, and even fixes one actual bug in the framework, and one limitation in the framework. The bug in the framework is that NetworkImage's _loadAsync method had await response.drain<List<int>>();, but if the response is null, it will throw a cryptic exception saying that Null can't be assigned to List<int>. The fix was just to use await response.drain<void>(); instead. The limitation is that RelativePositionedTransition takes an Animation<Rect> rect parameter, and if you want to use a RectTween with it, the value emitted there is Rect?, and one of the examples was just casting from Animation<Rect> to Animation<Rect?>, which is invalid, so I modified RelativePositionedTransition to take a Rect? and just use Rect.zero if the rect is null.
-
- 25 Aug, 2021 1 commit
-
-
Greg Spencer authored
This extracts the sample code out from the API doc comments, and places them in separate files on disk, allowing running of the examples locally, testing them, and building of slightly larger examples.
-
- 07 Jun, 2021 1 commit
-
-
Jason Simmons authored
-
- 28 Sep, 2020 1 commit
-
-
Jonah Williams authored
Check in linux and windows platform code now that they are stable, so that we could use in devicelab in the future. Removed the ICO from the windows example to avoid analysis check, and since it won't be important for benchmarking or UI tests
-
- 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
-