I've always questioned the usefulness of showing each user's number of shared files in your user list. How do you personally end up using that information?
Like the other person who replied, I use the number of files as a gauge to how much I might share with another user. If someone has a lot of files shared, then they might be "worthy" of some rare stuff. Sometimes, ppl share small amounts but change it often, so it isn't necessarily an exact science. But it gives me an idea whether to seek them out in the first place.
i want to know, if a user has more than e.g. just one file shared. (if not, i banned him, caus one is none.) the fastest way to find that out was (in slskNS) to add that user to your list...
browsing the files often takes too long or doesn't work.
There are two things that can generally go wrong with this method of checking whether the user is sharing. One, the user may not have been sharing when they logged in, but shared something afterwards, in which case the server will still report their number of shared files as zero as it's only reported during login. The other is that the user might be sharing privately, ie with almost no one but a few. They will still be shown to be sharing any number of files in your userlist. I'd recommend the 'send warning message to users with empty shares' option as a much better way to handle this sort of thing.
ok, i see the problem with that method.
but there should be a way to handle the problem with users who (permanently) share only very few files (often the incoming folder with incomplete or other useless files). letting these people download is to the disadvantage of all other users (most of which share many (or rare) files, i suppose).
maybe you could enable an extended use of the automated empty share message, e.g. sending the message also to users with an adjustable amount of shared files (maybe 10 or 100), so that the user could still explain it.
This is where the whole idea of automatically hunting down users who aren't sharing starts breaking down, and the reason I objected to doing anything about it the first place. If someone wants to get around an automated mechanism, there's very little anyone can do. The empty share warning mechanism, I feel, is the best that can be done because it takes a more advisory, non-accusatory approach towards users who aren't sharing. If you want to make sure another user is sharing anything of value you're gonna have to do some legwork, ie browse their files and look at them.
"a more advisory, non-accusatory approach" - well, that depends on your message! ;)
on the one hand, i understand that you as the developer want to keep the system as open as possible, but on the other hand, you allow buddy/group-sharing which is totally closed for other people. and the mechanism that i suggested would only extend your "advisory, non-accusatory approach", insofar as you could tell people that they should share more (or get banned).
so far i simply ban those people, because i dont feel like (after browsing) sending them a message and then wait for whether they answer or not, then maybe discuss about why they only share 2 files and then ban them or not.
with the automated message everything would be made clear. and if they dont answer, after a certain amount of time, they get banned, but they would know why and they still could explain it and i could unban them in case it turns out it was a mistake.
Well, the advisory part at least remains generally true if only because you're messaging them before doing anything else. I suppose you could always change your message to "YOU'RE BANNED MOTHERFUCKER!", which would be neither advisory nor non-accusatory, but that seems like a roundabout way to use the empty share warning mechanism. Also if at all possible please don't change your message to "YOU'RE BANNED MOTHERFUCKER!".
Anyway, the empty share warning mechanism is there for you to use as you please. If you want to preemptively ban people who get the message that's your decision. But I think detecting an empty share is a good place to draw the line on when to send the message. What's wrong with only sharing 100 files? What if you're only sharing a few of your favorite things? What if I give the user a file number setting as you suggest and they end up setting it much higher?
The truth of it is this: If you're going to share publicly, you have to give up a measure of control. I share publicly, I don't have an empty share warning message, I never check if people downloading from me are sharing anything and I'm happy as a clam. Sometimes you just have to trust that enough people are going to do the right thing. I'm not discounting any of your arguments, I just think the empty share warning mechanism is fine as it is right now.
I use the number of files shared info for something else: If it's a big number, I often decide to browse the files and see if there is something I might like. So it causes me to download more. If a guy shared a lot by a band I like, chances are I can discover other stuff by browsing his files, but I'd only do that with a guy who shares a lot. Maybe it could be incorporated in the "Get user info" dialog?
I don't see why you wouldn't allow your users to display information like filecount and average transfer speed in their buddy list. Isn't that a bit paternalistic?
Anyway, here's another reason to want it displayed, which I think is valid: when filecount and average speed both show 0, it often means that the peer hasn't logged on for a while and is considered "dead" by the server. I want an easy way to detect such users and then decide whether to remove them from my list or not. Also, in some cases I add users to my list because of their filecount or speed; if those numbers change drastically later on, I want to be able to see that at a glance.
If you keep a large buddy list and make much use of it (like I do), then you really need a more comprehensive display of information. It should also be possible to choose by what criterion to sort the buddies. In fact, the sorting should be stable so you can sort first by filecount, then by speed, etc.
As you've posted in about twenty different places, I decided I'll concentrate some of my responses in one post. The general points I wish to communicate are:
Of course it's your client, and especially since you're giving it away for free it's totally up to you to decide what's going in and what isn't. My apologies for making it seem like I thought otherwise.
I shouldn't have said "paternalistic". FWIW, the reason was not just that you decided not to implement a feature I like. Rather, from the current thread I was under the impression that you're trying to prevent users from applying certain "reasoning errors" that might be related to filecounts in the user list. I thought that would be overly protective as users might have (valid) reasons to want a feature that you don't know about.
Either way, thanks for reading all of my requests. The fact that I'm posting them now is only because I'm now testing out SoulseekQt, not because I think you should implement them now, so no pressure is intended!
As for the choice Nicotine+ versus SoulseekQt: you guessed right that I'm currently using Nicotine+, and that I like having all the options that are in Nicotine+. However, the Qt client is currently much more actively maintained, and I hope it will become a viable replacement in the future. I'm also looking into iSoul, that's a very neat attempt as well, but it's also less actively maintained than Qt.
No problem! I was reacting more to the idea of paternalism in general than your particular use of it. I do appreciate your enthusiasm and help, and have actually gotten a lot of new stuff added to my to do list as a result of your posts. The only problem is that it's so big now that I can't imagine when I'll be able to get the next build out the door :)
I would miss this option the most. Many of the people on my list update regularly. When you don't display their file counts, how am I supposed to know they've added anything? Sometimes people on my list have no files shared and don't even realize it. I can politely remind them their files are missing. The K/sec column is also missed. Having the country flags in the userlist would be a nice bonus.