search

wez / wezterm

A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust
https://wezfurlong.org/wezterm/
Other
17.15k stars 771 forks source link

flatpak release: Unable to set cursor to left_ptr: cursor not found #2687

Open sdroege opened 1 year ago

sdroege commented 1 year ago

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

Linux Wayland

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

gnome-shell

WezTerm version

20220905-102802-7d4b8249

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

Running the current release from flathub as of today gives lots of warnings as follows

17:08:48.768  ERROR  window::os::wayland::frame > Unable to set cursor to bottom_side: cursor not found
17:08:48.772  ERROR  window::os::wayland::frame > Unable to set cursor to left_ptr: cursor not found
17:08:48.772  ERROR  window::os::wayland::frame > Unable to set cursor to left_ptr: cursor not found
17:08:48.772  ERROR  window::os::wayland::pointer > Unable to set cursor to xterm: cursor not found
17:08:48.773  ERROR  window::os::wayland::pointer > Unable to set cursor to xterm: cursor not found
17:08:48.774  ERROR  window::os::wayland::pointer > Unable to set cursor to xterm: cursor not found
17:08:48.775  ERROR  window::os::wayland::pointer > Unable to set cursor to xterm: cursor not found
17:08:48.776  ERROR  window::os::wayland::pointer > Unable to set cursor to xterm: cursor not found

The cursors are also indeed not changing correctly, e.g. when going to the edges of the window for resizing.

The same works correctly when building the current version locally from git.

To Reproduce

Just run it via flatpak run org.wezfurlong.wezterm

Configuration

no config

Expected Behavior

Not hundreds of lines of errors and cursors are changing correctly.

Logs

No response

Anything else?

No response

wez commented 1 year ago

To troubleshoot, see: https://wezfurlong.org/wezterm/faq.html#i-use-x11-or-wayland-and-my-mouse-cursor-theme-doesnt-seem-to-work

I think you probably want to try running something like this to see more diagnostics:

flatpak run --env=WEZTERM_LOG=window::os::x11::cursor=trace,window::os::wayland::pointer=trace,info org.wezfurlong.wezterm
sdroege commented 1 year ago

Thanks!

That doesn't enable more output (same as before), and especially nothing for X11. $XCURSOR_PATH and $XCURSOR_THEME are not set, and the configuration doesn't contain a xcursor_theme.

As written it also works outside of flatpak, so my best guess is that the path to the default cursor theme somehow needs to become accessible.

wez commented 1 year ago

This should be fixed 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.

sdroege commented 1 year ago

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

The "problem" here is that it works fine with builds from source and will probably also work fine with things like .appimage because it doesn't provide any sandboxing :)

I'll check again the next flatpak release and re-open if the problem persists. Thanks for looking into this!

sdroege commented 1 year ago

The same still happens with the latest flatpak release (wezterm 20221119-145034-49b9839f)

wez commented 1 year ago

What does:

flatpak run --env=WEZTERM_LOG=window::os::x11::cursor=trace,window::os::wayland::pointer=trace,info org.wezfurlong.wezterm

output?

sdroege commented 1 year ago

Same as before


$ flatpak run --env=WEZTERM_LOG=window::os::x11::cursor=trace,window::os::wayland::pointer=trace,info org.wezfurlong.wezterm
19:38:16.897  ERROR  window::os::wayland::frame > Unable to set cursor to left_ptr: cursor not found
19:38:16.955  ERROR  window::os::wayland::frame > Unable to set cursor to left_ptr: cursor not found
19:38:16.957  ERROR  window::os::wayland::pointer > Unable to set cursor to arrow: cursor not found
19:38:16.964  ERROR  window::os::wayland::frame   > Unable to set cursor to left_ptr: cursor not found
19:38:17.467  ERROR  window::os::wayland::pointer > Unable to set cursor to xterm: cursor not found
19:38:17.477  ERROR  window::os::wayland::pointer > Unable to set cursor to xterm: cursor not found
19:38:17.480  ERROR  window::os::wayland::pointer > Unable to set cursor to xterm: cursor not found
19:38:17.482  ERROR  window::os::wayland::pointer > Unable to set cursor to xterm: cursor not found
19:38:17.484  ERROR  window::os::wayland::pointer > Unable to set cursor to xterm: cursor not found
19:38:17.487  ERROR  window::os::wayland::pointer > Unable to set cursor to xterm: cursor not found
[...]
bldur commented 1 year ago

Just followed build from git main branch and seeing the same, on gentoo with sway. Seems like x11-themes/xcursor-themes needs to be added to get-deps! Or being fine without a theme? Also needed to set a default in ~/.icons/default/index.theme

sdroege commented 1 year ago

When switching the host from Debian to Fedora, the problem inside the flatpak container goes away. So there must be something about how the container inherits cursor themes that is the problem here.

bldur commented 1 year ago

When switching the host from Debian to Fedora, the problem inside the flatpak container goes away. So there must be something about how the container inherits cursor themes that is the problem here.

After seeing this, built from source, on gentoo. Flatpak doesn't look to come bundled, and there are no in-built themes for mouse pointers/cursors. The fix look to have been, "more effort towards finding one".

Someone is packaging it for guix, so guix binary install or guix built container will also be possible.

devmatteini commented 1 year ago

I have the same problem on Ubuntu 22.04 with Gnome and Wayland. I installed the .deb version (wezterm-20221119-145034-49b9839f.Ubuntu22.04.deb)

For me, it's happening when resizing a pane:

23:33:40.798 ERROR window::os::wayland::pointer > Unable to set cursor to ew-resize: cursor not found
23:33:40.877 ERROR window::os::wayland::pointer > Unable to set cursor to ew-resize: cursor not found
23:33:41.028 ERROR window::os::wayland::pointer > Unable to set cursor to ew-resize: cursor not found
23:33:41.140 ERROR window::os::wayland::pointer > Unable to set cursor to ew-resize: cursor not found
mhantsch commented 8 months ago

I am still getting these errors using the flatpak version (wezterm 20230712-072601-f4abf8fd) on Pop!_OS 22.04.

Starting it with XCURSOR_PATH=/usr/share/icons XCURSOR_THEME=Adwaita flatpak run org.wezfurlong.wezterm works around the issue, but it's not working out of the box. What's worse, when you launch wezterm it via the system launcher, this problem prevents resizing the window using mouse / drag window corners.

bldur commented 8 months ago

I am still getting these errors using the flatpak version (wezterm 20230712-072601-f4abf8fd) on Pop!_OS 22.04.

Starting it with XCURSOR_PATH=/usr/share/icons XCURSOR_THEME=Adwaita flatpak run org.wezfurlong.wezterm works around the issue, but it's not working out of the box. What's worse, when you launch wezterm it via the system launcher, this problem prevents resizing the window using mouse / drag window corners.

And there are so many ways of dealing with X related themes, back in the day when you had to walk in two feet of snow over a mountain to obtain something that looked better than FVWM. You'd be certain there was only the environment variables and simple text files to deal with. Now you still have this, and and extended filesystem hierarchy standard and priorities.

Is it broken without working out of the box for all obscure distros and OS flavours? Documenting it is probably sufficient? I agree though, but it's not as bad as relying on deprecetated hardware X cursors in obsolete nvidia drivers. It's a quirk that has a potential minefield that adds obscruity to weird behaviour, error when a theme isnt defined is fine? I suspect that for most, it is fine and mileage from chosen OS vary, but suddenly different cursors in wez may be worse, and things change.

Fixing it so a pointer theme is always picked up, or that the error doesnt show if you dont use one? Or just keep the quirk?

mhantsch commented 8 months ago

I am still getting these errors using the flatpak version (wezterm 20230712-072601-f4abf8fd) on Pop!_OS 22.04. Is it broken without working out of the box for all obscure distros and OS flavours? Documenting it is probably sufficient?

My point is that a flatpak should work independent of the choice of distro. @devmatteini had the same issue on Ubuntu; that's not even an obscure distro.

bldur commented 8 months ago

I am still getting these errors using the flatpak version (wezterm 20230712-072601-f4abf8fd) on Pop!_OS 22.04. Is it broken without working out of the box for all obscure distros and OS flavours? Documenting it is probably sufficient?

My point is that a flatpak should work independent of the choice of distro. @devmatteini had the same issue on Ubuntu; that's not even an obscure distro.

It does work, but is excessive regarding not finding a local home or system default mouse pointer theme. There is reason to suspect there are lots of performance related things like it.

My point is, if you are going for configurable eye kinda terminal with ligature fonts support, you may care about being pointed in a direction to fix it. And applications may inherent wezterm overrides.

Maybe a fix would wezterm config override pointing to a specific file or folder with a theme? Just add the variable in your .bashrc and forget about it, or learn xdg and freedesktop stuff. It's fine as it is I think, just put information about it somewhere? Consider yourself unix porn sniped. https://freedesktop.org/wiki/DesktopThemeSpec/ https://www.gnome-look.org/browse?cat=107&ord=rating

Edit addendum: https://specifications.freedesktop.org/icon-theme-spec/latest/ar01s03.html https://www.gnome-look.org/p/1356095

unpack theme in .local/share/icons/ $ cat .icons/default/index.theme [icon theme] Inherits=volantes_cursors

and it should be all you need to do, certainly sufficient for me on wayland with sway for waylands apps. https://wiki.archlinux.org/title/Cursor_themes

if you work on how to set cursor size other than XCURSOR_SIZE=64, let me know!

always been a mess, so remove the error and use X or whatever built in and not to complain about it. or put it in wezterm config, theme name and size strings to look in the right places in order? its so niche and minor thing that opens up a rabit hole of ways of doing things system wide.

mhantsch commented 8 months ago

@bldur Thanks for all your pointers, they are useful. I can do all of that, yes. I should, however, not have to jump through those hoops.

WezTerm shows up in the app store of distros, e.g. the Pop!_Shop or other package management systems. User selects it and clicks on install. (Installs the flatpak version.) When they then select WezTerm from the distro's application launcher, it opens without any way of resizing the window. A not-so-fit Linux user would think that WezTerm sucks, and believe it is poorly implemented (=buggy).

I think WezTerm is an extremely capable terminal; however it's integration in standard setups has room for improvement.

This will be my last comment on this topic.

bldur commented 8 months ago

@bldur Thanks for all your pointers, they are useful. I can do all of that, yes. I should, however, not have to jump through those hoops.

I think WezTerm is an extremely capable terminal; however it's integration in standard setups has room for improvement.

This will be my last comment on this topic.

Well, it is not xterm, and especially not unicode-rxvt or suckless with reliance on tmux.

Here is my config that come with performance issues with excessive ligatures in the text. And the fact that i can CTRL|SHIFT U, and get a popup menu to select emojis... It's a terminal on the edge! 😀 copy pasted from wezterm prompt. Or any unicode thing supported by selected fonts. https://github.com/tonsky/FiraCode https://github.com/rubjo/victor-mono https://github.com/googlefonts/noto-emoji

Tried to recover bitmap terminus font or feel and gave up in favour of flashy. Many likely still prefer patched suckless with tmux, but no ligatures and emojis. Wezterm isn't competing with gnome terminal and the like.

Mouse pointer theme issue is minor, and if you ask me, it belongs as configuration option next to Zenburn with font sizes, for mouse pointer theme and pointer size, respecting freedesktop and standard locations to happily ignore systems settings for terminal setup.

https://github.com/bldur/configs/blob/main/wezterm/wezterm.lua

But yeah, use this in a large terminal and have large amounts of italics text and watch it crawl when scrolling.

And sorry for derailing this issue! wezterm config in neovim with gruvbox colorscheme. wezterm-gruvbox

I'm done! And opions may differ, on emojis in terminals, but i find the idea funny.