@Nick-Hall and @codefarmer
Do you think that this is worth adding to the Third-Party add-on collection?
Or maybe this Custom Filter gramplet (and the Cairo Clock and the Sample Report by @GaryGriffin ) could be the beginning of a separate “Developer” (addon plugin collection/repostitory) project. Where users could clone it locally and learn how to use the make.py to manage a local “Project” folder (with the necessary addons/gramps53/listings and addons/gramps53/download folders).
Such a local folder could be uploaded for simple sharing.
The Cairo Clock is the only baseline example of a Plugin that is currently available for download.
The .gpr.py still needs some tweaking. It could use a comment appended on the navtypes=["Person","Families"], with the other types or a reference URL. (I haven’t tracked down the list yet. There isn’t a list in the Create a Gramps Plugin Registration file article. Nor could I find one in Sphinx.)
And the .gpr.py article needs some more explicit discussion about ensuring the registration remains unique if you use such templates while creating several of the same Addon Type.
Making a local repository for gramplets may not be for the weak of heart. I did it on a Mac, but needed help from multiple people (especially John Ralls). John updated the documentation after my experience, but it is still tricky work - probably too high of a burden unless you are a Mac developer. You have to build a local version of gramps as one of the steps.
Just populating a local folder with sample gramplets would be easy, but the minute the user wanted to build their own (or even rebuild one of the samples), they have to bite a much bigger problem - building a local gramps.
All you need to do is create the addons-source folder, run the make.py against it (which creates the addons/gramps52/download and addons/gramps52/listings folders), and add the path to the addons/gramps52 folder in the Addon Manager’s Projects tab.
Running the make.py could be easier andadding a Project could be less fussy.
Have you tried to do the build and listing option for make.py with a sample gramplet? These are the 2 steps that are required when updating or adding a gramplet to a repository. They require the path to the local built gramps. As I recall, listing will fail unless the local gramps exists.
The current make.py is actually already a little too overambitious. It tries to build all the PO translation files and different language addon-xx.json files. Perhaps it could limit itself to writing the addons-en.json and maybe the native language .json file.
The rest of the PO file’s term translations could be done as a separate tool. And the other JSON files could be yet another operation. It is likely that all the Weblate data was why the full master build of Gramps is needed.
There’s an opportunity to evolve the process. Without the flexibility in language, the make should adapt nicely to an add on Tool.
Using the stripped down make.py as a foundation, an addon (Developer audience tool) would only need the following functionalities:
has a text field for a folder path with File Chooser (like the Database path in the Preferences)
I disagree. Makefiles should be all-powerful in the build and clean function (my Unix development days are showing). There are few people who have permission to merge PRs in the addons repo (where the tgz and listing files reside) and they need this full functionality. Yes, I broke it recently, but that was an anomaly.
Developers pre-5.2 had to put their test gramplets into gramps52/plugins/GrampletName folder. In 5.2, they can still do that -or- build a repo. But I wonder how many people actually want/need to build their own repo for local use.
I can understand if I would want to publish some of my custom gramplets, but I have chosen to do that with the standard gramps repo process as I do not have licensing issues with anything I do. The few 3rd party repos I am aware (FS, Isotammi) have reason to be independent.
Being able to create a repo is great (and I have a local unpublished repo). But if you are not planning on publishing it as a 3rd party repo, then it is not really needed. Or, I would argue, worth the effort.
