Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Feichtmeier opened this issue Jul 2, 2021 · 18 comments
Labels
in debugger Relates to the debug adapter or process of launching a debug session in flutter Relates to running Flutter apps is bug
Milestone

Comments

@Feichtmeier
Copy link

Feichtmeier commented Jul 2, 2021

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:
no
From within vscode with the android emulator:
Peek_2021-07-02_00-05

From the terminal:
ya
From intellij:
yayaya
From intellij with android as the target:
int

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 :(

@larssn
Copy link

larssn commented Jul 2, 2021

The Monokai theme is also showing the wrong colors after this update. It's very green now.

@DanTup
Copy link
Member

DanTup commented Jul 5, 2021

@larssn I believe this issue is about the theme of the running app and not the editor. There are some comments about editor theming in #3458 (comment) though - I believe the changes are expected and what you're seeing is how the Monokai theme is intended to be. If you believe that's incorrect, please post in that issue with some specific examples, thanks!

@larssn
Copy link

larssn commented Jul 5, 2021

@DanTup You might be right. Looking at https://github.com/microsoft/vscode/blob/main/extensions/theme-monokai/themes/monokai-color-theme.json it does seem to very very green.

But strangely until the update it didn't look like that.
Maybe the conclusion is that the theme never rendered correctly in the first place, and I've been using it for years.

Anyway, thank you. 👍

@DanTup
Copy link
Member

DanTup commented Jul 5, 2021

@larssn the reason is that we only recently started using Semantic Tokens for the highlighting. These had much less information than the semantic tokens so a) could've resulted in simpler/less highlighting, and b) might be coloured differently from semantic tokens (themes can apply colours to both semantic tokens and to textmate grammars, and there's nothing to say they need to be semantically the same).

If you prefer the old way, you can disable semantic highlighting - although generally I'd suggest it should give better results, so a better option may be to just customise the theme to your liking but sticking with semantic tokens.

@larssn
Copy link

larssn commented Jul 5, 2021

I'm slowly getting used to the "Dark+" theme, which is similar'ish to what Monokai used to look like.

But thanks for the info. I'll definitely keep semantic highlighting on. 👍

Have a great day

@DanTup
Copy link
Member

DanTup commented Jul 5, 2021

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?

@DanTup DanTup added this to the v3.25.0 milestone Jul 5, 2021
@DanTup DanTup added in debugger Relates to the debug adapter or process of launching a debug session in flutter Relates to running Flutter apps labels Jul 5, 2021
DanTup added a commit that referenced this issue Jul 5, 2021
@DanTup DanTup closed this as completed in e6a7149 Jul 6, 2021
DanTup added a commit that referenced this issue Jul 6, 2021
@Feichtmeier
Copy link
Author

Thank you very much @DanTup will test this when I'm back home

@DanTup
Copy link
Member

DanTup commented Jul 6, 2021

@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).

@Feichtmeier
Copy link
Author

I will try the nightly build! Thank you very much

@Feichtmeier
Copy link
Author

@DanTup tried the nightly build finally, sadly this issue remains.

@DanTup
Copy link
Member

DanTup commented Jul 13, 2021

@Feichtmeier are you able to capture a log (run the Dart: Capture Debugging Logs command, then run the project and repro, then click Cancel on the logging notification to open the log) and send it to me at logs@dartcode.org? I was able to reproduce your original issue perfectly, but the nightly build seemed to resolve it for me 😔

Thanks!

@DanTup DanTup reopened this Jul 13, 2021
@Feichtmeier
Copy link
Author

Feichtmeier commented Jul 13, 2021

Screenrecord:
Peek 2021-07-13 12-24

Log:
Dart-Code-Log-2021-06-02 12-25-44.txt

Edit: and thanks for looking again into this!

@DanTup
Copy link
Member

DanTup commented Jul 13, 2021

@Feichtmeier can you describe exactly what's happening in the recording? I was a little confused about what was going on (it looked like the theme did change initially, but then ended up being out of sync with the system theme?).

I checked the logs, but it doesn't look like VS Code changes the theme at all during that period, so I'm wondering it there's also another issue (if you search the logs for "BrightnessOverride" which is the VM Service extension used to toggle it, it only seems to appear in the ServiceExtensionAdded events, but there are no calls to set it).

Does this happen if you try with an Android emulator/device, or only on Linux Desktop?

@Feichtmeier
Copy link
Author

@DanTup

I toggled the gnome/ubuntu desktop theme from yaru-dark to yaru-light.
Some weeks ago ( like you can see in this example ) the flutter app started from within vscode (run button or play button) followed the system theme if both "theme" and "darkTheme" properties of the MaterialApp were set.
Now they do not follow but somehow switch to late. The first switch works, then the second and third and so on do the opposite of what would be expected.

For the the android emulator when started from vscode it is fixed 👍
fixedforandroid

Previously as you can see in the opening post it also did not work for android if started from vscode.

@DanTup
Copy link
Member

DanTup commented Jul 13, 2021

Ok, seems like maybe there are two issues then:

  • VS code overriding the theme incorrectly (this affecting all platforms and is what I could repro and fixed in latest code)
  • Theme not working correctly for Linux Desktop

I think the second one might be a Flutter issue rather than a VS Code issue (since for the most part, VS Code doesn't do anything differently - the platforms are entirely abstracted by Flutter). I'm curious if you can repro this from the terminal or from Android Studio (that might confirm it). I can't find any other issues reporting this in Flutter, but I'm not sure we can do any more in the extension here (since the log shows that we're not touching the theme at all).

@DanTup
Copy link
Member

DanTup commented Jul 13, 2021

I'm not sure if this is related (it's not clear to me whether "revise" means "fix" or this just implemented it):

flutter/engine#25535

I'm also not sure whether that change made it into the current stable. I'd recommend testing on master/dev if you can, and also from terminal/Android Studio. If it's fixed on master/dev or repros on Android Studio/terminal, then I think it's definitely something that will need addressing in Flutter.

@DanTup
Copy link
Member

DanTup commented Jul 19, 2021

@Feichtmeier I'm going to use this issue for the first issue mentioned above which has been fixed here in the extension. If you can reproduce the other issue when running from the terminal (which I would suspect you can) then please file an issue at https://github.com/flutter/flutter/. If you can still only repro in VS Code (even when using the nightly build with the fix above) please open a new issue specifically about this and I'll have to get a Linux install set up I can do some debugging in. Thanks!

@Feichtmeier
Copy link
Author

@DanTup alright, thanks for the help and sorry for not replying for so long. Somehow this notification got lost

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in debugger Relates to the debug adapter or process of launching a debug session in flutter Relates to running Flutter apps is bug
Projects
None yet
Development

No branches or pull requests

3 participants