| Summary: | maximized xterm doesn't cover the whole screen (KDE4.6 regression, KDE4.5 was fine) | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Roc Vallès <vallesroc> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | cfeck, draggor, drew.m.fisher, flateric, nucrap |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Supposedly maximized xterm window (not really maximized) | ||
I can confirm this behavior in the Fedora 4.6.0 packages. I'll add that there's an interesting interaction of this bug with window tiling: when compositing is enabled, window tiling is enabled (I use the spiral layout), and the xterm window is on a virtual desktop of its own (which, with tiling enabled, would maximize the window), the xterm window becomes completely invisible. No window decoration, nothing. You can still interact with it; it's just not displayed. Floating the window restores its visibility (since it is not longer maximized). Might be related to the change for gvim. @Thomas what do you think? As a fast workaround: use Konsole, that works correctly. And just to let you know: this is an xterm bug, not a kwin bug. Looks like gvim also has this same bug, then. It exhibits the same behavior as xterm (window goes invisible when tiled fullscreen with desktop effects). Does this hold true for any window that is resizable, but forces its dimensions to match an exact multiple of a certain increment? Perhaps such windows should always float when tiled. It's result of a "strategy change" in that code, yes (the treatment of non atomic increment requests + maximizing + rules was pretty arbitrary/confusing) and Drew is right in the second paragraph of comment #3 XTerm set's a non atomic resize increment (6:14 here, but i guess it depends on the font - at least it's not 1:1) This is (now) in general honored (also when attempting to maximize the window), but can (now successfully ;-) be overridden (in general) by a specific window rule (workarounds/"strictly obey geometry"/do NOT check the last box - the dialog needs general improvement, btw.) Once this is done, the window is (successfully) maximizable and (in case of gvim/emacs) shall stay maximized, even if the client will try to unmaximize/resize (this does NOT require to rule "ignore geometry requests", so the client can usually adjust its size if it feels like) - what caused the emacs (and gvim i think) "unmaximizability". Rational: - The flag as set by clients like xterm or gvim is (either and usually) pretty much pointless because there won't be any regression. the client can perfectly handle the "oversizie") or - if /really/ required - should always apply (also to "maximized" windows). Candidates for the latter are clients that "invalidly" stretch their content with the window (try mplayer for one) - If the user wishes to be able to and to maximize a client, it should however stay like this (and not be auto-unmaximized and then resized by veery smart clients attempting to "fix" their geometry) I guess it /would/ be possible to auto-ignore strict geometry for clents who attempt to maximize unless overridden by a rule, but to me that frankly sounds like special casing the wrong kind of client. (But i'm not the maintainer ;-) So to sum up: --------------- - no feature is gone - you will however have to add a "workaround" rule in order to maximize (ie. apply an arbitrary geometry to) clients with fixed aspect/grow dimension - the new behavior is more consistent (either arbitrary size or not) - whether the old one should be (fixed and) reverted -> Martins choice ;-) - tiled windows have to deal with this case anyway (since whether by rule or default - happen it can :-) *** Bug 267963 has been marked as a duplicate of this bug. *** Just curious, how do other window managers handle the request for incremental geometry? If I want my window size to be resized in 10x10 steps, I cannot resize it to 1024 pixels wide (full screen)... So the window manager has to: * ignore the increment, and go full screen (1024 pixels wide) * ignore the full screen request and only use 1020 pixels * try to handle both, and fill the remaining 4 pixels with blank (gray? black?) ::limiting "others" to "compiz or openbox" ;-) - Openbox acts as kwin used to and ignores geometry restrictions for maximized windows. This however leads to stretched windows (because the aspect is ignored) what's pretty nasty in the case of video players. - Compiz acts like kwin currently does but can do the restore (as provided by the review request mentioned in bug #267963) I came along this when fixing emacs "i fix myself" issue and figured that the client should set these restrictions either for a good reason (aspects in the case of video players) or not at all (it's pretty pointless in the case of xterm and friends). Another option would have been to ignore the baseincrement but honor the aspect for maximization attempts - but kwin only provides one rule that would then cover (baseincrement , aspect) x (maximized, normal) ... :S My personal preference is to honor the restrictions by default but unlink the maximized state from the geometry (forecasting some sort of "zoom" feature) - but we're still discussing the best way ;-) Git commit 44795854aa522c323e5fa1d9600bb63cb5aac02d by Thomas L��bking. Committed on 08/03/2011 at 21:33. Pushed by luebking into branch 'master'. Unlink maximization state from actual geometry Since clients with restricted geometry now cannot cover the entire screen by default it was necessary to unlink the state from the actual geometry to re-provide the "restore" feature. The patch also extends the protection of the maximized state to unilateral maximizations (emacs issue) BUG: 265568 BUG: 252314 CCBUG: 252255 review request https://git.reviewboard.kde.org/r/100606/ M +0 -1 kwin/client.cpp M +0 -1 kwin/client.h M +13 -44 kwin/geometry.cpp http://commits.kde.org/kde-workspace/44795854aa522c323e5fa1d9600bb63cb5aac02d *** Bug 291733 has been marked as a duplicate of this bug. *** *** Bug 339096 has been marked as a duplicate of this bug. *** |
Created attachment 56911 [details] Supposedly maximized xterm window (not really maximized) Version: unspecified (using KDE 4.6.0) OS: Linux xterm tries to enforce window size to be a multiple of the size of a character. Kwin doesn't handle maximizing its window properly anymore. Note that this seems to happen with all window decoration themes, making it not specific to one of them. Reproducible: Always Steps to Reproduce: 1. Open an xterm. 2. Maximize it. Actual Results: With KDE 4.6, the window is made almost as big as maximized size but isn't maximized; Window resizing borders remain, often making xterm text selection painful as it's easy to end up resizing the window instead. Expected Results: KDE 4.5's and prior kwin did force the window size to the standard maximized size properly.