#linux window position workarounds

24 messages · Page 1 of 1 (latest)

lusty hull
#

Are there any known workarounds for being able to set the position of a window on linux/wayland?

After lots of research trying to figure out why tauri::Window::set_position isnt working for me, I've found that its just not-supported / silently no-ops on wayland. Have there been any other attempts to work around this to be able to set a position or anchor for the window on linux?

sidebar; I made a bug to track this silent no-op https://github.com/tauri-apps/tauri/issues/14913

tauri info:

[✔] Environment
    - OS: Linux 18.0.0 x86_64 (X64) (zorin on wayland)
    ✔ webkit2gtk-4.1: 2.50.4
    ✔ rsvg2: 2.58.0
    ✔ rustc: 1.93.0 (254b59607 2026-01-19)
    ✔ cargo: 1.93.0 (083ac5135 2025-12-15)
    ✔ rustup: 1.28.2 (e4f3ad6f8 2025-04-28)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (overridden by environment variable RUSTUP_TOOLCHAIN)

[-] Packages
    - tauri 🦀: 2.10.2
    - tauri-build 🦀: 2.5.5
    - wry 🦀: 0.54.1
    - tao 🦀: 0.34.5
    - tauri-cli 🦀: 2.10.0

[-] Plugins
    - tauri-plugin-positioner 🦀: 2.3.1
    - tauri-plugin-fs 🦀: 2.4.5
    - tauri-plugin-opener 🦀: 2.5.3
    - tauri-plugin-log 🦀: 2.8.0

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../frontend/dist
#

Somewhere in my research someone said one can work around this by creating a very large Wayland window and a smaller surface inside of it. But that layer is buried so deeply in the dependency chain that it seems inaccessible.

torpid jasper
#

I made a bug to track this silent no-op
Would throwing an error really be better? We should definitely update the docs though, weird that we didn't include that considering we have it in tao.

#

But yes, this is an intentional design choice of wayland so there's really nothing we can do.

lusty hull
#

I've found an alternative by consulting the Rust GameDev server

torpid jasper
lusty hull
#

it unforunately does mean making or installing gnome extensions

#

and some additional functionality once i figure out how a gnome extension can put a window into "always on top" mode

torpid jasper
#

hmm, if your app is only supposed to work on Gnome that could work yea

lusty hull
#

Yeah its a personal project. I can special case the code to detect Gnome+Wayland and deplay this requirement. Its just more work that ideally wouldnt be needed at the application level

#

but it wouldve been easier to figure out if tauri threw an error back at me

torpid jasper
#

noted

lusty hull
#

i'll post back here with my findings (if i remember) once i have this all figured out.

lusty hull
#

Okay I have confirmed window-calls works for moving a window and adding make_above functionality to it was easy.
Now I'll just have to figure out if I can automatically install, document the dependency, and perhaps PR into original repo with changes.

lusty hull
#

Unfortunately, tauri does not expose a way to get the raw window id stored in Detached window. So the best I can do for now is to find the window by name using gnome extensions.

indigo ember
#

Can you look into how the Gnome extension gets the window IDs are write a simple wrapper around that in Rust so it works across different DEs, eg. KDE, Cosmic, etc.?

lusty hull
#

Yeah I'll post back here once I have something working. Probably won't support multiple distros, but that's what open-source collabs are for

indigo ember
#

Hah yeah, that makes sense. There's probably a way to get the window ID from the process spawning within the Tauri core/plugin code, but I've not looked into this part of the application yet. I've been trying to wrap my head around notifications on mobile first. The Rust core has access to the OS APIs so that's probably the most conistant cross DE/Platform way. When you get something working it will be interesting to see what you did!

lusty hull
#

its working locally in my project, but has not been wrapped by a dedicated crate yet

lusty hull
#

that pull request was merged into the window-calls gnome extension repo

lusty hull