[PATCH] Rearange tasks with drag and drop

[Aaron J. Seigo]

On Thursday 12 June 2008, christian mollekopf wrote:
> applies to:
> windowtaskitem.h
> windowtaskitem.cpp
> tasks.h
> tasks.cpp
>
> This Patch adds support to rearange the tasks in the taskbar per drag and
> drop. It isn't possible to drag a task to another taskmanager which is
> correct.

the patch itself looks good. i do have one major concern, however:

how will this interact with auto sorting? eventually we'll want to provide the 
following sorting and grouping systems:

* no sorting
* alpha
* by desktop 
* group by application
* group by task? (or perhaps we'll just rely on group by desktop for this)

in all but the first one (no sorting) we'll now have two systems if drag 
sorting is always enabled. so i think this will need to be turned off in the 
case of sorting being on.

so what i'd like to see happen with this patch before it goes in is defining a 
TaskSortOrder enumeration in Tasks with values for the above items and have a 
member that is initialized to NoSorting. then only do the drag start if 
m_sortOrder == NoSorting.

we can worry about implementing the actual sorts later, but for now this means 
we won't have to go back and re-work *this* feature at that point.

as a side note, the pager should probably accept "taskbar/task" drops as well 
(i implemented that in kde3 and nobody complained and a few people seemed to 
actually like it; i know i did ;), and this patch is the important first step 
in that direction.

> A Problem i couldn't solve is that the cursor is a standart cursor is used
> during the drag.

what do you want instead?

> I noticed that the windowtaskitems accept every drop event
> they get. I think they should forward the events to the corresponding
> mainwindow but i dont know how to achieve this.

i'm not sure this is actually achievable today.

afaik it would require that windows advertise what to do on "generic drop"; 
the current model is to vary the drop depending on where in the window it is 
dropped, but we have no idea what mimetypes, etc a "whole window" accepts.

interesting area for research, though.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080612/bc0e67b1/attachment.pgp