Version: unspecified (using KDE 4.4.2) OS: Linux Periodically, when a maximized window is first sent to bottom of the stack and then reselected, it will un-maximize. This happens erratically with no pattern I have noticed, but can be reliably reproduced on my system with a strange sequence of events. The specific sequence of events to reproduce it reliably are unlikely to occur in normal activities, but it also happens at other times with no pattern I have been able to discern. Reproducible: Sometimes Steps to Reproduce: Assuming that I have window A that is maximized and active and at the top of the stack and window B that is not maximized and below window A, if I send window A to the bottom (middle-click on titlebar), then left-click on the titlebar of window B, then left-click on the titlebar of window A once more, window A will reduce from maximization. This happens often if done in that order slowly, but has a 100% chance of happening if all that is done in less than 1 second. Two other specific details with how this happens: It only happens to a window if the window is activated by selecting the titlebar, not by selecting the contents of the window; It only ever happens if the selected window is at the bottom of the stack (if there are other windows below it, I've never seen this happen, although the amount of windows above the window does not seem to matter). Actual Results: Window becomes un-maximized. Expected Results: Window should remain maximized. I am using the defaults window settings after upgrading Kubuntu to version 10.04. When I run "kwin --version" it says "KWin: 4.4.2 (KDE 4.4.2)" which was not an option on "application version" dropdown, so I left that as "unspecified".
please uncheck "Maximize windows by dragging them to the top..." in the "Screen Edges" page of kwins config dialog (rmb any titlebar, "configure...") and see whether the problem remains. do you use a notebook/touchpad?
I didn't even know that option existed. As it turns out, that does solve the problem. So, an easy-to-work-around bug. Thank you very much. (and no, I do not use a notebook/touchpad)
it however seems you're triggering a move - do you feel that happens to easy? (that's why i asked about the touchpad - most of them are -frankly- crap ;-)
Yeah, I'm using a regular optical mouse, so it's not just that I'm working with a crappy input device. Yes, it's now clear that it's triggering a move, and after a little testing with that option turned back on, I'd definitely say that it's happening far too easily. I see no visual indication of motion whatsoever. I am not clicking-and-dragging, just using one quick click, so the behavior is very unexpected. Watching closely while doing this several times, it becomes clear that it happens no matter how little I actually move the cursor. If it is adjusted by even a single pixel while I am clicking, this happens, and that's just easy to do accidentally. It seems like the sort of thing that should have a threshold, like at least 5 pixels or at least a half of a second of holding down before it tries moving the window, but I have no idea how much trouble that would cause to other use-cases.
"kcmshell mouse" / "advanced" check "drag start time" and "start distance"
... forget - the value is apparently ignored
*** This bug has been marked as a duplicate of bug 222100 ***