@tzx many thanks for doing this work! I appreciate it a great deal! I'll see if I can persuade one or two people to run with this and we can figure out where to go from there!

@tzx amazing, Herculean effort :D

I'll check the todo!() macros and compare some window and settings behaviours across the compositors I use (GNOME, sway, COSMIC) and report back

In terms of continuing this work, if I were up to actually contributing code, should we fork the fork and raise PRs against it, fork the fork and submit a new PR here, or add more people as collaborators to the fork to preserve this PR?

Since we just cut a release, which gives folks an up to date stable build to target, I'm conceptually ok with merging this and making nightly a bit wonky for wayland users while we quickly try to close any gaps that might cause work to be lost, and then we can take a bit longer to polish up the rest.

I'll update this comment with results from other configurations, but to start with...

I'm running cargo run --bin wezterm-gui --release -- --config '...' for each scenario, and my machine has both an AMD iGPU and AMD dGPU (no nVidia in the mix), with 1.25 scale on my single monitor (no multi-monitor)

Compositors with server-side decorations here are:

• COSMIC pre-alpha, Rust, based on Smithay: https://github.com/pop-os/cosmic-comp
• sway 1.8.1, based on wlroots: https://swaywm.org/

Compositors with only client-side decorations here are:

• GNOME 45: https://www.gnome.org/

Ahh, I forgot about turning off window_decorations in my config when working on frame decorations when I was trying wezterm on weston... Hope it's an easy fix.

@tzx don't worry about it
If there are other settings you think I ought to be interested in, let me know
But, I will eventually dive in and figure out what to look at based on your comment ( #4777 (comment) ) and the todo!() s
So don't stress about it :)

Okay, I've had a chance to play with this

I'm no expert in Wayland or SCTK, although learning a lot just reading through the code

What I'd like to do is prepare a PR that can be merged soon after this PR, and my approach is to hard code CSD via SCTK Fallback Frame, ignoring user and compositor preference, with the user able to move/resize/maximise the window without hitting any todo!()

Then separate future PRs can look at updating to SCTK 0.18, and restoring user control over decorations

I've created a branch here: https://github.com/jokeyrhyme/wezterm/tree/smithay-0-17-conflicts-after-4824-and-4866

I figured it was worth tackling the git conflicts separately before trying to do much else

This incorporates the changes to resize_increment behaviour from #4824 and #4866

Otherwise, this doesn't change the observed results: #4777 (comment)

FWIW, a valid outcome for client-side decorations is to default to lean on the https://wezfurlong.org/wezterm/config/lua/config/integrated_title_button_style.html feature to render most/all of that UI. I think that would reduce the problem space in the wayland specific code to handling resize "handles" around the window borders, which can be done with transparent surfaces. The benefit of that is that no custom drawing would be necessary at the wayland layer.

I tested this branch on Hyprland and found the following issues:

1. For every key press, I see an error that looks like: "ERROR window::os::wayland::window > set_cursor: Cursor not found" on stderr
2. With window_decorations of NONE, or "TITLE | RESIZE" I get the "trying to resize hidden frame" panic
3. With window_decorations of "TITLE" or "RESIZE" It opens, but there are strange gray lines to the bottom and left:
   
4. The text of the terminal seems offset, possibly due to decorations, but the decorations aren't actually rendered. This is most obvious if I open a TUI with a background color, like vim:
   
5. Probably related to 4, If I go down to the bottom of the window, then the last line oveflows past the end of the window:
   

Actually... If I make the window floating, it makes a little more sense:

It looks like it is trying to draw the whole window offset from the frame Hyprland is using for the window. Maybe there is a problem between the reference frame of the window including the client decorations and without.

Although, ideally I'd use window_decorations="NONE" on hyprland. But that currently panics.

A few thoughts on this:

1. We should be passing in the appropraite decorations mode to xdg_shell::new_window (second argument) instead of always using Decorations::FollowServer.
2. If we are suing server-side decorations (which I don't think we know until after getting a configure back from the server, I'm not entirely sure where the code that handles that is), then we shouldn't create the window_frame for the decorations at all. I think that panic is happening because we are trying to resize the frame after hiding it.

if someone else doesn't get to it, I think I know what needs to be done to fix this, and a general idea of how to fix this at least using the fallback frame.

Although using https://github.com/PolyMeilex/sctk-adwaita might look nicer.

@tmccombs thanks!

I believe this PR is effectively frozen, so I've created some follow-up PRs that address some of the panics by using the fallback frame in all cases (for now) as a temporary stop-gap

• fix(wayland)!: bump smithay to 0.17; merge conflicts #4905
• fix(wayland)!: hardcode client-side decorations; hardcode scale=1.0 #4906

I've rebased this and pushed it to main, for (mostly) better and (ideally temporarily) slightly worse!
Thanks again @tzx!

Hi, just wondering, would this somewhat improve the fractional scaling situation in Wayland?

Here's my draft at attempting to improve this:

#4970

start if i enter:
env WAYLAND_DISPLAY=1 wezterm

added that to the .desktop app script, and opens everytime now on hyprland.

also added it to hotkey obviously, just verify your wayland display number.