Hi, On Mon, 2004-01-26 at 08:50, Raphael Manfredi wrote: > Are you sure this is needed ONLY for passive searches?
> Imagine a passive search opened AFTER an active search which has almost > maxed-out. When query hits come back, they will be dispatched to both, > and the counts in the passive search and those in the active search can > become different. Shouldn't we ALWAYS sort by the '#' displayed in the > GUI and forget about the value in the data structure? In my example > above, the active search will max out BEFORE the passive one, and if > many hits come back which update lots of parent nodes, then sorting by '#' > in the active search could lead to wrong results. Results returned for a passive search don't update the records count value. There should not be a case (and indeed I haven't be able to create one) where the passive search will mess up the count value (because it never uses it or modifies it). However, the point raised is a good one. The only reason I introduced the count value into the record was to keep it consistent with the other columns/other sorting functions. The only reason I left it in for this last patch I submitted was speed. So: - We could remove the "count" value from the search result struct altogether and always sort by the value in the gui column - Which would remove the need for a special column sorting case - At the expense of speed. It's a noticeable hit with 5000 results but because insertion sort (used for count columns) works pretty well for the count column (since it's basically all 1's) it stills ends up being faster then the quicksort used for, say, sorting by name. So I don't think users will think it inconsistent... it will just be slower than it needs to be which sort of sucks for such a common sorting case. So the patch as submitted yesterday should make the passive search sorting behave correctly as far as I can tell (please let me know if it's otherwise). I can quite easily create a patch that removes the count record value altogether and uses a gui lookup for column sorting for all sort by # cases. Functionally it'll be worse but it'll be neater in code. Let me know. Emile ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
