[PATCH] Rearange tasks with drag and drop, Task Grouping

Aaron J. Seigo aseigo at kde.org
Tue Jun 17 01:31:41 CEST 2008


On Monday 16 June 2008, christian mollekopf wrote:
> > 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)
>
> hmm...
> if i try to upload the patch and click on view diff before publishing i get
> this:

well, perhaps you should publish first? =)

> Top Level Groups (group which isn't in a group) should basically be
> expanded. The groups ar colored and in the menu there are these entries
> plus some i forgot, but you get an idea: -All To Desktop
> -All To Desktop
> -Minimize All
> -Maximize All

sounds good..

> -Leave Group(just this task leaves group)
> -Group Menu-> delete Group (group gets completely removed)
>                       all single tasks with their normal entries
> -Collapse to Groupitem

managing these states is going to be "fun".

> If you click on a task just this one is affected and not the whole group.
> Those tasks can be dragged around freely if GroupSorting is enabled.
> The tasks can be sorted among the group members and if you drop a task
> outside of the group the rest of the group follows.

in a no-auto-sort, this will work fine.

> All groups that aren't toplevel are collapsed by default but can be
> expanded. They have the same menu like the ones above but the whole group
> is affected by clicks on them. If GroupSorting is activated they can be
> dragged around as well.
> If the cursor stays on a GroupTaskItem for some time (0.2s-0.5s) there
> could  show up a little tooltip which is a QLinearGraphicsLayout itself and
> contains the group members. This way everything could be done by dragging.

that could work..

> If the groupModifierKey is pressed one can group or ungroup tasks with drag
> and drop by simply dragging them on each other or out of the group.

this will be tricky (but not impossible) to get "right" from an interaction 
feel POV... 

i'm really interested to see what you come up with here for a first draft...

> >> 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?
>
> Maybe you mean the AbstractGroupingStrategy in plasma/applet/tasks/future
> but i think this one is for automatic group suggestions.

no, i was thinking of the 4.0 code base which has a Group class.

> I created a new class that can hold other groups or tasks.

that sounds about right.

> The groups are stored by the Taskmanager base class, because its the only
> one that is always there.

can you share your class headers? would make following this a lot easier =)

> For the TaskGroupItem I will probably just subclass the WindowTaskItem.

i'm not sure that makes a lot of sense. there used to be an AbstractTaskItem 
and GroupTaskItem and WindowTaskItem subclassed from it. this is a bit over-
engineered, really, but i think it at least got the idea that Group and Window 
are not related right.

> quite heavy, especially the Tasks class which handles all the sorting.

sorting probably belongs in the Group.

> Would it make sense to make a different class with the Drag an drop stuff
> and the layouting in it and derive the Tasks class from it? I'm not sure if
> it is the right approach.

no, because Tasks should derive (as it does now) from Applet. i suggest a 
third class: TaskGroup, which subclasses QGraphicsItem or QGraphicsWidget and 
implements sorting and grouping. grouping can be done by creating TaskGroups 
in a TaskGroup.

TaskGroups can then either collapse or show all items side by side, for 
instance. one could even expand individual groups as you note about....

> A problem I came across is the colorizing of the WindowTaskItems. The whole
> thing there with svg and so on seems quite weird.
> If someone has an idea how to colorize them... any help is appreciated :)

 you can use one of qimageblitz's effects. i'm a little concerned about the 
level of configuration this (and all the other features) is going to put on 
both the code and the user.

as a suggestion: don't worry about colorizing groups now. get the basic 
interaction done first and then worry about prettying it up more at that point 
=)

-- 
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/6dc9979c/attachment.pgp 


More information about the Panel-devel mailing list