Can we experiment with the new add-on registrations?
Perhaps you could take a look at the .gpr.py Registration file I’ve tweaked for testing the new features. I’m not sure if the IMPORTs on line 24 are necessary to use the Status, Audience and Maintainers items. It looks like they are unfortunately case sensitive.
I was curious how the Addon Manager will handle a single registration file with multiple addons of different combinations. And whether the help-url can be relative … pointed to a folder within that addon’s folder in the plugins folder?
Perhaps you could add the following folder to the 5.2 addon trove/hoard/stockpile for the beta?
The help_url is relative unless it starts with “http://” or “https://”. The base url for the wiki manual, and the extension for language translations are added for you.
Do you think it would be a viable feature request to have a ‘relative base’ url placeholder?
So the default would continue to use the wiki URL. But a new placeholder would allow redirection to the addon’s specific plugins subfolder under the Gramps User Directory.
So each developer could create preliminary documentation as a HTML file in their GitHub Repository. And when they include that in their .tgz file, local documentation would install with the addon.
To keep things neat if there were image files, I’d probably put the docs (or maybe just everything but the landing page) in a subfolder. In which case, the registration line might look like:
help_url="[local]/myDocs/myAppDoc.html"
Since the implemented fallback for a help_url is the base URL & “Addon:” & the <addon name>, that colon won’t work when the local machine doesn’t have a CMS parsing the request. So a local landing page fallback for a help_url="[local]" might be the “file://” & <local path> & <addon name> & “.html”
Ideally, since the GitHub standard is for a markdown-base help file in each repository, a fallback for help_url="[local]" might be for a Gramps GitHub dialect markdown rendering tool that shows the local README.md file.
The maintainers and maintainers_email have been changed to lists. (Wasn’t sure if it expects eMails in < and > … like Doug Blank did in his comments. Of if a zero legth string for the email would point users to the Bug Tracker.