Bug 313379 - Overlap factor of keepAbove windows in placeSmart should be infinite
Summary: Overlap factor of keepAbove windows in placeSmart should be infinite
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: core (show other bugs)
Version: 4.9.5
Platform: Other Linux
: NOR wishlist
Target Milestone: 4.11
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-16 20:53 UTC by Arne Babenhauserheide
Modified: 2013-02-25 06:55 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 4.11
Sentry Crash Report:


Attachments
take tabbing and activities into account when placing (6.38 KB, patch)
2013-01-18 14:55 UTC, Thomas Lübking
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arne Babenhauserheide 2013-01-16 20:53:11 UTC
I had a video running in one quarter of the screen in a window which was set to always be in foreground.

Then I opened another video and did not see it, because it opened behind the always-in-foreground window.

I think it would be better, if that always-in-foreground window would push new windows to the free regions of the screen. Essentially they should never open completely behind the always-in-foreground window, except if that window occupies the whole available space.

Reproducible: Always
Comment 1 Thomas Lübking 2013-01-16 21:00:56 UTC
What placement policy did you configure (kcmshell4 kwinoptions) and does that happen with all windows?
Comment 2 Arne Babenhauserheide 2013-01-16 23:58:36 UTC
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.
Comment 3 Thomas Lübking 2013-01-17 00:46:37 UTC
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)
Comment 4 Arne Babenhauserheide 2013-01-17 21:19:59 UTC
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.
Comment 5 Arne Babenhauserheide 2013-01-17 21:21:43 UTC
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).
Comment 6 Thomas Lübking 2013-01-17 21:39:14 UTC
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.
Comment 7 Martin Flöser 2013-01-18 13:46:40 UTC
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?)
Comment 8 Thomas Lübking 2013-01-18 14:55:50 UTC
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.
Comment 9 Martin Flöser 2013-01-18 15:39:31 UTC
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).
Comment 10 Thomas Lübking 2013-02-18 21:48:23 UTC
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