Taskmanager with grouping support preview version

[christian mollekopf]

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

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

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.

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

Okay, but if i make the AbstractGroupableItem unguarded, wouldn't this make tasks
stored as AbstractGroupableItem unguarded?

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

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.


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

No im not. Since my idea was that de TaskGroup passes the settings (SortingMode, etc.) and
the Tasks, and the GroupingStrategy wouldn't store any groups, there was simply no need for this.
The Idea behind the single instance of the GroupingStrategy was simply that there should be a common backend
for regularly used groups which the groupingStrategy learns. The other taskbars shouldn't follow the "main" taskbar (if there is one).

So different Taskmanagers (or docks or menues or whatever) would have been created by simply creating a new rootGroup.
The RootGroup has its own set of TaskPtrs and is absolutely free to do whatever it wants to do.

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

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

It would allow to have a taskmanager where the toplevel is sorted by, let say, alpha 
and subgroups could still be managed manually. This would possibly lead to loads of 
configuration options and a don't see a real use case. I just wanted to leave this option
open for future ideas as i thought it wouldn't have many negative sides. But as i can see
now its probably better to do it centrally in GroupingStrategy so we have a clean code.

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

Well, i guess you're right. =)

So as a summary of my (new)vision:

-Each visualization has its own GroupingStrategy which manages its own
 set of abstractGroupableItems.

-the taskGroup remains just as a container of other groupable items. all grouping functions (joinGroup, leaveGroup)are removed from the abstractGroupableItem.

-If a new Task appears, the GroupingStrategy gets it from the TaskManager class, it then tries to find a reasonable group for it or puts it in the top group otherwise.

-The visualization just follows the Group tree exported by the GroupingStrategy.

-If the user groups to tasks manually (if supported by GroupingStrategy), the GroupingStrategy groups these items and not the items group each other.


This way the GUI part will get smaller because the AbstractGroupableItems are completele stupid about grouping and the whole layout of the taskmanager-library gets much clearer.

Hopfully im getting closer to your vision now =)

Regards


_________________________________________________________________
Windows Live Spaces - Ihr Leben, Ihr Space. Hier klicken und informieren.
http://get.live.com/spaces/overview
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20080708/210b782e/attachment-0001.html