Taskmanager with grouping support preview version

[christian mollekopf]

> From: aseigo at kde.org
> To: panel-devel at kde.org
> Subject: Re: Taskmanager with grouping support preview version
> Date: Mon, 7 Jul 2008 13:34:15 -0600
>
> > > * in the taskbar we're usually getting one task at a time from the window
> > > manager (as windows are added/removed). i don't see any API that easily
> > > maps an item to an existing group. that seems odd. where does the "which
> > > group should this task be put in?" code currently exist?
> >
> > You're right, the task should probably first be passed to the
> > GroupingStrategy which tries to put it into the best TaskGroup or the
> > RootGroup. The group which receives the task, then tries to group fitting
> > tasks together.
>
> right ...
>
> > my idea of the GroupingStrategy is that as soon as a AbstractGroupableItem
> > is added or removed to a TaskGroup, the TaskGroup passes its children to
> > the GroupingStrategy singleton, and the singleton returns possible matches
> > which items should group together. If the match isn't just possible but
> > rather for sure, the Group groups the items according to the
> > GroupSuggestion returned by the GroupingStrategy. If the match is just a
> > suggestion the Group ignores it. Everytime the user groups tasks manually
> > or renames a group the GroupingStrategy learns from it.
>
> ah, so GroupingStrategy would then return N different possibilities? how would
> it know which suggestions map to which GroupableItem? actually, what i'd
> probably do is just have GroupingStrategy do all the work, breaking TaskGroups
> up, creating new ones, etc. that way all the logic is one place and you don't
> have the annoyance of having to pass information from GroupingStrategy to
> TaskGroup back to GroupingStrategy (which is what the current API does).
>
> otherwise, it sounds like a sound approach.

Hmm... lets say each TaskGroup has its own GroupingStrategy. If an item is added/removed 
to the group the GroupingStrategy checks for items that match according to one 
of the implemented grouping strategies.
If it is an absolute match and it is save to group those items without user 
interaction everything is fine.
But what if user interaction is needed? I think every GroupableItem has to 
hold a list with all group suggestions they fit in, so those options 
can be presented to the user. 
The GroupingStrategy isn't directly in touch with the user i think.

If an item is added we could slightly colorize items that could possibly fit 
and the color would fade out without interaction of the user after
5-10sec or so. This way we could show the user the possibility of grouping. 


> > > the way i might go about it is have the strategy manage a collection of
> > > groups that it then exports. this would be a tree of objects representing
> > > the groups and their nesting. groups would contain items and be
> > > completely stupid about the grouping mechanics. that way the relationship
> > > between group and strategy is obvious, it's clear how multiple strategies
> > > would work in parallel, and give a sane point for configuration
> > > management
> >
> > I don't get this part, sorry. On what would this tree of groups be based?
>
> it would be a mapping of the TaskPtr collection into a hierarchical structure
> meant for display. the mapping would be done by the GroupingStrategy. so we'd
> have:
>
> TaskManager: manages a random collection of TaskPtrs that map to the actual
> windows
>
> GroupingStrategy: maps the TaskPtrs into a structure that makes sense for
> displaying
>
> Taskbar widget: creates pretty things on screen that follows the
> GroupingStrategy's hierarchy


Wouldn't the whole hierarchy have to be reevaluated if an item gets added to a group?
I think it is better if the GroupingStrategy of the current rootGroup adds the new task 
to a reasonable subgroup or keeps it otherwise.

> not at all =) the menus can stay in the library quite easily.
>
> or really, the QActions can.
>
> i've never really been a huge fan of the menus themselves being in the
> library, but the functionality they provide makes lots of sense. what we
> really want is a class or set of classes here that provides a set of QActions
> that can then be plugged into a menu.

Thats a good idea. This way we dont have to do actions over the edge of the non-gui-class 
and everything is properly separated.

> two possible approaches:
>
> * TaskActions class with a QList<QAction*> actions() method. the QActions
> would be connected to slots in TaskActions that perform the actual work.
>
> * a set of QAction subclasses, such as MinimizeAction, which can be created
> and put into menus.
>
> the former is less work, the latter is a lot more flexible. in fact, the two
> approaches could even be combined where TaskActions is a simple factory class
> for determining which of the specialized QActions to create based on a set of
> Tasks handed in. that might even be the best solution.

I will see what i can do, but it sounds good :-)

> > typedef KSharedPtr<AbstractGroupableItem> AbstractPtr;
> > typedef KSharedPtr<TaskGroup> GroupPtr; //Task group inherits
>
> this doesn't address the problem of TaskPtr also being used improperly (hint:
> never access TaskPtr::data()). that's the real issue here: TaskPtr represents
> a window and is shared by everything that uses this library. it is what needs
> protecting against usage-after-deletion.

My Idea was that tools like the ProgramSwitcher (alt-tab) could support groups 
created in the main taskbar.
Or there could be runners which use the Groups, or it could be possible in the 
future to have a GroupManagerWidget where you could store your groups...
But i'm not quite sure if this is a good idea anymore. But therefore i though 
it would be reasonable to share all those classes.

> but i don't think it's meaningful to try and share the AbstractGroupableItems:
> those will be specific to each visualization (e.g. a taskbar on the panel).
>
> it's probably more sane to have each visualization use their own set of
> groupable items. in this pattern, each visualization would have its own
> GroupingStrategy and that GroupingStrategy would maintain its own collection
> of groups and items.

Agreed. The way it works at the moment is that every visualization (Taskmanager) 
has its own rootGroup so groups that are created on a certain visualization aren't 
created on another too. But i don't see the point of creating several GroupingStrategy.

> i don't see any really common use cases for shared GroupingStrategy.
>
> what do you think?

I think the GroupingStrategy learns from the user this should affect all visualizations, 
so a newly created group on one visualization is instantly available as a suggestion on 
another visualization. The GroupingStrategy has to get the groupmembers of the Group 
currently evaluating anyway so i don't see the point of having a GroupingStrategy in each visualisation.
And finally the GroupingStrategy should save its statistics about what the user grouped 
together and a think its too complicated to distinguish on which visualization the user grouped them.


> > > > -Save custom order on collapse group
> > >
> > > custom order? you mean the order someone has dragged the item into? this
> > > is not going to work with automated systems, or at least make them very
> > > complicated, or require being able to switch
> >
> > Well, then at least in this mode. To me as a user it was almost a "must
> > have" feature to sort the items as i like but its maybe not that crucial
> > anymore with groups...
>
> we didn't have this feature in kde3, either, of course. being better than kde3
> is of course one of our goals. i'm just trying to offer some caution here to
> make sure that the new taskbar code doesn't end up becoming an insane maze in
> an attempt to satisfy too much flexibility.

Sounds absolutely reasonable :-) I think i will just freeze that feature until 
the rest is a bit more stable...

> > > > -Implement Dragging of expanded groups by dragging groupmember outside
> > > > of group
> > >
> > > unless the implementation is more straightforward than the description,
> > > this could be a problematic feature.
> >
> > This works actually quite well...
>
> i'm not questioning that it works well from a purely "does it work without
> bugs" POV, but from a "is this something that users will actually find
> enjoyable" POV. i'm reserving my own judgement until i can actually try it out
> =)

I'm gonna try it on my family so we have a feedback of an average "dumb" user ;-P


So as a summary of my (current)vision:
-Each visualization has its own rootGroup which manages its own 
set of abstractGroupableItems.

-The GroupingStrategy gets called by the altered group but is global 
so the learning effort is as well.

-The GroupingStrategy takes the configuration (SortingMode etc.) from 
the group so this isn't global. 
(we should be able to have differently 
configured taskbars, and since a rootgroup virtually represents a 
visualisazion we can put this in the TaskGroup and there is still 
the possibility for future modifications, to let different groups 
behave differently without any extra effort.)

Regards Chris



_________________________________________________________________
Es ist höchste Zeit dabei zu sein - Holen Sie sich jetzt die neue Generation der Windows Live Services!
http://get.live.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20080707/abee2fb0/attachment-0001.html