Summary: | SlidingPopups protocol requires screen geometry mapping on client or server side | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Matthias Fuchs <mat69> |
Component: | effects-various | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | notmart, vlad.zahorodnii |
Priority: | NOR | ||
Version: | git master | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
Fixes issue at least with Xinerama
Patch to fix the issues for PopupApplet _not_ KRunner |
Description
Matthias Fuchs
2011-07-29 08:53:45 UTC
Adding KWin as CC as they might know more about this problem. Created attachment 62296 [details]
Patch to fix the issues for PopupApplet _not_ KRunner
I tested some more and interestingly the same issue exists with animations starting from Left, but both Bottom and Right are not affected.
All the other notes taken above remain valid.
I think this is rather a bug in KWin SlidingPopupsEffect::paintWindow I think the idea was to start the animation from the top of the panel and not from top of the screen - at least for the popups. In either case in the scenario described above (1. b)) they start not at the correct position rather at the middle of the screen and moving back from there. The start & stop geometries are piped into the effect from outside (the panel, popup, whatever controls it in the client) - the effect doesn't care about screen geometries & struts at all -> no idea whether this is still notmart's issue, but it's on the client's (in this case plasma) side. That is true, though the start and stop geometries that are pushed into it are the correct absolute geometries. This is also why I mentioned that I am not sure if absolute geomtries are allowed at all or if relative (to the screen) geomtries should be used in all cases. Ahhh, ok - i missed the 1024+1024-h part in your ... longer ... OP ;-) From the discussion i thought there was an offset against an absent panel. You're however right (except that there's certainly no such bug in XChangeProperty..) - compositing happens "per screen" while under Xrandr or TwinView multiscreen QWidget::geometry() is relative a combined screen area. This needs to be mapped, and actually preferable on the server (kwin effect) side so we fix it w/o changing the "protocol". So in that case it should be fixed in slidingpopups.cpp? I wonder if the QRegion in SlidingPopupsEffect::paintWindow is correct in this regard. yes ... slidingpopups.cpp should be fixed. "mAppearingWindows[ w ]" *sigh* anyways, back on topic: what QRegion do you mean? the paintWindow parameter? That's window related and should be fine (place this window across to screens, scroll. works? works! -> that region is ok ;-) The fix should happen in slotPropertyNotify() and that points need to be offset by i guess "effects->clientArea(ScreenArea, EffectWindow *w).topLeft()" 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 @Martin Is this bug still actual? Can it be marked as RESOLVED? Good question... No new comment for seven years: I assume we can consider it fixed. Okay then, marking as fixed. |