Bug 324910

Summary:	Task buttons can not be dragged to the first (top) position in a vertically placed taskbar widget
Product:	[Unmaintained] plasma4	Reporter:	Marcelo Sales <mmtsales>
Component:	widget-taskbar	Assignee:	Plasma Bugs List <plasma-bugs>
Status:	RESOLVED FIXED
Severity:	normal	CC:	hein
Priority:	NOR
Version:	4.11.0
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:	http://commits.kde.org/kde-workspace/bcb27fe25c1927b9bb0cb978f2a9462eb8bfca44	Version Fixed In:	4.11.2
Sentry Crash Report:

Description Marcelo Sales 2013-09-14 15:12:45 UTC

If a taskbar widget is placed in a vertical plasma panel and is configured to allow manual sorting of the task buttons, it is not possible to drag a button to the first (top) position of the widget. As a workaround, it is possible to drag it to the second position and then drag the first (top) button down to the second position, forcing the task button you had previously placed in the second position to move to the top position.
This was working perfectly before version 4.11.

Reproducible: Always

Steps to Reproduce:
1. Create a vertical plasma panel
2. Add a taskbar widget to that panel
3. Configure the taskbar widget to allow manual sort of the task buttons
4. Open several tasks, creating several task buttons on the taskbar widget
5. Try to drag one of the buttons to the first (top) position of the taskbar widget. You will be able to move it up only until it reaches the second positon, but not to the top position. You can then move the top button to the second position, forcing the other button to move to the top position.
Actual Results:  
You can't drag a button to the top position in a vertically placed taskbar widget.

Expected Results:  
You should be able to drag any button to any position you want.

Comment 1 Eike Hein 2013-09-14 23:00:57 UTC

Git commit cf574a938e08e4cf77fb4c552a0a4bdd1668191e by Eike Hein.
Committed on 14/09/2013 at 22:55.
Pushed by hein into branch 'KDE/4.11'.

Simplify insertion index calculation for DND reordering.

The original code took a stab at there being some travel resistance
to drags to avoid undesired accidental moves, but aside from doing
this in a naive (and buggy) way, it also turns out to be unnecessary
in further testing: Drag initiation has resistance to it anyway, and
during moves, the lack of resistance makes accidental overshoots
easy to correct for, along with the upside of making DND feel much
more fluid.

M  +6    -18   plasma/desktop/applets/tasks/package/contents/code/tools.js
M  +3    -1    plasma/desktop/applets/tasks/package/contents/ui/MouseHandler.qml

http://commits.kde.org/kde-workspace/cf574a938e08e4cf77fb4c552a0a4bdd1668191e

Comment 2 Eike Hein 2013-09-14 23:03:08 UTC

Git commit bcb27fe25c1927b9bb0cb978f2a9462eb8bfca44 by Eike Hein.
Committed on 14/09/2013 at 22:55.
Pushed by hein into branch 'frameworks-scratch'.

Simplify insertion index calculation for DND reordering.

The original code took a stab at there being some travel resistance
to drags to avoid undesired accidental moves, but aside from doing
this in a naive (and buggy) way, it also turns out to be unnecessary
in further testing: Drag initiation has resistance to it anyway, and
during moves, the lack of resistance makes accidental overshoots
easy to correct for, along with the upside of making DND feel much
more fluid.

M  +6    -18   plasma/desktop/applets/taskmanager/package/contents/code/tools.js
M  +3    -1    plasma/desktop/applets/taskmanager/package/contents/ui/MouseHandler.qml

http://commits.kde.org/kde-workspace/bcb27fe25c1927b9bb0cb978f2a9462eb8bfca44

Comment 3 Marcelo Sales 2013-09-14 23:33:51 UTC

Wow! I had just reported this bug and it is already fixed! :)
Thanks!

Comment 4 Eike Hein 2013-09-14 23:36:13 UTC

Thanks for the report! :)