I just tried you steps to reproduce with  rekonq and could not reproduce. I am 
using Fullscreen windows and two screens quite regulary and have never noticed 
such a problem.

Is it possible that wine removes _NET_WM_ACTION_MINIMIZE? You can test with 
xprop on the window.

(It makes me wonder: that's the second wine related issue in one week)

Created attachment 49849 [details]
Xprop output for Wow

(In reply to comment #1)
> I just tried you steps to reproduce with  rekonq and could not reproduce. I am 
> using Fullscreen windows and two screens quite regulary and have never noticed 
> such a problem.
> 
> Is it possible that wine removes _NET_WM_ACTION_MINIMIZE? You can test with 
> xprop on the window.
> 
> (It makes me wonder: that's the second wine related issue in one week)

xprop shows (full output attached):
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP

So it seems it's at least not disabling minimize.  Are you running twinview or a different setup?

I also tested the issue with SMPlayer as the fullscreen app and it has the same problem.  I'll attach xprop output for smpalyer shortly.

Any other ideas?  I'm willing to debug if someone can point me in the right direction; I wouldn't know where to start on my own.

Created attachment 49850 [details]
Xprop output for SMPlayer

oh I missunderstood the first comment and I can confirm that it does not work. You have to click the entry of window B (window A is the fullscreen window)

Reassigning to Plasma as that looks like a bug in the tasks applet

Thank you, I wasn't entirely sure kwin was the right product but i didn't see one for the task manager itself.  Good to know I'm not the only one with the issue at least.

*** Bug 225668 has been marked as a duplicate of this bug. ***

*** Bug 243394 has been marked as a duplicate of this bug. ***

I'm now back home and still willing to help track this down.  Please let me know if there is anything I can do to help.

*** Bug 252466 has been marked as a duplicate of this bug. ***

When i play a fullscreen game in Wine, Alt-Tab is showing other windows, but cannot switch to them. I think this is because the current fullscreen app winodw is not minimized when switching to other window.

If i assign o global shorcut for Kwin to minimize window (Meta-M in my case) it allows me to minimize the fullscreen wine app, but doesn't change the screen resolution, thus the screen is distorted (see attachment: the plasma desktop is shown in 800x600 but distorted)

Created attachment 56674 [details]
distorted desktop because the original sreen resolution is not restored when minimizing fullscreen wine game

The screen geometry is not a matter of plasma or the WM - wine sets it, wine has to reset it.

The problem you encounter is (likely) that neither wine nor the game expect you to "minimize" it (the game has been written for an entirely different system with a very specific "window manager", ie. explorer.exe)
The game probably runs ins some kind of OpenGL game mode (glutEnterGameMode) where you even alt+tab should be ignored but does not grab the keyboard. This could be worked around by setting a window rule to ignore global shortcuts for the window (alt+tab then won't react anymore)

I've met a lot of issues in internet when people say that other non-windows fullscreen apps suffer the same (for example http://ubuntuforums.org/showpost.php?p=5421264&postcount=8), so i don't think it's wine's or this particular game's problem.

What i am thinking of is for kwin to minimize the current app window if it is fullscreen before switching to next winddw.

>even alt+tab should be ignored

I think this is good that aven for a fullscreen app Alt-Tab is still working, and i expect that i would be still able to swtich to another window without closing current fullscreen app.

> I've met a lot of issues in internet when people say that other non-windows
> fullscreen apps suffer the same (for example
> http://ubuntuforums.org/showpost.php?p=5421264&postcount=8), so i don't
> think it's wine's or this particular game's problem.
that thread is two years old and is about Ubuntu. <jedihandmove>This is not 
the problem you are looking for</jedihandmove>

(In reply to comment #14)
> I've met a lot of issues in internet when people say that other non-windows
> fullscreen apps suffer the same (for example
> http://ubuntuforums.org/showpost.php?p=5421264&postcount=8), so i don't think
> it's wine's or this particular game's problem.
> 
> What i am thinking of is for kwin to minimize the current app window if it is
> fullscreen before switching to next winddw.
> 
> >even alt+tab should be ignored
> 
> I think this is good that aven for a fullscreen app Alt-Tab is still working,
> and i expect that i would be still able to swtich to another window without
> closing current fullscreen app.

I have two points.  First, this looks like something other than the original bug that I reported, which deals with other tasks not being minimize-able fro the task manager when a fullscreen app is open (usually on another monitor).  Would you mind making a new bug for your issue?

Second, minimizing a fullscreen task when you switch away from it is not such a great idea for those of us with multi-monitor setups.

On Sunday 30 January 2011 21:46:36 Kevin Lyles wrote:
>  First, this looks like something other than the
> original bug that I reported, which deals with other tasks not being
> minimize-able fro the task manager when a fullscreen app is open (usually
> on another monitor). Would you mind making a new bug for your issue?
Yes you are right, this report should only focus on the first reported issue 
and not be hijacked, as that makes it difficult to track the bug. Sorry for 
not recognizing before and not intercepting.

(In reply to comment #14)
> I've met a lot of issues in internet when people say that other non-windows
opera -> f11 -> alt + tab = works
scummvm/tuxracer/various id shooters -> alt+enter -> alt + tab: no reaction. alt+f3: no reaction. reason : they grab the keyboard as you're not supposed to dealt with the window system
jedi academy (through wine) -> fs -> alt+tab: tablist, select a window: no reaction.

sense a pattern here, i do =)

> What i am thinking of is for kwin to minimize the current app window if it is
> fullscreen before switching to next winddw.

no. that would be an unrelated and unexpected side effect and therefore plain wrong.
what if the "other" window is a related dialog/windows (eg. if you're using gimp, krita, inkscape, openoffice etc. in fs mode)
 
> I think this is good that aven for a fullscreen app Alt-Tab is still working,
> and i expect that i would be still able to swtich to another window without
> closing current fullscreen app.

not if the fs window application grabs the input devices (mouse, keyboard), what esp. games usually do.

(In reply to comment #16)
> I have two points.  First, this looks like something other than the original
> bug that I reported, which deals with other tasks not being minimize-able fro

Actually very correct, sorry.

@Victor:
you'll have to open another bug, but i'm quite sure that this is a(nother) wine thing (esp. since it alters the resolution - you'd expect kwin to trace & change resolutions with activating windows?)

Please forgive me for being off topic.

I thought the issue decribed by me has the same roots.

I think it's pointless to open another bug, as people will say it is a X-server related bug.

But i would like to be able to minimize a full screen app wihout using workarounds, like in MS Windows - i think this is quite normal expectation.

still OT and  (In reply to comment #19)
> But i would like to be able to minimize a full screen app wihout using
> workarounds, like in MS Windows - i think this is quite normal expectation.
No, it's actually not - the clients do this on windows (as well as they could perfectly on X11 - but wine probably faces other issues running after wild uses of outdated MFC functions)
The reason is the variable sense in this - games (used to) break GDI rendering when on screen but on the other hand you certainly don't want to minimize eg. your fullscreen browser because its "save" dialog shows up, yesno?

*** Bug 266237 has been marked as a duplicate of this bug. ***

Sorry for cross posting!

I have been facing this bug too and I have sort of found out how to reproduce
it every time :D

First Please Note: A taskbar entry for a window appears smooth when it is
minimized and depressed with shadows when it is maximised...this is the
standard KDE Plasma scheme!


Well, to produce this bug all you have to do is:

1) Minimize a window( worked for kate, Quassel and Dolphin in my case! Didn't
try with other programs...)
2) You will notice that the taskbar entry is smooth, and it should be so
everything is fine till now.
3) Now click on the taskbar entry and quickly as soon as you clicked on it move
mouse pointer upwards to remove it from hovering over the taskbar entry...You
need to get the speed right, it might take a few tries for you to get the right
speed!
4) Importantly, now you will notice that the window is maximised now, but, but
its taskbar entry is not depressed( like it should be ), but is smooth...(this
is WRONG!)
5) Now no matter how much you click on this smooth task bar entry, the window
will not minimize!!!
6) There you have it folks, the bug was reproduced everytime for me.

If in case all the above seems incredulous and you are not able to reproduce
it, then put a comment here, I will make a video and add it as an attachment :)

I hope this bug gets fixed soon, as it hampers productive use of the
taskmanager!!!

I have the same problem using KDE 4.6.5 in Arch Linux.

When I have SMplayer at full screen in my second monitor the task manager won't minimize any windows in the primary monitor when I click on their name (they can be minimized fine by clicking the button on the windows border). If I exit full screen mode in the 2nd screen everything works fine.

*** Bug 277278 has been marked as a duplicate of this bug. ***

And 4.7 RC1 shows the same bug.

*** Bug 278871 has been marked as a duplicate of this bug. ***

judging from dupe #278871 there seems a connection to an issue that _could_ duplicate bug #207258

There are three separate bugs being mentioned here that really should be kept separate:

1) #246838 (this bug): Inability to minimize applications via the task manager when a fullscreen application is open on another desktop.

2) #278869: Inability to minimize a particular application via the task manager irrespective of the presence of a fullscreen application.  This bug seems to be more of a timing issue caused by moving the mouse in a certain way while clicking.  Comment #22 of bug #246838 is really an observation of bug #278869.

3) #278871: Window animation effect sometimes zooms to the middle of the screen.  Martin marked this bug a duplicate of #246838 (presuming it to be the same bug as #278871) after I published a video (http://www.youtube.com/watch?v=tw-3q7xMQAQ) where both bugs #278869 and #278871 occur to the same application.  However, I have serious doubts about the relation between #278869 and #278871, especially since I can reproduce both of these bugs independently of the other.  In fact, the occurance of both bugs simultaneously has never happened for me until I recorded that video!

So, I believe these three bugs should be kept separate until it can truly be shown that they are related (and #278871 should be reopened).

Whoops, I gave Martin credit for Thomas's bug marking in the previous comment.

Sorry i only watched the video ;-)

So yes
a) this but comment #22 is different from your bug #278869
b) i would now have said that bug #278871 without the #278869 (ie, text not video) is ultimately a dupe of bug #207258 ... but that's your bug as well.

=> reopening bug #278871, sorry for the noise <mantra>taskbars suck</mantra> :P

Thomas,
a) I am convinced that comment #22 is the same bug I reported--Karan just found a different (and more consistent) way to reproduce it.
b) Even though the symptoms are similar, bug #207258 is a different bug that was eventually fixed (related to stacked taskbar entries).

Thanks for reopening :)

*** Bug 287232 has been marked as a duplicate of this bug. ***

*** Bug 286828 has been marked as a duplicate of this bug. ***

*** Bug 305055 has been marked as a duplicate of this bug. ***

KDE 4.9.4 shows the same issue under certain conditions.

To reproduce, open Konsole and Dolphin, make Konsole a full screen window on a secondary monitor, then try to minimize Dolphin from the taskbar. Nothing will happen.

It is interesting that the System Activity Monitor minimizes as expected, when the same test applies.

Hi ! 

I encounter this issue everytime in KDE 4.10.1 (Kubuntu 12.10).

I have a dual head setup, using Nvidia proprietary drivers (TwinView). If I display a video in VLC, in fullscreen mode on the second monitor, double-clicking a task manager entry in order to minimize it, on the primary screen, doesn't work.

(it works for raising the window though, and I can still minimize a window using the title bar buttons).

Best regards,
Mahen

This appears to be a problem in KWin.

libtaskmanager relies on KWindowSystem::stackingOrder() which in turn relies on NETRootInfo::clientListStackingCount() and NETRootInfo::clientListStack() which in turn is managed by kwin in kde-workspace/kwin/layers.cpp in Workspace::propagateClients

this needs to be modified to take multiple screens into account and when a window is fullscreen on one screen to also include the window with focus on another screen.

I confirmed this by looking at what libtaskmanager was seeing and then tracing that through kwindowsystem 'n friends.

(In reply to comment #37)
> This appears to be a problem in KWin.

You can try any other halfwise NETWM compliant WM on this (openbox, metacity, compiz, ...) and get the same result.
The available lists you refer are _NET_CLIENT_LIST_STACKING and _NET_CLIENT_LIST - they're simply not screen aware.

Those lists include *all* windows from all screens.
So this:
> this needs to be modified to take multiple screens into account and when a
> window is fullscreen on one screen to also include the window with focus on
> another screen.
is wrong.

The stacking order is defined by the NETWM spec as well:
"- windows of type _NET_WM_TYPE_DESKTOP
- windows having state _NET_WM_STATE_BELOW
- windows not belonging in any other layer
- windows of type _NET_WM_TYPE_DOCK (unless they have state _NET_WM_TYPE_BELOW) and windows having state _NET_WM_STATE_ABOVE
- focused windows having state _NET_WM_STATE_FULLSCREEN"

Now, the plain behavior would indeed be to move windows to the regular layer as soon as any other window gets the focus, but the NETWM spec nowhere considers multiple screens and the common behavior is to keep them on top of things as long as the active window is on the other screen - the reason is that you get bug reports about panels covering the video player once you click a window on the other screen.

We also cannot move the focused window to the absolute top of the stack (ie. also above panels and keep above windows) so actually the only thing kwin could do from here would be to lie about the stacking order when exporting it (move the panel down or the active window on top of the list, but not in the stack) bearing the risk to confuse other clients - just that even then it would only work with KWin.

Libtaskbar will have to ignore _NET_WM_STATE_ABOVE (which btw. can minimized, despite being below the fullscreen window...) and _NET_WM_TYPE_DOCK anyway, so it seems reasonable to do the same for windows on other screens or perform a general occlusion check (ie. move down the list and either ignore the window or include it to a region to test against the window geometry).

Leavin the decision to Martin, but personally i vote against lying about the order, lowering fullscreen windows below panels on the "inactive" screen or creating a "KWin & Plasma only" fix.

Thanks Thomas - moving back to Plasma. I think we don't want to put incorrect information to _NET_CLIENT_LIST and we clearly don't want to lowering fullscreen windows below panels on the inactive screen (or someone might get killed if I want to watch a video on my second screen...).

I'd say this is a wonderful example for a RESOLVED WAYLAND bug.

Martin and Thomas: I am disappointed by your response.

Let's recap:

* no other window manager gets this "right" either (so kwin shouldn't?)
* NETWM is stuck in the stone age (so kwin gets to as well?)

These are irrelevant and non-compelling when it comes time to fix bugs.

Then there is the advice: "Libtaskbar will have to ignore _NET_WM_STATE_ABOVE (which btw. can minimized, despite being below the fullscreen window...) and _NET_WM_TYPE_DOCK"

Well .. yes. It already does all of that, because that's how window management works.

"it seems reasonable to do the same for windows on other screens"

IMHO not really, and here's why:

Let's say I have two screens. On screen 0 i have a konsole window fullscreened via kwin's window title bar menu. Great. On screen 1 i have kwrite (not fullscreened). KWrite has input focus and I'm typing away madly. Now I press kwrite's entry in the task bar. Whoops, doesn't go away. Why? Because the full screen app, despite being on a different screen and not having input focus, is stacked above the kwrite window according to kwin. So the kwrite window obviously has focus, obviously is stacked above the full screen window (if i drag it to screen 0, it appears above the konsole window) and yet in the stacking order it is below the fullscreen app. Utterly illogical.

In any case .. whatever, I'm willing to accept that KWin is going to stick to this non-intuitive stacking order. I'll add a test in the libtaskmanager code to do what imho KWin ought to be doing itself: checking that the window is fullscreened but perhaps on a different window.

> * NETWM is stuck in the stone age (so kwin gets to as well?)
yes, at least as long as we are on X11. I'm not going to break the spec for a 
bug fix. The only way to fix this is to add the atoms in a multi screen aware 
way. That's not possible as KDE libs is still feature frozen.

Sorry, right now there is nothing we could do in KWin to fix the bug. We can 
neither change the way how we export the stacking order as we are in feature 
freeze for 4.11 nor can we add more atoms because KDE libs is in feature 
freeze.

For 5.x the solution is called "Wayland". But at the moment, sorry nothing we 
could do. If you disagree: patches welcome

Git commit 3e29c44711c86cdc8183a37abc801575e8cef678 by Aaron Seigo.
Committed on 17/06/2013 at 19:52.
Pushed by aseigo into branch 'master'.

ignore full screen windows that are on different physical screens

imho this is doing window management, and since it really crosses over
into knowing which window has focus ought to be done by the window
manager. kwin devs disagree, so here we go implementing window
managery logic in libtaskmanager.

M  +14   -0    libs/taskmanager/taskmanager.cpp

http://commits.kde.org/kde-workspace/3e29c44711c86cdc8183a37abc801575e8cef678

"That's not possible as KDE libs is still feature frozen."

feature frozen, not bug fix frozen. (not sure what you require in kdelibs for this, but ok)

"as we are in feature freeze for 4.11"

you keep using that word. i do not think it means what you think it means.

in any case, as you can see above i've gone ahead and "fixed" it in libtaskmanager, but it comes at a cost. 

now anyone using multiple screens will get plasma-desktop waking up 200ms after each and every window move. this was optimized, by me, long ago because there is noticeable overhead. it was really only useful in the case of a tasks widget (back then: kicker task applet) is showing "only windows on this screen". it was part of the "make the desktop wake up no more than once per second, worst case, in default config" work i did many years ago.

now, because the window manager which does actually have perfect knowledge of the window situation misreports* the stacking order, that bit of work is not so useful anymore. (at least it survives for the single screen case). enjoy your increased power consumption.

* yes: misreports. there is no way in any sane definition of the word "stacking order" that there can be a window with input focus (complete with the active window border) on screen 0 is "behind" a full screen window on screen 1.

so i've worked around it, but it's really suboptimal imho.

ignoring performance, from a design POV this also puts window manager type code (imperfectly) into libtaskmanager. for all the times we've said "let the window manager manage the windows", it seems we truly mean it only when it is convenient.

"waking up 200ms after each and every window move"

to clarify on this point, in case someone misunderstands: the events are all compressed so at most we get one refresh of the window info in any given 200ms slice of time.

(In reply to comment #40)


> * no other window manager gets this "right" either (so kwin shouldn't?)
You're leaving out the main point here, being *why* they don't being because it is the sane thing to do to cover the MS unawareness of the spec.
You're also ignoring that you'll still receive bugreports from people trying to use openbox or compiz with plasma-desktop.

FYI: No other panel i tried has any particular problem with this situation.

> * NETWM is stuck in the stone age (so kwin gets to as well?)
If you want to abandon NETWM, please state that clearly.

If you want an iprovement of the NETWM spec: I totally agree.
It lacks a MS concept and contains the word "should" far to often.
But i thought we maybe wanted to resolve users from this problem this or maybe next year.

> Well .. yes. It already does all of that
I didn't question that this happens nor suggest or advice to do so.
"Will have to" was rather meant as assumption, not as instruction.
I probably carried over a German idiom ("wird ohnehin müssen") here? Sorry for that.
The intention of my words was that libtaskbar already has to filter windows, so adding one more filter was not unreasonable.

> the kwrite window obviously has focus, obviously is stacked above the full
> screen window 
No. Maybe "apparently", but not "obviously" as it /is/ not.

> (if i drag it to screen 0, it appears above the konsole
> window)
Not true or you're facing a bug or a different version of KWin.

The window is below the fullscreen window and remains there until you release it. That moment it's on the same screen as the fullscreen window, has input focus and by requirement of the NETWM spec (minus the silent agreement among WMs to cover the lack of a MS concept) the fullscreen window looses it's special layer. If your focus strategy somehow raises the active window (what is pretty common) it will then of course be on top of the no more specially treated (as by spec request) fullscreen window.

> and yet in the stacking order it is below the fullscreen app.
No more at that very point.
The list gets updated and the focused window is now above the fullscreen window in the list because that lost it's special position.

You can check for yourself using 
xprop -root | grep -E '^_NET_CLIENT_LIST_STACKING'
and
xwininfo -f <window_id_here>

Also, and that is most important:
this is entirely unrelated to the situation of this bug.

What however might be related is this example:
Disable raising of active windows (only to reliably cause a stacking order that can be caused programmatically nevertheless and anytime), have to windows aside each other (not intersecting) and click the taskbar entry of the active window. Despite being active and uncovered, it's risen. Intended? Logical?

> code to do what imho KWin ought to be doing itself: checking that the window
> is fullscreened but perhaps on a different window.

"different screen", i assume?
KWin /is/ doing that and that is /precisely/ what causes you this bug.

Apparently that didn't make it through, so here's a re-explanation of the status quo:
---------------------------------------------------------------------------------------------
If we would ignore the screen relation of focused and fullscreen window, libtaskbar would work the way it is and it would also be the vanilla implementation of the (however completely MS unaware) NETWM spec - ie. it would not even be wrong or a violation of the NETWM spec.

Actually everyone is atm. silently deviating from the spec as it's simply insufficient regarding multiple screens.

The reason why KWin -and every other WM i tried- do look at the screen here, is that otherwise fullscreen windows unintentionally do not end up on top of the stack in multiscreen scenarios.

In case that was really not clear:
Lying about the stackig order when exporting it is *really* the only thing KWin could do here w/o introducing a new (old) bug.
Upgradiding NETWM to 2.0 would certainly be nice and teh *right* thing to do, but no near-term solution (and esp. not for the KDE 4 cycle)

(In reply to comment #43)
> now anyone using multiple screens will get plasma-desktop waking up 200ms

That's not required. KWin considers windows to be on a particular screen when >= 50% of them is.
You could also perform an occlusion check on trying for the action on clicking the task item.

> * yes: misreports. there is no way in any sane definition of the word
> "stacking order" that there can be a window with input focus (complete with
> the active window border) on screen 0 is "behind" a full screen window on
> screen 1.

It's also absolutely possible to have active windows on event the bottom of the stack.
My english is certainly a little hazy, but where excatly do you draw the line between "focus" and "stack"?

"You're also ignoring that you'll still receive bugreports from people trying to use openbox or compiz with plasma-desktop."

.. at which point we can say, "Bug in your window manager, use kwin." Just as we always have.

"FYI: No other panel i tried has any particular problem with this situation."

Probably because no other panel listens to kwin's stacking order thoughts.

"If you want to abandon NETWM, please state that clearly."

That is a silly thing to say. Please.

"If you want an iprovement of the NETWM spec: I totally agree.
It lacks a MS concept and contains the word "should" far to often.
But i thought we maybe wanted to resolve users from this problem this or maybe next year."

.. and kwin could implement windows stacking (or even just how it is advertised) in this one particular case differently to address that issue. I'm not sure what benefit there is to implementing every bug in NETWM. What does that gain us in this exact case, exactly?

"No. Maybe "apparently", but not "obviously" as it /is/ not."

GIven that the window title bar is in the active state, that it is receiving focus input, the number of users who will care about this technicality: zero.

The stacking order as *advertised* by kwin to the external world and the *visual* and *functional* appearance do not match.

"The intention of my words was that libtaskbar already has to filter windows,"

A-ha, that makes more sense, yes.

"so adding one more filter was not unreasonable."

The problem is that every filter is post-window-manager window-management, and in this case incurs a performance penalty just to work around window managers being unhelpful with multiple screens.

Can I do it? Yep, see the commit above. Is it the best possible end result? I don't think so.

And you agree:

"Upgradiding NETWM to 2.0 would certainly be nice and teh *right* thing to do, but no near-term solution (and esp. not for the KDE 4 cycle)"

So why this bug was dropped from kwin and pushed back to this component is something I do not understand at all.

"KWin /is/ doing that and that is /precisely/ what causes you this bug."

Yes, it /is/ doing that, and then it says that it stacks it above all the other windows even though it is quite obviously NOT the top window. I'm glad kwin is trying to do *something* in the multiscreen situation, I just wish it would do it a bit more sensibly.

"> now anyone using multiple screens will get plasma-desktop waking up 200ms"

That's not required. KWin considers windows to be on a particular screen when >= 50% of them is."

.. and yet that is the source of the bug. When the focused window is not on the same screen as the fullscreen app (at all; completely, 100% on a different screen) the stacking is wrong. So we have to figure it out in libtaskmanager, and that means updating the KWindoInfo so we have the proper geometry to do so.

"You could also perform an occlusion check on trying for the action on clicking the task item."

Which is what happens. However, the update on the KWindowInfo object that TaskManager::Task uses internally is done when the window updates. This has to happen because libtaskmanager tells the outside world when information changes (e.g. names). I did see if it was possible to do this on demand inside of the methods that return the information, and this very easily led to deadlocks that I decided to not debug after looking at the backtraces trailing off into xlib calls from KWindowSystem/Info code.

"It's also absolutely possible to have active windows on event the bottom of the stack."

Yes, it is. (Quite aware of that as we rely on that in plasma-desktop.) But in this exact use case it makes no sense from the user's perspective, however.

"My english is certainly a little hazy, but where excatly do you draw the line between "focus" and "stack"?"

The window that has focus is the one that gets input when I type on my keyboard and in this case it's also the one that has kwin's "this window is active" title bar presentation.

The window stack should reflect that in the multi-screen case. In that case, with a fullscreen window on screen 1 and a window with focus on screen 0 (because I brought it forward e.g. by clicking on it), I would expect the window stack as reported by KWindowSystem::stackingOrder()  to be:

* <random desktop windows like panels or whatever on screen 0>
* the focused window on screen 0
* <random desktop window like panels on screen 1>
* the full screen window on screen 1

> > (if i drag it to screen 0, it appears above the konsole
> > window)
> 
> Not true or you're facing a bug or a different version of KWin.
With compositing enabled the window might be elevated to get it above the 
quick tile outline. This might be the cause here when dragging a window to 
another screen

> "That's not possible as KDE libs is still feature frozen."
> 
> feature frozen, not bug fix frozen. (not sure what you require in kdelibs
> for this, but ok)
exposing a new atom to have multi screen aware _NET_CLIENT_LIST is a feature 
to me and that needs to be done in kwindowsystem.
> 
> "as we are in feature freeze for 4.11"
> 
> you keep using that word. i do not think it means what you think it means.
We already had that discussion last release cycle with the shadows. To me a 
"bugfix" which changes behavior is a feature and by that covered by the feature 
freeze. I think during our discussion we agreed to disagree on that point.

(In reply to comment #48)

> With compositing enabled the window might be elevated to get it above the 
> quick tile outline. This might be the cause here when dragging a window to 
> another screen

Ah, yes - sorry. They're indeed (visually) elevated while hinting the Quicktile but no more when the window leaves the triggerarea.

So, we figured that I usually don't use quicktiling ...

> * <random desktop windows like panels or whatever on screen 0>
> * the focused window on screen 0
> * <random desktop window like panels on screen 1>
> * the full screen window on screen 1
sounds great but windows are not on screen 0 or screen 1, they are in most 
cases on both (e.g. the shadow). So while that certainly would be a solution, 
I don't think that is the right approach. The only possible approach with that 
would be to export the list per screen and the overlapping ones in each list 
which needs changes in kwindowsystem.

Btw. if as a side-effect libtaskmanager is now more multi-screen aware we can 
make use of that and also provide the "Move to Screen" menu.

tl; dr
(the rest of the message contains more explanations on things a nd answers, but this seems most relevant)

Determine the isActive state of the window, that is queried to be on top.
If it is active, just ignore all leading fullscreen windows when parsing the stack top->bottom (unless it's the queried one, of course)

Ratio:
If the window is not active, it can raise above any of those fullscreen windows (which will leave their special stack position) - unless they're keepAbove, of course.

If the window is active, any leading fullscreen window in the stack is either
a) fullscreen on a different screen
b) keepAbove
c) a fullscreen window randomly moved up in the NORMAL layer, which it shares with the active window, w/o obtaining the focus.

The active window can only rise above those windows in cases (a)+(b) and case (c) will be a rather rare occasion. Even if it occurs the result would be minimize -> activate (and raise)

This would only be required for multiscreen setups and as additionally securing item, every dock type (containing the taskbar ... ;-) or keepAbove window succeeding the leading fullscreen window(s) is a clear indicator for the (non keepAbove) fullscreen window to occupy the special fullscreen layer.
If it's not active, it's on a different screen than the active (queried) window.

I hope i didn't miss anything.

-------

The long term solution would probably be a "canRaise" property on windows (since that is what you actually want, not some specific - and wrong ;-P - stacking order)

------

(In reply to comment #47)

> Probably because no other panel listens to kwin's stacking order thoughts.
They either check the stacking order via X11 directly or query the root properties. They're however equal. And they act as plasma does (w/o the bug causing condition)

>> If you want to abandon NETWM, please state that clearly.
> That is a silly thing to say. Please.
Well, thank you for the clarification.

> .. and kwin could implement windows stacking (or even just how it is
> advertised) in this one particular case differently to address that issue.

Either we blatantly lie into the stacking order property or you will get unwanted windows on top of your fullscreen window by working on the other screen.

-> Do you suggest to lie or to have panels covering video players in this case?

> I'm not sure what benefit there is to implementing every bug in NETWM. 
We are not. As pointed out, more or less every WM actually deviates because the NETWM spec has an issue here.

> GIven that the window title bar is in the active state, that it is receiving
> focus input, the number of users who will care about this technicality: zero.
This is not a user list and i was clarifying a false assumption.
 
> The stacking order as *advertised* by kwin to the external world and the
> *visual* and *functional* appearance do not match.
Are you trying to play on intersection here?
FYI: there is only one global list for the stacking order, not one list per intersection group or whatever. (The KWindowSystem API also clearly reflects that)

> The problem is that every filter is post-window-manager window-management
No. libtaskmanager filters data relevant to *its* task.
It does not manage windows at all.

> So why this bug was dropped from kwin and pushed back to this 

I explained the situation.
I stressed that every fix in KWin would not help the taskbar with other WMs.
I suggested a way for libtaskbar to fix this bug, that does also not occur with other taskbar/WM combinations.

The choice for Martin was to lie about the stacking order, to have this fixed in the tasklib or to tag it somehow "upstream, later: netwm severely needs improvement"
You certainly would not want to keep this bug open for the next two years until the NETWM spec has been, well, rewritten (if that can happen in this timeframe...) and the new protocol implemented in frameworks.

> Yes, it /is/ doing that, and then it says that it stacks it above all the
> other windows even though it is quite obviously NOT the top window. 

Ok, once more:
The fullscreen window *is* on top of all other windows and precisely that is exported. "Above" here does not imply "intersect" - you don't ask for a stacking order of a particular client or screen via KWindowSystem either (where the intersection idea would of course be insane)

The unwill to lie about the stacking order made Martin refuse any near-term possible "solution" (being to lie to everyone to suit a particular client) from KWin's side.

> the same screen as the fullscreen app (at all; completely, 100% on a
> different screen) the stacking is wrong. 
Yes, as several times explained: because ppl. complain about panels on top of their video players. Every relevant WM works around this "bug in NETWM"

> to happen because libtaskmanager tells the outside world when information
> changes (e.g. names). I did see if it was possible to do this on demand
> inside of the methods that return the information, and this very easily 

Ahh - ok. That explains the issue on your side and also likely why other taskbars have no particular problem here.
I had expected the library would trigger "activateRaiseOrMinimize".

I'm not sure why asking X11 for the geometry in isOnTop() would get you races, but see the idea on top.

> The window that has focus is the one that gets input when I type on my
> keyboard and in this case it's also the one that has kwin's "this window is
> active" title bar presentation.

That is _NET_ACTIVE_WINDOW on the root, there's really no suggestion to have it on top of the window stack and the definition is that
"_NET_CLIENT_LIST_STACKING has bottom-to-top stacking order." - the active window is nowhere mentioned and if it was only about that, the taskbar could just minimize active windows.

> * <random desktop windows like panels or whatever on screen 0>
> * the focused window on screen 0
Note, that this would be a clear violation of the NETWM spec as present.
The focused window is *never* to be above docks or keepAbove window (unless it's keepAbove itself)

> * <random desktop window like panels on screen 1>
> * the full screen window on screen 1

What precisely would that get you here?
The fullscreen window on screen 1 is still on top of the stack and the screen of a window is not exported at all and, as Martin already pointed out, users expect a mixed stacking order, visualized between the screens.

-> _NET_WM_SCREEN and _NET_WM_CAN_RAISE seem far more useful and actually doable to me here.