Skip to content

CI dry run: gtk4 branch#1

Draft
johncarmack1984 wants to merge 23 commits into
devfrom
gtk4
Draft

CI dry run: gtk4 branch#1
johncarmack1984 wants to merge 23 commits into
devfrom
gtk4

Conversation

@johncarmack1984

Copy link
Copy Markdown
Owner

Fork-internal dry run of the full workflow matrix for tauri-apps#369. Not for merge.

johncarmack1984 and others added 3 commits July 7, 2026 13:26
Builds on the feat/gtk4 backend: brings in the extension work from
rmakestrash's fork and adapts everything to dev's current API, so the
public surface stays what dev ships today and call sites compile
unchanged.

- gtk4 0.11 and png 0.18, MSRV 1.92 to match gtk4's floor
- the gtk dependency is optional behind a `gtk` feature (part of
  default) with dev's BSD-wide target cfg; `libxdo` stays as a no-op
  feature name for compatibility
- shared modules follow dev's current API (the KeyAccelerator line);
  the only changes there are the feature and target cfg gates
- backend methods keep their gtk3 names and shapes; only widget types
  move with the toolkit (Menu to PopoverMenu, MenuBar to
  PopoverMenuBar, Container bounds to Widget)
- predefined item accelerators are wired on gtk, matching macOS
- KeyAccelerator::to_gtk covers the Key-based accelerator path

Co-authored-by: amrbashir <github@amrbashir.me>
Co-authored-by: rmakestrash-jpg <rmakestrash-jpg@users.noreply.github.com>
GTK4's PopoverMenu does not render icons set on a gio::MenuItem, which is
why menu icons were blank on the gtk4 backend. Mark icon items with a
`custom` attribute and bind an icon+label widget (a flat button carrying
the item's action) via PopoverMenu/PopoverMenuBar add_child; the binding
reaches nested submenu slots too. Context menus rebuild on show so label,
icon, and checked-state changes are reflected instead of showing a stale
first build.

Verified headless (xvfb) with a menu whose icon and label are mutated
live: the icon renders and updates, addressing the icon issue tracked in
tauri-apps#270.
The runners need libgtk-4-dev next to the existing gtk3 packages,
which stay for the tao and wry dev-dependencies. The test job's
pinned toolchain moves to 1.92 to match the crate's MSRV, set via the
action's toolchain input because dtolnay/rust-toolchain has no 1.92
tag.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants