On Wednesday 30 September 2009 01:35:41 j...@progsoc.org wrote: > > On 2009-09-04 20:16:52, Aaron Seigo wrote: > > > this results in a "leak" in that every window ever created will have an > > > item that stays forever, no? shouldn't it only keep track of winIds > > > that still exist, and do so in the manual grouping strategy? > > > > Christian Mollekopf wrote: > > Yes this would result in a "leak" (as long the groupmanager instance > > exists). I just noticed that also manual grouping is broken since it also > > relies on the pointers to remain. > > > > I will work on a new patch where manual grouping and sorting keep > > track of the windows/groups by winIds. > > > > Aaron Seigo wrote: > > any progress on this? > > > > Christian Mollekopf wrote: > > yes, but since i'm rather busy atm. it takes some more time. > > I'll try to finish it until next week. > > > > Cheers > > Out of curiosity, will this change affect how new applications are > displayed/handled in the taskbar? Ideally they'd just appear (and stay > unless moved) to the right of any extant tasks. If not, can I ask a big > favour ... ? ;)
This will not change the behaviour of the taskbar, new tasks are appended on the right if no or manual sorting is used, otherwise according to the sorting strategy. Regards > > > - jedd > > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/1526/#review2247 > ----------------------------------------------------------- > > On 2009-09-28 20:26:09, Christian Mollekopf wrote: > > ----------------------------------------------------------- > > This is an automatically generated e-mail. To reply, visit: > > http://reviewboard.kde.org/r/1526/ > > ----------------------------------------------------------- > > > > (Updated 2009-09-28 20:26:09) > > > > > > Review request for Plasma, Aaron Seigo and Marco Martin. > > > > > > Summary > > ------- > > > > this fixes the manual sorting strategy, which is broken atm if the > > desktop is changed. > > > > Since the manual sorting strategy relies on AbstractGroupableItem pointer > > not to change, we cannot remove it from the bookkeeping in case it > > returns (after a desktop change for instance). I don't know if this is > > acceptable because this results in the item never being removed from the > > itemList until the groupmanager instance is deleted (lifetime of the > > applet which created the instance). > > > > Another option would be to identify tasks and groups by WId, which is a > > bit more complicated, but if you think it would be better/cleaner, i > > could supply a patch. > > > > > > This addresses bug 200255. > > https://bugs.kde.org/show_bug.cgi?id=200255 > > > > > > Diffs > > ----- > > > > /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1018615 > > > > Diff: http://reviewboard.kde.org/r/1526/diff > > > > > > Testing > > ------- > > > > Tried it, works. > > > > > > Thanks, > > > > Christian > _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel