Review Request: Fix taskmanager's "by desktop" sorting mode

Dmitry Suzdalev dimsuz at gmail.com
Tue Mar 23 23:36:43 CET 2010



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



More information about the Plasma-devel mailing list