Bug 514267

Summary:	Kwin doesn't restore snapped window position/geometry after maximize it
Product:	[Plasma] kwin	Reporter:	Guido <guido.iodice>
Component:	general	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED INTENTIONAL
Severity:	normal	CC:	guido.iodice
Priority:	NOR
Version First Reported In:	6.5.4
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

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.