Additional Tagging & Reporting Tools

[hiccup]

Hey boroda74,

With some skins, the colouring of your main panel doesn't work very well.
Especially the readability of text on buttons can be problematic sometimes.
Is it something you can address, or should I throw this in the general direction of Steven?

(and I notice the caption bar doesn't adhere to the skin, but that's not really a big issue)

[boroda]

"The user can move each line to anywhere he wants (either on the same table or to the other)." i havent gotten this: all 3 tables have different sets of columns.

[redwing]

Only between "Current" and "Stored" table on the same section. No need to move to different sections.

[boroda]

got it. should 'current' table contain just 1 line or you mean by 'current' all stored templates, but stored in native mb configuration file?

[redwing]

Yes, all currently stored templates in MB's settings file. 16 for virtual tags, 8 for external tool commands, 6 for custom web links (Steven said he increased custom web links for 3.1, but that can be addressed later).

[psychoadept]

Is it going to be possible to manage organization templates this way, too?

[boroda]

and auto-organization ones. i hope, yes. probably i'll start to develop this tomorrow. i intend to extend tag tools plugin, because to develop new plugin afresh is a bit harder, then to reuse existing plugin.

[redwing]

I like the idea to extend the current plugin. Thanks for doing this!

[boroda]

mb coloring api is *very* limited (thats why 'use skin colors' option is unchecked by default), so if its important for you request Steven to extend api or just dont use 'use skin colors' option.

[hiccup]

No problem, I'll just uncheck 'use skin colors'.

[boroda]

@redwing
could you make a mockup(s) of tag(s) history dialog(s) and context menu(s)? nothing fancy is needed, just ideas. i cant think something elegant. of course no need for mockups of backup/restore settings dialogs.

[redwing]

- If there has been no changes in any tags for a track, then "Tag History" context menu command for that track should be disabled. That disabled state itself is a useful information to the user.

- If there were changes, show those tags and values only on the popup window upon clicking on the command. Something like this would suffice, really no need for fancy visual clutters.



The example shows previous values of Title and Album Artist along with when each value was updated.
If the user right-click on one of the previous values, context menu shows "Copy" and "Restore" command. With copy, the user could paste it on a notepad and edit the value (and then could copy and paste it using MB's tag editor). With restore, the plugin overwrites the current value with the selected value.

- Some tag values can be very lengthy (e.g. classical music) and multiple selection of cells needs to be supported. Maybe clicking on a column header could select all tag values on that day like Excel.

[redwing]

"Copy" "Edit" "Restore"

"Edit" would be also useful when the user wants to edit the current value while browsing previous values.

[boroda]

thanks. i guess its 'elegant' enough.

[boroda]

@redwing

It would be useful if a plugin can auto-save MB's xml database file regularly, and when something goes wrong it can assist the user in restoring lost tags. This would allow to import only specific tags from the xml file and thus give more choices to users migrating from other music players

do you mean that backup file format should be itunes xml format rather than my own format? 'time machine' is a simple task for me, but creating itunes xml parser/writer is not that trivial task. are you sure that its important (not (only) for you, but in general)?