Bug 296171 - Partial maximization state destroyed for fully maximized windows
Summary: Partial maximization state destroyed for fully maximized windows
Status: CONFIRMED
Alias: None
Product: kwin
Classification: Plasma
Component: core (show other bugs)
Version: git master
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 317760 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-03-16 18:57 UTC by Christoph Feck
Modified: 2022-04-17 20:05 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Feck 2012-03-16 18:57:04 UTC
I have setup window rules for Konqueror and Konsole to start in partial maximized mode. When I now fully maximize a window by clicking on the Maximize button, and later restore it by clicking that button again, the window is not restored to partial maximization, but to non-maximized mode.

This is a fairly recent regression in master (3 days or so).
Comment 1 Martin Flöser 2012-03-16 19:00:11 UTC
the one man's bug is the other man's feature :-)

http://quickgit.kde.org/index.php?p=kde-workspace.git&a=commit&h=2b3bcb59586a40636e0d5f97c5d0d083945bdba7
Comment 2 Thomas Lübking 2012-03-16 19:03:35 UTC
there's also another report claiming the restore button to be some sort of "back in history" button failing on some other occasion (because it is actually not)

We may have to clarify the nature and point to the onedimensional un/maximization.
Comment 3 Christoph Feck 2012-03-18 02:25:10 UTC
Thanks for the clarification, I did not know that the new behavior was intended.
Comment 4 Victor Mataré 2012-09-11 13:32:24 UTC
Hm, interesting. Felt like a regression to me, too. The thing is, I expect the restore button to restore the window to the size it had before it was maximized, simple as that. That's easy to understand and it's obvious.

Whereas the new behavior is inconsistent: If I drag the window size to V-Maximized size, then maximize, then restore, I get the previous (V-Maximized) size. If I use the V-Maximize command, then maximize, then restore, I get the size I had before V-Maximize.

What's even worse is windows that are created filling the screen vertically, but not horizontally. In this case it seems they are set to V-Maximized state, but before that no size is known. Then if I maximize and restore, the window is set to some arbitrary size (which seems to be hardcoded).

This is bad behavior since it's complex and it requires the user to reason about which state the window was in when Maximize was clicked. And the state of the window is not visually discernible: For a vertically maximized window, there are three different possible outcomes of the maximize-restore sequence:
1. The window was started in that size -> restored to arbitrary (hardcoded) size
2. The window was dragged to that size -> restored to previous size (expected behavior!)
3. The window was V-Maximized -> restored to size before V-Maximize

So I need to remember what I did with that window before clicking Maximize to know what will happen when I click Restore. I think it should be obvious how that's distracting and counterintuitive, so please consider reverting 2b3bcb59586a40636e0d5f97c5d0d083945bdba7.
Comment 5 Victor Mataré 2012-09-11 13:48:10 UTC
Addendum: I do recognize the issue behind bug #195576. But I'm sure there's a solution to both of these problems that results in intuitive and expected behavior. Maybe I need to make up my mind come up with something. Having looked at #195576 just now, I realize reverting may be a bad idea as well, but it also shouldn't stay like this forever ;-)
Comment 6 Thomas Lübking 2012-09-12 18:49:11 UTC
(In reply to comment #4)
> Whereas the new behavior is inconsistent:
"no"

> If I drag the window size to V-Maximized size
false assumption.
QuickTiled windows are not unilaterally maximized, they just randomly cover the screen height.
"Problem" here is that you can drag a v'maxed window into QTLeft and when withdrawing the v'maxed state on dragging it out, you'd restore to the wrong dimension.

> What's even worse is windows that are created filling the screen vertically,
> but not horizontally. In this case it seems they are set to V-Maximized
yes, really old kludge because KMainWindow does not really store the maximization state, so on window mapping (only) a "covers screen" geometry is interpreted as maximization in resp. direction.
This *needs* to be fixed in KMainWindow for frameworks (or we need a feature break exception for 4.10) - not only for this reason.

The idea behind bug #195576 is, that the maximization is a flag and the plain left click sets/withdraws it in both directions (with precedence to setting)
Comment 7 Thomas Lübking 2013-04-03 08:31:39 UTC
*** Bug 317760 has been marked as a duplicate of this bug. ***
Comment 8 Grósz Dániel 2022-04-17 20:05:40 UTC
This should be configurable. For some user preferences, the current behavior is annoying (while the other bug's comments show that some people prefer the current behavior). With the wide screens common today, I use vertically maximized windows a lot, and frequently toggle between the vertically maximized and the fully maximized state (especially with browser windows). The easiest-to-activate action (double-clicking the title bar) should toggle between those two states when starting with the vertically maximized state.