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

Wezterm Generates Many Warnings due to Getting Appearance #3082

Closed
acook opened this issue Feb 9, 2023 · 3 comments
Closed

Wezterm Generates Many Warnings due to Getting Appearance #3082

acook opened this issue Feb 9, 2023 · 3 comments
Labels
bug Something isn't working fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds.

Comments

@acook
Copy link
Contributor

acook commented Feb 9, 2023

What Operating System(s) are you seeing this problem on?

Linux X11

Which Wayland compositor or X11 Window manager(s) are you using?

Budgie, default for Solus

WezTerm version

wezterm 20230208-091928-fd5c6dce

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

No, and I'll explain why below

Describe the bug

I'm building from source and I've looked at the code, basically if Wezterm isn't able to get the appearance (constantly) from the portal it will spam errors to the Lua term or the term it is launched from.

To Reproduce

Run Wezterm and don't let it talk to xdg_desktop_portal to get the current desktop appearance.

Configuration

no config

Expected Behavior

Wezterm would detect is the portal was available, maybe make one warning and then cache the result instead of constantly re-querying it.

Logs

00:57:16.967  WARN   window::os::x11::connection > Unable to resolve appearance using xdg-desktop-portal: Reading xdg-portal org.freedesktop.appearance color-scheme: org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.freedesktop.portal.Settings” on object at path /org/freedesktop/portal/desktop

Anything else?

Any time there is a redraw you'll see the error. If you move the window there will be a ton of them for ever pixel moved.

It occurs to me that maybe we shouldn't be looking this up every tick anyway. It's taking what would normally be an async call and blocking on it every time.

If I"m reading PR #2402 it looks like we're caching the value, so it could be even more I supposed.

The code was introduced in this PR #2268 which does the check.

https://github.com/wez/wezterm/blob/main/window/src/os/x11/connection.rs#L186 is its current home.

I went looking to see if there was a way to subscribe to a change using xdg portal, so then we could get notified and either invoke an event handler or just check it at our leisure. But I'm not savvy to it and didn't find anything.

Of course, I also have the portal libraries installed and it isn't clear to me why Wezterm isn't find the setting, but that's a separate issue.

I'm pretty tired right now, so apologies if I missed anything obvious.

@acook acook added the bug Something isn't working label Feb 9, 2023
wez added a commit that referenced this issue Feb 9, 2023
When it outright doesn't work, just cache that state rather than
repeatedly querying it.

refs: #3082
@wez
Copy link
Owner

wez commented Feb 9, 2023

This should be resolved now in main.

It typically takes about an hour before commits are available as nightly builds for all platforms. Linux builds are the fastest to build and are often available within about 20 minutes. Windows and macOS builds take a bit longer.

Please take a few moments to try out the fix and let me know how that works out. You can find the nightly downloads for your system in the wezterm installation docs.

If you prefer to use packages provided by your distribution or package manager of choice and don't want to replace that with a nightly download, keep in mind that you can download portable packages (eg: a .dmg file on macOS, a .zip file on Windows and an .AppImage file on Linux) that can be run without permanently installing or replacing an existing package, and can then simply be deleted once you no longer need them.

If you are eager and can build from source then you may be able to try this out more quickly.

@wez wez added the fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. label Feb 9, 2023
imsnif pushed a commit to imsnif/wezterm that referenced this issue Feb 11, 2023
When it outright doesn't work, just cache that state rather than
repeatedly querying it.

refs: wez#3082
@acook
Copy link
Contributor Author

acook commented Feb 12, 2023

I pulled the latest and compiled. Now I see the message just once and never again.

I took a look at the code too, looks like it is handling different conditions and storing them now.

Awesome, thanks!

@wez wez closed this as completed Feb 12, 2023
@github-actions
Copy link
Contributor

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 15, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds.
Projects
None yet
Development

No branches or pull requests

2 participants