Quick Tagger is meant to replace bind-keyboard-shortcuts-to-simple-tag-edit functionality of the old Masstagger component. It's not meant to be a complete tag editing solution replacing the Properties dialog or other tag editing related components.

To understand what you mean could you describe me in few words how such a component could look like?

Not like a submenu but instead a dialog or panel - with all mood-related settings being visible. Its not just UI stuff but also behaviour.... manually tagging every single track/album may be annoying. One could use tricks like that the user doesnt actually tag the files himself and instead just sets his current mood or the mood of the music in a panel - with the component then automatically applying those settings to every fully played track. So, you just tell it the current mood of the music... and it cares itself about the tagging. The reason why such a mode may work, is because if you're a mood-type listener, then mood wont change drastically with every played track :) Also - the same component could be used for autogenerating playlists which fit certain mood criteria. There are many possibly interesting things which could be done, which are not the point of quicktagger.... but i'm getting off-topic here - if you want to discuss this further, it may make sense to start a seperate topic

in what way is the masstagger 'old'? i happened to update foobar today and i am still using masstagger scripts..? :unsure:

The "old" possibly refers to the last released version, not to what you do with your internet connection.

QUOTE

- ability to add/modify more than one tag at once. It comes down to adding MassTagger scripts to the context menu, which was my request I've mentioned above.

If you want configurable contextmenu in masstagger, then why do you post this request in Quicktagger-thread instead of in a Masstagger-thread? Are you proposing to "add masstagger to quicktagger" instead of "add contextmenu-options to masstagger"? If yes, could it be that this doesnt make any sense at all?

in what way is the masstagger 'old'? i happened to update foobar today and i am still using masstagger scripts..?

The "old" possibly refers to the last released version, not to what you do with your internet connection.

i was only confused cuz masstagger is still included in the optional components. but thanks for the sarcasm. possibly. incidentally i just transferred all the overlapping features between masstagger and quick tagger.. it took like three minutes and cleaned up the list masstagger scripts a bit.

i was only confused cuz masstagger is still included in the optional components. but thanks for the sarcasm. possibly. incidentally i just transferred all the overlapping features between masstagger and quick tagger.. it took like three minutes and cleaned up the list masstagger scripts a bit.

Well, even though masstagger is currently being bundled in the installer, not much has happened to it for.... whatever really long time.... it is seen as an old/obsolete component by some.... mainly because it isn't up-to-date with current development paradigms.... one out of many examples: it completely lacks any preview.... with the result, that quite a few users experienced mass-destruction of their metadata, because a script didnt work as expected. Sure, you can argue with the "make test-backups first and try it on them before doing the real thing".... right, but the point would be "why is that even necessary? shouldn't i know beforehand, what a component will do to my files?". And this is just one example - masstagger has various other issues.

As for transfering masstagger scripts to quicktagger... that was exactly the point when i conceptualized Quick Tagger..... doing simple things quick and easy, without all the options and complexity bloat of masstagger.... one doesn't even need to care about organization of scripts into groups.... that happens automatically. Its how IMHO good software should work: you just tell it what you want, and the software does all the work for you with predictable results. The predictability-property is also the reason why the menu-structure is like "Quick Tagger ---> Set <Rating> to ---> 1". It acts as a replacement for the lack of a preview: the user is told exactly what will happen and it makes the interface self-explaining.

Its how IMHO good software should work: you just tell it what you want, and the software does all the work for you with predictable results. The predictability-property is also the reason why the menu-structure is like "Quick Tagger ---> Set <Rating> to ---> 1". It acts as a replacement for the lack of a preview: the user is told exactly what will happen and it makes the interface self-explaining.

Agreed. But an [optional] flat menu structure would be helpful and make clicking life way easier:

CODE

Quick Tagger Set field1 to a Set field1 to b Separator Set field2 to a Set field2 to b

Agreed. But an [optional] flat menu structure would be helpful and make clicking life way easier:

CODE

Quick Tagger Set field1 to a Set field1 to b Separator Set field2 to a Set field2 to b

Yes I know we can assign keyboard shortcuts.

Interesting idea. One could also make this a bit more automatic by turning such an option into "show flat menu-structure if number of actions is below N". I'm just not sure, if its worth the added complexity or if there are possible problem-scenarios. Will need to think about this further, before deciding if it would make sense from my POV.

Interesting idea. One could also make this a bit more automatic by turning such an option into "show flat menu-structure if number of actions is below N". I'm just not sure, if its worth the added complexity or if there are possible problem-scenarios. Will need to think about this further, before deciding if it would make sense from my POV.

After thinking about it a bit, i dont think that this would play out well in practice. Such a menu would not look like as you described it in your example, because quicktagger also allows removal and editing of each field. As soon as you get more than 2 fields, that will get really messy. The result would be, that it would only be useful if one has actions for no more than 2 fields. Thus, it would be an "exotic" feature which is only useful in a very low amount of cases. Either that, or you add even more options to enable/disable removal and editing. The low benefit (compared to how it is now) doesnt really justify the implementation effort and added complexity.