Summary: | KWin should export the tiling state for clients which should restore either tiling or the pre-tiled size | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | enoopt.adams |
Component: | core | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | CONFIRMED --- | ||
Severity: | wishlist | CC: | cfeck, L.Bonnaud, nate, postix |
Priority: | NOR | ||
Version: | 5.22.1 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
See Also: | https://bugs.kde.org/show_bug.cgi?id=374154 | ||
Latest Commit: | Version Fixed In: | ||
Bug Depends on: | |||
Bug Blocks: | 428272 |
Description
enoopt.adams
2013-10-03 02:02:14 UTC
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. *** |