User list does not sort properly

[rufuscoder]

Original author: Silas.M...@gmail.com (August 28, 2008 18:44:48)

What steps will reproduce the problem?

1. Sort user list by "Share"

What is the expected output? What do you see instead? I expect it to order the users by the amount that they are sharing. In my recent upgrade, nothing changes most of the time. In fact, it doesn't usually change no matter what you choose to sort by. Also, when it does work for "Share", it sorts by number: if someone has 200 GiB and someone has 250 MiB, the 250 is sorted as being the larger number.

What version of the product are you using? On what operating system? 0.9.10 on 10.4.11 (PowerBook G4)

Please provide any additional information below.

Original issue: http://code.google.com/p/shakespeer/issues/detail?id=58

[rufuscoder]

From krus...@gmail.com on October 07, 2008 15:14:06 system 10.5.5 intel user list is not sortable

[rufuscoder]

From hwa...@gmail.com on October 07, 2008 16:21:13 Yes, we removed the sorting based on other things than name and op status because it was very broken and buggy.

Patches welcome! (See SPUserList and how it uses MHSysTree which is a tree data structure that is always-sorted so we don't need to re-sort every time a user joins/leaves a hub)

[rufuscoder]

From krus...@gmail.com on October 08, 2008 07:34:17 What about using NSArrayController with Auto Rearrange Content option set ?

[rufuscoder]

From markus.m...@gmail.com on October 08, 2008 08:37:24 NSArrayController only deals with arrays and in some cases sets, we're using an MHSysTree for user lists.

[rufuscoder]

From krus...@gmail.com on October 08, 2008 09:34:20 In what MHSysTree is better from NSArray + NSArrayController ? I know that is quite big modification, but i think it is worth. Specially when usage NSArrayController and binding give extra functionality e.g. @sum or @count for binding number of users or share to display control. Another improvement is that from NSArrayController Array of selected items can be obtained what simplifies performing selector on every selected item.

[rufuscoder]

From markus.m...@gmail.com on October 08, 2008 09:43:47 Could probably be done with an array. If I remember correctly, MHSysTree is always sorted, making it ideal for lots of concurrent user lists being updated all the time. Håkan tried a dictionary once, but changed it back to MHSysTree because CPU usage was too high, check out r409 for more info on that.

If you want to write some code for this, that would be great!

[rufuscoder]

From krus...@gmail.com on October 08, 2008 09:51:17 If I have time I will write a patch

[rufuscoder]

From hwa...@gmail.com on October 08, 2008 12:09:29 I don't think auto-arrange content helps us. It's still an array or dictionary under the hood, but the sort call is called "automatically"... It really doesn't remove the sort step though:

Think large hubs, where people join and leave a lot. And think that you have a bunch of those open. Having to re-sort the user lists continually means eating a bunch of CPU.

Before issue #19 I had tried to change us to use NSArray and NSDictionary, but the re- sorting that had to happen was too expensive and ate CPU. This is the problem you need to avoid if you want to fix this bug.

The rationale for a "balanced tree" data structure (MHSysTree) is that things are not re-sorted when you add a new item, because the items are added to the right place in the data structure immediately. The data structure is "always-sorted", so no sorting ever needs to happen, basically.

It would be ideal if you could find a clean way to modify MHSysTree so it can be re- sorted on new criteria. Right now its sorting (of SPUser objects) is based on calling each item's compare: selector on different occasions (on add, for example). Unfortunately, since the selector is called on each instance (SPUser) object, each instance would have to be aware (or find out) about the current sort descriptors; 1) A pointer from each SPUser to the table and its sort descriptors is really not nice. Each item having to call somewhere to find out the sort descriptors on every compare: call also seems really ugly and possibly inefficient. So I'm not sure how to solve it.

[rufuscoder]

From hwa...@gmail.com on October 08, 2008 12:15:23 Maybe if a MHSysTree could know which table it is associated with, then it could grab that table's sort descriptors and hand them to the compare: selector on SPUser as an argument, and the SPUser object would use these descriptors in its sort algorithm.

[rufuscoder]

From krus...@gmail.com on October 08, 2008 13:27:39 Maybe id_cmp shouldn't be a function but pointer to function. When sort key is changed new comparison function would by assigned to id_cmp (also tree needs to be rearranged). SPUser then should respond to e.g. compare:withKey selector, and each comparing function would use it with different key. Changing id_cmp can by done by class method of MHSysTree.

[rufuscoder]

From krus...@gmail.com on October 08, 2008 16:08:40 I have thought about problem, and I realised, that I need sort only for sorting users by share. Temporary solution (until sort will by back) would be second filter which pass users with share grater then entered value. Also multiple selection in users list would be useful.

[rufuscoder]

From krus...@gmail.com on October 11, 2008 08:11:56 The function pointer concept is not quite a good idea. It works only if there is one instance of MHSysTree. But I figured out quite easy method for adding sort information to id_cmp function. You should modify sys_tree macros in such way that they pass an extra argument (NSSortDescription) to cmp function. When resort is requested just create new MHSysTree with new sort information, move all users to new tree and finally assign new tree to old one.

Sorry for spam...