Where is there documentation for how addons.txt lines are generated?

Development
1

Anyone know where to find the docs on the new_addons.txt file used for managing Gramps Plugin Manager? In particular, how a new (or updated) addon is registered for inclusion? And the format spec?

And why does the file saved in the User Directory gramps51 folder have a slightly different format. (It adds spaces not found in the GitHub file. It also converts the backslashed single-quotes in strings to eliminate the backslashes and double-quotes the strings.)

Why am I asking?

It is difficult to keep the wiki documentation accessible for features in Gramps. Even when Users know the correct Feature name, the search gives WAY too many secondary hits from outdated version pages and other languages. (But at least you can change languages with a click & type the current version in the URL.) So having the feature listed identically to how hint & labels appear in the GUI is critical.

Unfortunately, most of the add-ons (particularly, Tools, Reports, Quick Reports, import/export, libraries & filter Rules) do not have a Help button. And many of those do not have a GUI element to get a rollover hint of the name. So the only way for Users to discover the name is through the Plugin Manager.

Gramps has no feature to export a list of addon names to use as a documenting checklist. (Or an exploration guide.) My assumption is that the label in the Plugin Manager (and Plugin Manager Enhanced) will always match the ‘n’ (name?) terms of each row in the new_addons.txt file. So I decided to use that instead.

Yesterday was spent harmonizing the row labels in the Addon List table to the addons-en.txt … there are still a few rows left to do.

Manual harmonization is tedious and error prone. Worse, I just realized that translators will have to repeat the same exercise. They have to harmonize the translated wiki page to match the precise translations of the translated names of their addons.

The format of the add on file is not CSV. Which means it doesn’t lend itself to import to Excel for automated verification. (It primarily uses a comma as the delimiter. But it uses a colon as a secondary delimiter. While a single quote is mostly used to enclose strings that include the delimiters, it uses double quotes if the string includes single quote! and each row has an opening & closing curly braces. ARRGH!)

I had hoped to Parse the new_addons.txt and use that to generate a pastable replacement MediaWiki table. Figuring that if I automatically created a hotlink to the ‘v’ (version) value, that would create a Red (does not exist) hyperlink in the wiki table… indicating where the documentation needed to be reviewed & updated.

But the new_addon.txt lacks a lot of stuff: Help URL,Thumbnail URL, Use audience, rating, hotlinked contact.person. Several of the .gpr.py lines correspond to the fields in the addons.txt file… but not ALL of them.

So how do these various files correlate?

2

These are the addon rows that are still outstanding:

  • Geneanet import for Gramps
  • ` 'Html View
  • MongoDB
  • Query Gramplet

AncestorFill.addon.tgz
AssociationsTool.addon.tgz
BiographyQuickview.addon.tgz
DetDescendantReport-images.addon.tgz
DoubleCousins.addon.tgz
ExportProlog.addon.tgz
ExtendedAttributes.addon.tgz
ExtendedAttributes.addon.tgz
FixCoords.addon.tgz
GenealogyTree.addon.tgz

  • Ancestor Tree
  • Descendant Tree
  • Sandclock Tree
  • Sandclock Tree for a Family

GenealogyTree.addon.tgz
GenealogyTree.addon.tgz
GenealogyTree.addon.tgz
JSON.addon.tgz

  • JSON Export
  • JSON Import

LastChange.addon.tgz
Overview.addon.tgz

  • Family Overview
  • Person Overview

RepositoriesReport.addon.tgz
RestoreHist.addon.tgz

3

This view is no more used. It was the prerequisite for the geography vievs before 4.x
The dependencies for windows are too big. it’s always usable in linux if you install the webkit package
ie (gir1.2-webkit-3.0) on ubuntu.

1 Like
4

You have the following:

gramps-project / addons

I don’t know if there is documentation for that.

5

Thank you.

There’s also the List Your Addon procedural listing in the wiki too. Both the wiki & GitHub give a placeholder style “do the following” that help with “how?” but do not touch on “why?”.

Still, with a wikipage using a WikiContributor account (as opposed to Anonymous browsing), I have a place to begin filling in. How do I suggest changes to the GitHub docs?

6

new_addosn.txt is created by the ‘plugin manager enhanced’ for its own use. This is needed in order to keep track of available addons, and to avoid having to download the Github list every time someone opens the PME. I don’t recall why I reprocessed the github file, although the same information should be in both. Looks like I use Python eval() on the github version and then write it back out as a Python dict, which probably explains the slight format changes. So that explains the quoting changes (Python rules). Note that each line is able to be processed as Python code…

The Github file is created with the ‘make’ file in the Github addons-source repo, again for the PM/PME use. This is how we prepare the ‘addons’ repo from the addons source. The original authors apparently never though they would need the Help URL,Thumbnail URL, Use audience, rating, hotlinked contact.person etc.

The make file examines the addons-source repo and processes .gpr files to create the addons tgz and listings, when one of the developers accepts PRs or otherwise wants to publish addons. Look at the make if you want to see some of the details.

P.S. If you wanted to process the addons listing (or the addons-source repo) you would probably find it easier to do in Python; the tools to get the data are pretty simple and the make file provides a nice example on how to do it.

1 Like
7

If ever changes are planned in this file and in this addon, it would be cool to add the installation date of addons in it to display these dates in the list of installed addons

1 Like
8

Thank you. That’s good to know. Having grown so addicted to the extra visibilities of the Plugin Manager Enhanced, I failed to switch back to the standard and re-evaluate. The original probably doesn’t store a copy of the addons-en.txt locally. Time to explore some more.

Perhaps you stored the tweaked file format in the new_addons.txt so there was a visual cue (and easy mechanical validation) that this was data that had already been processed?

Will go explore the make.py Python file. While slowly growing used to reading Python, I am still not spotting syntax problems. (The white space sensitivity is completely alien.)

Knowing that the make has features to generate the PO files is very intriguing. That means there might be the potential to generate multilingual ‘includes’/transclusion chunks too. The add-on.txt has a far higher percentage of correlations to the .gpr.py data than to the wiki table. (And there are definitely missing pieces.) But it is a starting point.

9

It seems like new installations & updates (noting “from” & “to” versions) to add-ons should be part of the Session Log. That way it is visible in the GUI.

Logging that info in the new_addons.txt seems overly complex with few opportunities to exploit the data be stored.

I realize that the session log is flushed aggressively. But if you had a use for this data, you could copy the data into a Note. (Like creating a ToDo Note that prompts you to ‘explore the newest lookups available in the latest WebConnect add-on’.)

11

Feedback is always nice.

I like the Idea of displaying the Version installed (which is currently only visible via the Detailed Info dialog) but both the Plugin Manager and Plugin Manager Enhanced only display info in tabulated form. You can look at the Info and copy that data… one addon at a time. There is no capacity to retain or copy data en masse except through a screen capture. And the Manager tools are fairly modal. (You have to dismiss them.) Which makes them less effective diagnostic tools. Adding more detail there might add clutter without improving clarity.

Maybe such info would be better as a static Report? Then we could copy&paste reference data into bug reports or support forums.

There has been friction about what a Plugin Manager should do and ought not to do. It got pretty heated. (To the point that development was abandoned.) So I expect the developer doesn’t want to revisit the code for minor tweaks. It would probably have to be a grand new feature with undeniable values to entice new development.

12

I never use any of this… but yes, a static report would be of use for most problem solving, just like the system reports you can get from most OS.

I install the addons and forget them until there are updates, when I see new versions, I just install them and forget them if they don’t work I delete the ones giving me problems and don’t install them again EVER.

One of the reasons is because I think any of the GUI’s for the addons have little or none user-friendliness.
But again, I use/have used Gramps for one reason alone, and that is the functionality as a registration software… but as soon as I find a more suited software, I will stop using it until there are more interchangeability in the import/export formats, so that it is possible to do analyzes on the data and get the result back to the storage without creating “15000 lines” of code in either Python or VBA, or to use 2-3 extra applications just to transcode one dataformat to another…

To be honest, personally I think there are at least 5 things that is more important than what version of a gramplet that is installed…
But if something shall be done, it should be done in a more user-friendly way.

PS. I think what you are doing with the WIKI are both really important and great…

14

For diagnostic purposes? It isn’t likely to be ever needed. (That’s a tribute to how well this portion of Gramps works.) However, as a workflow support tool, such a list might be useful more often.

Lots more often if the report also listed all the Gramplets active in the Sidebar & Bottombar… and which split bars were enabled. Slowdowns start to make a lot more sense to users when they see how many addons are actively sucking resources from the system. (For instance, I enjoy the discoveries revealed by the Deep Connections Gramplet. But it REALLY bogs down my system.)

More practically, the number of addons has grown to a point that many people just install them all. But then only only explore a few that session. Unlike forums like this that remind you of unread postings, there is no reminder of unused addons. So users fail to follow-through exploring in the next session.

Thus, an addons Report could also serve as a exploration bucketlist.

15

Yes that’s what I do. This is why I would have installation date in addons list. To know what I’ve try or not.

1 Like