Summary: | Window movement does not honour StaticGravity | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Billy Biggs <vektor> |
Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Debian testing | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Billy Biggs
2004-08-14 18:22:02 UTC
I'm sorry, kwin is not alone. The OS X window manager moves around with _both_ NorthWestGravity and StaticGravity. Is this WM broken in a new and different way? The fact that the window doesn't move if it requests the same position with NorthWest gravity is a feature. There are applications like XV which request positioning on the same place this way, so KWin ignores such requests, and I don't think there are cases when any app would request position in such way and wouldn't be broken. NorthWest positioning with different position works in KDE3.3.0 as specified by ICCCM, just like other gravities. I'm not sure if it has worked in KDE3.2.3, but as there is no 3.2.4 planned -> closing. I understand the situation with NorthWestGravity, but my concern here is purely about StaticGravity. It does not seem to be behaving correctly in kwin 3.2.2. Can you confirm that it is broken, or check if my sample application does not move with StaticGravity under kwin in 3.3.0? As I said, StaticGravity works in 3.3.0. Note also that keeping normal windows inside the workarea has higher priority than gravities, so e.g. trying to position a window at (0,0) with kicker on top is not going to work regardless of the gravity. Thanks. |