wez
adopt sctk-adwaita as our frame on wayland
This bumps sctk-adwaita to use the main branch that allows to hide the title bar. Allows dragging via the tab_bar, and adopts the changes in https://github.com/wezterm/wezterm/pull/6923#issuecomment-2853352203.
On GNOME 48:
https://github.com/user-attachments/assets/31f94480-9e37-4b2f-b8eb-a0ab7b18a242
https://github.com/user-attachments/assets/c4205d61-5257-4c17-8f31-07a066c6b881
Works great on Gnome 48 on Fedora 42. I am able to drag the window without the double click bug. Window renders nicely with sctk-adwaita frame.
I would recommend that 752-754 in windows.rs be completely removed since it is not needed instead of commenting it out.
Will do, i completely forgot about the comments. I am just waiting on @wez to reply back on tasks remaining for this PR to be merged, i haven’t tried on other compositors yet but i would say its better than the current wayland fallback.
On Sun, Jul 20, 2025 at 11:23 AM TeshST @.***> wrote:
teshst left a comment (wezterm/wezterm#7095) https://github.com/wezterm/wezterm/pull/7095#issuecomment-3094690874
I would recommend that 752-754 in windows.rs be completely removed since it is not needed instead of commenting it out.
— Reply to this email directly, view it on GitHub https://github.com/wezterm/wezterm/pull/7095#issuecomment-3094690874, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG253KNWHT47NCPVVFG7QRT3JPNBZAVCNFSM6AAAAACBY53VUSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAOJUGY4TAOBXGQ . You are receiving this because you authored the thread.Message ID: @.***>
Thanks for taking this! Can't say I've ever encountered the above 3 issues…
Thanks for taking this! Can't say I've ever encountered the above 3 issues…
I think it was due to a dirty build maybe, or i copied over the debug build by mistake, i just cleaned and rebuilt and i am not running into those issues. Are there any remaining issues you are aware of that we can add to the todo list?
I'm pleased that there's progress and good feedback here; thank you!
I am currently in the middle of moving between countries and won't have access to my linux workstation for another month, so I won't be able to test this myself until then.
I'm not going to do a deeper review of this PR right now because:
- It is marked as draft, which signifies that it is not ready for review
- it has merge conflicts and cannot be merged
Please also ensure that any comments that I made on the original PR are also addressed here; I haven't had bandwidth to review the state of that one or compare to this one.
Thanks again!
I'm pleased that there's progress and good feedback here; thank you!
I am currently in the middle of moving between countries and won't have access to my linux workstation for another month, so I won't be able to test this myself until then.
I'm not going to do a deeper review of this PR right now because:
* It is marked as draft, which signifies that it is not ready for review * it has merge conflicts and cannot be mergedPlease also ensure that any comments that I made on the original PR are also addressed here; I haven't had bandwidth to review the state of that one or compare to this one.
Thanks again!
Thanks for the reply, no worries, i will mark this for review once:
- [x] Test this build out on other compositors.
- [x] Look into https://github.com/wezterm/wezterm/pull/6923#issuecomment-2848763225.
- [x] Fix wl_shm_pool error when decorations are set to NONE.
@wez @valpackett Some input would be great regarding the wl_shm_pool error, when decorations are set to NONE, using stk_adwaita is not viable since it crashes when we set the frame to hidden.
What should be the behavior when decorations are NONE, skip the frame entirely? That would mean making the window_frame an optional. I have made the changes with a few bugs, here's what that looks like when decorations are none.
Is that the desired logic? To skip the CSD frame entirely if the decorations are NONE, or should we stick with stk-adwaita entirely and see if we can make it work while the frame is hidden
GNONE:
KDE:
I think yes, NONE should mean skip it entirely, though IIRC when I tried that it was kinda annoying to make it optional. We should ask the sctk-adwaita developer about the crash though..
We should. I actually already made it an optional and have it skipping the frame currently on NONE and letting the compositor draw the frame. There’s couple of bugs i need to fix and the code is messy, i can push it if this is the route we should go.
On Tue, Jul 22, 2025 at 1:35 PM Val Packett @.***> wrote:
valpackett left a comment (wezterm/wezterm#7095) https://github.com/wezterm/wezterm/pull/7095#issuecomment-3104752046
I think yes, NONE should mean skip it entirely, though IIRC when I tried that it was kinda annoying to make it optional. We should ask the sctk-adwaita developer about the crash though..
— Reply to this email directly, view it on GitHub https://github.com/wezterm/wezterm/pull/7095#issuecomment-3104752046, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG253KLABOOR3CAHGM7VQI33J2OAFAVCNFSM6AAAAACBY53VUSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCMBUG42TEMBUGY . You are receiving this because you authored the thread.Message ID: @.***>
@valpackett Try out the latest commit. If the decorations are set to NONE, the compositor handles the frame and our frame is never made. Although i do think i need to have 2 seperate functions to create a new frame and to destroy it, in event that the configuration is changed to NONE. I am not sure, would be happy to hear your suggestion.
I do think right now there might be slight bugs when changing the config window decorations until there is a restart of the terminal, i will need to focus on that next.
GNOME INTEGRATED(stk-adwaita with no title bar):
GNOME TITLE (stk-adwaita):
GNOME NONE (compositor):
KDE INTEGRATED(stk-adwaita with no title bar):
KDE TITLE (stk-adwaita):
KDE NONE (compositor):
Here are the the current remaining issues with this PR currently, i am not aware of anything else:
- [x] Changing window_decorations in the config on the fly is not working correctly, but of course fixed by a restart. Need to handle going from server to CSD frame case. Need to handle creating/destroying the CSD frame in separate functions.
@HearseDev Likely, you will want to rebase the main branch instead of merging the main branch into this PR.
@HearseDev Likely, you will want to rebase the main branch instead of merging the main branch into this PR.
Thanks for the heads up, its my first PR not really experienced with git that much.
Fount one issue with the current PR: with window decorations enabled in Fullscreen mode wrong size window displaying (black rows on the top and bottom of the screen).
Fount one issue with the current PR: with window decorations enabled in Fullscreen mode wrong size window displaying (black rows on the top and bottom of the screen).
thank you for the feedback, will look into this and make changes as soon as possible.
@aliaksandr-trush Hi, I haven't been around my linux machine but I will be soon so I can test the bug myself, I have personally never experienced it.
Is this the issue you were experiencing? Looks like it might be present on upstream wayland, I will test it when I have access to my machine. https://github.com/wezterm/wezterm/issues/6275
@aliaksandr-trush Hi, I haven't been around my linux machine but I will be soon so I can test the bug myself, I have personally never experienced it.
Is this the issue you were experiencing? Looks like it might be present on upstream wayland, I will test it when I have access to my machine. #6275
Hello, Double-checked the issue on my end, and I am not able to reproduce it in mainstream. Steps to reproduce:
- In wezterm.lua set
local wezterm = require("wezterm")
local config = wezterm.config_builder()
config.window_decorations = "TITLE"
return config
- Start new wezterm instance
wezterm start - Press Alt+Enter to make it Fullscreen.
@aliaksandr-trush Hi, I haven't been around my linux machine but I will be soon so I can test the bug myself, I have personally never experienced it. Is this the issue you were experiencing? Looks like it might be present on upstream wayland, I will test it when I have access to my machine. #6275
Hello, Double-checked the issue on my end, and I am not able to reproduce it in mainstream. Steps to reproduce:
1. In wezterm.lua setlocal wezterm = require("wezterm") local config = wezterm.config_builder() config.window_decorations = "TITLE" return config2. Start new wezterm instance `wezterm start` 3. Press Alt+Enter to make it Fullscreen.
Hi, thank you so much for the reproduction steps, i reproduced the issue successfully and pushed a fix, let me know if that works for you or any other issues.
@aliaksandr-trush Hi, I haven't been around my linux machine but I will be soon so I can test the bug myself, I have personally never experienced it. Is this the issue you were experiencing? Looks like it might be present on upstream wayland, I will test it when I have access to my machine. #6275
Hello, Double-checked the issue on my end, and I am not able to reproduce it in mainstream. Steps to reproduce:
1. In wezterm.lua setlocal wezterm = require("wezterm") local config = wezterm.config_builder() config.window_decorations = "TITLE" return config2. Start new wezterm instance `wezterm start` 3. Press Alt+Enter to make it Fullscreen.Hi, thank you so much for the reproduction steps, i reproduced the issue successfully and pushed a fix, let me know if that works for you or any other issues.
I am not able to reproduce the issue now. Thanks.
Sorry, I don't have context for the PR but as you requested on #7156 here is a screenshot (wayland - hyprland):
Doesn't seem to have the scaling/dpi issue but I assume those bars aren't meant to be like that. This is what it looks like off the main branch:
@aliaksandr-trush In the future (when sctk-adwaita adds an option to hide borders), what should be the default behavior? Disable borders completely with no option to enable them. Right side is without borders (setting border color to be transparent)
@Rolv-Apneseth With the merge of https://github.com/PolyMeilex/sctk-adwaita/pull/79, this pr by default does not draw any borders on the window.
@aliaksandr-trush As of right now, by default the CSD frame does not draw any borders, i was wondering if i should add a decoration option to disable the border for wayland "WAYLAND_DISABLE_BORDER" and draw borders by default.
@aliaksandr-trush In the future (when sctk-adwaita adds an option to hide borders), what should be the default behavior? Disable borders completely with no option to enable them. Right side is without borders (setting border color to be transparent)
@aliaksandr-trush As of right now, by default the CSD frame does not draw any borders, i was wondering if i should add a decoration option to disable the border for wayland "WAYLAND_DISABLE_BORDER" and draw borders by default.
I believe these questions mostly for @wez
Hi! I'm excited by this PR, despite not having a lot of bandwidth: my recent country move continues to wipe out much of my spare time. In addition, an ubuntu update broke plasma/wayland for me, so I'm back on X11 and haven't had bandwidth to see if wayland is fixed now.
That's a long-winded way of saying: I can't fully test and verify this PR with my own eyes right now, but I don't want that to block merging it if it is ready!
Could you summarize the net effects of this PR? Are there any gaps? I can see that there are a couple of questions for me above, but it would help me if you could put them into context and maybe show me a couple of screenshots if that helps to explain whether they are conceptually blocking merging this, or are more along the lines of future enhancements? If you've already done that above, please re-summarize in a new comment as I'm a bit swamped with comments and notifications in general!
Thank you for working on this!
Hi! I'm excited by this PR, despite not having a lot of bandwidth: my recent country move continues to wipe out much of my spare time. In addition, an ubuntu update broke plasma/wayland for me, so I'm back on X11 and haven't had bandwidth to see if wayland is fixed now.
That's a long-winded way of saying: I can't fully test and verify this PR with my own eyes right now, but I don't want that to block merging it if it is ready!
Could you summarize the net effects of this PR? Are there any gaps? I can see that there are a couple of questions for me above, but it would help me if you could put them into context and maybe show me a couple of screenshots if that helps to explain whether they are conceptually blocking merging this, or are more along the lines of future enhancements? If you've already done that above, please re-summarize in a new comment as I'm a bit swamped with comments and notifications in general!
Thank you for working on this!
Hi @wez thank you for the reply. Yes, i believe this PR is ready to merge at the moment, i have been using this daily without any issues, and any issues that were reported have been successfully fixed and tested (also people have reported them as fixed)
Here are the effects of this PR:
- Completely switches to using sctk-adwaita for CSD frame. SSD frame is used only when decorations are set to NONE. Otherwise sctk-adwaita is preferred.
Smithay client-toolkit dependency was updated.
CSD (Integrated/No title):
CSD(Title):
That is basically the net effect of this PR, the commits are basically just adjusting the code, and fixing reported issues and making sure there are no gaps left.
2. Are there any gaps? There might be slight gaps, i have tried my best address all minor and major issues reported here. Although i did try to adjust my PR with the recent wayland merges, and i believe i have successfully adapted them as they were only 1-4 line fixes and no one reported any issues. I am talking about: https://github.com/wezterm/wezterm/commit/135b187fa85fc6a457f29f36c2a282dc4a97213a https://github.com/wezterm/wezterm/commit/c6f25ea3f99c0117fec61fe4260272f84310dc54
sctk dependency was updated as well, and i fixed the key repeating issue for compositors using wl_keyboard v10+. But i also kept the original implementation as a fallback mechanism for compositors that might not be using wl_keyboard v10+. 7511654
- Context about the question: "As of right now, by default the CSD frame does not draw any borders, i was wondering if i should add a decoration option to disable the border for wayland "WAYLAND_DISABLE_BORDER" and draw borders by default."
Frame border drawing disabled:
Frame border drawing enabled:
My question was basically, at the moment i completely disable the drawing of borders for the frame. If it is desired, i would be happy to submit a separate PR to implement a special option to disable/enable drawing borders for the CSD frame. This is out of the scope of this PR and does not block this PR in any way.
Summary of this PR: Successfully switch to sctk-adwaita to handle our CSD frame. SSD frame is preferred when decorations are set to "NONE".
UPDATE: drafted the pr until https://github.com/wezterm/wezterm/pull/7095#issuecomment-3487726973 is resolved to make the experience optimal for window managers and implement the correct behavior.