Suggestion - Add Tag Sources and actions to the RMB context menu

See attached.

Sort of a combined suggestion but these two would be nice to have on the context menu on RMB.



This will be a nice addition.

1 Like

Nice idea! I've added this with Mp3tag v3.05c, already making good use of it :slight_smile:


I have no problem with this addition, but I object to the fact that one of the newly added items to the context menu share the "S" hotkey with the "Save Tag" function.

Consequently, you can no longer right click/context menu key & press "S" without having to then press Enter to save tags; it's added an extra keypress and both messes with my muscle memory, but adds an unnecessary step to the process. For context, I typically use MP3Tag with as little mouse input as possible, as it just slows me down.

May I humbly request that you please mitigate this in whatever way is acceptable to the users of the new function, such that "right-click, press 'S' key" reverts to the same behavior it had prior to 3.05c.

Thanks Florian!

Another shortcut to save modifications is Ctrl-S - this would avoid to use any mouse input at all.
Also, I wonder in which workflow you use the context menu to save tag data: if you edit in the files list, leaving a field saves that modification straight away, no need to save explicitly.
And if you edit in the tag panel, then I would assume that either Ctrl-S or a click on the "Save" button in the toolbar would be much quicker than to move the mouse to the files list, right-click and then press S...
There are so many ways that lead to Rome.

Imagine sometimes my right hand is on the mouse and so I right click to trigger the context menu, and sometimes that hand is on the right side of the keyboard and so I use my right thumb to hit the context menu key to the right of my Right-ALT key.

I'm not in the habit of using CTRL-S to save (in MP3Tag, at least). I could change, but why should I instead of just not having the new context menu item share a letter? Surely I'm not the only one who is going to have their workflow impacted, though maybe the only one to post about it; time will tell.

If I have to stay on 3.05b forever because of this, I will, it's that important to me. I suspect, however, that this is an unintended consequence that Florian didn't foresee. He seems reasonable, so I predict a behavior toggle in the options, or a change to the letter that activates Tag Sources in the context menu is something we'll see in the future, hopefully.

If such fixes would hinder you in some way, now is the time to speak up, otherwise I'm not sure what you're either defending or advocating for. I didn't ask for another way to do the same thing, I'm pointing out a fairly significant hiccup to what is likely a common workflow for more users than just myself, and requesting that the UI/UX be modified ever so slightly so as to not unnecessarily introduce extra friction (an extra, unnecessary keypress) to a common process.

I see that I can't convince you.
Still, I think that you

is an empty threat.
Also, I think that you are not only

but actually something more substantial.
I checked the German version (which is my favourite GUI) and it uses the "q" as hotkey for the tag sources in the context menu - the same that is used for the menu in the main window.
So I assume that the string is the same that is (re-)used in the context menu.
I only find this reference: _C_MNU_TAGSOURCES Tag-&Quellen
(Or _C_MNU_TAGSOURCES Tag &Sources in the English language file).
So if you want 2 different hotkeys then you need an additional entry in the language file. It does save time for all the translators if they only have to translate 1 string instead of 2.

Yet, this also means that you can modify the language file yourself and replace the string with something that you like better.
I assume, though, that this change will be lost in an update.
And, naturally, the tag sources menu will then open with a different hotkey.

I don't understand why you need to "convince" me of anything, it's not the point of my original comment.

Furthermore, why shouldn't the "new" entry to the context menu have a different, non-conflicting, shortcut, rather than change the one that was in use already for a different function, or cause people to have to find a workaround if they don't like the new, unannounced behavioral change?

I'll wait to hear from Florian on this, because I don't know who you are, and you seem to only want a conflict or to shoot down any suggestions or opinions I might have. Your posts amount to telling me I'm wrong for using the program the way I do, and then suggesting that it's difficult for the programmer to change the key that's used to activate a function in a menu (it's not; as you've noted, in Windows it's typically as simple as putting an ampersand in front of the desired letter you wish to activate the entry) while mischaracterizing my request.

Have a nice day, I won't be responding to you anymore if this is the manner of discourse I can expect.

As far as I can see you stated:

And the answer is "Yes" you can have back this particular behaviour right now, without the need to wait for a new version: simply edit the (local) language file for your GUI and modify the named string.
Whether this will be a persistent modification only time will tell.

I am not quite sure, though, if other users will be satisfied that they then have to call the same function with different hotkeys.

There is defintitely some right-click confusion introduced with this change. The "S" is highlighted (underlined) for both the Save and Tag Sources choices, and seems the sources takes precedence for whatever reason. I do believe by default the S should remain as Save, since that is pretty generically expected. The hot key for Tag Sources should change in this case IMO.

I would like to emphasize that this is a problem for the English language file - and perhaps other languages.
But there are languages (like German) that do not have this problem.
This does not mean that it wouldn't be nice to keep the old habits. It just means that all users are requested to become creative and suggest sensible hotkeys that overcome the problem.

Thanks for pointing to the duplicate menu mnemonics. As you've already suspected, it was unintended and possibly disrupting to existing workflows.

I'd not encourage anyone to edit the language file to circumvent this. It'll also change the mnemonic in the main menu and the change will be overwritten with the next update anyway.

The tricky issue with this is, that each of the localizations are using different mnemonics and it became impossible to test them all and resolve possible conflicts.

What I plan to do to for the context menu (and already started working on) is to automatically detect and — if possible — resolve collisions.

Thanks for raising the issue. It almost became impossible to take into account all side-effects, combinations of languages and individual use cases — so feedback is always appreciated.

This is now implemented with Mp3tag v3.05d.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.