from http://bugs.musicbrainz.org/ticket/5835

Picard currently offers a number of extension hooks for plugin authors. However, I regularly see people posting plugin ideas on the forums that can't be written around those existing hooks, and I personally have hacked up (or, in some cases, tried to) a variety of such things myself.

Of course, this being Python, you can hook anything at all through monkeypatching, but that requires a good bit of Python skill and a solid understanding of the Picard code, and it's much more likely to be broken by future changes in the code.

Looking over a few dozen forum threads and my own local patches, I've come up with a list of new plugin hooks that I think would satisfy most of what people have (so far) found a need for.

1. Album and track metadata processors. Already exists.

2. Release event metadata processors. This can be hacked into an album processor pretty easily, but it might be better to have an explicit hook.

3. Album, cluster, track, and file context menu actions. Already exists.

4. Main menu (at least File, View, Options, and Tools) actions (somewhere in main_window.py).

5. Option pages. Already exists.

6. UI init actions. Already exists.

7. Script functions. Already exists.

8. File formats mapped to extensions. Already exists.

9. File formats and/or filename preprocessors mapped to URL schemes. For example, I can add an action that adds filenames like "itunes://0123456789ABCDEF", and then I want to hook formats.open() so this looks up track 0123456789ABCDEF in iTunes to get its filename and then calls formats.open on the result.

10. Post-load actions, which get called after the metadata is read in but before File._loading_finished (probably in File.load).

11. Post-save actions, which get called after the metadata is saved and the file is renamed but before File._save_finished (probably in File._save_and_rename). However, a few things people have suggested might fit in better as pre-save actions, or even somewhere in the middle (after save, but before rename).

12. Filename-parsing actions, which get called after or in place of the default parsing and can fill in (additional) missing metadata from the pathname in various different ways (at the end of File._copy_metadata).

13. Post-fingerprint actions, which get called when a file is fingerprinted (probably in Tagger._lookup_puid). The only use for this I've seen is to save the fingerprint automatically, which probably belongs in Picard rather than as a plugin, so it's probably not necessary.

14. Mappings for new metadata fields to human-readable display names (in display_tag_name, but probably better to register a new mapping than to register a hook to that function).

15. Mappings for new metadata fields to each file type. I'm not sure how this could be implemented, given that the list of formats and the list of fields are both extensible. And you can already explicitly add a bunch of type-specific metadata fields instead of one generic one, although that is a bit messy. But people have asked for it.

16. Adding fields to the list (currently only musicip_puid) that get copied from files to tracks on matching (in Track.add_file, but probably better to register a new field rather than a hook).

17. Various kinds of batch actions, e.g., an action that runs on the list of file objects included in a save operation when the last file in that list finishes saving. I'm not sure this really fits into Picard, since so much of the code is written around the idea of one-by-one processing rather than batch processing. It's not that it would be hard to add, just that it might be unpicardish.

18. Command-line flag handlers. I don't know that this is a good idea, especially since the command-line parsing happens before most of the infrastructure is set up. Especially since most of the suggested flags were intended to do things like "quit after command-line parsing" or "don't show the UI", and turning Picard into a batch-processing program or a single-instance app really isn't a job for a plugin.

It would also be nice if there were some easier way to bundle extension modules (like the appscript and pycom that iTunes integration needs) into a plugin, but I can't see any way Picard can help with that hassle.