Bug 514267 - Kwin doesn't restore snapped window position/geometry after maximize it
Summary: Kwin doesn't restore snapped window position/geometry after maximize it
Status: RESOLVED INTENTIONAL
Alias: None
Product: kwin
Classification: Plasma
Component: general (other bugs)
Version First Reported In: 6.5.4
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-01-07 11:24 UTC by Guido
Modified: 2026-01-08 14:09 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Guido 2026-01-07 11:24:58 UTC
SUMMARY
When a window is snapped to the edges of the screen and then maximised, its geometry and position are not restored when it is un-maximized.

STEPS TO REPRODUCE
1.  Open a window (i.e. dolphin) and snap it on the right border
2.  Maximize the windows
3.  Unmaximize the window

OBSERVED RESULT
The window is restored to the "saved" geometry/position before the snapping

EXPECTED RESULT
The window should be restored at the snapped state

USE CASE
In general, for consistency, unmaximization should restore the window to its last position/geometry, in this case the snapped one.
This is particularly useful when two windows are side by side, for example to compare files or copy and paste pieces of text, etc.
It often happens that you need to maximize one of the windows but then have to return to the previous situation. With the current behaviour, you are forced to snap again the previously snapped window each time.


SOFTWARE/OS VERSIONS
perating System: Manjaro Linux 
KDE Plasma Version: 6.5.4
KDE Frameworks Version: 6.21.0
Qt Version: 6.10.1
Kernel Version: 6.18.3-2-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 8 × 11th Gen Intel® Core™ i5-1135G7 @ 2.40GHz
Memory: 16 GiB of RAM (15.3 GiB usable)
Graphics Processor: Intel® Iris® Xe Graphics
Comment 1 Vlad Zahorodnii 2026-01-08 14:09:42 UTC
One can argue both ways about this, i.e. that the geometry should be restored back to the original value after leaving all the special modes.

Tiling has been working like this since it had been introduced, and changing it will upset people who are used to this behavior. Code-wise, everything is tied to a single saved geometry too. Making it configurable (to choose between two behaviors) is also easier said than done, that code is quite tricky already, we won't be able to manage even more complexity there.

The current behavior is pretty much intentional.