Running a flutter project from within vscode no longer follows the system theme

Describe the bug When I run flutter apps with the theme and darkTheme properties set from within code, the launched application does not follow the linux desktop dark theme and the android emulators system theme.

To Reproduce Steps to reproduce the behavior: Create a new flutter application Change the theme property to a light theme and the darkTheme property to a dark theme. Switch your system theme to a dark theme in Android or Linux GNOME desktop

Expected behavior The flutter app follows the system theme “brightness” and switch from dark to light

Screenshots From within vscode: From within vscode with the android emulator:

From the terminal: From intellij: From intellij with android as the target:

Versions (please complete the following information):

• VS Code version: 1.57.1
• Dart extension version: v3.24.0
• Dart/Flutter SDK version: Flutter version 2.3.0-17.0.pre.622, but this happens with all channels (stable, dev, beta, master)

Additional information: this worked perfectly fine until some days ago

Edit: vscode snap or .deb - same behaviour 😦

[DanTup]

@Feichtmeier this ended up being a bit more of a refactor than I’d expected so I don’t plan to release it in a patch. It’ll be included in the next release likely around the end of the month.

However I have now set up nightly builds so if you’d like the fix before then you could grab the latest one (right now it’s mostly the same as the last release build but with this and a few other minor fixes). You can download it from the artifacts on the most recent job here:

https://github.com/Dart-Code/Dart-Code/actions/workflows/nightly-build.yml

Some instructions on installing are here:

https://dartcode.org/docs/installing-a-preview-release/

VS Code should automatically move you back to the stable release once it’s out (it will auto-update as long as the version number on the marketplace is newer).

[DanTup]

Looks like when we ask the app for the BrightnessOverride value we get the _resolved_ value but our code assumes it was the override value. This means when we try to restore the values (which is normally after a Hot Restart, although we’re currently doing this on startup too) we can end up adding an override for the brightness (of the current resolved value). This only started happening recently because restoring the toggles had become broken (and was fixed as part of #3426).

I haven’t fully thought it through, but I think a reasonable fix (that won’t re-introduce #3426) would be:

• Stop storing the local state of these debug extensions unless they’ve been explicitly through VS Code (eg. by running the Toggle Foo commands)
• Always update the current state for an extension before toggling, in case it was changed by another tool (this avoids issues where it has to be run twice to have any effect)
• If we see an event that another tool changed a setting, remove it from our state (so we would no longer restore it)

We can’t tell when the system is modifying the theme though, so if you toggle the theme in VS Code (with Toggle Brightness) we will still set an override that prevents the system toggle from working for the rest of the debug session - but I think that’s resonably understandble.

@jacob314 @jonahwilliams FYI in case you have better ideas. I wonder if it would be better if the tool handled restoring these, since it knows both the resolved and overridden value, and avoids any confusion with who should restore them?