Difference between revisions of "Adapt a built-in Report"

From Gramps
Jump to: navigation, search
m (See also)
m (ch-ch-ch-changes)
Line 20: Line 20:
 
#  Update the <code>.gpr.py</code> registration file to point to the correct file and correct classes.
 
#  Update the <code>.gpr.py</code> registration file to point to the correct file and correct classes.
  
Attaching are 2 samples with the old (names ending with report.py) and the new code (names ending with reporti.py) as well as the revised <code>.gpr.py</code> files. The old code may have changed since I wrote the new code quite a while ago - so every diff may not be important.
+
Attached are 2 samples with the old (names ending with report.py) and the new code (names ending with reporti.py) as well as the revised <code>.gpr.py</code> files. The old code may have had updates. The adaptation was written quite a while ago - so every diff may not be significant.
 +
 
 
== See also ==
 
== See also ==
 
* [[Addons development]]
 
* [[Addons development]]

Revision as of 03:30, 8 April 2021

Gnome-important.png
🚧 Work In Progress

This wikipage is an outline from a template being roughed in. Please don't edit just yet. Instead, contribute suggestions on the Discussion page.

This page is not planned be linked to a public page until about 2 weeks after 8 April 2021.

If this notice remains after that date, please feel welcome to remove this notice and consider the content 'fair game' for unlimited editing.

Purpose

A question was posted to the Discourse forum wondering if there were tips somewhere for copying an internal Gramps report to a make an experimental add-on?

It seems like more people would be intrigued with the possibilities of tweaking reports without the risk of breaking a feature. Particularly one that they use often enough that tweaking it seemed like a good idea.

Making a duplicate add-on sidesteps putting the original at risk. However, there are differences between built-ins and 3rd party add-ons. It seemed like that might require at least converting the library paths and making a new .gpr.py registration file. What else?

A reply privately shared

In a private message, GaryG privately replied and sent a few copies of reports generated that address the question.

In the sample cases, Gary had taken the Detailed Ancestor and Detailed Descendant stock reports and added the ability to include *all* images for everyone. The Detailed individual report had that functionality, but the ancestor/descendant did not.


ch-ch-ch-changes

The important changes

  1. Change the Class names to be unique. Each report has 2 classes - one for the code and one for the report. In my cases, I added a trailing ‘i’.
  2. Change the name of the report styles. This is necessary if you are using books, not absolutely required if not. For the Descendant report I changed the style prefix from DDR to DDRI, for instance. I didn’t change the Ancestor report.
  3. Update the .gpr.py registration file to point to the correct file and correct classes.

Attached are 2 samples with the old (names ending with report.py) and the new code (names ending with reporti.py) as well as the revised .gpr.py files. The old code may have had updates. The adaptation was written quite a while ago - so every diff may not be significant.

See also

Sample Report Specifications