feat(linux): port to gtk4#1258
Conversation
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
Thanks for the PR but I should let you know that I am working on alternative that uses current winit code base at https://github.com/tauri-apps/winit-gtk4/tree/amr/feat/gtk4 I don't know yet but there is a good chance will be using winit-gtk4 instead of porting tao to gtk4 |
|
winit-gtk4 on the winit codebase makes sense to me. If that's the direction, happy to help over there instead. point me at what needs doing. No attachment to this specific PR; whatever transfers (the muda side, the headless test setup), transfers. My only aim is resolving the security warnings. |
The gtk4 port as inherited: started in tauri-apps#1104, continued with the rebase to 0.34.5, the optional libadwaita feature, the gtk::init ordering fix, and the no-x11 compile fix. Co-authored-by: Conrad Hale <halec5@mail.uc.edu> Co-authored-by: rmakestrash-jpg <rmakbox@gmail.com> Co-authored-by: Aurélien Jacobs <aurel@gnuage.org>
Package Changes Through 1879ad8There are 1 changes which include tao with minor Planned Package VersionsThe following package releases are the planned based on the context of changes in this pull request.
Add another change file through the GitHub UI by following this link. Read about change files or the docs at github.com/jbolda/covector |
dtolnay/rust-toolchain has no 1.92 tag, so the version ref fails to resolve; @master with the toolchain input is the documented form for untagged versions.
|
if we use tao (in the beginning*) instead of winit then i wonder if it makes sense to put it behind a feature flag and have gtk3 and gtk4 side by side for a while. That would make migration in wry and tauri a bit easier i think and would potentially make a 2.x release possible. Alternatively we could release tao gtk4 as 0.50 or something but having to deal with to release trains kinda sucks. * in the beginning: i'm not sure about winit-gtk4's, and more importantly winit 0.31's timelines so perhaps it makes sense to start the gtk4 migration with tao and then later on migrate to winit. That would allow us to move a bit quicker. If we don't even want to consider a 2.x tauri (pre)release than this doesn't matter i guess. |
|
@FabianLars The flag is realistic. Everything gtk-facing lives in platform_impl/linux plus the unix extension traits, so the shape would be: today's backend moves to linux/gtk3 unchanged, this port lands as linux/gtk4, mutually exclusive features with gtk3 as the default, compile_error! on both or neither. CI grows a second linux leg. Current users see zero change until they opt in. Two caveats. The unix extension traits expose gtk types, so those signatures switch with the feature. wry and tauri cross that seam either way, the flag just makes it opt-in. And gtk4 dropped the global-position APIs, so outer_position and set_always_on_bottom go unsupported there. Side by side means nobody inherits that until they choose it. The RUSTSEC warnings only clear for builds that opt in, so I'd call the flag the migration path rather than the fix. For tauri the same flag would need to travel through wry and muda (tauri-apps/muda#369 can take the same shape), plus tray-icon for apps that use it. Happy to restructure this PR that way if that's the direction. The port is done, so what's left is layout and plumbing. |
|
disregard my feature flag idea. i was overruled. |
|
No worries on my end; the backend is identical either way, so nothing here is wasted. Feel free to take this PR whole, in parts, or not at all, whatever fits the v3 shape. Happy to grab whatever other gtk4 migrations are needed to get tauri past gtk3, whether it's tauri v2.x or v3+ |
4 participants
Closes #1051. Supersedes #1104. This takes @conradhale's GTK4 port and @rmakestrash-jpg's continuation of it (rebase to 0.34.5, the optional libadwaita feature, the
gtk::initordering fix, plus @aurelj's no-x11 compile fix), merges everything onto current dev, and bumps the stack to gtk4-rs 0.11 / glib 0.22. Their commits carry their authorship in the branch history; my work is the forward merge, the 0.11 bump, and CI.Discussed in tauri-apps/wry#1474. gtk4 0.11 here matches @Ranrar's wry gtk4/webkit6 branch, so the two can land as a coherent pair.
What the forward merge had to reconcile, so nobody has to re-derive it in review:
Windowfields.portal.rsis rewritten from glib channels (removed in glib 0.20+) to async-channel, matching how the port already moves events. The dummy-windowSetThemearm now emitsThemeChangedlike upstream.Keyconstants.Propagation::Proceedchanges are gtk3-signal-specific. GTK4 event controllers neither swallow decoration events nor double-deliver, so the port keeps its plain controllers. The xdg_surface buffer-size workaround is likewise replaced by the port's existing maximize process.Breaking, beyond the obvious type swap: public gtk types in the Unix extension traits are gtk4 0.11 types; the
x11feature is backed by gdk4-x11; new optionallibadwaitafeature; MSRV rises to 1.92, gtk4-rs 0.11's floor. The MSRV bump is crate-wide, not Linux-only, and it's the one call here I most want maintainer eyes on.Verified:
cargo check --all-features,clippy --all-targets(lib clean; the two remaining lints are in examples unchanged from dev), andcargo test, on rust 1.96 / Debian trixie / GTK 4.18. Both things this draft was waiting on have since happened: tauri itself builds against this branch (wry on webkit6, muda on gtk4), and a real Tauri app runs on it under X11 -- window creation, the event loop, and keyboard input all through this port. The menu in this capture was opened by key events going through the gtk4 event controllers:Wayland session time is what's left.