Version: 4.4 RC1 (using Devel) OS: Linux Installed from: Compiled sources After the aero-snap feature has arrived I often un-maximize my windows when trying to click the menu-bar because I accidentally hit above on the window decoration. It seems that dragging it a pixel om something like that will un-maximize the window. I think we can avoid this by requiring that the window is dragged 50 px or so before it un-maximizes. Thanks for awesome window-managing.
Note: Aero Snap is a feature provided by Windows 7 and not by KWin! Bug reports to Aero Snap should be reported to the Microsoft Bug tracker. I have been using the quick maximization feature in kwin for quite some time and have never triggered it accidentialy. Clicking the title bar does not trigger the restore, there is a time delay. To me this is sufficient and I think a drag delay would be disturbing. It should be one or the other, not both.
Sorry for the microsoft lingo. I've triggered it some times, but perhaps we are using it differently. For reference, I'm using a touchpad on a laptop, and its normal for me that my other finger moves a little when I click it. Let's see if other people report it.
Well yes, I use a trackball, so I never click and move at the same time.
This has started to cause problems for me after an upgrade to 4.4.0, using a mouse. This probably is a result of my window behaviour settings: I have "Click to Focus", have unticked "Click raises active window" and set clicks in the Title Bar to "Raise" the window. The most common scenario that causes problems is switching between a maximised window (e.g. kate) and a normal window (e.g. konsole). Switching focus is fine, but when I want to raise the maximised window over everything else I move the mouse to the top of the screen then click in the titlebar and, whoops, I've restored the window. This happens the majority of the time and is fairly jarring. I don't know how the restore feature could be made less sensitive - perhaps by using velocity information?
Sounds like another case of missing startDragTime() and/or startDragDistance() handling?
*** Bug 228815 has been marked as a duplicate of this bug. ***
*** Bug 228819 has been marked as a duplicate of this bug. ***
Martin Gräßlin said in bug 228819: "KWin uses a drag delay (which should be changed to a pixel delay) for entering the moving mode." I think unmaximizing shouldn't happen until the user has moved the mouse a few pixels, however normal window moving shouldn't have a pixel delay like this, because it would feel choppy.
Nikola, KWin has both a distance as well as a time threshold when moving windows. If you think it feels choppy, please file an enhancement request to adjust those values ;)
Oops, you are correct, I didn't notice the distance threshold, so I guess it works perfectly :) Compared to moving the window a few pixels, unmaximizing it is much more jarring, so perhaps there should be a larger threshold in this case than the normal threshold. And I also don't think you should be able to unmaximize it just by holding the mouse button down. I only have problems with Chrome, and that's because of Chrome's custom decorations and incompatible behavior, but it seems that Pascal d'Hermilly and Oliver Henshaw had problems despite the thresholds built into KWin.
Update: Ubuntu is implementing window dnd by clicking the menubar. Here's the patch: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/gtk+2.0/lucid/revision/157#debian/patches/062_dnd_menubar.patch I haven't tested this as I don't run lucid, but I strongly suspect this will cause problems with all gtk apps, i.e. clicking on an empty portion of the menubar will unmaximize the window.
(In reply to comment #11) > I haven't tested this as I don't run lucid, but I strongly suspect this will > cause problems with all gtk apps, i.e. clicking on an empty portion of the > menubar will unmaximize the window. I suggest that you raise these concerns in launchpad. We as a upstream project are not responsible to fix bugs introduced by a downstream. AFAIK no kwin developer is using (K)Ubuntu, so there is no chance for us to test it.
I've commented at https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/532421 and https://bugzilla.gnome.org/show_bug.cgi?id=611313 It looks like this is a per-theme setting, so at least you can switch to a different gtk theme to fix it.
(In reply to comment #11) > I haven't tested this as I don't run lucid, but I strongly suspect this will > cause problems with all gtk apps, i.e. clicking on an empty portion of the > menubar will unmaximize the window. not necessarily. bespin has this feature (hack) longer than kwin provides aer..... "quick maximization" ;-) i naturally implemented the drag to start on mouse moves, _not_ presses/clicks, as that was far too annoying - regardless of the aer... "quick maximization" behaviour. just tested, there's no problem (and there's not even a minimum drag distance/timing)
The GTK patch calls gtk_window_begin_move_drag as soon as you press the mouse button. Like Chrome and like Compiz. (unless I'm reading the code wrong)
I just tried to require a window move before restoring the window and I did not succeed and will not try again to circumvent broken apps. Btw while testing I noticed that Chromium is completely broken in regards to window moving. If the window is the same size as the maximize area it will be maximized. *sigh* that gives me a good feeling how GTK apps will behave with CSD
*** Bug 240024 has been marked as a duplicate of this bug. ***
*** Bug 237055 has been marked as a duplicate of this bug. ***
This is in a way a dupe of bug #289494, just that that bug (if considered a bug, unrestricted moving is faaar older than quick maximization and has always been relaxed regarding all restrictions) is completely inside KWIn and not caused by debatable client behavior. I'll mark this as dupe, since either we threshold quick maximization for unrestricted move resize or not at all. (see commen #16) FTR: both, compiz is free to trigger move/resize on what ever it wants since it's a WM and chrome plays WM - both is no way comparable with "i clicked the wrong pixel in the menu and therefore the window started moving" *** This bug has been marked as a duplicate of bug 289494 ***