Taskmanager with grouping support preview version

[Aaron J. Seigo]

On Tuesday 08 July 2008, christian mollekopf wrote:
> > > 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.
> >
> > i'm highly dubious of the desire, let alone need, for this.
> >
> > can you give some actual use cases?
>
> they would be presented as grouping suggestions when one right-clicks on a
> taskitem.

sorry, i actually was looking for use scenarios (i'm guilty of using the two 
terms interhcangably at times)...

http://weblog.obso1337.org/2008/use-scenarios-and-use-cases/

i find coming up with such scenarios is a great way to direct development, 
especially of ambitious new features.

> > again, what are the use cases for this? maybe i'm just not getting what
> > you're vision is for the taskbar here, but ... yeah .. why should the
> > user care about such things? how would they interpret these colours?
> > etc...
>
> It would tell the user "Hey we have somthing you probably want to group,
> but we're not quite sure so its up to you".
> If the user groups it it is automatically done next time.
> If he doesn't the colors won't show up.
>
> But its maybe more distracting than useful.

i'm leaning towars "probably distracting". it is certainly something you could 
experiment with once your GroupingStrategy design is in place and working, 
though. i just would caution against trying to put this in right away, since 
it may not work out.

> > that would require publishing the data across processes (the alt-tab
> > switcher runs in kwin; runners are in krunner; the taskbar would be in
> > plasma) and so the objects still wouldn't be shared (rather they'd be
> > syncronized).
>
> Okay, but if i make the AbstractGroupableItem unguarded, wouldn't this make
> tasks stored as AbstractGroupableItem unguarded?

if an AbstractGroupableItem holds onto a TaskPtr, the TaskPtr is guaranteed to 
stick around as long as there is one AbstractGroupableItem referencing it. 
that's why it's critical that TaskPtr is always used and TaskPtr::data() is 
never stored.

> > there is no guarantee that every visualization will want to have the same
> > grouping strategy. if they do, they can find a way to share that strategy
> > amongst themselves. but putting that assumption in libtaskmanager itself
> > sounds artificially limiting.
>
> Click... Now i understand.
> You mean that we should be able to create a new representation tree of an
> existing group by simply creating a new GroupingStrategy.
> That makes sense.

right...

> But if were doing all the grouping in the GroupingStrategy im absolutely
> with you.

cool

> Hopfully im getting closer to your vision now =)

tbh, your ideas are pretty good and fresh and i haven't really had to add much 
at all. i've just offered a few bits of advice to hopefully keep the code from 
becoming too difficult to implement.

-- 
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/20080708/c7633ed9/attachment-0001.pgp