Suite / XNote Placement / Window placement on Wayland
Why Wayland will not let an app place its own window
Not an oversight, not a missing feature, and not something the application can fix.
If an application used to reopen its windows where you left them and stopped when you moved to Wayland, this is why — and why the fix cannot live in the application.
The protocol has no way to say it
Under X11 a client could call XMoveWindow and put itself anywhere, on any screen. Wayland has no equivalent, and this is deliberate rather than unfinished: a surface is given a size by the compositor and has no say in where it is placed, which monitor it lands on, or which workspace it appears in. A client cannot even ask where it currently is.
The reason is the same one behind the screenshot rules: on X11, self-placement was indistinguishable from a window shoving itself in front of whatever you were doing. Removing the capability removes a whole class of misbehaviour, and it hands window management back to the thing that actually knows about your monitors, your workspaces and your focus — the compositor.
The cost falls on well-behaved applications with many small windows. A sticky-notes program, a floating palette, a tool window: each one knows exactly where it should go and has no way to get there.
Why the usual workarounds do not work
"Just remember the geometry"
An application can save size and restore it — size is negotiated with the compositor. Position is not part of that negotiation at all, so half the state round-trips and half is silently dropped.
"Use a protocol extension"
There are protocols for placing surfaces relative to another surface you own — menus, tooltips, popups. There is none for absolute placement of a top-level window, because that is the capability being withheld.
"Fall back to X11"
Running under XWayland restores the old behaviour and gives up everything the native port was for: fractional scaling, correct input on mixed-DPI setups, and the rest. A regression dressed as a fix.
"Let the compositor remember"
Mutter has no general window-position memory, and no setting to add one. This is the gap.
What has to live in the compositor
If placement is the compositor's job, then window placement memory is a compositor feature too — and on GNOME, a Shell extension is how you add one. XNote Placement is that for XNote's sticky notes: it records each note's position, monitor and workspace as you move it, and puts the note back when it opens again after a login or a restart.
Describing it that way makes it sound trivial. It is not, and the interesting parts are all consequences of working from the compositor side, where you have windows rather than application objects.
Three problems you only meet from this side
A window has no identity
XNote's pads are plain windows; the compositor sees no note id. The extension reproduces each note's title from the first line of its file and matches on that, so the record survives restarts — and a note it cannot match confidently is left exactly where the compositor put it, rather than guessed at.
Monitor indices are not stable
An index reshuffles when a display wakes late or a KVM switches inputs, and two identical panels cannot be told apart by model. Monitors are keyed by serial number first. A note whose monitor is gone stays on screen, clamped into the work area, instead of being restored off-canvas.
A new window is not where it will be
A fresh XNote window is 0×0 for roughly its first 90 ms, and mutter places it twice before it settles. Reading the position too early records nonsense; a fixed delay is a guess that breaks on a slower machine. The extension re-asserts the stored place and records nothing until the window has converged.
What this means if you hit the same wall
The general shape transfers to any application with this problem on GNOME: the application keeps what it legitimately owns — the note, the document, the size — and a small extension owns the placement, keyed by something stable that the compositor can actually observe. The two halves ship separately because they run in different processes with different privileges, which is also why the extension is worth reading before you install it: it is a few hundred lines, it has no network functionality, and its state is one small file.
The limits are worth stating plainly. It is GNOME Shell 50 on Wayland; it does nothing on X11, where the application never had the problem; and a title-matching heuristic is a heuristic, which is why the failure mode is "left alone", not "moved somewhere wrong".
- XNote Placement — what it does, install, where your data lives
- How it works — the storage format, the timing measurements, and why this is an extension rather than a feature of XNote
- XNote — the sticky notes themselves, native Wayland since 3.0