Plugin: Toplevel window absolute positioning for Wayfire

[froloffw7]

I have developed a custom Wayland protocol extension and supporting components designed for absolute toplevel window positioning under Wayfire.
As xdg-shell deliberately lacks absolute coordinate setters/queries, this project addresses tasks such as geometry restoration across application restarts and programmatic positioning of auxiliary UI elements relative to the screen.

The solution consists of a client-side patch for the GDK-Wayland backend of GTK3 and a compositor-side implementation that includes two distinct Wayfire plugins:

1. pos_restore — Automatically saves the last on-screen position of a window and restores it upon the next application launch. Note that this plugin operates independently and does not require the custom protocol or the GTK3 patch to function.
2. winpos — Implements the custom zwp_winpos_manager_v1 protocol extension to handle absolute coordinate setters and queries. This allows standard gtk_window_move() and gtk_window_get_position() calls to work as expected without modifications to the applications, but required GTK3 patch. For GTK4 the same patch is also possible to create.

Environment & Compatibility

• Compositor: Wayfire 0.11 (wlroots)
• Client Integration: GTK3 (3.24.x) via GDK patch
• Build System: Meson ≥ 0.51, wayland-scanner, wayland-protocols

Repository Structure

• proto/ — XML description of the zwp_winpos_manager_v1 protocol.
• src/ — Wayfire plugins: pos_restore (geometry restoration by app_id/title), winpos (protocol itself)
• test/ — Native Wayland client for isolated protocol testing, GTK3 test.
• patches/ — GTK/GDK-Wayland backend patch for GTK3.

The source code and initial release (v1.0.0) are available on GitHub:
https://github.com/froloffw7/wayfire-plugin-window_position

Feedback, testing results, and technical discussions regarding this implementation are welcome.

[soreau]

A little known fact is that Wayfire actually already allows clients to position their surfaces, but only for Xwayland windows. Unfortunately, the problem with patching toolkits is that going forward, you'd have to be able to deliver your patched version somehow and then clients that care would have to implement their handling. They would have to assume wayfire+gtk3, which is increasingly a narrow subset of usage, with gtk4 well under way. I think the common consensus is that Wayfire should position the clients as is expected in Wayland compositors. I would recommend exploring Wayfire's IPC interface, which would allow you to record client window geometry and restore it, based on criteria like app-id and title. You could write a file with the data to be persistent across sessions. If you have questions about Wayfire IPC, feel free to ask.

[froloffw7]

You are absolutely right about the maintenance burden of patching toolkits, especially with GTK4 adoption, and the confirmation of what I found while digging through the XWayland view code (handle_client_configure).

Regarding the IPC approach: pos_restore plugin actually operates very similarly to what you suggested. It runs entirely on the compositor side, tracking windows by app_id and titles to save/restore their geometry persistently, completely independent of the custom protocol and without requiring any GTK patches. It works out of the box for standard setups. Comparing with the existing place plugin it gives more flexibility to the user.

The second plugin (winpos) and the GTK patch were specifically created as a fallback for cases where active, client-side positioning (like runtime programmatic window movement initiated by the app itself) is strictly required by the user's workflow.

Thank you for the feedback.