Bug 455268 - Can't drag only a single window from one virtual desktop to another
Summary: Can't drag only a single window from one virtual desktop to another
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-desktop-grid (show other bugs)
Version: 5.25.0
Platform: Neon Linux
: VHI normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: regression
: 455280 455486 455488 455516 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-06-14 18:54 UTC by Peter
Modified: 2022-06-27 21:27 UTC (History)
14 users (show)

See Also:
Latest Commit: https://invent.kde.org/plasma/kwin/commit/2eb0c67b0bc7ee62e37cb510fafeec66a012b53f
Version Fixed In: 5.25.1
Sentry Crash Report:

Attachments
Cannot move a single window (2.37 MB, video/mp4)
2022-06-15 00:01 UTC, hugh 		Details
Cannot move to a desktop with existing windows either, swaps them. (1.40 MB, video/mp4)
2022-06-15 00:02 UTC, hugh 		Details
in action (3.10 MB, application/octet-stream)
2022-06-19 23:21 UTC, Eray Erdin 		Details
View All Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Peter 2022-06-14 18:54:08 UTC 
SUMMARY
***
Since today's update, I can't drag single windows from one virtual desktop to another> can't drag one window at a time from one virtual desktop to another.
***


STEPS TO REPRODUCE
1. Set up 2 by 2 virtual desktops
2. Open a number of windows in one virtual desktop
3. Ctrl-F8
4. Position cursor over one window.  (Perimeter is highlighted.  NB I don't remember which setting gives this highlighting.)
5. Left click mouse and drag towards a different virtual desktop 

OBSERVED RESULT
Perimeter of the window under the cursor is highlighted but, when clicking and dragging, all windows in the virtual desktop move together.

EXPECTED RESULT
Only the window under the cursor should move.  (I believe this was the behaviour with Plasma 5.24)

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: KDE Neon
(available in About System)
KDE Plasma Version: 5.25.0 
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.4

ADDITIONAL INFORMATION
I don't know if this is related .....

I am also using an external monitor.  I can drag windows between virtual desktops all on the laptop screen or all on the external monitor screen.  However, if I try to drag windows from the laptop screen to external monitor (or vice versa) then, while in desktop grid view, the windows don't appear on the external monitor (when dragging from the laptop) or the laptop (when dragging from the external monitor).    

I can still drag single windows from laptop to external monitor or vice versa, when viewing any one virtual desktop.   

As always, thanks and regards
Comment 1 hugh 2022-06-15 00:01:00 UTC 
Created attachment 149719 [details]
Cannot move a single window

Cannot move a single window in desktop grid also.
Comment 2 hugh 2022-06-15 00:02:08 UTC 
Created attachment 149720 [details]
Cannot move to a desktop with existing windows either, swaps them.

Cannot move to a desktop with existing windows either, swaps them.
Comment 3 David Redondo 2022-06-15 07:43:39 UTC 
*** Bug 455280 has been marked as a duplicate of this bug. ***
Comment 4 Nate Graham 2022-06-15 16:27:05 UTC 
Will be fixed by https://invent.kde.org/plasma/kwin/-/merge_requests/2523
Comment 5 Peter 2022-06-15 16:56:16 UTC 
(In reply to Nate Graham from comment #4)
> Will be fixed by https://invent.kde.org/plasma/kwin/-/merge_requests/2523

Nate, 

Many thanks for this.  Can you say roughly how long it may take for the fix to be released as an update?  

Best regards

P
Comment 6 Nate Graham 2022-06-15 17:00:55 UTC 
If all goes well, 6 days.
Comment 7 Peter 2022-06-15 17:07:58 UTC 
(In reply to Nate Graham from comment #6)
> If all goes well, 6 days.

Excellent.  

Again, many thanks.

P
Comment 8 Nate Graham 2022-06-15 17:34:59 UTC 
Don't thank me, thanks Marco who's fixing it, and also thank him again for the wonderful QML port of the Desktop Grid effect in Plasma 5.25 that fixed a ton of bugs and ensures it will be easily maintainable for a decade or more to come. :)
Comment 9 Vlad Zahorodnii 2022-06-16 11:25:40 UTC 
Git commit e04542995e45d29c4b4ef8664a6653afa112cfd6 by Vlad Zahorodnii, on behalf of Marco Martin.
Committed on 16/06/2022 at 09:50.
Pushed by vladz into branch 'master'.

fix windows dragging in desktop grid

Don't disable the main drag handler when canclosewindows is disabled,
that one is not used to close windows but to drag them on other desktops or screens

M  +2    -1    src/effects/private/qml/WindowHeap.qml

https://invent.kde.org/plasma/kwin/commit/e04542995e45d29c4b4ef8664a6653afa112cfd6
Comment 10 Vlad Zahorodnii 2022-06-16 11:33:53 UTC 
Git commit 99529e584b3605c040ad5ad88792a28a2c1ff263 by Vlad Zahorodnii, on behalf of Marco Martin.
Committed on 16/06/2022 at 11:33.
Pushed by vladz into branch 'Plasma/5.25'.

fix windows dragging in desktop grid

Don't disable the main drag handler when canclosewindows is disabled,
that one is not used to close windows but to drag them on other desktops or screens


(cherry picked from commit e04542995e45d29c4b4ef8664a6653afa112cfd6)

M  +2    -1    src/effects/private/qml/WindowHeap.qml

https://invent.kde.org/plasma/kwin/commit/99529e584b3605c040ad5ad88792a28a2c1ff263
Comment 11 Fabian Vogt 2022-06-17 14:23:01 UTC 
While that patch fixes it for dragging windows with the mouse cursor, it's still broken when using the touchscreen here, always dragging all windows of that virtual desktop.
Comment 12 Nate Graham 2022-06-17 18:54:42 UTC 
*** Bug 455486 has been marked as a duplicate of this bug. ***
Comment 13 Nate Graham 2022-06-17 18:54:54 UTC 
*** Bug 455488 has been marked as a duplicate of this bug. ***
Comment 14 Patrick Silva 2022-06-18 14:12:45 UTC 
*** Bug 455516 has been marked as a duplicate of this bug. ***
Comment 15 Brian M 2022-06-19 02:23:46 UTC 
Issues:
  1) Confirmation of Peter's problem
  2) Additionally, current workspace no longer highlights
___________________________________________________________

As of 5.25 update, I began observing same behavior as this bug reporter (Peter) demonstrated in both videos.

Additionally, in my initial installation of Stable User KDE Neon, about 10 days ago, the desktop grid view emphasized the current desktop at normal brightness, with all other windows dimmed.  As you moved around the workspaces, the "brightened" desktop followed the cursor movement indicating the next desktop to be activated if clicked upon -- this highlighting no longer exists just as you can see in Peter's videos.  

All desktops now appear at full brightness with no implication of workspace change except by watching the cursor.  This is the case irrespective of grid layout (same in a single row of windows, as well as a grid configuration).
__________


System Information:

Operating System: KDE neon 5.25
KDE Plasma Version: 5.25.0
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.4
Kernel Version: 5.13.0-51-generic (64-bit)
Graphics Platform: Wayland
Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz
Memory: 31.1 GiB of RAM
Graphics Processor: Mesa Intel® Xe Graphics
Manufacturer: Framework
Product Name: Laptop
System Version: AB
__________

Thank you for all the work you folks are doing.  The gestures and overview are an especially welcomed addition!
Comment 16 postix 2022-06-19 10:12:43 UTC 
(In reply to Brian M from comment #15)
> Additionally, in my initial installation of Stable User KDE Neon, about 10
> days ago, the desktop grid view emphasized the current desktop at normal
> brightness, with all other windows dimmed.  As you moved around the
> workspaces, the "brightened" desktop followed the cursor movement indicating
> the next desktop to be activated if clicked upon -- this highlighting no
> longer exists just as you can see in Peter's videos.  
> 
> All desktops now appear at full brightness with no implication of workspace
> change except by watching the cursor.  This is the case irrespective of grid
> layout (same in a single row of windows, as well as a grid configuration).

That's a different issue tracked at #453999
Comment 17 Eray Erdin 2022-06-19 23:21:04 UTC 
Created attachment 149935 [details]
in action

This is how it occurs in action.
Comment 18 Marco Martin 2022-06-20 08:01:26 UTC 
(In reply to Fabian Vogt from comment #11)
> While that patch fixes it for dragging windows with the mouse cursor, it's
> still broken when using the touchscreen here, always dragging all windows of
> that virtual desktop.

this happening on both x11  and wayland?
Comment 19 Fabian Vogt 2022-06-20 08:04:09 UTC 
(In reply to Marco Martin from comment #18)
> (In reply to Fabian Vogt from comment #11)
> > While that patch fixes it for dragging windows with the mouse cursor, it's
> > still broken when using the touchscreen here, always dragging all windows of
> > that virtual desktop.
> 
> this happening on both x11  and wayland?

I only tried Wayland so far, I can try X11 later today if that helps.
Comment 20 Marco Martin 2022-06-20 08:32:59 UTC 
Testing a bit, i only kindof reproduced it, observing a slightly different behavior:
it seems that both with mouse and touch, the first time i try to drag a window it never works, the second time i try to drag the same window, it works fine
Comment 21 Marco Martin 2022-06-20 09:15:18 UTC 
reproduced on wayland (and wayland only) touch dragging is quite broken
Comment 22 Bug Janitor Service 2022-06-20 09:18:40 UTC 
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2550
Comment 23 Marco Martin 2022-06-20 10:11:08 UTC 
Git commit c1a536a52739f92f40ce72421c54354db57b3fac by Marco Martin.
Committed on 20/06/2022 at 10:11.
Pushed by mart into branch 'master'.

Fix dragging especially by touch

The drag manager of a window now can take over from anything, so that
the events to initiate a drag are not stolen by the tap handlers
(fixes the drag starts only the second time is tried issue)

On wayland drag by touch was completely broken by the supportsclosewindows check,
now the touch drag handler is always active and the check of the property is done only
when the drag is over

M  +2    -6    src/effects/private/qml/WindowHeap.qml

https://invent.kde.org/plasma/kwin/commit/c1a536a52739f92f40ce72421c54354db57b3fac
Comment 24 Vlad Zahorodnii 2022-06-20 10:16:07 UTC 
Git commit 2eb0c67b0bc7ee62e37cb510fafeec66a012b53f by Vlad Zahorodnii, on behalf of Marco Martin.
Committed on 20/06/2022 at 10:16.
Pushed by vladz into branch 'Plasma/5.25'.

Fix dragging especially by touch

The drag manager of a window now can take over from anything, so that
the events to initiate a drag are not stolen by the tap handlers
(fixes the drag starts only the second time is tried issue)

On wayland drag by touch was completely broken by the supportsclosewindows check,
now the touch drag handler is always active and the check of the property is done only
when the drag is over


(cherry picked from commit c1a536a52739f92f40ce72421c54354db57b3fac)

M  +2    -6    src/effects/private/qml/WindowHeap.qml

https://invent.kde.org/plasma/kwin/commit/2eb0c67b0bc7ee62e37cb510fafeec66a012b53f
Comment 25 Nate Graham 2022-06-21 17:48:46 UTC 
*** Bug 455479 has been marked as a duplicate of this bug. ***
Comment 26 Peter 2022-06-27 19:52:50 UTC 
Just updated to Build 64, and everything working again.  I notice also that the way windows move across the different virtual desktops on the different screens has also changed and  is, I think, now more intuitive and convenient than before.   

Thanks again to Nate, Marco, Vlad, and everyone else involved.   A beautiful DE.
Comment 27 Nate Graham 2022-06-27 20:00:14 UTC 
Hooray!