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

Wayland doesn't expose user's configured mouse cursor theme/style #1742

Open
jgcodes2020 opened this issue Mar 21, 2022 · 7 comments
Open

Wayland doesn't expose user's configured mouse cursor theme/style #1742

jgcodes2020 opened this issue Mar 21, 2022 · 7 comments
Labels
bug Something isn't working Wayland

Comments

@jgcodes2020
Copy link

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

Linux Wayland

WezTerm version

wezterm 20220319-163727-ee5d5714

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

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

#524 reported the same bug on X11. Although Wayland does not have a cursor configuration protocol just yet (see here for some work being done), the de-facto configuration method is still to use the Xcursor theme.

Setting the relevant environment variables XCURSOR_THEME and XCURSOR_SIZE does change the cursor, so there's that.

To Reproduce

  • Use a different cursor theme. (Ubuntu uses one by default)
  • Move the cursor over the WezTerm window.
  • Notice that the cursor is now the default one. (For me this is Breeze because I installed some KDE software)

Configuration

The only relevant setting is enable_wayland = true.

Expected Behavior

This is my normal cursor (Yaru):
image

This is the cursor I see when mousing over WezTerm (Breeze):
image

I would expect to not see the cursor change when mousing over WezTerm

Logs

Logs don't provide relevant info

Anything else?

No response

@jgcodes2020 jgcodes2020 added the bug Something isn't working label Mar 21, 2022
@wez
Copy link
Owner

wez commented Mar 21, 2022

It sounds like things are actually working correctly: setting the XCURSOR_THEME does work and respects what you've configured.

The heart of the issue is that wayland doesn't have a way to advise clients of the configured theme, so there's no way for wezterm to know which theme should be used without using some kind of desktop-environment specific mechanism to do so.

@wez wez changed the title WezTerm should use Xcursor theme on Wayland Wayland doesn't expose user's configured mouse cursor theme/style Mar 21, 2022
@wez wez added the Wayland label Mar 21, 2022
@jgcodes2020
Copy link
Author

For now, I've created a workaround using gsettings on GNOME:

#!/usr/bin/sh
export XCURSOR_SIZE="$(gsettings get org.gnome.desktop.interface cursor-size)" 
export XCURSOR_THEME="$(gsettings get org.gnome.desktop.interface cursor-theme | sed -E "s/(^'|'\$)//g")" 
exec /usr/bin/wezterm $@

wez added a commit that referenced this issue Mar 22, 2022
@wez
Copy link
Owner

wez commented Mar 22, 2022

With the commit that I just pushed, you can move your workaround into your lua config:

local wezterm = require 'wezterm'

local xcursor_size = nil
local xcursor_theme = nil

local success, stdout, stderr = wezterm.run_child_process({"gsettings", "get", "org.gnome.desktop.interface", "cursor-theme"})
if success then
  xcursor_theme = stdout:gsub("'(.+)'\n", "%1")
end

local success, stdout, stderr = wezterm.run_child_process({"gsettings", "get", "org.gnome.desktop.interface", "cursor-size"})
if success then
  xcursor_size = tonumber(stdout)
end

return {
  xcursor_theme = xcursor_theme,
  xcursor_size = xcursor_size,
}

In addition to no longer requiring a wrapper script, this has the advantage of you being able to manually trigger a config reload (ctrl-shift-r by default) to update the theme without having to restart wezterm.

wez added a commit that referenced this issue Jul 13, 2022
There are some other settings in there that could also help with
things like the cursor theme on Wayland.

Note that we don't currently subscribe to the settings changed
signal: that can be done in a follow up.

refs: #2258
refs: #1742
@wez
Copy link
Owner

wez commented Jul 14, 2022

main is now technically capable of talking to XDG Desktop Portal to query these sorts of settings. The settings interface currently only portably defines the dark mode/appearance in a DE-agnostic way; these are the portable settings:

gdbus call --session --dest=org.freedesktop.portal.Desktop --object-path=/org/freedesktop/portal/desktop --method=org.freedesktop.portal.Settings.ReadAll '["org.freedesktop.appearance"]'
({'org.freedesktop.appearance': {'color-scheme': <uint32 1>}, 'org.freedesktop.appearance': {'color-scheme': <uint32 1>}, 'org.freedesktop.appearance': {'color-scheme': <uint32 1>}},)

However, the cursor theme and size are reported under a org.gnome.desktop.interface namespace along with a lot of other gnome specific stuff; you can see for yourself by running:

gdbus call --session --dest=org.freedesktop.portal.Desktop --object-path=/org/freedesktop/portal/desktop --method=org.freedesktop.portal.Settings.ReadAll '[]'

It wouldn't be terribly difficult to hook this up in wezterm, but I'm not sure if this would give surprising results sometimes. For example, if you have two sessions running different DE on the same machine, would they both end up using the gnome settings? That's probably not desirable. I don't know if this stuff is smart enough to avoid that or not.

@MuhammedZakir
Copy link
Contributor

For example, if you have two sessions running different DE on the same machine, would they both end up using the gnome settings?

I don't think that will cause problem because if I understand correctly, when you query the session dbus (--session), it gets the session address from DBUS_SESSION_BUS_ADDRESS env var, and different login sessions will have different session addresses.

@miguno
Copy link

miguno commented Jan 4, 2024

The code snippet at #1742 (comment), which explicitly sets wezterm's xcursor_theme and xcursor_size configs based on GNOME's existing settings for those configs, is the only solution I found to fix the mouse cursor from disappearing as described at #3334.

I would have added this comment to the linked issue, but couldn't because that issue is closed. Maybe @wez could add that, as the linked issue is the first Google result when searching for e.g. "wezterm mouse disappearing"?

@wez
Copy link
Owner

wez commented Jan 4, 2024

Done

dvonessen added a commit to dvonessen/nixdots that referenced this issue Feb 25, 2024
subnut added a commit to subnut/dotfiles-chimera-gnome that referenced this issue Jun 26, 2024
wezterm defaults to the "default" cursor theme, which might not be
configured by default (heh)

See - wez/wezterm#1742 (comment)
subnut added a commit to subnut/dotfiles-chimera-gnome that referenced this issue Jun 27, 2024
wezterm defaults to the "default" cursor theme, which might not be
configured by default (heh)

See - wez/wezterm#1742 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Wayland
Projects
None yet
Development

No branches or pull requests

4 participants