Applications remain the same size as when you drag them to tile the window. If you don't close the application, it will return to that size when you drag it, but if you close it, it remains that size. If you close the window while it is tiled like that, it should open in its default size. Tiling a window to half the screen is usually for a specific use, and after that use is done, you don't need the window to remain like that. Reproducible: Always Steps to Reproduce: 1.Click and drag window to side screen edge to tile 2. Close window 3. Open same application 4. Drag window away from screen edge Actual Results: Window remains in the tall/skinny size instead of returning to its size before tiling. Expected Results: Return to original size
this is more or less "INVALID" the window manager does not maintain sizes across "closing" and reopening (in meaning of destroying, not unmapping) windows; the client picks a size to startup with (remember the common --geometry parameter) For kmainwindow, the way it stores sizes and states is utterly hackish anyway and needs to be fixed for PW/2 ("kde5") anyway. What the WM *could* do was to restore the untiled state when it knows the window will close. pitfalls: - operating on actual release is likely too late - the client will have stored its size before - operating on the close button will be inconsistent (compared to closing from inside the client) and cause false positives (if the client intercepts the event to move to systray) proper solution would be for clients to re/store the tiling as the maximization state (requires netwm upgrade) the only other solution was to guess the tiling from the size, but we can't just quarter tile every client that randomly picks that size...
> For kmainwindow, the way it stores sizes and states is utterly hackish anyway kwin can have many states and sizes for each window (tiled/normal/maximized/partially maximized/full-screened/auto-tiled/auto-snapped/etc.). Ideally kwin provides API to save/restore the window state (e.g. to a single opaque QByteArray). QMainWindow could then use this API when saving/restoring.
(In reply to comment #2) "hackish" is more about the current way to store the maximization state as "oversized". Ultimately, the state needs to be exported as window property (maximization states are, tiling would be required - thus the required (proprietary) netwm upgrade) and read/re/stored by KMainWindow. See bug #324957 and linked bugs. > API to save/restore the window state (e.g. to a single opaque QByteArray). > QMainWindow could then use this API when saving/restoring. Drawback: "kwin only". Fails on other DEs, WMs (and other clients had to either link that feature or lack information about tiling states)
> > API to save/restore the window state (e.g. to a single opaque QByteArray). > > QMainWindow could then use this API when saving/restoring. > > Drawback: "kwin only". Fails on other DEs, WMs (and other clients had to > either link that feature or lack information about tiling states) not a huge drawback - we might be able to inject it through our QPA and make it dependent on whether KWin is active or not. That way it would affect all Qt applications would not be dependent on KMainWindow and give correct behavior with KWin and other window managers.
*** Bug 387812 has been marked as a duplicate of this bug. ***
*** Bug 374154 has been marked as a duplicate of this bug. ***