<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
> From: aseigo@kde.org<br>> To: panel-devel@kde.org<br>> Subject: Re: Taskmanager with grouping support preview version<br>> Date: Mon, 7 Jul 2008 13:34:15 -0600<br>><br>> > > * in the taskbar we're usually getting one task at a time from the window<br>> > > manager (as windows are added/removed). i don't see any API that easily<br>> > > maps an item to an existing group. that seems odd. where does the "which<br>> > > group should this task be put in?" code currently exist?<br>> ><br>> > You're right, the task should probably first be passed to the<br>> > GroupingStrategy which tries to put it into the best TaskGroup or the<br>> > RootGroup. The group which receives the task, then tries to group fitting<br>> > tasks together.<br>><br>> right ...<br>><br>> > my idea of the GroupingStrategy is that as soon as a AbstractGroupableItem<br>> > is added or removed to a TaskGroup, the TaskGroup passes its children to<br>> > the GroupingStrategy singleton, and the singleton returns possible matches<br>> > which items should group together. If the match isn't just possible but<br>> > rather for sure, the Group groups the items according to the<br>> > GroupSuggestion returned by the GroupingStrategy. If the match is just a<br>> > suggestion the Group ignores it. Everytime the user groups tasks manually<br>> > or renames a group the GroupingStrategy learns from it.<br>><br>> ah, so GroupingStrategy would then return N different possibilities? how would<br>> it know which suggestions map to which GroupableItem? actually, what i'd<br>> probably do is just have GroupingStrategy do all the work, breaking TaskGroups<br>> up, creating new ones, etc. that way all the logic is one place and you don't<br>> have the annoyance of having to pass information from GroupingStrategy to<br>> TaskGroup back to GroupingStrategy (which is what the current API does).<br>><br>> otherwise, it sounds like a sound approach.<br><br>Hmm... lets say each TaskGroup has its own GroupingStrategy. If an item is added/removed <br>to the group the GroupingStrategy checks for items that match according to one <br>of the implemented grouping strategies.<br>If it is an absolute match and it is save to group those items without user <br>interaction everything is fine.<br>But what if user interaction is needed? I think every GroupableItem has to <br>hold a list with all group suggestions they fit in, so those options <br>can be presented to the user. <br>The GroupingStrategy isn't directly in touch with the user i think.<br><br>If an item is added we could slightly colorize items that could possibly fit <br>and the color would fade out without interaction of the user after<br>5-10sec or so. This way we could show the user the possibility of grouping. <br><br><br>> > > the way i might go about it is have the strategy manage a collection of<br>> > > groups that it then exports. this would be a tree of objects representing<br>> > > the groups and their nesting. groups would contain items and be<br>> > > completely stupid about the grouping mechanics. that way the relationship<br>> > > between group and strategy is obvious, it's clear how multiple strategies<br>> > > would work in parallel, and give a sane point for configuration<br>> > > management<br>> ><br>> > I don't get this part, sorry. On what would this tree of groups be based?<br>><br>> it would be a mapping of the TaskPtr collection into a hierarchical structure<br>> meant for display. the mapping would be done by the GroupingStrategy. so we'd<br>> have:<br>><br>> TaskManager: manages a random collection of TaskPtrs that map to the actual<br>> windows<br>><br>> GroupingStrategy: maps the TaskPtrs into a structure that makes sense for<br>> displaying<br>><br>> Taskbar widget: creates pretty things on screen that follows the<br>> GroupingStrategy's hierarchy<br><br><br>Wouldn't the whole hierarchy have to be reevaluated if an item gets added to a group?<br>I think it is better if the GroupingStrategy of the current rootGroup adds the new task <br>to a reasonable subgroup or keeps it otherwise.<br><br>> not at all =) the menus can stay in the library quite easily.<br>><br>> or really, the QActions can.<br>><br>> i've never really been a huge fan of the menus themselves being in the<br>> library, but the functionality they provide makes lots of sense. what we<br>> really want is a class or set of classes here that provides a set of QActions<br>> that can then be plugged into a menu.<br><br>Thats a good idea. This way we dont have to do actions over the edge of the non-gui-class <br>and everything is properly separated.<br><br>> two possible approaches:<br>><br>> * TaskActions class with a QList<QAction*> actions() method. the QActions<br>> would be connected to slots in TaskActions that perform the actual work.<br>><br>> * a set of QAction subclasses, such as MinimizeAction, which can be created<br>> and put into menus.<br>><br>> the former is less work, the latter is a lot more flexible. in fact, the two<br>> approaches could even be combined where TaskActions is a simple factory class<br>> for determining which of the specialized QActions to create based on a set of<br>> Tasks handed in. that might even be the best solution.<br><br>I will see what i can do, but it sounds good :-)<br><br>> > typedef KSharedPtr<AbstractGroupableItem> AbstractPtr;<br>> > typedef KSharedPtr<TaskGroup> GroupPtr; //Task group inherits<br>><br>> this doesn't address the problem of TaskPtr also being used improperly (hint:<br>> never access TaskPtr::data()). that's the real issue here: TaskPtr represents<br>> a window and is shared by everything that uses this library. it is what needs<br>> protecting against usage-after-deletion.<br><br>My Idea was that tools like the ProgramSwitcher (alt-tab) could support groups <br>created in the main taskbar.<br>Or there could be runners which use the Groups, or it could be possible in the <br>future to have a GroupManagerWidget where you could store your groups...<br>But i'm not quite sure if this is a good idea anymore. But therefore i though <br>it would be reasonable to share all those classes.<br><br>> but i don't think it's meaningful to try and share the AbstractGroupableItems:<br>> those will be specific to each visualization (e.g. a taskbar on the panel).<br>><br>> it's probably more sane to have each visualization use their own set of<br>> groupable items. in this pattern, each visualization would have its own<br>> GroupingStrategy and that GroupingStrategy would maintain its own collection<br>> of groups and items.<br><br>Agreed. The way it works at the moment is that every visualization (Taskmanager) <br>has its own rootGroup so groups that are created on a certain visualization aren't <br>created on another too. But i don't see the point of creating several GroupingStrategy.<br><br>> i don't see any really common use cases for shared GroupingStrategy.<br>><br>> what do you think?<br><br>I think the GroupingStrategy learns from the user this should affect all visualizations, <br>so a newly created group on one visualization is instantly available as a suggestion on <br>another visualization. The GroupingStrategy has to get the groupmembers of the Group <br>currently evaluating anyway so i don't see the point of having a GroupingStrategy in each visualisation.<br>And finally the GroupingStrategy should save its statistics about what the user grouped <br>together and a think its too complicated to distinguish on which visualization the user grouped them.<br><br><br>> > > > -Save custom order on collapse group<br>> > ><br>> > > custom order? you mean the order someone has dragged the item into? this<br>> > > is not going to work with automated systems, or at least make them very<br>> > > complicated, or require being able to switch<br>> ><br>> > Well, then at least in this mode. To me as a user it was almost a "must<br>> > have" feature to sort the items as i like but its maybe not that crucial<br>> > anymore with groups...<br>><br>> we didn't have this feature in kde3, either, of course. being better than kde3<br>> is of course one of our goals. i'm just trying to offer some caution here to<br>> make sure that the new taskbar code doesn't end up becoming an insane maze in<br>> an attempt to satisfy too much flexibility.<br><br>Sounds absolutely reasonable :-) I think i will just freeze that feature until <br>the rest is a bit more stable...<br><br>> > > > -Implement Dragging of expanded groups by dragging groupmember outside<br>> > > > of group<br>> > ><br>> > > unless the implementation is more straightforward than the description,<br>> > > this could be a problematic feature.<br>> ><br>> > This works actually quite well...<br>><br>> i'm not questioning that it works well from a purely "does it work without<br>> bugs" POV, but from a "is this something that users will actually find<br>> enjoyable" POV. i'm reserving my own judgement until i can actually try it out<br>> =)<br><br>I'm gonna try it on my family so we have a feedback of an average "dumb" user ;-P<br><br><br>So as a summary of my (current)vision:<br>-Each visualization has its own rootGroup which manages its own <br>set of abstractGroupableItems.<br><br>-The GroupingStrategy gets called by the altered group but is global <br>so the learning effort is as well.<br><br>-The GroupingStrategy takes the configuration (SortingMode etc.) from <br>the group so this isn't global. <br>(we should be able to have differently <br>configured taskbars, and since a rootgroup virtually represents a <br>visualisazion we can put this in the TaskGroup and there is still <br>the possibility for future modifications, to let different groups <br>behave differently without any extra effort.)<br><br>Regards Chris<br><br><br><br /><hr />Bis zu 500 Fotos im Monat für Freunde und Familie freigeben! Jetzt gratis auf Windows Live Spaces <a href='http://get.live.com/spaces/overview' target='_new'>Hier klicken!</a></body>
</html>