Bug 287602

Summary:	sliding popups doesn't show behind the panel in KDE 4.8 beta 1
Product:	[Plasma] kwin	Reporter:	Weng Xuetian <wengxt>
Component:	compositing	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	dpalacio, jay, KaiUweBroulik2, ultr
Priority:	LO
Version:	4.7.3
Target Milestone:	---
Platform:	Chakra
OS:	Linux
Latest Commit:		Version Fixed In:	4.8.0
Sentry Crash Report:

Description Weng Xuetian 2011-11-26 11:23:19 UTC

Version:           4.7.3 (using Devel) 
OS:                Linux

All test with default effect setting.

Reproducible: Always

Steps to Reproduce:
1. reset effect to default
2. check slide popup is enabled.
3. open kickoff

Actual Results:  
kickoff appears before panel

Expected Results:  
kickoff doesn't appears before panel

Comment 1 Martin Flöser 2011-11-26 11:48:13 UTC

caused by the removal of PaintClipper. Setting the correct paint region or filtering the window quads in SlidingPopups might fix this issue.

I consider it as a minor issue as it is only visual.

Comment 2 Martin Flöser 2011-12-07 05:30:32 UTC

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

Comment 3 Thomas Lübking 2011-12-07 23:48:33 UTC

I guess we could simply elevate all (intersecting) panels instead.

Just tried implentinting in the generic effect - works nicely with yakuake 

plasma-desktop stuff however apparently checks for the effect, not the root property... grep didn't tell me anything about, though :\

Comment 4 Martin Flöser 2011-12-08 06:23:54 UTC

> I guess we could simply elevate all (intersecting) panels instead.
I'm not sure whether this would work for the Plasma stuff. Deleted 
windows are always top most in the stacking order (see bug #158262). So 
elevating would put the docks underneath closed windows nevertheless.

Comment 5 Thomas Lübking 2011-12-08 21:45:03 UTC

nope, wrong on all accounts

1. me cannot count up to 3 ;-)
(ie. plasma stuff works ok, but doesn't set all data)

2. elevating still raises above all deleted ;-)
(but that "stuff" are docks and i blindly raised all docks - so the code just needed to be a bit smarter =)

I'll optionally provide sliding support in the generic animations, have some more testing (and feedback on the outcome, still may not be sufficient) and ... err we could attempt to port slidingPopups to animationEffect for maybe(?) one of the minor releases?! (would be like 100 loc ;-)

Comment 6 Martin Flöser 2011-12-08 21:52:14 UTC

sounds good :-)

Comment 7 Thomas Lübking 2011-12-09 15:43:47 UTC

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

Comment 8 Martin Flöser 2011-12-10 11:39:55 UTC

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

Comment 9 Martin Flöser 2011-12-10 21:41:56 UTC

Git commit cbdd7295d100b19ec55d4b88f2a8113095439e26 by Martin Gräßlin.
Committed on 10/12/2011 at 12:31.
Pushed by graesslin into branch 'master'.

Fixing incorrect clipping of sliding popups

Make use of new extension of protocol for magic number -1.
If offset is -1 KWin has to decide the offset. This fixes all the
incorrect animations and allows us to perform clipping again by
filtering out the window quads which should not be visible.

Additionally the effect now sanitizes the offset. That is for e.g.
Yakuake setting an offset of 0, but there is a strut on the top
corner causing Yakuake not to appear on 0, but with an offset of
the strut. Such cases are now considered as well and the animation
is fixed.

REVIEW: 103367
BUG: 287602
CCBUG: 261159
CCBUG: 278760
FIXED-IN: 4.8.0

M  +115  -37   kwin/effects/slidingpopups/slidingpopups.cpp

http://commits.kde.org/kde-workspace/cbdd7295d100b19ec55d4b88f2a8113095439e26

Comment 10 Thomas Lübking 2012-01-03 20:04:35 UTC

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