Minimize on close behavior made optional.
See the Changelog for list of features and fixes currently only available in the nightly builds.
Many of the complaints lately have, one way or the other, had to do with share browsing. Firstly, and quite understandably, a fair number have been baffled by the absence of any status tracking for share browsing requests. If your listening port is properly forwarded, either because the UPnP module managed to talk to your router or, much less likely, because you've forwarded it yourself, this is less of an issue. Most attempts to browse the shares of other users should be successful, and you've probably learned it's just a matter of waiting until the browse window pops up. If the request is not successful, because a connection couldn't be formed to the user or for some other reason, there was no indication of the failure at all. The problem is much worse for users whose listening ports are not accessible, as those should be able to, on a good day, connect to about 20% of all other users. And for many of these users, it appeared as if the share browsing function was not working at all. Well, tonight's build may not improve on the listening port situation, but it should do a much better job of letting you know what's going on. To begin with, the share browse window is now shown immediately upon request. It will also let you know whether the connection attempt to the user has failed, and provide you with a handy clickable link to a webpage that will test whether your listening port is open, and suggest a list of port forwarding guides if it finds that it isn't. It may not seem like a big change, but it sure did slice lengthwise. I usually take a couple of days to play around with the client when so much code has shifted around, but I've decided to put a rush on this one to stem the tide of share browsing related confusion. I'll be sure to fix any issues that arise on the day.
Secondly, a check to ensure the client isn't already running when you start it involving the allocation of shared memory is sometimes preventing SoulseekQt from restarting after an unscheduled shutdown on Mac, and possibly on Windows and Linux as well. This is something I had removed a while ago, but then popped back in after some poorly managed subversioning across virtual machines. The check should now be removed again. This of course means you can happily start more than one instance of SoulseekQt again, often to disastrous results. I'll have to find an alternative to using shared memory.
Links on the download page as usual.