Rearange tasks with drag and drop, Task Grouping

Tue Jun 17 16:49:05 CEST 2008

> well, perhaps you should publish first? =)

erm... maybe your right^^
I thought i could review the diff file there....

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

Shouldn't be too much of a problem (hopefully).
> 
>> 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... 

Do you think so?
I think its quite easy to work with...

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

glad to hear :)

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

well, i've got the svn code of course so....
do i have to download the 4.0 code? i don't have a clue where to look for this group class....

>> 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 =)

should i paste them on the reviewboard as well or just attach them to the mail?
I attached two of them because the others havent really changed. Most things are done in existing classes.

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

I was just about to do that^^
I think it would be quite reasonable because, the handling of thoes items are exactly the same 
exept for some details (different menu, keeping cursor on it pops up group instead of window...)

>> quite heavy, especially the Tasks class which handles all the sorting.
> 
> sorting probably belongs in the Group.

I put the TaskGroup class into  workspace/libs/taskmanager because i think there is the non-gui part, isnt it?
The TaskGroup just holds a List of pointers to the member tasks an groups.
I don't understand how the group should do the sorting..
At the moment the sorting is just what you do manually with Drag and Drop. 
This is a gui task and is done in the QLinearGraphicsLayout (Tasks class).
 The Drag and Drop mechanism just honors if a task is in a group so Groups stay together.

Do you think that the Sorting should go through the group?
So the Tasks are layoutet according to the order they are in the internal list in the group?

I think this would make things even more complicated...
Top Level tasks for example don't have a group. 
And if you drop task of a group somwhere, you would have to check where it was 
dropped and change its position in the TaskGroup accordingly.

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

Do i understand that right this would be like another QGraphicsLinearLayout in the Taskmanager(if it is expanded)?

If this is the case i think it would be reasonable replace the currently in Tasks managed QGraphicsLinearLayout with this new class because 
its exactly the same  for the groups, exept that the toplevel hasn't a group. 
The Tasks class would also contain a LayoutWidget so we could reuse everything for the expanded group and the Tasks class would get
a lot small if it doesn't have to handle all sorting issues.
Collapsed groups would be replaced by a GroupTaskItem which is derived from AbstractTaskItem.

PS:
I already started creating a LayoutWidget. The header is appended.
The m_layout in the Tasks group which was a QGraphicsLinearLayout before is now replaced by the LayoutWidget.
Unfortunately this way we need a new painter i think. Threfore i pass the Tasks handle to the layout in the LayoutWidget so they have a painter.

Don't know if its a bit too complicated to understand from this text =)

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

I don't want to provide to much of configuration there...
Maybe one could choose between several sets of colors, but im not quite there^^

> 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 
> =)

good idea^^

One thing is left. Should a Task be able to be member of more than just one group?
Could be reasonable for a chat programm that one uses for several tasks, but makes everything more complicated.
It's implemented in the task header as you can see but im just using the first item in the group for now.
_________________________________________________________________
Sie haben nie Platz in Ihrer Inbox? Mit Windows Live Hotmail haben Sie jetzt 5GB Speicherplatz - gratis! Holen Sie sich hier Ihren neuen  Windows Live Hotmail Account!
http://get.live.com/mail/overview
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: taskgroup.h
Url: http://mail.kde.org/pipermail/panel-devel/attachments/20080617/185141f2/attachment-0002.h 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tasks.h
Url: http://mail.kde.org/pipermail/panel-devel/attachments/20080617/185141f2/attachment-0003.h 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: layoutWidget.h
Type: application/octet-stream
Size: 3152 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080617/185141f2/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: layoutWidget.cpp
Type: application/octet-stream
Size: 9325 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080617/185141f2/attachment-0003.obj 