Bug 283925

Can't attach the screencast (1.6 MiB, size limit 1.0 MiB): http://oserv.org/bugs/kwin-bug.ogv

I can reproduce this problem in the following setup:

Primary monitor: 1920x1200
Secondary monitor: left of primary, 1680 x 800, rotated 90 degrees (it's
vertical)

Whenever maximized windows are moved from the second monitor to the first, they
exhibit the behavior shown, i.e. they immediately maximize to full width and
they are not resizable, unless using window settings or editing settings
manually.

s/tastbar/taskbar/

Sorry.

This also equally happens with height (if width is not full-sized).

Steps to reproduce are the same: open a window, move it to the bottom, resize it upwards so it's real height will be greater than screen height. The width should be normal (half the screen width, for example). Close the app and start it again. Window now can can't be resized or moved in vertical direction, but can in horizontal.

Thanks for the report.

The KWin developers are actually aware of this behaviour.
It's currently just not clear whether this was supposed to be a feature (intended behaviour) and for what reason or simply a bug, but that will be sorted out before the 4.8 release.

The window is simply maximized in that direction (right resp. middle click the maximize button to unset that flag)
This constrain for windows that map beyond screen dimensions has always been in place (to ensure the window has borders on screen and can be resized by joe user w/o alt+rmb) but the fixed position of such windows is new.

*** This bug has been marked as a duplicate of bug 283302 ***

This is not just a duplicate (but it depends on that bug).

If you read the description, you can see, that i did not intentially maximize window in horizontal direction, it got maximized by itself.

This is the main issue in this bug.

The problem is that if an app was closed with window size > screen size, it gets partially maximized on the next start.

You can (and should) fit the window to the screen, if the screen size is less that the window size in applicationrc, but don't do partial maximize! A normal maximize is ok, if the fitted window has exact same dimensions as the screen.

The proper solution would be storing ("maximized" | "maximized horizontally" | "maximized vertically") as a separate flag in applicationrc, but not on the same fields as width/height.

A hackish, not complete solution would be doing partial maximizing only if the window size in applicationrc equals exactly to screen size + 1 (it is stored that way), but not if it equals to screen size + 10, screen size + 20, or anything else. This would make the probability to set such configuration manually very small (but not zero).

While it *might* appear differently from a users POV, this /is/ the very same bug.

a) Windows opening with dimensions beyond the screen geometry have ever since been constrained and set maximized in this direction.
b) 2-dimensionally maximized windows can actually be
 - not movable at all
 - fully movable (just as onedimensionally max'd, depends on whether they show frames)
 - moved to unmaximize ("quick maximization")
c) since 4.7 the maximization state is completely independent from any geometry, i know that because it was me who changed kwin in 4.6 and 4.7 in this regard - the maximization state setting apart this has been in place before and is intentional.
d) what you experience as "snap back" was only supposed to happen if windows are moved to another screen. (see comment #6)

Last: since you've apparently no deeper insight on this, i'd very much appreciate if you trust my decision on the state of the bug and in doubt always feel free to just ask "why" (since i could always be wrong) - but please do not change such attributes on your own if you're not absolutely sure that they're wrong. Thank you.

*** This bug has been marked as a duplicate of bug 283302 ***