Taskmanager with grouping support preview version

[Aaron J. Seigo]

On Monday 07 July 2008, christian mollekopf wrote:
> > otherwise, it sounds like a sound approach.
>
> Hmm... lets say each TaskGroup has its own GroupingStrategy.

i'd assume that the there would be one GroupingStrategy for each set of 
TaskGroups, so one GroupingStrategy per taskbar/kasbar/whatever.

1 Visualization -> 1 GroupingStrategy -> N TaskGroups -> N Tasks

inverting GroupingStrategy and TaskGroup will likely make things considerably 
more complex as then GroupStrategy or TaskGroup objects (one or the other) 
would need to cooperate with each other rather than simply be directed by a 
manager object.

> If an item is
> added/removed to the group the GroupingStrategy checks for items that match
> according to one of the implemented grouping strategies.

right...

> If it is an absolute match and it is save to group those items without user
> interaction everything is fine.

right....

> But what if user interaction is needed? 

then the design has failed. a new window appearing should NEVER require user 
interaction. period. user interaction should be optional at best, but NEVER 
required. the taskbar is not what users are focusing on, they are focused on 
their tasks. the taskbar is a way to gain an overview and switch between 
tasks. nothing more.

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

> The GroupingStrategy isn't directly in touch with the user i think.

that's irrelevant, tbh. where the suggestions for grouping come from or are 
managed is completely irrelevant from the user's POV. as soon as you starting 
thinking "data structure ... that translates to the user interface" you've 
lost. the two are completely separate ideas and one should not impact the 
other beyond "data structure must be able to service the needs of a 
visualization"

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

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

yes, let's step back and gather use cases so we can talk about what this 
actually trying to deliver.

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

no, and what does that have to do with the Taskbar widget visualizing the data 
structure?

> I think it is better if the GroupingStrategy of the current
> rootGroup adds the new task to a reasonable subgroup or keeps it otherwise.

absolutely; this has nothing to do with the Taskbar widget, however. the 
Taskbar will update itself to reflect this change, but the Taskbar widget 
should have *little to no interaction* with the organization of the tasks into 
the hierarchy.

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

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

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

as an example: so that you can have a taskbar with a GroupingStrategy that, 
for instance, shows only the windows on that screen, and a window list menu 
that shows all windows grouped by application. 

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.

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

you're still thinking in terms of "there is one taskbar". how do you allow 
for, say, a MacOS style dock? or a simple menu? or..? the tasks plasma applet 
can share a GroupingStrategy easily amongst all instances of the tasks plasma 
applet if we want; that doesn't require GroupingStrategy to be a singleton. 

but if GroupingStrategy is a singleton, then we make libtaskmanager far less 
useful for things like a dock or a QMenu representation.

you're also making the assumption that people will necessarily want more than 
one taskbar that is identical. none of that is a given.

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

i won't tell them you said that ;-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.)

what are the use cases for having different groups in the same taskbar behave 
differently?

and do you perhaps think that storing the configuration in one class, making 
suggestions in another, and making the final decision back in the first class, 
then communicating the decision back to the second class is a little .. 
clumsy?

why not store, suggest and organize all in one class (GroupingStrategy) and 
reprseent the hierarchy in another (TaskGroup)?

the config-in-TaskGroup, suggest-by-GroupingStrategy, decide-in-TaskGroup, 
inform-GroupingStrategy-of-decision is going to result in spaghetti code.

-- 
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/dce6dcaa/attachment.pgp