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

[Aaron J. Seigo]

On Thursday 12 June 2008, christian mollekopf wrote:
> > 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.

cool; can upload this patch to http://reviewboard.vidsolbach.de/dashboard/ so 
that i can review it there (the tool makes it soooo much easier)

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

it's not grouping that becomes an issue so much as it is sorting; one could 
sort by alphabetical order, by desktop, both ... grouping is orthogonal to 
sorting, however. it is used to group windows with a commonality (e.g. the 
belong to the same application) together into one entity; that entity then 
gets sorted with the rest of them.

> I guess Groups arent replaced by a single taskbaritem,  they're just
> grouped  in position and color.

well, we'll end up making them collapse down to a single item. one of the 
benefits of grouping is space savings.

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

i think this would be better as a separate applet tbh. it can share code with 
tasks, but it would be nice not to make tasks even *more* complex that it 
already is.

> I could start this task.

sure =)

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

isn't there already a group item in there?

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

yep. this patch looks ok, though i don't think you need to re-accept the drag 
object in dragMoveEvent.

> > 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();

.. or just trust the user to be somewhat smart about it and activate the 
window being hovered (after a delay) if the taskbar doesn't natively 
understand the mimetype.

that way the use pattern is: drag, hover over task representation, window pops 
up, move to window.

-- 
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/20080616/189d1805/attachment.pgp