Feat/native wayland - #11
Open
lunar-seal wants to merge 8 commits into
Open
Conversation
Co-Authored-By: GPT-5 Codex <noreply@openai.com>
Co-Authored-By: GPT-5 Codex <noreply@openai.com>
Resizable/maximizable/minimizable/closable, min/max size, and always-on-top now reach the CEF window delegate instead of being dropped, and frameless native Wayland windows get Tauri's data-tauri-drag-region CSS behavior via CEF's draggable-regions API. Co-Authored-By: GPT-5 Codex <noreply@openai.com>
The CEF Views/Ozone-Wayland windowing path is a parallel, less-hardened alternative to the default X11 embedding path this crate has years of focus/embedding fixes behind: single window, single webview, no raw window handles, no runtime decoration changes. Sable, the only current consumer, already treats the entire CEF runtime as opt-in via its own `cef` Cargo feature (mirroring `wry`); this crate itself already gates other non-default surfaces the same way (`devtools`, `sandbox`, `macos-private-api`). Gate LinuxWindowing::Wayland and the native_wayland module the same way so a consumer has to explicitly opt in before this experimental path is even reachable, instead of it being silently compiled into every Linux build. Also drops a few `.clone()` calls on Copy types in native_wayland.rs that clippy flags once the native-wayland feature actually gets built. Co-Authored-By: GPT-5 Codex <noreply@openai.com>
Author
|
Now it seems to work great. A wayland limitation will be the absence of window decorations, but we could just display a native looking thing up top. |
- remove winit/x11 references - sanity check implemented functionality - limit impact on X11 backend to more or less zero
lunar-seal
force-pushed
the
feat/native-wayland
branch
from
August 27, 2026 15:20
bb64af4 to
aad7f99
Compare
lunar-seal
marked this pull request as ready for review
August 27, 2026 15:21
Author
|
This should be sensible/maintainable now and be decoupled from the existing code. |
lunar-seal
marked this pull request as draft
August 28, 2026 07:54
Author
|
It's maybe possible to completely remove the cef polling too but I need to look at it properly |
lunar-seal
marked this pull request as ready for review
August 28, 2026 16:57
Author
|
I don't want to have too much complexity in one step. |
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Using wayland would have all kinds of benefits, such as performance, always perfect support for fractional scaling, and the polling hack for the focus tracking is not needed.
Funnily enough, while using CEF in chrome mode and then evening using the chrome native message pump, nothing relies on the tauri window being the parent of the chrome window. This means the cef views framework could be used.
Wayland support for the views framework has been available for a while: https://www.collabora.com/news-and-blog/blog/2019/05/08/cef-on-wayland-upstreamed/
So introducing wayland support isn't that hard. Tauri doesn't do this because they have to support all kinds of cases, fortunately Sable only needs this single top level window for now.
I instructed gpt 5.6 sol to implement this alongside the current X11 path and it turned out to be a pretty solid proof of concept. The basic chat experience works.
Although, there are a lot of things not working like opening links in the native browser.
Also, some cleanup is needed to avoid duplicating the entire logic on window events.
Another idea could be to just fully use the views framework for both X11 and Wayland, as the upstream approach does way more than Sable probably ever needs.