[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