I am presently studying GRAMPS code to understand how the application globally works.
Since virtually everything in GRAMPS is a plugin, I am focusing on the gramps/gen/plug/ directory.
I am puzzled by _docgenplugin.py which defines DocGenPlugin (a sub class of Plugin). This class is used absolutely nowhere, not even by the module is subdirectory docgen/.
I see that special provisions are made in OptionListCollection.save() method of _options.py for the corresponding options. But, again, I could find no use of these options.
My question is: what was the intent when the class was written? Which kind of report or plugin was targeted?
Last semantically “significant” (2 lines adding new private variables) patch dates back to 2012 (but minor) by Paul Franklin and base contents was created in 2008 by Brian Matherly.
The document generators are plugins that produce the output of reports. They implement the document interfaces and are instantiated in the plugin manager.
You should also look in the gramps/plugins/docgen directory to see the implementations of the different output formats that Gramps supports.
I checked directory gramps/gen/plug/docgen/ and this is why I ask my question: all classes in there are fresh “root” classes. They don’t depend at all on DocGenPlugin.
Looking at gramps/plugins/docgen/ (which I already did), generators depend on classes from gramps/gen/plug/docgen/ which don’t reference DocGenPlugin. Even the “UI part” in gramps/gen/plugins/xxxreport/ directories, classes are based on Report, never on DocGenPlugin.
I wonder if this is a dead-end branch in development. The authors had certainly an idea about it. Or application code has disappeared during GRAMPS evolution.
Yes. And the /docs/ collection of pages on the site is rather disappointing: it is an automatic extraction of the “here-doc” in the various modules. IMHO there is no added-value compared to code reading.
I have configured an LXR (see also here) for GRAMPS on my computer. This allows me to display cross-references and query usages.
The tool is very handy to discover statically unused classes, functions, … It fails on methods dynamically passed through variables (but there is at least one usage where the method is assigned to a variable).
The classes in gramps/gen/plug/docgen define the generator interfaces.
The document generator plugins in gramps/plugins/docgen/ implement support for the different output formats. They can support one or more of the generator interfaces.
The plugins are actually instantiated in the plugin manager. The plugin contains a reference to the generator class. I don’t know why multiple inheritance wasn’t used here.
The report dialog gives the user a choice of output formats based on the available document generator plugins that support the required generator interfaces.