Minimize on close behavior made optional.
See the Changelog for list of features and fixes currently only available in the nightly builds.
Personally this is the default way I've been using the old slsk client forever ... if not default behaviour, it would be amazing to at least see a preference to change the functionality to the way things used to work.
I don't understand your post, this feature is currently present in SoulseekQT.
The dispute is over whether files are downloaded from the folder that are not shown in the search results. The original Soulseek client would actually retrieve the list of files in the folder and then download them. SoulseekQt makes no such request, but instead downloads the files in the folder that are shown in the search results. I feel that it's a cleaner and safer way to do it, ie you know what you're downloading. And to replicate the old client's functionality, I've provided a 'Browse Folder' option that browses the user's file and navigates to where the folder is, so you can download it yourself after you've seen what's in it.
Please, please change this back or add an equivalent context menu option. You've taken what was an instant, one-step, one-click process and turned in into a four-click process that makes the user sit through a delay while it fetches the file list (which sometimes indefinitely fails to appear) and then makes them find the directory in the file list again. From a usability standpoint it's monstrous, and from a security standpoint it makes no difference. I stopped looking at the list of files I was downloading in the right-hand pane the second time I had to go through this whole mess, and I'm sure everyone else has too.
I'm sorry, I just think the way this is done in SoulseekQt is preferable. Yes, it takes a little longer and a few extra clicks, but at least you know exactly what it is that you're downloading. And I appreciate that you don't even look at the list of files in the folder, but you have no reason to assume others don't. And while you're looking at the user's share you might find something else you're interested in. As for the file list failing to appear, if there's a problem with SoulseekQt's ability to form additional peer connections it certainly needs to be addressed, though I can only address it on a case by case basis. But what you describe is exactly one reason I didn't want to reimplement the old method of retrieving folders that aren't displayed in search results. Since your client doesn't know what files are in the folder, it requests them from the remote and only then downloads the files. Whatever might be stopping the user's entire share from being retrieved can very well cause the same with the list of files in the folder. Except in the latter case you won't even know. Nothing will ever be queued for download.
This might be worth explaining in a modal dialog that appears on the first use of the Download Folder option. To dismiss the dialog, the user would have to click a "Don't remind me" button. The dialog would just have a little message like "In SoulseekQt, when you download a folder from the search results, you will only queue the currently displayed files. If you want to download the entire folder, including any files not displayed in the search results, select Browse Folder from the context menu, and download the folder from the browse results."