*** Bug 489558 has been marked as a duplicate of this bug. ***

I'm not sure if this is a bug or intended, but I can duplicate the behavior. I used to be able to rearrange QuickLaunch icons in Plasma 5, but not in Plasma 6.

It's a regression, not intended.

can confirm this is still a thing on plasma 6.2.2

It's also very hard to drop icons into the quicklaunch and they always land at the beginning (left side). The only way to have them ordered is to drop them in the desired order. Also, the blue border where the icon would drop, only shows up (and glitches a lot) when no icons are in place. The next icons you drop, there's no way to know if you're dropping them in the quicklaunch widget or directly on to the bar.

Updating Plasma version for this bug, as it's still happening on 6.2.5 both on X11 and Wayland session.

I set the version back to what it was. Please don't change this. See the field descriptions here for an explanation
https://bugs.kde.org/page.cgi?id=fields.html#alias

(In reply to TraceyC from comment #7)
> I set the version back to what it was. Please don't change this. See the
> field descriptions here for an explanation
> https://bugs.kde.org/page.cgi?id=fields.html#alias

Understood! Sorry about that :)

Still can't rearrange quicklaunch icons in 6.3.6 on Debian Trixie. A workaround that's a little better than removing launchers and adding them back in is to edit the text file "~/.config/plasma-org.kde.plasma.desktop-appletsrc":

Find the line that starts with "launcherUrls=" and rearrange those urls in the desired order... You may need to log out and then log back in for the changes to take effect.

I have opened a merge request that addresses this issue here: https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/1029

Correcting status

Git commit b93257b9939f276546bb32f34276b838dca9fe99 by Nate Graham, on behalf of Alex Folland.
Committed on 08/04/2026 at 10:11.
Pushed by ngraham into branch 'master'.

applets/quicklaunch: fix drag-and-drop reordering in Plasma Wayland and prevent resulting Wayland-specific Plasma shell crashes

The original `DropArea` was defined as the first child of the root layout item, so other sibling objects in the hierarchy overlapped it in Z-order and consumed all drag events before the `DropArea` could receive any. In Wayland, Qt delivers drag events to QML items using Z-order hit-testing, so the `DropArea` must be on top of the stack to receive drag events. Moving the `DropArea` definition to the end fixes the Z-order so it receives drag events because it's on top of the stack by being created last. In X11, Qt's drag event routing does not use Z-order hit-testing in the same way, which is why this is not a problem there. Clicking to launch or see context menus, and hovering for tooltips both still work in Wayland with the fix.

In Wayland, a drag event's `event.mimeData.source` is always `null` because the drag has MIME data but not the exact source object reference. This causes `isInternalDrop()`, which relies on comparing the source object of the drag, to always return `false`, so every rearrangement drag is misdetected as a drag-and-drop from an external program. When misdetected this way, the drag triggers URL changes mid-drag (inserting and removing launchers), which causes asynchronous URL change event handlers (`onLauncherUrlsChanged` and `onPopupUrlsChanged`) to destroy and recreate all launcher instances while the drag is still active, crashing the Plasma shell. To handle that in Wayland, this instead detects internal drops by comparing the URL from the drag with URLs from the launchers, and guards the URL change event handlers to ignore changes mid-drag.

Also, this uses `ListModel.move()` to perform live reordering during a drag, which repositions items without destroying launcher instances, unlike `moveUrl()` which internally destroys and recreates launcher instances which leads to launchers disappearing when dragged away.

A further improvement would be to have the URL change event handlers queue any externally-applied URL changes to apply after the drag finishes so automatic external config changes are not lost if they happen while the user is dragging launchers around. That scenario is probably rare enough that it's not worth including with this Wayland fix.

M  +0    -4    applets/quicklaunch/IconItem.qml
M  +59   -20   applets/quicklaunch/Popup.qml
M  +97   -52   applets/quicklaunch/main.qml

https://invent.kde.org/plasma/kdeplasma-addons/-/commit/b93257b9939f276546bb32f34276b838dca9fe99