| Summary: | window opens covered by part of bottom panel | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Martin Koller <kollix> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | 4.11.1 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/kde-workspace/31e7f10831ec980c2a9306175b31ddb0f6dccde2 | Version Fixed In: | 4.11.2 |
| Attachments: |
before starting gvim
with gvim started patch... for "thomas-private" branch |
||
|
Description
Martin Koller
2013-09-11 13:47:02 UTC
Created attachment 82272 [details]
before starting gvim
Created attachment 82273 [details]
with gvim started
just for checking: that's not an auto-hiding panel? No, it's always visible I don't think so. @Koller What placement strategy do you use, is this a multiscreen setup and does a rule to ignore geometry requests help? (kcmshell4 kwinrules, size and position tab) This is a laptop with only the internal screen. Placement is set to "Smart" I do not understand what to define in the "Ignore requested geometry" combobox. I thought "Ignoring" is just a bool, but what is "Do Not Effect", etc. and the Yes/No Radio for ? (I tried with "Do Not Effect" - no difference, and with "Apply Initially"/Yes - no difference) (In reply to comment #6) > I do not understand what to define in the "Ignore requested geometry" > combobox. Try "Force" / "Yes" "Do not affect" only exists for reverse rule sharpening (ie. you want to apply that to all gvim windows, except when the title contains "FooBar" or so) ok, this seems to work, although it has an interesting effect: the new gvim window has more or less the same size as the konsole window from where I start gvim. Is that expected ? There's also another interesting behaviour: When the new window is placed on the left side of the screen, it is so far to the left that also the window decoration border is outside the screen (seems to be exactly only the border which is outside). Is that also expected ? (In reply to comment #8) > ok, this seems to work Thanks, means I know which path it walks ;-) > although it has an interesting effect: the new gvim > window has more or less the same size as the konsole window from where > start gvim. > Is that expected ? "Expectable" - the visible gvim window resized itself after being initially placed (which is now forbidden) and because of its nortwest gravity slips under the panel. > There's also another interesting behaviour: When the new window is placed on > the left side of the screen, it is so far to the left that also the window > decoration border is outside the screen (seems to be exactly only the border > which is outside). > Is that also expected ? It's the part inside the window and yes: https://bugs.kde.org/show_bug.cgi?id=318107 It's however also the reason why the window is now allowed to grow under the panel (a part of the window is already outside the workarea, so no further restrictions are applied - KWin wouldn't of course place it there) and the place to fix the problem. Thanks for your assistance. Created attachment 82285 [details]
patch... for "thomas-private" branch
Attached is a patch which may or may not cleanly apply on 4.11, but you may safely try.
I'll make a review request when returning to this branch.
Git commit 31e7f10831ec980c2a9306175b31ddb0f6dccde2 by Thomas Lübking. Committed on 11/09/2013 at 20:50. Pushed by luebking into branch 'KDE/4.11'. keepInArea, client geometry containment condition Since windows can place the decoration outside the screen this needs to be still a valid condition when checking whether we've to keep in area In addition: calculate tx, ty and perform one move call (include rule check and XMoveWindow unless there's a geometry blocker ...) FIXED-IN: 4.11.2 REVIEW: 112805 M +13 -13 kwin/geometry.cpp http://commits.kde.org/kde-workspace/31e7f10831ec980c2a9306175b31ddb0f6dccde2 |