<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
> > 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>><br>> i'm highly dubious of the desire, let alone need, for this.<br>><br>> can you give some actual use cases?<br><br>they would be presented as grouping suggestions when one right-clicks on a taskitem.<br><br>> > The GroupingStrategy isn't directly in touch with the user i think.<br>><br>> that's irrelevant, tbh. where the suggestions for grouping come from or are<br>> managed is completely irrelevant from the user's POV. as soon as you starting<br>> thinking "data structure ... that translates to the user interface" you've<br>> lost. the two are completely separate ideas and one should not impact the<br>> other beyond "data structure must be able to service the needs of a<br>> visualization"<br>><br>> > If an item is added we could slightly colorize items that could possibly<br>> > fit 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>> again, what are the use cases for this? maybe i'm just not getting what you're<br>> vision is for the taskbar here, but ... yeah .. why should the user care about<br>> such things? how would they interpret these colours? etc...<br><br>It would tell the user "Hey we have somthing you probably want to group,<br>but we're not quite sure so its up to you". <br>If the user groups it it is automatically done next time.<br>If he doesn't the colors won't show up.<br><br>But its maybe more distracting than useful.<br><br>> yes, let's step back and gather use cases so we can talk about what this<br>> actually trying to deliver.<br>><br>> > > Taskbar widget: creates pretty things on screen that follows the<br>> > > GroupingStrategy's hierarchy<br>> ><br>> > Wouldn't the whole hierarchy have to be reevaluated if an item gets added<br>> > to a group?<br>><br>> no, and what does that have to do with the Taskbar widget visualizing the data<br>> structure?<br>><br>> > I think it is better if the GroupingStrategy of the current<br>> > rootGroup adds the new task to a reasonable subgroup or keeps it otherwise.<br>><br>> absolutely; this has nothing to do with the Taskbar widget, however. the<br>> Taskbar will update itself to reflect this change, but the Taskbar widget<br>> should have *little to no interaction* with the organization of the tasks into<br>> the hierarchy.<br>><br>> > > this doesn't address the problem of TaskPtr also being used improperly<br>> > > (hint: never access TaskPtr::data()). that's the real issue here: TaskPtr<br>> > > represents a window and is shared by everything that uses this library.<br>> > > it is what needs protecting against usage-after-deletion.<br>> ><br>> > My Idea was that tools like the ProgramSwitcher (alt-tab) could support<br>> > groups created in the main taskbar.<br>><br>> that would require publishing the data across processes (the alt-tab switcher<br>> runs in kwin; runners are in krunner; the taskbar would be in plasma) and so<br>> the objects still wouldn't be shared (rather they'd be syncronized).<br><br>Okay, but if i make the AbstractGroupableItem unguarded, wouldn't this make tasks<br>stored as AbstractGroupableItem unguarded?<br><br>> > > but i don't think it's meaningful to try and share the<br>> > > AbstractGroupableItems: those will be specific to each visualization<br>> > > (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<br>> > > collection of groups and items.<br>> ><br>> > Agreed. The way it works at the moment is that every visualization<br>> > (Taskmanager) has its own rootGroup so groups that are created on a certain<br>> > visualization aren't created on another too. But i don't see the point of<br>> > creating several GroupingStrategy.<br>><br>> as an example: so that you can have a taskbar with a GroupingStrategy that,<br>> for instance, shows only the windows on that screen, and a window list menu<br>> that shows all windows grouped by application.<br>><br>> there is no guarantee that every visualization will want to have the same<br>> grouping strategy. if they do, they can find a way to share that strategy<br>> amongst themselves. but putting that assumption in libtaskmanager itself<br>> sounds artificially limiting.<br><br>Click... Now i understand.<br>You mean that we should be able to create a new representation tree of an existing group<br>by simply creating a new GroupingStrategy.<br>That makes sense.<br><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<br>> > visualizations, so a newly created group on one visualization is instantly<br>> > available as a suggestion on another visualization.<br>><br>> you're still thinking in terms of "there is one taskbar". how do you allow<br>> for, say, a MacOS style dock? or a simple menu? or..? the tasks plasma applet<br>> can share a GroupingStrategy easily amongst all instances of the tasks plasma<br>> applet if we want; that doesn't require GroupingStrategy to be a singleton.<br>><br>> but if GroupingStrategy is a singleton, then we make libtaskmanager far less<br>> useful for things like a dock or a QMenu representation.<br>><br>> you're also making the assumption that people will necessarily want more than<br>> one taskbar that is identical. none of that is a given.<br><br>No im not. Since my idea was that de TaskGroup passes the settings (SortingMode, etc.) and<br>the Tasks, and the GroupingStrategy wouldn't store any groups, there was simply no need for this.<br>The Idea behind the single instance of the GroupingStrategy was simply that there should be a common backend<br>for regularly used groups which the groupingStrategy learns. The other taskbars shouldn't follow the "main" taskbar (if there is one).<br><br>So different Taskmanagers (or docks or menues or whatever) would have been created by simply creating a new rootGroup.<br>The RootGroup has its own set of TaskPtrs and is absolutely free to do whatever it wants to do.<br><br>But if were doing all the grouping in the GroupingStrategy im absolutely with you.<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>> what are the use cases for having different groups in the same taskbar behave<br>> differently?<br><br>It would allow to have a taskmanager where the toplevel is sorted by, let say, alpha <br>and subgroups could still be managed manually. This would possibly lead to loads of <br>configuration options and a don't see a real use case. I just wanted to leave this option<br>open for future ideas as i thought it wouldn't have many negative sides. But as i can see<br>now its probably better to do it centrally in GroupingStrategy so we have a clean code.<br><br>> and do you perhaps think that storing the configuration in one class, making<br>> suggestions in another, and making the final decision back in the first class,<br>> then communicating the decision back to the second class is a little ..<br>> clumsy?<br>><br>> why not store, suggest and organize all in one class (GroupingStrategy) and<br>> reprseent the hierarchy in another (TaskGroup)?<br>><br>> the config-in-TaskGroup, suggest-by-GroupingStrategy, decide-in-TaskGroup,<br>> inform-GroupingStrategy-of-decision is going to result in spaghetti code.<br><br>Well, i guess you're right. =)<br><br>So as a summary of my (new)vision:<br><br>-Each visualization has its own GroupingStrategy which manages its own<br> set of abstractGroupableItems.<br><br>-the taskGroup remains just as a container of other groupable items. all grouping functions (joinGroup, leaveGroup)are removed from the abstractGroupableItem.<br><br>-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.<br><br>-The visualization just follows the Group tree exported by the GroupingStrategy.<br><br>-If the user groups to tasks manually (if supported by GroupingStrategy), the GroupingStrategy groups these items and not the items group each other.<br><br><br>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.<br><br>Hopfully im getting closer to your vision now =)<br><br>Regards<br><br><br /><hr />Bloggen, posten und Dateien freigeben für Freunde und Familie - jetzt noch einfacher mit Windows Live Spaces! <a href='http://get.live.com/messenger/overview' target='_new'>Hier klicken!</a></body>
</html>