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
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.
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"
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:
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
M +13 -13 kwin/geometry.cpp