i think there is a bugreport about exactly what you describe. i can try to find it tomorrow
Beat Wolf Am Dienstag 23 März 2010 23.36:43 schrieb Dmitry Suzdalev: > > On 2010-03-23 22:05:51, Aaron Seigo wrote: > > > so essentially it removes any sorting within the desktop sorting. i'm > > > fine with that change (though perhaps others will now complain ;), > > > though i have some thoughts below. > > Hmm, I just realized that some people might like to keep tasks sub-sorted > by name indeed. For some reason I don't care about that a bit, but otoh > this constant "jumping" of tasks always made me eager to write this patch > :) > > So now i'm really confused - will the majority of people be like me or the > opposite? :) Usability advice needed. > > If i'm in the minority, then I guess I can perfectly keep these changes > local > > > On 2010-03-23 22:05:51, Aaron Seigo wrote: > > > trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortings > > > trategy.cpp, line 66 > > > <http://reviewboard.kde.org/r/3375/diff/2/?file=21517#file21517line66> > > > > > > so window groups will shuffle randomly when windows leave or join > > > or anything else that may cause winIds() to shift order. seems > > > like trading one issue for another. > > > > > > i wonder if it wouldn't be nicer to have a stable way to identify > > > AbstractGroupableTasks (a QUuid? or an integer based sequence?) > > > for such occasions. > > > > > > that would also make things such as leftWinIdIsValid unecessary. > > > the winId is just as random to the user; the only downside i can > > > see is a small amount more memory consumption. > > Yes, this would be better indeed. > In my klipper experiments i used QUuids to identify history items. > but are there some downsides of simply assigning each new task an integer > id++ as it's ID? That would be lighter that quuid :) > > > On 2010-03-23 22:05:51, Aaron Seigo wrote: > > > trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortings > > > trategy.cpp, line 70 > > > <http://reviewboard.kde.org/r/3375/diff/2/?file=21517#file21517line70> > > > > > > can be just "else if (leftWinIdIsValid)" since we know both aren't > > > due to the initial if. > > yes, thanks > > > On 2010-03-23 22:05:51, Aaron Seigo wrote: > > > trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortings > > > trategy.cpp, line 78 > > > <http://reviewboard.kde.org/r/3375/diff/2/?file=21517#file21517line78> > > > > > > why storing in a temp var which is returned? > > nice one :) > will change. > > > - Dmitry > > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/3375/#review4637 > ----------------------------------------------------------- > > On 2010-03-23 20:48:15, Dmitry Suzdalev wrote: > > ----------------------------------------------------------- > > This is an automatically generated e-mail. To reply, visit: > > http://reviewboard.kde.org/r/3375/ > > ----------------------------------------------------------- > > > > (Updated 2010-03-23 20:48:15) > > > > > > Review request for Plasma. > > > > > > Summary > > ------- > > > > This patch fixes a sorting order for "Sort by Desktop" mode of > > taskmanager lib. > > > > Summary: > > When in "Sort by Desktop" mode, sort by_desktop+by_winId, instead of > > by_desktop+by_winTitle as it is now. > > > > More details: > > Currently in "by desktop" sorting mode tasks are sorted by desktop and > > then by name. This leads to inconvenient things, here are some examples: > > > > - I have a browser with several tabs open. Whenever I change a tab, > > browser changes window title. This makes task jump in a task bar from > > one position to another while I'm simply changing tabs. - I have a > > 'konsole' window and as I do 'cd onedir', 'cd zletter_dir', etc, title > > is changed, task jumps - Some other situations caused this too, don't > > recall, but you got the idea :) > > > > What I've done: > > Instead of sorting by name, i made it to sort by winId. Tasks without > > winId are sorted out to the end of the list and sorted by name there. > > Typically these are the startup-in-progress items. > > > > As a side effect this fixes bug > > https://bugs.kde.org/show_bug.cgi?id=219528 which has the same roots: > > invalid sorting order due to wrong comparison of regular items with > > "starting up" items. > > > > Long description, short patch ;) > > > > > > This addresses bug 219528. > > > > https://bugs.kde.org/show_bug.cgi?id=219528 > > > > Diffs > > ----- > > > > trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortings > > trategy.cpp 1105743 > > > > Diff: http://reviewboard.kde.org/r/3375/diff > > > > > > Testing > > ------- > > > > Tested on trunk. Task items retain their sort order, not reacting to > > title changes, charming :) > > > > It affects only task applets with sort mode set to "by desktop" > > > > > > Thanks, > > > > Dmitry > > _______________________________________________ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
