Taskmanager with grouping support preview version

[Aaron J. Seigo]

On Monday 07 July 2008, christian mollekopf wrote:
> hi, im just going to answer on point where i disagree or have further
> questions.

perfect.

> > so could you please commit your code into a branch in KDE's svn? that way
> > there's a hope of tracking what's going on and getting involved.
> > /branches/work/plasma-groupingtaskbar or something like that would be
> > great.
>
> I have an account now and will upload the files a soon as i have done the
> basic refactoring according to your comments.

awesome =))

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

> > * what is the purpose of having separate suggesting methods for names,
> > colours and icons, other than to go through the list 3 times? i can't
> > think of any situation where you'd only want the names or only the
> > colours, or in which having the other information would be detrimental.
> > on the flip side, going through the list N times is a bit wasteful. not
> > to mention it complicates the API =)
>
> Those methods were thought for later suggestions in the GroupEdit window
> where you should be able to choose between suggestions freely or enter new
> names, colors etc.

ok, makes sense =)

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

> The GroupingStrategy would hold the configuration and various other
> GroupingStrategies which are derived from AbstractGroupingStrategy and
> deliver the actual guesses.

that makes sense.

> > * where will ordering of items be handled? you seem to be assuming a
> > manual ordering of things always and that's not what most people want:
> > they want an automated ordering (alpha, by desktop, etc). i'm not sure it
> > belongs in TaskGroup because all task groups in a given collection should
> > behave similarly and alternative strategies would require either putting
> > all possible strategies into TaskGroup or making it subclassable.
> > (neither are pretty)
>
> The ordering should probably also be handled by the GroupingStrategy and we
> could have there a ManualOrdering mode...

agreed.

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

> > * there are gui concepts mixed into this data class. collapsed/not
> > collapsed is not a data concept, it's a visualization concept. all of
> > that logic belongs in the UI side.
>
> Thats true, but if i remove it i have to move the whole TaskRMBMenu class
> out of the lib and move it to workspace/plasma/applets/tasks/ so i have
> direct access to the collapsed() function.

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.

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.

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

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.

i don't see any really common use cases for shared GroupingStrategy.

what do you think?

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

> > > -It should be possible to have multiple rows and force a certain number
> > > of rows or let the LayoutWidget automatically appen and remove rows as
> > > needed.
> >
> > beware of "a million dialogs" syndrome
>
> This option isn't necessarily available to the user. Its more that the
> rootgroup can have several rows while subgroups can be forced to use just
> one...

ok, great =)

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

-- 
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/20080707/33703cfb/attachment-0001.pgp