Bug 313379

What placement policy did you configure (kcmshell4 kwinoptions) and does that happen with all windows?

I use economically and I only saw it once when minitube was the one in foreground (it has a compact mode which automatically sets always-in-foreground).

I can reproduce it, though, by just making a konqueror window full-width and 90% of height and then opening many emacs-frames. At some point one of the frames appears behind the konqueror window.

Hehe - yes, the algorithm tries to avoid any kind of stacking.
KeepAbove windows are ranked 16 times higher than normal windows but at some point (when the window would be stacked below many other windows) the single keepAbove window is considered acceptable.

I altered the subject and move this to wishlist (and correct component) - the algorithm bases upon some fvwm stuff and dates back to the late ninetees.

Another issue you could encounter is with some clients which demand a certain screen position. This can only be overridden by a rule (disobey geometry request or force an initial position)

Does stacking mean “nothing visible” or “partly hidden”?

The latter is acceptable, but the first is an (sometimes inevitable¹) problem.

¹: if there is no free screen space at all.

PS: thank you for your answer! possibly the issue got visible, because I use auto-grouping, so I often have quite many windows which occupy exactly the same place (with kwin-level tabs).

The algorithm attempts to minimize general occlusion, but
(In reply to comment #5)
> possibly the issue got visible, because I use auto-grouping

Probably, tabbing was introduced much later and the algorithm treats all windows in a group individually (instead of "as one" like you'd likely perceive it)

So a minor patch might easily improve your situation.
Introducing a behavioral change, i'm not sure it could make it into 4.10 but i can attach it here is you compile yourself.

Given that the placement algorithm is one of the oldest pieces of code in KWin which have hardly changed at all, I'd say it rules out 4.10.

off-topic note: I wanted to look into placement in general as I would like to allow scripts to define new strategies. Also I find the way of how Placement works a little bit pre-oop (string matched against function to call?)

Created attachment 76540 [details]
take tabbing and activities into account when placing

Patch to make placeSmart aware of tabs and activities.

It's matched against an enum (string is just for settings translation)

"OOP" might be "problematic" because we need all placers and resolve them by window type (dialog placement) or rule.
Also the placement is stateless (the workspace parameter is pointless, since we got a singleton workspace and also the clients can access it), so it sounds more like attaching a functor to each client (while you still got to determine the strategy, just in the client -> dislocal)

One could either remove the workspace member, move ::place(Client *c, QRect) to Client::place(QRect) or keep the object, and resolve policy to a functor template - while that's probably overhead.

actually I was thinking in the direction of a Functor. Which is kind of an OOP approach to message invocation ;-)

And yes workspace should be removed (like in so many other places).

Git commit 68f356c0f1cbb47ffcb3bdb185cead4fc57d371d by Thomas Lübking.
Committed on 22/01/2013 at 20:09.
Pushed by luebking into branch 'master'.

ignore non current tabbed and on different activities clients
REVIEW: 108932
FIXED-IN: 4.11

M  +50   -43   kwin/placement.cpp

http://commits.kde.org/kde-workspace/68f356c0f1cbb47ffcb3bdb185cead4fc57d371d