Bug 126817

Summary:	Fullscreen windows are not kept on top when a window is active on another screen
Product:	[Plasma] kwin	Reporter:	Parker Coates <coates>
Component:	xinerama	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	Screenshot 1: All is well Screenshot 2: Where'd that panel come from? Screenshot 3: Switching monitors or applications doesn't amke a difference

Description Parker Coates 2006-05-05 20:57:44 UTC

Version: (using KDE KDE 3.5.2)
Installed from: Ubuntu Packages
OS: Linux

I have a dualhead system set up with nVidia's Twinview. I'm very impressed with how well KDE handles the setup, especially with some to the multihead options added in newer versions. The kicker, however, has one major bug with dual monitors and fullscreen applications.

For example, if I open a video in Kaffeine (Xine) and launch it fullscreen on monitor 2, everything runs as expected, at first. (See screenshot 1.) On monitor 1, I can rightclick the desktop, use the KMenu, and do a few other things without things messing up. However, if I focus any window on monitor 1, the panel immediately appears on monitor 2, on top of the fullscreen video. (See screenshot 2.) If focus is returned to the fullscreen Kaffeine the monitor 2 panel disappears once again. The problem is the same regardless of which monitor holds the fullscreen app or which application is fullscreened. (See screenshot 3.)

This is a major annoyance for two major reasons:
1. One of the big benefits of a dual head setup is the ability to play media on one head while do other things on the second head. With the current situation true "fullscreen" media is not possible.
2. It is impossible to run an fullscreen application on each monitor, without a panel appearing on at least one of the screens.

At the moment, I make do by manually hiding panels over fullscreen apps, but this is obviously not ideal. I'm assuming this behaviour is a bug and not a feature; I can't think of any reason this would be desirable, but I might be wrong.

Thanks a lot. I've loved all the recent additions to the kicker. Locked panels and systray hiding are top notch.

Comment 1 Parker Coates 2006-05-05 21:00:03 UTC

Created attachment 15926 [details]
Screenshot 1: All is well

Comment 2 Parker Coates 2006-05-05 21:01:06 UTC

Created attachment 15927 [details]
Screenshot 2: Where'd that panel come from?

Comment 3 Parker Coates 2006-05-05 21:02:06 UTC

Created attachment 15928 [details]
Screenshot 3: Switching monitors or applications doesn't amke a difference

Comment 4 Parker Coates 2006-11-20 15:14:54 UTC

After further research and discussion as seen in this thread, http://lists.kde.org/?l=kde-devel&m=116241490425280 , it's been determined that the issue lies with KWin and not Kicker.

Thanks for changing the product, Lubos. I had tried to change it earlier, but failed to figure it out.

Comment 5 Mark Williamson 2007-06-18 07:22:12 UTC

I can confirm I've just seen this behaviour too.  It's really only a minor nit, but I'm fairly convinced it's unintended behaviour.  Actually, it's more noticeable if you use focus follows mouse, because the moment you move the mouse to the other screen, chances are you'll focus a window.

I have a theory as to what's up here: on single monitor setups, kwin pops up the panel if you switch focus to another app (e.g. alt+tab switching) without switching off fullscreen mode for the previous app.  This means that whilst using the newly focused app the panel will show up as usual, rather than being stacked underneath the fullscreen app in the background.

I'm guessing that the assumption "If the fullscreen app isn't focused then you need to raise the panel" has been coded without multi-monitor awareness.  I think more intuitive behaviour would require "If the fullscreen app isn't focused and another app *on this monitor* has focus, raise the panel.  Otherwise, don't do anything.".

I hope maybe this clarifies things a bit.

Comment 6 Lubos Lunak 2008-08-23 12:03:28 UTC

r851204