Open main menu

Gramps β

Adapt a built-in Report

Revision as of 18:42, 8 April 2021 by Bamaustin (talk | contribs) (A reply privately shared)
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.

Contents

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 {on March 28th}, GaryG privately replied and sent a few copies of reports generated that are examples of internal reports converted to the Add-on format.

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.

Find the Report

Reports can be difficult to find int he Gramps collection of source code. There are a wide variety of report flavors: text and graphical reports, Quick Reports, reporting View modes and reporting Gramplets. And each can be built-in or be a 3rd Party Add-on.

So, the first step is to find the master copy of the module generating the report.

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.

Not yet converted...

 

Please update or expand this section.


Apart from filing a bug report and waiting a long time for someone qualified to do something about it, you will have to modify the code.

Unfortunately the Detailed Descendant and Detailed Ancestor reports are part of the main program and are not plugins.

The result of that is that you have to modify the code of the existing program, Both the ancestor and descendant report programs are to be found (Linux) /usr/lib/python3/dist-packages/gramps/plugins/textreport directory. Root permission will be required. Compare the two files, They do similar things so there should be some similarities. Look for the formatting codes (eg DAR-Title) to give some idea of what the program is printing in a given bit of code.

Oh yes, and get a book on Python programming.

Always keep a copy of the original file for when you really screw up.

When you change a file you will need to close and reopen Gramps to see the changes take effect.

Don’t be afraid to have a go, and good luck.

If you do manage to get it working, then keep a copy of your modified file, because the next Gramps update will overwrite everything that you have done.

This may come across as critical of the development team. that is not my intention. They have higher priorities than fixing things which do work well, even if some of us wished they worked differently.

See also