Expand per-user context menu on Message List

I'm liking the new Message List window. It lets me see that there are some chats I missed when I shut down the client or crashed, and it lets me see who all got the automatic message sent to non-sharers. Right now, the only right-click option available for items in this list is to remove the chat from the list. I would like more options, like: Browse user's files (so I can see if people who got my automatic msg are now sharing); Add user to list / Remove user from list; Message user (same as double-clicking on the item) ...basically the same things that are available in the context menu on each chat screen, so I don't have to open a separate chat window for each one to get to these options.
Your rating: None
Average: 1 (1 vote)


Good idea! This should have the usual user menu options in the chat list:


That was fast. It's working great! Thanks!

The extra prompt to remove the chat seems a bit unnecessary. If you are trying to remove the chat, that's probably what you want to do. I still would like to see a clear all button.

I tend to agree. The reason I added a prompt is that the remove chat option is currently at the top of the menu, which can sometimes result in an accidental removal with a little hapless clicking. I'll definitely have the clear all button in the next build though.


Great you add the clear all button in the next build. It was already an item in the 'Remarks.doc' in our Dropbox. We, the translators, regret you don't react anymore at the 'remarks', 'suggestions' in the Dropbox. I hope you will have a look at the 'Missing strings' as well.

I apologize for that. I've barely had any time to breathe in between looking for a new job, trying to fix stuff and add features, and learning Android programming to expand my skill set. I've added everything that can be translated from the missing strings document to the language files.


I'm very glad with your reaction. We (translators) know you're very busy, but just were a bit worried. I finished the new Dutch, German, French and Italian language files. I think there are still some missing strings that need to be translated, such as: 'too many files', 'Remote pending shut down', disallowed extention', 'cancelled' (when an upload has been cancelled).

Thanks! Those last few strings are more difficult to translate because they're transmitted between clients. Understandably you can't transmit the transfer status in your own language, but maybe I can write a translation function on the receiver's end.

Are these strings different from for example 'connecting', 'complete', 'requesting', 'aborted', 'queued' and 'uploading' ?, because these strings are succesfully translated ?

All the translators have set the language choice in the original language now, as a lot of programs do.
So English, Nederlands (Dutch), Français (French), Español (Spanish), Русский (Russian),
Deutsch ( German), Italiano ( Italian) and Polski (Polish). Maybe you can change that in the English version.

Maybe you can add a short reaction on each remark and suggestion in the Remarks.doc, Missing strings.doc and Suggestions. doc files, so we know which ones can be deleted.

Thanks Nir,

Transfer status strings are managed locally, whereas transfer denial messages are actually communicated from the uploader to the downloader. You can technically have a routine that translates each possible denial message, but there are third-party clients that use non-standard messages. It's still probably the best solution. I'll try that out as soon as I get the chance.

Second: Sure, that's easy to do.

third: Maybe we can settle on one document. Missing strings? I'll take a look at it.

Thanks, Nir


I've made just one document called 'Missing strings' and added the remarks and suggestions to it. If you can add just a short reaction on each topic, we know what can be deleted from the document.

Some time ago you suggested to add a link to the 'Manual.doc' and 'Handleiding.doc' in a sort of general section. Do I keep these documents in the dropbox or remove them ?

Will do. I still have linking to your guides on my to do list, I'm just trying to figure out a good place to put them. Maybe a User Contributions section or something along those lines.

By the way, you're having problems with Windows 8 and every new SoulseekQt executable, right? Do you mind trying the build here:


It's linked dynamically against the newest version of Qt, I want to see if that makes a difference so I know whether to switch to it or not.

Thanks, Nir

Runtime error.

I tried the version, but got a runtime error;

This application failed to start because it could not find or load the Qt platform plugin "windows". Reinstalling the application may fix this problem.

After clicking on OK:

The application has requested the runtime to terminate it in a usual way. Please contact the application support team for more information.

There was no runtime (number) showed.

I don't think my problems were related to Windows 8.1. Qt (2014.1.8 and 2014.2.6) were/are working fine.

Just let me know when you want to add the link to the manuals. Before that I will have to update them according to the latest build.

Peter Leijsten

Okay, I've added all the transfer denial strings I could find in SoulseekQt and the original client to the language files. I've also changed the language selection dropdown to use the native label for each language, as you've suggested.

'Disallowed extention' is still missing in the denial strings. Please see Missing strings.doc