Development/Summer of Code/2018/Picard: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
 
(2 intermediate revisions by the same user not shown)
Line 2: Line 2:


==Ideas==
==Ideas==
=== Qt5/Py3 Port ===


=== Picard Plugins API v2 ===
=== Picard Plugins API v2 ===
Line 9: Line 8:
Languages/skills: Python, PyQt5, Flask<br>
Languages/skills: Python, PyQt5, Flask<br>


Picard 2.0 is going to be PyQt5 based, which means all the existing plugins have to be ported to PyQt5/Py3. Since Picard v1 plugins will be incompatible with v2 and vice versa, we need to implement a new v2 end-point for the Picard website. This gives us the opportunity to modify the way our plugin system works. There is a need of providing a uniform GUI api for plugins to allow quick GUI option settings, i18n support and UI uniformity with the rest of the Picard code. Also, additional metadata headers need to be implemented to allow cross-platform compatibility checks.
Picard 2.0 is going to be PyQt5 based, which means all the existing plugins have to be ported to PyQt5/Py3. Since Picard v1 plugins will be incompatible with v2 and vice versa, it gives us the opportunity to modify the way our plugin system works. There is a need of providing a uniform GUI api for plugins to allow quick GUI option settings, i18n support and UI uniformity with the rest of the Picard code. Also, additional metadata headers need to be implemented to allow cross-platform compatibility checks.


For more info see:
For more info see:
[https://tickets.metabrainz.org/browse/PICARD-977 PICARD-977]
[https://tickets.metabrainz.org/browse/PICARD-977 PICARD-977]

=== Picard concurrency re-write ===

Proposed Mentors: ''samj1912'' / ''zas''<br>
Languages/skills: Python, PyQt5<br>
Difficulty: Hard<br>

Currently Picard uses threads to offload I/O tasks. Since threading is notoriously detrimental in Python at times, due to its GIL, we were looking for someone to re-write the Picard concurrency code and switch it to a multi-processing model or make use of the new py3.6 asyncio features. This will allow us to improve and cater to a much requested feature of allowing Picard to mass-tag files, something Picard is unable to do so currently without staying responsive.

For more info see:
[https://tickets.metabrainz.org/browse/PICARD-975 PICARD-975]

Latest revision as of 11:59, 18 January 2018

MusicBrainz Picard

Ideas

Picard Plugins API v2

Proposed Mentors: samj1912 / zas
Languages/skills: Python, PyQt5, Flask

Picard 2.0 is going to be PyQt5 based, which means all the existing plugins have to be ported to PyQt5/Py3. Since Picard v1 plugins will be incompatible with v2 and vice versa, it gives us the opportunity to modify the way our plugin system works. There is a need of providing a uniform GUI api for plugins to allow quick GUI option settings, i18n support and UI uniformity with the rest of the Picard code. Also, additional metadata headers need to be implemented to allow cross-platform compatibility checks.

For more info see: PICARD-977

Picard concurrency re-write

Proposed Mentors: samj1912 / zas
Languages/skills: Python, PyQt5
Difficulty: Hard

Currently Picard uses threads to offload I/O tasks. Since threading is notoriously detrimental in Python at times, due to its GIL, we were looking for someone to re-write the Picard concurrency code and switch it to a multi-processing model or make use of the new py3.6 asyncio features. This will allow us to improve and cater to a much requested feature of allowing Picard to mass-tag files, something Picard is unable to do so currently without staying responsive.

For more info see: PICARD-975