| Summary: | Positioning of windows in restored session doesn't work (Wayland session restore new protocol) | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Piotr Mierzwinski <piotr.mierzwinski> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | piotr.mierzwinski, strong.drum0546, xaver.hugl |
| Priority: | NOR | Keywords: | qt6, wayland-only |
| Version First Reported In: | master | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Piotr Mierzwinski
2025-04-27 21:24:51 UTC
Can confirm this on git-master, Arch Linux, amdgpu, Laptop with external screen via HDMI and internal screen enabled. The restored windows spawn on the external monitor, all centered. Apps still need to support it (In reply to Zamundaaa from comment #2) > Apps still need to support it So for every KDE apps needs to be added support for this feature? If so, then how this will work for non KDE apps, like Firefox? Saving size of windows works, but saving position doesn't. IMHO Nate's announcement was very misleading or not very precise, at least for me. Hi Piotr, thanks for taking the time and testing this out on such a recent system like Neon. That's really cool. I'm by no means an expert on this, but it seems that this is just one of the messy things inherited from the X11 era, where windows could place themselves and many making their own implementations on how they remember position. Nate has written an explanation about this, giving some background about how positioning windows is different in X11 than in Wayland: "Native Wayland windows are not allowed to determine where to place themselves on screen at all; the compositor does this." https://invent.kde.org/ngraham/canned-responses#user-reports-that-wayland-app-doesnt-remember-its-window-position-observes-that-it-works-on-x11-for-them-and-requests-an-explanation-of-why-theres-a-difference From my first tests, a possible solution (not remembering per se but an initial positioning on session start) for us users could be System Settings > Window Management > Window Rules > Add new... > Detect Window Properties and click the window which position you wish to be enforced. Click the Plus and check mark buttons on Window class, Position, Size etc. Haven't tried this for Firefox windows but I imagine it's difficult identifying your three different windows. Maybe this helps you, it did for me. *** This bug has been marked as a duplicate of bug 15329 *** (In reply to Lenzoid from comment #4) > Hi Piotr, thanks for taking the time and testing this out on such a recent > system like Neon. That's really cool. I'm by no means an expert on this, but > it seems that this is just one of the messy things inherited from the X11 > era, where windows could place themselves and many making their own > implementations on how they remember position. > > Nate has written an explanation about this, giving some background about how > positioning windows is different in X11 than in Wayland: > > "Native Wayland windows are not allowed to determine where to place > themselves on screen at all; the compositor does this." > > https://invent.kde.org/ngraham/canned-responses#user-reports-that-wayland- > app-doesnt-remember-its-window-position-observes-that-it-works-on-x11-for- > them-and-requests-an-explanation-of-why-theres-a-difference > > From my first tests, a possible solution (not remembering per se but an > initial positioning on session start) for us users could be System Settings > > Window Management > Window Rules > Add new... > Detect Window Properties > and click the window which position you wish to be enforced. Click the Plus > and check mark buttons on Window class, Position, Size etc. Haven't tried > this for Firefox windows but I imagine it's difficult identifying your three > different windows. Maybe this helps you, it did for me. > > *** This bug has been marked as a duplicate of bug 15329 *** Thank you for work around. I will test it. Your previous answer "Apps still need to support it" means that the support will be provided in the future (maybe in Plasma 6.4 yet)? Anyway I hope so, because now we have regression compare to Plasma 5 or Plasma 6 and X11 session and soon we will have 6.4 version... [Nate] "Native Wayland windows are not allowed to determine where to place themselves on screen at all; the compositor does this." I'm confused a bit. Firstly you said that applications need to support it, and Nate saying that "the compositor does this.". So how exactly is? I found that doesn''t it (windows position seem isn't save) and reported it, because I supposed that "the compositor does this." (In reply to Piotr Mierzwinski from comment #5) > Your previous answer "Apps still need to support it" means that the support > will be provided in the future (maybe in Plasma 6.4 yet)? For KDE apps, yes. There is an implementation in Qt, though I don't know in which version it'll land. > [Nate] "Native Wayland windows are not allowed to determine where to place > themselves on screen at all; the compositor does this." > I'm confused a bit. Firstly you said that applications need to support it, > and Nate saying that "the compositor does this.". So how exactly is? > I found that doesn''t it (windows position seem isn't save) and reported it, > because I supposed that "the compositor does this." The compositor has control over window positioning, but applications still need to provide information about which window corresponds to which window of the previous session. > The compositor has control over window positioning, but applications still need to provide information about which window corresponds to > which window of the previous session.
So how this will be solved in non KDE application, i.e. Firefox?
They (applications) will be patched by persons making packages for given distribution?
Or maybe such application will positioned at central of screen, like now is happen for all?
|