[PATCH] Rearange tasks with drag and drop, Drop tasks on pager

[christian mollekopf]

> 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.

I implemented the enum as you suggested. 

Wouldn't it be possible to assign a shortcut for grouping so we could still use the sorting with drag and drop.

I guess Groups arent replaced by a single taskbaritem,  they're just grouped  in position and color.
In this case i would suggest that you can still sort the items among the group memers. 
If you drag a group member outside the group the rest of the group just follows to the new location. 
Of course all minimize or maximize functions would apply on all group members.

I think we should also add a taskmanager mode where it just displays tasks which were explicitly dropt on it.

I could start this task. At least without those automatic group modes.
I would implement just manual grouping for beginning. Seems to be a doable task for me at least from the Programming Skills POV.

Implementation:
There are two ways i can think of. We could create a taskGroupItem class which has its own qgraphicslinearlayout and looks like one normal task  to Tasks class, 
or we could handle the whole stuff in the Tasks class...
I would prefer the taskGroupItem..

> 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.

Implemented in second patch.
On drop the virtual desktop is also changed and im not sure if this is good, 
but it also works this way if you drag the window directly on the pager so i kept the behaviour.


>> A Problem i couldn't solve is that the cursor is a standart cursor is used
>> during the drag.
>
> what do you want instead?

Ok, maybe the sentece wasn't optimal^^
What i mean is, that during the drag i get the black standard qt cursor instead of the grey oxygen cursor.
I could set it during the drag with setDragCursor(QPixmap ), if i only knew where to retrieve the cursor.


>> 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.

One have just to keep in mind that all events which may be meant for the taskmanager are catched this way by the tasks.
Therefore we should maybe just comment out the event->accept(); 

_________________________________________________________________
Windows Live Spaces - Ihr Leben, Ihr Space. Hier klicken und informieren.
http://get.live.com/spaces/overview
-------------- next part --------------
A non-text attachment was scrubbed...
Name: taskbarDragDrop.diff
Type: application/octet-stream
Size: 9467 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080612/cbabe2bf/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pagerTaskDrop.diff
Type: application/octet-stream
Size: 3909 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080612/cbabe2bf/attachment-0003.obj