Bug 288791

#1)
"kcmshell4 kwinscreenedges", 
- is the upper central checkbox in the monitor active?
- is quick maximization enabled?

#2)
Open a konsole and after triggering the problem run "xwininfo", the cursor turns into a cross, move it to where you'd move it to show the panel and click it. Post the output.

Sidenote)
I've seen that proxy (similar to non autohiding panels) appearing on random screen positions, thin bright line, visible on at least pretty dark wallpapers. Crossing it shows the panel and than the proxy position is corrected)

Created attachment 66664 [details]
The settings window for kwin screen edges

#1)
 - I do not have an "upper central checkbox" there. (See screenshot)
 - But it might important to note: I have screen edge desktop switching enabled.
 - Quick maximization is not enabled, but tile windows on the sides of screen.

#2) 
$ xwininfo 

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0x1c0015f (has no name)

  Absolute upper-left X:  1
  Absolute upper-left Y:  1023
  Relative upper-left X:  1
  Relative upper-left Y:  1023
  Width: 1278
  Height: 1
  Depth: 0
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOnly
  Colormap: 0x0 (not installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: yes
  Corners:  +1+1023  -1+1023  -1-0  +1-0
  -geometry 1278x1+1-0

Sidenote: ;)
I found that opening or closing a window brings the normal behaviour of the panel back, too. You do not need to switch the desktop. Even bringing focus to another window (by clicking an inactive window, bringing it to front) repairs the behaviour. But resizing the currently focused window does not help.

(In reply to comment #3)
>  - But it might important to note: I have screen edge desktop switching
> enabled.

> #2) 
> $ xwininfo 
>   Absolute upper-left X:  1
>   Absolute upper-left Y:  1023
>   Relative upper-left X:  1
>   Relative upper-left Y:  1023

that should be the kwin electric border

> Sidenote: ;)
sounds like either the stack is polluted or plasma doesn't catch the kwin electric border raise.

> sounds like either the stack is polluted or plasma doesn't catch the kwin
> electric border raise.
I know that we raise the border window again when an effect creates an input 
window, so that the borders are always on top of the input window. So I'd vote 
for Plasma doesn't catch the raise.

Dev target for 4.9: finally move all workspace related screen edge handling to 
just one place. Either kwin or yet another kded.

Unfortunately this bug became worse in KDE 4.8.0 (kubuntu backports). Right after starting the desktop the raising of the panel does work. But after it stops working you cannot reactivate it to raise itself again. The changing the desktop trick does not work anymore.

It will be a hard time until 4.9.0.

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

(In reply to comment #6)
> Unfortunately this bug became worse in KDE 4.8.0 (kubuntu backports). Right
> after starting the desktop the raising of the panel does work. But after it
> stops working you cannot reactivate it to raise itself again. The changing
> the desktop trick does not work anymore.
> 
> It will be a hard time until 4.9.0.

I just tested 4.9 beta1, issue still persist :-(

Oh no. 2 days ago I have found that the problem still exists in 4.8.3 (partially updated to 4.8.4 in debian/sid 64bit), so I had the hope that it would work in 4.9 again. The only workaround I have found is to set the panel to "Always visible".

You can change task switcher. Currently I'm using simple list showing miniature window previews. No so nice as Present window plugin. but I can have hidden panel.

KWin electric borders should only be created for required borders/edges, ie. for the ones where you've configured a border effect trigger resp. all if "switch desktop on edge" is set to "always enabled" (and you've at least 4 desktops in a square)

Therefore:
------------
a) can you please specify your electric border setup (wherever you've panels - be it from plasma or a docker like cairo-dock or whatever - as well as configured active screen edges)
b) in case there's no apparent conflict (panel and active screen edge on the lower border)

@Marian: I am already using the simple window list as IMHO this is the most usefull one. But in some situations I would like to use e.g. the present window effect via manual hotkey.

@Thomas: The "electric border"(?) setup:
* One panel (the only one; the standard KDE main panel) at the bottom of the screen.
* 8x4 desktops
* no desktop effects for desktop corners configured.
* "Maximize windows by dragging them to the top of the screen" is disabled.
* "Tile windows by dragging them to the side of the screen" is enabled.
* "switch desktop on edge" is enabled "always" with an activation delay of 400ms and a reactivation delay of 300ms.

I also have tried if it makes any difference to switch the panel behaviour from "windows can cover" to "Auto-hide". But the same problem occurs here: The auto hidden panel is not displayed anymore when touching the bottom edge. But interesting: You can see the bottom edge glow up as if the mouse pointer is noticed there from kwin.

Gert

> * "switch desktop on edge" is enabled "always"
This "breaks" it for you and the conflict (kwin needs to monitor all edges, plasma needs to monitor the bottom one) cannot be resolved w/o a centralized electric border daemon sending messages to all interested clients (ie. comment #5) which does so far not exist.

(If the panel would work, desktop switching would not and did not - at least not where the panel is)

If you're only interested in switching desktops while moving windows:
that does not require and electric border.

But the two functionalities ("switch desktop on edge" and "show panel") do work after starting KDE. So there seems to be not really a conceptual conflict. The problem is that the effect (present windows) does change something in the whole setup so that afterwards the functionality is broken!?

And it worked without problems in 4.7.

(In reply to comment #14)
> But the two functionalities ("switch desktop on edge" and "show panel") do
> work after starting KDE.
Hardly. The panel proxy (some invisible window you can click to signal the panel to raise) will be above the electric border (same kind of window, just with other effect), so at this time it will not be possible to change the desktop at a region covered by the panel proxy (about where the panel is)

> So there seems to be not really a conceptual conflict.
Yes, is :-(

> The problem is that the effect (present windows) does change
> something in the whole setup so that afterwards the functionality is broken!?
As mentioned before, the effect raises KWin's electric borders (to get them above the effect input window and allow them to exit the effect) so that they are ultimately above the panel proxy which in return won't receive any further events (ie. "you can't click it because it's covered by another window")

Speculation & Hacks
------------------------
Since you don't use the electric border to trigger present windows at all (ie the effect is not bound to any active screen edge) there's actually no point in raising them, since they're not required to exit the effect - this should be doable immediately.
Overmore this particular effect *might* in general be coverable by not raising the electric borders and instead just forward the actions of the effect input window events to them, but that would end up in an ugly hack and only cover this particular case.
No idea whether this can be done as an interim hack and how dirty it ends up, but (no more speculation) the only *sane* solution is a border daemon that allows (in this case) kwin & plasma-desktop to receive the same events (whether through X11 event selection or IPC)

---

(In reply to comment #15)
> And it worked without problems in 4.7.
And which version was this bug originally reported against?
The only difference was that it was possible to raise the panel proxies by several actions then (what apparently has changed, but not from KWins side - those windows are not managed)

Deviating from the facts will not lead to a solution; reality won't change just because you want it to.

> (In reply to comment #15)
> > And it worked without problems in 4.7.
> And which version was this bug originally reported against?
> The only difference was that it was possible to raise the panel proxies by
> several actions then (what apparently has changed, but not from KWins side -
> those windows are not managed)
> 
> Deviating from the facts will not lead to a solution; reality won't change
> just because you want it to.

See bug 291141. I reported against 4.8. I'm sure It worked for me in 4.7.

I invite everybody to try this hacky workaround but do not expect it to be merged upstream just because it's available:

https://git.reviewboard.kde.org/r/105245/(In reply to comment #17)

> (In reply to comment #17)
> See bug 291141. I reported against 4.8. I'm sure It worked for me in 4.7.

By that logic the world was a disc until you discovered it's not, right?
It does neither matter when you ran into it or what you recall. The bug *was* reported against 4.7, that is a *fact* and it won't go away as much as you'd like to argue.

OK. I just can't believe it is so long broken :-(
Sorry.

Git commit 98d29454147984db37e6564210caea8ce54374ff by Thomas Lübking.
Committed on 13/06/2012 at 21:44.
Pushed by luebking into branch 'master'.

HACK around bug 288791 - search for likely panel proxies and raise them after destroying an effect input window
REVIEW: 105245
FIXED-IN: 4.9

M  +3    -0    kwin/effects.cpp
M  +50   -0    kwin/screenedge.cpp
M  +5    -0    kwin/screenedge.h

http://commits.kde.org/kde-workspace/98d29454147984db37e6564210caea8ce54374ff

(In reply to comment #20)
> Git commit 98d29454147984db37e6564210caea8ce54374ff by Thomas Lübking.
> Committed on 13/06/2012 at 21:44.
> Pushed by luebking into branch 'master'.
> 
> HACK around bug 288791 - search for likely panel proxies and raise them
> after destroying an effect input window
> REVIEW: 105245
> FIXED-IN: 4.9
> 
> M  +3    -0    kwin/effects.cpp
> M  +50   -0    kwin/screenedge.cpp
> M  +5    -0    kwin/screenedge.h
> 
> http://commits.kde.org/kde-workspace/98d29454147984db37e6564210caea8ce54374ff

Great. It works again :-)
Thanks a lot.

actually not "again" - the patch is a hack

after closing the fullscreen effect it looks at all windows and checks what *could* be a foreign electric border (ducktyping:looks like duck, walks like a duck - it's probably not a dog then) and raises that, ie. does what the client holding that border actually *should* do (but actually can't easily know to have to do) - we still lack a sane solution for 4.10