Summary: | Can't drag only a single window from one virtual desktop to another | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Peter <p.wibberley> |
Component: | effects-desktop-grid | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | 89q1r14hd, barbolanero, david.vuckovic7, eraygezer.94, eridanired123, fabian, hugh.garse, kde, kiril, mabo, nate, notmart, postix, Squashynator |
Priority: | VHI | Keywords: | regression |
Version: | 5.25.0 | ||
Target Milestone: | --- | ||
Platform: | Neon | ||
OS: | Linux | ||
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
Cannot move to a desktop with existing windows either, swaps them. in action |
Description
Peter
2022-06-14 18:54:08 UTC
Created attachment 149719 [details]
Cannot move a single window
Cannot move a single window in desktop grid also.
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.
*** Bug 455280 has been marked as a duplicate of this bug. *** Will be fixed by https://invent.kde.org/plasma/kwin/-/merge_requests/2523 (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 If all goes well, 6 days. (In reply to Nate Graham from comment #6) > If all goes well, 6 days. Excellent. Again, many thanks. P 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. :) 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 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 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. *** Bug 455486 has been marked as a duplicate of this bug. *** *** Bug 455488 has been marked as a duplicate of this bug. *** *** Bug 455516 has been marked as a duplicate of this bug. *** 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! (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 Created attachment 149935 [details]
in action
This is how it occurs in action.
(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? (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. 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 reproduced on wayland (and wayland only) touch dragging is quite broken A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2550 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 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 *** Bug 455479 has been marked as a duplicate of this bug. *** 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. Hooray! |