Bug 324792 - window opens covered by part of bottom panel
Summary: window opens covered by part of bottom panel
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Unclassified
Component: general (show other bugs)
Version: 4.11.1
Platform: openSUSE RPMs Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-11 13:47 UTC by Martin Koller
Modified: 2013-09-25 21:15 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 4.11.2


Attachments
before starting gvim (120.13 KB, image/png)
2013-09-11 13:47 UTC, Martin Koller
Details
with gvim started (135.15 KB, image/png)
2013-09-11 13:48 UTC, Martin Koller
Details
patch... for "thomas-private" branch (4.79 KB, patch)
2013-09-11 20:54 UTC, Thomas Lübking
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Koller 2013-09-11 13:47:02 UTC
Whenever I open a new gvim window, it is very often placed at a position where the bottom line area of this new window is _below_ my only bottom panel.
That means, whenever I type a vim command (e.g. :q) I can not see what I type.
I see this behaviour only since I upgraded to 4.11.1 I think (had before 4.11 and before 4.10.5)
I haven't seen this so far with other windows, although I must admit that (as I'm a developer) I most often open and close gvim windows.

I can reproduce this problem easily:
I open a new konqueror window and a konsole window (see first screenshot attached).
The only not covered area on the desktop is left bottom.
Now in konsole I start vi (alias for gvim) and - voila - gvim window is below panel
(see second screenshot).

I tried with other programs but it seems this is only related to gvim.
I have "QtCurve" window decoration and no special kwin rule for gvim

Reproducible: Always
Comment 1 Martin Koller 2013-09-11 13:47:44 UTC
Created attachment 82272 [details]
before starting gvim
Comment 2 Martin Koller 2013-09-11 13:48:08 UTC
Created attachment 82273 [details]
with gvim started
Comment 3 Martin Flöser 2013-09-11 14:29:38 UTC
just for checking: that's not an auto-hiding panel?
Comment 4 Martin Koller 2013-09-11 14:54:14 UTC
No, it's always visible
Comment 5 Thomas Lübking 2013-09-11 14:56:26 UTC
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)
Comment 6 Martin Koller 2013-09-11 15:19:30 UTC
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)
Comment 7 Thomas Lübking 2013-09-11 15:38:36 UTC
(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)
Comment 8 Martin Koller 2013-09-11 18:24:58 UTC
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 ?
Comment 9 Thomas Lübking 2013-09-11 19:55:58 UTC
(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.
Comment 10 Thomas Lübking 2013-09-11 20:54:41 UTC
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.
Comment 11 Thomas Lübking 2013-09-25 21:15:56 UTC
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