Bug 220088 - Add option to disable desktop window switching in desktop grid
Summary: Add option to disable desktop window switching in desktop grid
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist with 1 vote (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-25 20:49 UTC by Roman Odaisky
Modified: 2012-03-11 18:37 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
patch against 4.6 (2.62 KB, patch)
2011-02-15 01:05 UTC, Thomas Lübking
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Odaisky 2009-12-25 20:49:01 UTC
Version:            (using Devel)
OS:                Linux
Installed from:    Compiled sources

The Desktop Grid with Present Windows activated exhibits rather a strange behavior. If I drag a desktop with more than one window by its empty space, all the windows are dragged, and if they’re moved to another desktop this way, the windows that had been there before jump to the desktop from where the dragged windows approached. The same happens if windows are tabbed together — in the grid they’re shown as one, but dragging empty space separates the windows temporarily, and other strange things happen in this case.

Is any of that intended behavior and if so, is it documented anywhere?
Comment 1 Roman Odaisky 2009-12-25 20:50:04 UTC
The “Compiled sources” tag is wrong, I’m using KDE 4.4 beta 2 from Ubuntu PPA.
Comment 2 Martin Flöser 2009-12-27 10:45:42 UTC
This is intended behaviour and by that I change to whishlist.
Comment 3 Mats Ahlgren 2011-02-13 23:21:29 UTC
This feature however is quite buggy. I never intend to drag desktops, but it happens "automatically" very often when I activate Desktop Grid. It also causes a usability problem -- "why did this happen?".

Due to simplicity and buggy behavior, I humbly suggest either increasing priority or reverting to bug status.

(And to deal with usability, I humbly suggest that there be graphical indicators of what happened, e.g. popup text saying what happened, or an anchor icon or grip bar on the bottom-right corner of each desktop; in fact, perhaps a grip/anchor area should be the only way to drag a desktop? because "free desktop space" is undiscoverable if the user uses predominantly maximized windows)
Comment 4 Thomas Lübking 2011-02-13 23:50:30 UTC
(In reply to comment #3)
> This feature however is quite buggy. I never intend to drag desktops, but it
> happens "automatically" very often when I activate Desktop Grid.
Err... could you please explain "how"?
(Whether the effect is triggered by an active screen corner or a shortcut, i can hardly imagine an "automatic" trigger, sorry)

> Due to simplicity and buggy behavior, I humbly suggest either increasing
> priority or reverting to bug status.
Sorry, but "errrmmm..." again: 
you claim the bug status by the claim of a claim [sic!] of a bug while claim and proof of any actual "bug" is pending and your case just is an uncommented "i trigger this accidentally"?
Comment 5 Mats Ahlgren 2011-02-14 00:02:41 UTC
After attempting to replicate this, I was able to instantly replicate it with 100% success after a few seconds.

If one triggers the desktop wall behavior on the top-left corner and clicks, there is a race condition where the desktop you switch to and the desktop you're coming from will be perma-switched.

I can only conclude that the desktop wall is incorrectly determining what constitutes a drag by considering the mouse to be held-down at the start of the process.
Comment 6 Thomas Lübking 2011-02-14 16:39:36 UTC
I can somewhat confirm the behaviour (there's no race, the window just switches and oc. one must not be on VD1 and the animation should not be faster than "normal") 

While i would not consider this "accidentally"  (touchpad, i assume? if you "accidentally" cause mouseclicks, you've bigger issues than this...) and the behavior is actually consistent and "expectable" (you click & hold desktop >1, but the area below changes and the next move events will happen on desktop 1) the result is weird and should not happen, notably since one cannot move windows during the animation either (iirc that was changed after introducing this feature) - this is however not this bug, but instead a valid one =)
Comment 7 Thomas Lübking 2011-02-15 01:05:07 UTC
Created attachment 57265 [details]
patch against 4.6

patch (for comment #5 issue) attached, review request as soon as i don't get weird certificates for git.reviewboard...
Comment 8 g111 2011-04-09 14:12:18 UTC
Swapping all windows of two desktops is a cool feature. I did not know this yet ;)

Regarding the patch for comment #5: Is this included in KDE4.6.1 already? If it is, I think it works, as I cannot reproduce the wrong behaviour here (aptosid debian/experimental-snapshots)
Comment 9 Thomas Lübking 2011-04-09 20:32:43 UTC
No, i completely forgot about the bug :S
I'll cook up review requests for 4.6 & 4.7 ... sorry :-(
Comment 10 Thomas Lübking 2011-04-23 13:11:59 UTC
Git commit a389a45ecaea2577f5162edd1485356c81263cce by Thomas Lübking.
Committed on 15/02/2011 at 00:55.
Pushed by luebking into branch 'KDE/4.6'.

prevent swapping desktops w/o explicit button press after animations have finished

CCBUG: 220088

M  +4    -1    kwin/effects/desktopgrid/desktopgrid.cpp     
M  +1    -1    kwin/effects/desktopgrid/desktopgrid.h     

http://commits.kde.org/kde-workspace/a389a45ecaea2577f5162edd1485356c81263cce
Comment 11 Thomas Lübking 2011-04-24 22:28:48 UTC
Git commit 3a617f745eb61c774c583b207e1e8f5eea7162ea by Thomas Lübking.
Committed on 24/04/2011 at 22:21.
Pushed by luebking into branch 'master'.

forward port of a389a45ecaea2577f5162edd1485356c81263cce

prevent accidental desktop swaps

CCBUG: 220088

M  +4    -1    kwin/effects/desktopgrid/desktopgrid.cpp     
M  +1    -1    kwin/effects/desktopgrid/desktopgrid.h     

http://commits.kde.org/kde-workspace/3a617f745eb61c774c583b207e1e8f5eea7162ea
Comment 12 Martin Flöser 2012-03-11 18:37:50 UTC
I assume the committed patch improves the situation. If not please reopen.