Created attachment 181807 [details] Demonstration of bug SUMMARY Tasks set to appear "To the left" rearrange according to their "To the right" positions when dragged with "Sort: Manual" STEPS TO REPRODUCE 1. Under the behavior tab—Set "Sort: Manually" 2. Set "New tasks appear: To the left" 3. Ensure there is sufficient blank space in the task bar that "To the left" and "To the right" are visually distinct. 4. Try rearranging tasks normally—it doesn't work. 5. Try rearranging tasks by dragging them all the way over to where they'd normally by on the "To the right" setting. OBSERVED RESULT Tasks rearrange when dragged according to their usual position on the left side of the task bar even though they appear visually on the right. Additionally, while testing this I seem to have encountered another bug. I'll briefly note it here and make another report if I have more time. As you can see in the attached file, some tasks are unable to move past other tasks. This still happens when I set tasks back to their usual position of the left side of the bar. EXPECTED RESULT Dragging tasks should rearrange relative to where the cursor is and their current visual positions. SOFTWARE/OS VERSIONS KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.0 ADDITIONAL INFORMATION Kernel Version: 6.14.7-arch2-1 (64-bit) Graphics Platform: Wayland
> SOFTWARE/OS VERSIONS > KDE Plasma Version: 6.3.5 > KDE Frameworks Version: 6.14.0 > Qt Version: 6.9.0 Missed OS when copy/pasting. EndeavourOS
Can reproduce. Most likely an artifact of the 180° rotation hack we do here.
This is pretty bad; it's also broken in the same way in the default configuration for RtL locales, not just if you have the reverse order set.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3930
Git commit a0f6640045e3bdd9fbfcf748df1d624616f39903 by Christoph Wolk. Committed on 12/08/2026 at 16:26. Pushed by cwo into branch 'master'. applets/taskmanager: correct for initial spacer in RtL If a horizontal task manager is set to RtL (either from the locale or from the widget's reverse setting), the option to fill the available space will place this extra space at the front of the widget, rather than at the end (as in LtR orientations). This space is part of the widget, but not of the GridLayout. When doing drag&drop reordering of the entries, we look up the mouse coordinates in the GridLayout to find where we should put things. These coordinates are in the widget's coordinate system. This breaks rather badly, as our attempts to look up the correct position are shifted to the right by the extra space. Instead, we subtract the difference between widget width and layout width from the mouse X coordinate if the TaskList is RtL. This gives us the correct X position for vertical panels, and does nothing on vertical or non-filling widgets (as both have the same width, so the adjustment is zero anyway). FIXED-IN: 6.7.5 M +6 -2 applets/taskmanager/qml/MouseHandler.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/a0f6640045e3bdd9fbfcf748df1d624616f39903
Git commit c045dfd0a783e3b6acadfb9c7103db82aaf7934a by Christoph Wolk. Committed on 02/09/2026 at 09:18. Pushed by cwo into branch 'Plasma/6.6'. applets/taskmanager: correct for initial spacer in RtL If a horizontal task manager is set to RtL (either from the locale or from the widget's reverse setting), the option to fill the available space will place this extra space at the front of the widget, rather than at the end (as in LtR orientations). This space is part of the widget, but not of the GridLayout. When doing drag&drop reordering of the entries, we look up the mouse coordinates in the GridLayout to find where we should put things. These coordinates are in the widget's coordinate system. This breaks rather badly, as our attempts to look up the correct position are shifted to the right by the extra space. Instead, we subtract the difference between widget width and layout width from the mouse X coordinate if the TaskList is RtL. This gives us the correct X position for vertical panels, and does nothing on vertical or non-filling widgets (as both have the same width, so the adjustment is zero anyway). FIXED-IN: 6.7.5 (cherry picked from commit a0f6640045e3bdd9fbfcf748df1d624616f39903) Co-authored-by: Christoph Wolk <cwo.kde@posteo.net> M +6 -2 applets/taskmanager/qml/MouseHandler.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/c045dfd0a783e3b6acadfb9c7103db82aaf7934a
Git commit 78814fbd38275ee03ce7ec1bff9f6e3645488c22 by Christoph Wolk. Committed on 05/09/2026 at 10:20. Pushed by cwo into branch 'Plasma/6.7'. applets/taskmanager: correct for initial spacer in RtL If a horizontal task manager is set to RtL (either from the locale or from the widget's reverse setting), the option to fill the available space will place this extra space at the front of the widget, rather than at the end (as in LtR orientations). This space is part of the widget, but not of the GridLayout. When doing drag&drop reordering of the entries, we look up the mouse coordinates in the GridLayout to find where we should put things. These coordinates are in the widget's coordinate system. This breaks rather badly, as our attempts to look up the correct position are shifted to the right by the extra space. Instead, we subtract the difference between widget width and layout width from the mouse X coordinate if the TaskList is RtL. This gives us the correct X position for vertical panels, and does nothing on vertical or non-filling widgets (as both have the same width, so the adjustment is zero anyway). FIXED-IN: 6.7.5 (cherry picked from commit a0f6640045e3bdd9fbfcf748df1d624616f39903) Co-authored-by: Christoph Wolk <cwo.kde@posteo.net> M +6 -2 applets/taskmanager/qml/MouseHandler.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/78814fbd38275ee03ce7ec1bff9f6e3645488c22