Summary: | auto-unshade enabled -> shade a window, grab it and move it around -> window doesnt auto-unshade | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | disabled account <caionnew> |
Component: | core | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | groszdanielpub |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
disabled account
2010-01-17 04:44:59 UTC
it actually unshades but is masked (you can see a tiny slim part of the window, best noticed when the client color is much different from the deco one) i'm however not sure whether this is really a functional bug or just a bad implementation (should the windows really auto-unshade while being dragged?) (In reply to comment #1) > it actually unshades but is masked (you can see a tiny slim part of the window, > best noticed when the client color is much different from the deco one) > > i'm however not sure whether this is really a functional bug or just a bad > implementation (should the windows really auto-unshade while being dragged?) Hm... You're right, I'm not sure about that... I believe both behaviors are equally usable, but since a consistent behavior would be the window unshading, I'd vote in favour of that.. *** Bug 235827 has been marked as a duplicate of this bug. *** There's still an issue with this - the window is passed the wrong geometry (even after the geometry restoring fix) -> my suggestion was to skip unshading if the window is in move and unshade it after the move/resize has finished (maybe invoking the hover timeout) Git commit feabb052f1434adb4f8a6f1dc203e07ad61a2355 by Thomas Lübking. Committed on 20/03/2012 at 16:38. Pushed by luebking into branch 'master'. don't hover unshade while moving REVIEW: 104280 M +2 -0 kwin/client.cpp http://commits.kde.org/kde-workspace/feabb052f1434adb4f8a6f1dc203e07ad61a2355 |