Bug 324391

Summary: Manually reordering task bar items not possible anymore without creating unintended shortcut icons
Product: [Plasma] plasma4 Reporter: Janek Bevendorff <kde>
Component: widget-taskbarAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED FIXED    
Severity: major CC: clemens.brunner, hein, jirislaby
Priority: NOR Keywords: regression
Version: 4.11.0   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In: 4.11.2

Description Janek Bevendorff 2013-09-02 11:32:20 UTC
When I reorder taskbar buttons with the mouse, it always creates a shortcut icon for it which I actually don't want to create.

Steps to reproduce:
1. Create a taskbar widget on a panel, right click on it and open the taskbar settings.
2. Set "Sorting" to "Manually" and close the dialog.
3. Open at least two (non-modal) windows that show up on the taskbar
4. click the right-most and drag it to the left

Actual results:
A shortcut icon for the program is created left to the taskbar widget

This bug has been introduced in 4.11 (beta) and has not appeared in earlier versions.
Comment 1 Myriam Schweingruber 2013-09-02 14:53:30 UTC
Confirmed with  KDE 4.11.0
Comment 2 Eike Hein 2013-09-02 15:05:08 UTC
Do you have widgets unlocked? Because dragging a task outside of the Task Manager with widgets unlocked is expected to insert an icon widget, that's not a bug (I heavily use manual reordering myself and have no problems here with widgets locked).
Comment 3 Myriam Schweingruber 2013-09-02 15:15:50 UTC
I didn't drag outside the Task manager, but in the middle of it, but this created an icon outside. And yes, I have the widgets unlocked.

FWIW: I just tested this behavior, I don't usually do manual reordering.
Comment 4 Eike Hein 2013-09-02 18:09:20 UTC
Git commit e1a590badee13b862c5393f45ea59ecad98a7267 by Eike Hein.
Committed on 02/09/2013 at 18:08.
Pushed by hein into branch 'KDE/4.11'.

Don't propagate drops to the containment while animating.

Plus a little cleanup in the drag move and leave code ...

M  +14   -13   plasma/desktop/applets/tasks/package/contents/ui/MouseHandler.qml

http://commits.kde.org/kde-workspace/e1a590badee13b862c5393f45ea59ecad98a7267
Comment 5 Eike Hein 2013-09-02 18:10:44 UTC
The above commit fixes this issue, thanks for the report. As a clumsy but effective workaround for 4.11.0: Wait with dropping until the reordering animation finishes.
Comment 6 Janek Bevendorff 2013-09-02 18:13:25 UTC
Waiting until the animation finishes doesn't work very reliably. Most 
of the time that still creates a quick launch icon or sometimes also 
just an empty placeholder for an item (which can't be removed unless I 
explicitly place a new icon there and then remove that one).
Comment 7 Eike Hein 2013-09-02 18:16:53 UTC
Well, then just apply that patch locally if you prefer (it's a QML file, so you don't need to recompile).
Comment 8 Janek Bevendorff 2013-09-04 14:58:15 UTC
Short question: this fix won't solve problems with dragging taskbar 
items to a pager widget, will it?
This is a similar issue I've been experiencing since the 4.11 betas. 
Dragging a taskbar button to one of the rectangles on a pager widget 
worked fine in 4.10.x and earlier, even with an unlocked desktop. Since 
4.11 this always creates shortcut icons if I'm not very, very careful.
Comment 9 Eike Hein 2013-09-05 01:00:54 UTC
Dragging tasks to the pager didn't work at all in 4.11.0 because of a missing feature in an underlying QML library. I readded this very early in the 4.11.1 release cycle after the library's maintainer came back from vacation to review my proposed patch. Between that addition, some further work on the DND code and this fix, dragging tasks to the pager should work very well now.
Comment 10 Eike Hein 2013-09-05 01:02:36 UTC
(Note though that you can easily avoid any sort of "create shortcut" problem by simply locking widgets.)
Comment 11 Eike Hein 2013-09-18 06:20:02 UTC
*** Bug 325030 has been marked as a duplicate of this bug. ***
Comment 12 Eike Hein 2013-09-25 11:59:40 UTC
*** Bug 325294 has been marked as a duplicate of this bug. ***