Betreff: Vorschlag für Dokumentationsaktualisierung: Plugin-Entwicklung in Picard 3.0.0.dev6
Hallo zusammen,
ich habe ein audio_quality-Plugin entwickelt, das die Audioqualität mit ffmpeg analysiert und als audio_quality-Tag speichert. Dabei sind mir mehrere Probleme in Picard 3.0.0.dev6 aufgefallen, die in der Dokumentation geklärt werden sollten:
PluginWrapper: Erfordert module und plugindir. Ohne plugindir schlägt die Initialisierung fehl (Log: PluginWrapper.__init__() missing 1 required positional argument: 'plugindir').
ExtensionPoint: _extension_points ist leer, und die Registrierung mit ExtensionPoint.register löst den Prozessor nicht aus.
Tagger Patching: Tagger.add_files kann gepatcht werden, wird aber nicht immer aufgerufen. Möglicherweise werden andere Methoden wie add_paths verwendet.
Vergleich mit 2.13.3: register_track_metadata_processor ist in 2.13.3 zuverlässig, aber in 3.0.0.dev6 fehlt eine klare Alternative.
Vorschlag für die Dokumentation:
Abschnitt über PluginWrapper-Initialisierung mit Beispiel.
Klärung der ExtensionPoint-Verwendung für Metadatenprozessoren in 3.0.0.dev6.
Dokumentation der relevanten Tagger-Methoden für Dateiladevorgänge.
Beispiel für ein Metadatenprozessor-Plugin mit ffmpeg-Integration.
Details:
Picard-Version: 3.0.0.dev6
Plugin-Code: [Füge den Code aus der vorherigen Antwort hier ein]
Debug-Log: [Füge den letzten Log ein]
Extension Points Ausgabe: [Füge die Ausgabe von python3 -c "import picard.pluginmanager; print(picard.pluginmanager._extension_points)" ein]
Ich bin bereit, bei der Formulierung der Dokumentation zu helfen oder weitere Tests durchzuführen. Wie kann ich diese Erkenntnisse am besten in die offizielle Dokumentation einbringen?
Subject: Documentation Update Suggestion: Plugin Development in Picard 3.0.0.dev6
Hello everyone,
I’ve developed an audio_quality plugin that analyzes audio quality with ffmpeg and saves it as an audio_quality tag. I’ve noticed several issues in Picard 3.0.0.dev6 that should be addressed in the documentation:
PluginWrapper: Requires module and plugindir. Without plugindir, initialization fails (Log: PluginWrapper.init() missing 1 required positional argument: ‘plugindir’).
ExtensionPoint: _extension_points is empty, and registering with ExtensionPoint.register does not trigger the processor.
Tagger Patching: Tagger.add_files can be patched, but is not always called. Other methods such as add_paths may be used.
Comparison with 2.13.3: register_track_metadata_processor is reliable in 2.13.3, but a clear alternative is missing in 3.0.0.dev6.
Suggestion for the documentation:
Section on PluginWrapper initialization with example.
Clarification of ExtensionPoint usage for metadata processors in 3.0.0.dev6.
Documentation of the relevant tagger methods for file loading operations.
Example of a metadata processor plugin with ffmpeg integration.
Details:
Picard version: 3.0.0.dev6
Plugin code: [Paste the code from the previous answer here]
Debug log: [Paste the last log]
Extension points output: [Paste the output of python3 -c “import picard.pluginmanager; print(picard.pluginmanager._extension_points)”]
I’m willing to help with documentation development or conduct further testing. How can I best incorporate these findings into the official documentation?
Das Plugin-System im aktuellen Entwicklungsstand für Picard 3 ist aktuell nicht bereit. Wir überarbeiten das Plugin-System und bestehende Plugins werden angepasst werden müssen.
Der Plugin-Code im aktuellen master-Branch wurde bei der Migration auf Qt6 zwat mit portiert, da bestehende Plugins aber dort nicht lauffähig sind wurde der Code nicht weiter angepasst.
Am bestem, Du stellst sicher, dass dein Plugin in der aktuellen Picard-Version läuft.
add_paths ruft letztendlich auch add_files auf. add_files ist letztendlich schon der zentrale Code, der beim hinzufügen von Dateien aufgerufen wird. Aber wie immer gilt beim Monkey Patching von internen Funktionen, dass es hier keine Garantie gibt. Die Funktionsweise kann sich von einer Picard-Version zur nächsen ändern.
Was ist denn der Use Case für diesen Fall? Würde das nicht mit einem file_post_load_processor funktionieren?