Version: git master (using Devel) OS: Linux Started happening some time ago. Can be disabled through the plasma tastbar, or through editing «Width 1920=1921» line in applicationrc. Reproducible: Always Steps to Reproduce: Set the window width > screen size. Restart the application. Actual Results: See video. Expected Results: Application should be movable and resizeable. If you allow full-width, but not full-screen applications. they should behave exactly as full-screen. They should not move or resize in that direction at all, but not jump back (as you can see in the video). That's confusing. There should be a checkbox in the window menu to disable full-width. It should not be possible to trigger full-width by simply resizing and moving a window. Storing fullscreen windows like width=screenwidth+1 and allowing full-width, but not full-height windows at the same time seems to be a bad decision. Anyway, i don't see a point in full-width, but not full-screen windows at all.
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 ***